RE: stucked connection (missing rst??)
Hi! Thank you for the quick answer! I have tried what you said, and I experienced that, when pf was not enabled, then everything went fine (I couldn't see any connection in TIME_WAIT state with netstat -n (I think the state was removed pretty fast). Could you explain to me, why this happened? 2 consecutive hping test give the following results with pf and without pf(hping -c 1 -s 60002 -S -p 22 1.2.3.4) (destination was my openbsd's ssh port) Without PF: hping -c 1 -s 60002 -S -p 22 1.2.3.4 14:18:08.729160 00:0c:f1:6b:31:d9 00:e0:18:c4:b7:68, ethertype IPv4 (0x0800), length 54: IP 1.2.3.5.60002 1.2.3.4.22: S 1101736515:1101736515(0) win 512 14:18:08.729449 00:e0:18:c4:b7:68 00:0c:f1:6b:31:d9, ethertype IPv4 (0x0800), length 60: IP 1.2.3.4.22 1.2.3.5.60002: S 4118501604:4118501604(0) ack 1101736516 win 16384 mss 1460 14:18:08.729458 00:0c:f1:6b:31:d9 00:e0:18:c4:b7:68, ethertype IPv4 (0x0800), length 54: IP 1.2.3.5.60002 1.2.3.4.22: R 1101736516:1101736516(0) win 0 hping -c 1 -s 60002 -S -p 22 1.2.3.4 14:18:10.247320 00:0c:f1:6b:31:d9 00:e0:18:c4:b7:68, ethertype IPv4 (0x0800), length 54: IP 1.2.3.5.60002 1.2.3.4.22: S 1568181478:1568181478(0) win 512 14:18:10.247565 00:e0:18:c4:b7:68 00:0c:f1:6b:31:d9, ethertype IPv4 (0x0800), length 60: IP 1.2.3.4.22 1.2.3.5.60002: S 2956670909:2956670909(0) ack 1568181479 win 16384 mss 1460 14:18:10.247574 00:0c:f1:6b:31:d9 00:e0:18:c4:b7:68, ethertype IPv4 (0x0800), length 54: IP 1.2.3.5.60002 1.2.3.4.22: R 1568181479:1568181479(0) win 0 With PF: hping -c 1 -s 60002 -S -p 22 1.2.3.4 14:16:48.379903 00:0c:f1:6b:31:d9 00:e0:18:c4:b7:68, ethertype IPv4 (0x0800), length 54: IP 1.2.3.5.60002 1.2.3.4.22: S 1809653489:1809653489(0) win 512 14:16:48.381907 00:e0:18:c4:b7:68 00:0c:f1:6b:31:d9, ethertype IPv4 (0x0800), length 60: IP 1.2.3.4.22 1.2.3.5.60002: S 3965240421:3965240421(0) ack 1809653490 win 16384 mss 1460 14:16:48.381918 00:0c:f1:6b:31:d9 00:e0:18:c4:b7:68, ethertype IPv4 (0x0800), length 54: IP 1.2.3.5.60002 1.2.3.4.22: R 1809653490:1809653490(0) win 0 hping -c 1 -s 60002 -S -p 22 1.2.3.4 14:16:49.545931 00:0c:f1:6b:31:d9 00:e0:18:c4:b7:68, ethertype IPv4 (0x0800), length 54: IP 1.2.3.5.60002 1.2.3.4.22: S 432383509:432383509(0) win 512 Thank you for your help! Tamas -Original Message- From: Daniel Hartmeier [mailto:[EMAIL PROTECTED] Sent: 2005. december 12. 16:31 To: Németh Tamás Cc: pf@benzedrine.cx Subject: Re: stucked connection (missing rst??) On Mon, Dec 12, 2005 at 03:56:18PM +0100, Németh Tamás wrote: Is this communication invalid? Is it against rfc? Yes, it violates the TCP RFC 793, see sections Knowing When to Keep Quiet and The TCP Quiet Time Concept starting on page 27 of http://www.faqs.org/rfcs/rfc793.html The concept of the quiet period is not specific to pf, but to TCP in general. Even if you'd disable pf, you'd most likely notice that your second hping SYN would not elicit a second SYN+ACK from the recipient, as the recipient's TCP/IP stack also keeps a record of the first (reset) connection with a TIME_WAIT (or CLOSED) state (try netstat -n on the recipient). Daniel smime.p7s Description: S/MIME cryptographic signature
Re: stucked connection (missing rst??)
On Tue, Dec 13, 2005 at 03:12:12PM +0100, Németh Tamás wrote: I have tried what you said, and I experienced that, when pf was not enabled, then everything went fine (I couldn't see any connection in TIME_WAIT state with netstat -n (I think the state was removed pretty fast). Could you explain to me, why this happened? Ah, you're not actually completing the handshake, but sending the RST instead of the the ACK. I guess the recipient stack immediately purges the TCP control block in that case. I'm not sure if this is strictly following the TCP RFC or just an optimization to safe memory during SYN floods. Either way, pf will still keep the state around until the default timeout has expired. If you don't like that, you can reduce the timeout (pfctl -st) to expire the state earlier. The client is clearly misbehaving in your case (re-using the address/port quadruple before the MSL quiet period has passed). Sending a SYN without the intention of completing the handshake is a cute trick at best (and an attack at worst), and you can't expect an uptime probe to work like that, in general. :) Daniel
Re: stucked connection (missing rst??)
On Tue, Dec 13, 2005 at 03:12:12PM +0100, Németh Tamás wrote: With PF: hping -c 1 -s 60002 -S -p 22 1.2.3.4 14:16:48.379903 00:0c:f1:6b:31:d9 00:e0:18:c4:b7:68, ethertype IPv4 (0x0800), length 54: IP 1.2.3.5.60002 1.2.3.4.22: S 1809653489:1809653489(0) win 512 14:16:48.381907 00:e0:18:c4:b7:68 00:0c:f1:6b:31:d9, ethertype IPv4 (0x0800), length 60: IP 1.2.3.4.22 1.2.3.5.60002: S 3965240421:3965240421(0) ack 1809653490 win 16384 mss 1460 14:16:48.381918 00:0c:f1:6b:31:d9 00:e0:18:c4:b7:68, ethertype IPv4 (0x0800), length 54: IP 1.2.3.5.60002 1.2.3.4.22: R 1809653490:1809653490(0) win 0 hping -c 1 -s 60002 -S -p 22 1.2.3.4 14:16:49.545931 00:0c:f1:6b:31:d9 00:e0:18:c4:b7:68, ethertype IPv4 (0x0800), length 54: IP 1.2.3.5.60002 1.2.3.4.22: S 432383509:432383509(0) win 512 Try hping -M to use a constant initial sequence number (ISN) across both invokations, then it should work. If invokations are not expected to be several seconds apart, you probably don't want pf to purge the state in between. Insertion and removal of state entries is costly, if you set pf up to insert a state for every single SYN and remove one for every single RST, you're exposing yourself to a DoS attack where an attacker floods you with SYNs and RSTs like that. Daniel
Re: stucked connection (missing rst??)
On 12/13/05, Daniel Hartmeier [EMAIL PROTECTED] wrote: Insertion and removal of state entries is costly, if you set pf up to insert a state for every single SYN and remove one for every single RST, you're exposing yourself to a DoS attack where an attacker floods you with SYNs and RSTs like that. This reminds me, one company I worked for got SYN flooded, and thus started dropping SYNs. So they enabled Linux SYN cookies, which involve an MD5 computation for each SYN it receives, and that succeeded in making the machines completely unresponsive, even to traffic on other ports like TCP/22. Apparently it's a bad idea to compute MD5 in kernel space on old Linux kernels (non-preemptible) for every SYN you receive. -- http://www.lightconsulting.com/~travis/ -- P=NP if (P=0 or N=1) My love for mathematics is like 1/x as x approaches 0. GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Missing something obvious about NAT (openbsd/pf)....?
Subject says it. I'm trying to bring up a new firewall with OpenBSD 3.8
+ pf to replace the aging Linux one here, and something is not clicking
for me between the ears. Right now all I'm trying to do is get NATing
working between the internal network and the internet, but I'm not even
getting that far. For some reason my initial nat pass rules never
kick off and the default block rule snarfs the return packets coming
back from the net. At least that's what tcpdump seems to be trying to
tell me
Setup is simple: internal net with static IPs at 192.168.0.x, external
link to the internet with a single static IP. Firewall has xl0 at the
net and xl1 on the internal net at 192.168.0.128. Working backwards,
here's what I'm seeing from tcpdump when I try to make a simple HTTP
request from the internal net and get a reply back:
#tcpdump -n -e -ttt -i pflog 0
tcpdump : listening on pflog, link-type PFLOG
Dec 13 12:41:02.4133 rule 20/(match) block out on xl1: 64.33.534.90.80
192.168.0.129.1110: [|tcp]
etc...
Here's the (simplified) pf.conf:
ext_if = xl0
good_if = xl1
ext_ip0 = 64.81.173.10
ext_ip1 = 64.81.173.11
good_net = 192.168.0.128/26
good_gw = 192.168.0.128
table firewall_ips const { $good_gw, $ext_all }
# policies / runtime options
set loginterface $good_if
set debug loud
set state-policy if-bound
# scrub
scrub in on $ext_if all
# Rule 1 (NAT) translate source address for outgoing connections
nat pass on $ext_if proto {tcp udp icmp} from $good_net to any -
$ext_ip0
# antispoof
pass quick on lo0 all label pass any-loopback
antispoof log quick for { $good_if $ext_if } inet label block
antispoof
# Rule 1.5 get stuff in to the firewall for NATing
pass in quick on $good_if inet from $good_net to any
# Rule 2 (global) All other attempts to connect to the firewall itself
from other than the good network are denied and logged.
block in log quick inet from any to firewall_ips label block in
other-fw_any
# Rule 7 (global) Provide for outgoing traffic
pass out quick on $ext_if proto tcp all modulate state flags S/SA label
pass out ext
pass out quick on $ext_if proto { udp icmp } all keep state label pass
out ext
pass out quick on $good_if proto tcp from any to $good_net modulate
state flags S/SA label pass out good
pass out quick on $good_if proto udp from any to $good_net keep state
label pass out good
# Rule 99 (global) Anything that falls through is denied and logged.
block in log quick inet all label block in (default)
block out log quick inet all label block out (default)
-
BTW, the rule 20 referred to in the tcpdump is the final block out
rule.
I actually don't know why I even need the rule #7 rules at all - I
would have expected the nat pass to have taken care of the outgoing
NATable traffic. Regardless, now that they're there, I can't understand
why they're getting evaluated (I can see this from pfctl -sa) but not
catching the return traffic, and letting it fall through to the default
block rule.
So, again, I think I'm missing something basic here. Help?
thanks ---jon---
Re: Missing something obvious about NAT (openbsd/pf)....?
On Tue, Dec 13, 2005 at 01:22:48PM -0800, Jonathan Rogers wrote: # Rule 1.5 get stuff in to the firewall for NATing pass in quick on $good_if inet from $good_net to any Add 'keep state' to the above rule, so it reads pass in quick on $good_if inet from $good_net to any keep state otherwise the replies are blocked when they try to go out through the internal interface. The state created on the external interface by the nat rule does not cover the packets on the internal interface. So you actually need to create two separate state entries per connection, one incoming on the internal interface (without translation) and one outgoing on the external interface (with nat). Another approach is to skip filtering on the internal interface alltogether, using pass quick on $good_if or, better, set skip on $good_if. Daniel
Re: Missing something obvious about NAT (openbsd/pf)....?
Daniel: A _lot_ just fell into place that wasn't connecting before. Thanks for providing the missing linknot to mention for pf itself. Much, much appreciated. -Jon-
