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 >
