Kernel problem handling SYN-ACK packets

[Dave Jones <dave_jones_314 () yahoo com>]

Hi,

I am observing what appears to be a kernel problem
related to making TCP connections. I am using nmap in
connect scan mode for bulk scanning. Nmap 3.30, SuSE
Linux kernel 2.4.21-199-default. Problems observed on
both Intel and AMD systems - all fairly powerful (at
least P3 1ghz, 384mb RAM) - using a variety of network
cards (mostly Intel and 3COM). I noticed that nmap
would sometimes miss ports that were open. Here is a
trace of the problem happening:

delores:/var/tcpdump # tcpdump -nvr dump.pcap5 'host
4.3.2.1 and port 80 and 51706'
12:33:14.470823 1.2.3.4.51706 > 4.3.2.1.80: S [tcp sum
ok] 996359288:996359288(0) win 5840 <mss
1460,sackOK,timestamp 2228534500 0,nop,wscale 0> (DF)
(ttl 64, id 57666, len 60)
12:33:14.488980 4.3.2.1.80 > 1.2.3.4.51706: S [tcp sum
ok] 458278202:458278202(0) ack 996359289 win 5792 <mss
1460,sackOK,timestamp 3179934702 2228534500,nop,wscale
0> (DF) (ttl 52, id 0, len 60)
12:33:14.489072 1.2.3.4.51706 > 4.3.2.1.80: R [tcp sum
ok] 996359289:996359289(0) win 0 (DF) (ttl 64, id
37620, len 40)
12:33:17.470637 1.2.3.4.51706 > 4.3.2.1.80: S [tcp sum
ok] 996359288:996359288(0) win 5840 <mss
1460,sackOK,timestamp 2228537500 0,nop,wscale 0> (DF)
(ttl 64, id 58213, len 60)
12:33:17.488135 4.3.2.1.80 > 1.2.3.4.51706: S [tcp sum
ok] 461277814:461277814(0) ack 996359289 win 5792 <mss
1460,sackOK,timestamp 3179935002 2228537500,nop,wscale
0> (DF) (ttl 52, id 0, len 60)
12:33:17.488211 1.2.3.4.51706 > 4.3.2.1.80: R [tcp sum
ok] 996359289:996359289(0) win 0 (DF) (ttl 64, id
38025, len 40)
12:33:23.470559 1.2.3.4.51706 > 4.3.2.1.80: S [tcp sum
ok] 996359288:996359288(0) win 5840 <mss
1460,sackOK,timestamp 2228543500 0,nop,wscale 0> (DF)
(ttl 64, id 59295, len 60)
12:33:23.489036 4.3.2.1.80 > 1.2.3.4.51706: S [tcp sum
ok] 467277032:467277032(0) ack 996359289 win 5792 <mss
1460,sackOK,timestamp 3179935601 2228543500,nop,wscale
0> (DF) (ttl 52, id 0, len 60)
12:33:23.489097 1.2.3.4.51706 > 4.3.2.1.80: R [tcp sum
ok] 996359289:996359289(0) win 0 (DF) (ttl 64, id
38732, len 40)

The trace is selective output of tcpdump -nv, with the
IP addresses anonymised. For comparison, here is the
trace of a successful probe:

13:58:47.956914 1.2.3.4.43716 > 4.3.2.1.80: S
4204540905:4204540905(0) win 5840 <mss
1460,sackOK,timestamp 2954223574 0,nop,wscale 0> (DF)
13:58:47.957048 4.3.2.1.80 > 1.2.3.4.43716: S
3208365450:3208365450(0) ack 4204540906 win 5792 <mss
1460,sackOK,timestamp 295445296 2954223574,nop,wscale
0> (DF)
13:58:47.957070 1.2.3.4.43716 > 4.3.2.1.80: . ack 1
win 5840 <nop,nop,timestamp 2954223574 295445296> (DF)
13:58:47.957334 1.2.3.4.43716 > 4.3.2.1.80: R 1:1(0)
ack 1 win 5840 <nop,nop,timestamp 2954223574
295445296> (DF)

When nmap calls connect() to open the connection, the
kernel sends a SYN. The remote host responds with a
SYN-ACK. The kernel responds with an ACK to complete
the threeway handshake. The kernel returns the socket
connected; nmap immediately closes this so the kernel
sends a RST.

However, in the first trace the kernel is responding
to the SYN-ACK incorrectly - by sending a RST instead
of an ACK. The kernel then retries the SYN 3s later,
then 6s after that. Each time the remote host
correctly responds with SYN-ACK, but the kernel
incorrectly responding with a RST.

In some cases this has caused nmap to completely miss
a port. However, nmap attempts several connect() calls
so most the time the port is detected. It is difficult
to see from the packet trace exactly how often this is
happening. It is quite rare - maybe happens once for
every 10 full 64k port scans.

Has anyone seen this before? What can I do to stop it
happening?

Any help much appreciated,

Dave


                
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List archive: http://seclists.org