Re: [pf] Re: Weird behaviour with pass out _keep state_
On Fri, Mar 13, 2009 at 10:15:06AM +, Stuart Henderson wrote: On 2009/03/13 10:25, Jeremie Le Hen wrote: It doesn't seem to be possible to disable sequence number/window tracking. Does it? It's possible if you port the sloppy state handling code from OpenBSD.. Using 'sloppy' is a bad idea, and not recommended unless you really, reallly know what you are doing. If you think you need to use it, you are most likely wrong and have either a bad network design or broken software. Fix those instead. I would only consider using 'sloppy' if BOTH of the following are true: a) There is a compelling performance or network architecture reason for doing so, such as asymetric routing or relayd with 'direct server return'. Avoid these if you can. b) All boxes which recieve TCP connections through these 'sloppy' rules are running OpenBSD -current or supported -stable; or there are additional layers of firewall further in on your network which don't use 'sloppy'.
Re: [pf] Re: Weird behaviour with pass out _keep state_
Daniel, On Thu, Mar 12, 2009 at 04:01:38PM +0100, Daniel Hartmeier wrote: The following scenario would produce what you observe: 1) nmap sends a first TCP SYN to AAA.BBB.CCC.DDD with a random initial sequence number th_seq1 2) pf allows the packet out and creates a state entry (check with pfctl -vvss) 3) the external host is down or doesn't respond to the TCP SYN at all 4) nmap times out waiting for a response, retries sending the probe (see nmap --max-retries) 5) nmap crafts a second TCP SYN to AAA.BBB.CCC.DDD, but unwisely chooses another initial sequence number th_seq2 != th_seq1 6) the packet matches the state entry in pf, but the sequence number is completely off, hence pf blocks the packet 7) when a local socket's outgoing packet is blocked by pf, the syscall gets errno No route to host I should have said that the very first sendto(2) fails. No timeout. Try running nmap with -vv, maybe it shows what it's trying to do. Also enable verbose logging (pfctl -x misc) and check /var/log/messages for BAD state entries, which come with sequence number mismatches. Here is what the kernel says (sorry for non line wrap): % Mar 13 08:18:52 yoda /netbsd: pf: BAD state: TCP 82.233.239.98:39225 82.233.239.98:39225 88.187.38.85:80 [lo=3443494040 high=3443494041 win=2048 modulator=0] [lo=0 high=1 win=1 modulator=0] 2:0 S seq=3041360721 ack=0 len=0 ackskew=0 pkts=1:0 dir=out,fwd M% ar 13 08:18:52 yoda /netbsd: pf: State failure on: 2 | 6 According to the source, I'd say that Nmap doesn't forge the packet with coherent window regarding its sequence number. Am I right? % printf(pf: State failure on: %c %c %c %c | %c %c\n, % SEQ_GEQ(src-seqhi, end) ? ' ' : '1', % SEQ_GEQ(seq, src-seqlo - (dst-max_win dws)) ? % ' ': '2', % (ackskew = -MAXACKWINDOW) ? ' ' : '3', % (ackskew = (MAXACKWINDOW sws)) ? ' ' : '4', % SEQ_GEQ(src-seqhi + MAXACKWINDOW, end) ?' ' :'5', % SEQ_GEQ(seq, src-seqlo - MAXACKWINDOW) ?' ' :'6'); It doesn't seem to be possible to disable sequence number/window tracking. Does it? Also, in my previous email I described an unexpected behaviour in my own understanding. When I disable state tracking, legitimate outward connections still work. The SYN packet is obviously allowed to leave, but pf doesn't record the connection state so the SYN/ACK response should be dropped. this doesn't seem to be the case as the box doesn't turn deaf :). Explanation? Thank you very much. Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org
Re: [pf] Re: Weird behaviour with pass out _keep state_
On 2009/03/13 10:25, Jeremie Le Hen wrote: It doesn't seem to be possible to disable sequence number/window tracking. Does it? It's possible if you port the sloppy state handling code from OpenBSD..
Re: [pf] Re: Weird behaviour with pass out _keep state_
On Fri, Mar 13, 2009 at 10:25:15AM +0100, Jeremie Le Hen wrote: % Mar 13 08:18:52 yoda /netbsd: pf: BAD state: TCP 82.233.239.98:39225 82.233.239.98:39225 88.187.38.85:80 [lo=3443494040 high=3443494041 win=2048 modulator=0] [lo=0 high=1 win=1 modulator=0] 2:0 S seq=3041360721 ack=0 len=0 ackskew=0 pkts=1:0 dir=out,fwd M% ar 13 08:18:52 yoda /netbsd: pf: State failure on: 2 | 6 This message means there already is a state entry for a connection from 82.233.239.98:39225 to 88.187.38.85:80. There must have been some outgoing packet that created the state entry. If it wasn't from nmap, what else was it from? If it was from nmap, obviously what has failed wasn't the FIRST sendto()... Also, in my previous email I described an unexpected behaviour in my own understanding. When I disable state tracking, legitimate outward connections still work. The SYN packet is obviously allowed to leave, but pf doesn't record the connection state so the SYN/ACK response should be dropped. this doesn't seem to be the case as the box doesn't turn deaf :). Explanation? You have to look at your entire ruleset, not just the 'pass out' rule. Either you don't have a generic block rule (default deny policy), or you have another 'pass in' rule which matches the return packets. If a packet doesn't match ANY rule in your ruleset, it will pass. Daniel
