nmap oddity

[Soda_Popinsky]

Can someone explain to me how the -T parameter makes any difference when scanning one port? In this case, -T1 reveals a port where -T5 doesn't.

C:\Documents and Settings\soda>nmap xxxxxx -P0 -T1 -p 4531

Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-07-04 11:13 Central
Daylight Time
Interesting ports on xxxx (xxxx):
PORT STATE SERVICE
4531/tcp open unknown

Nmap finished: 1 IP address (1 host up) scanned in 15.875 seconds

C:\Documents and Settings\soda>nmap xxxxxx -P0 -T5 -p 4531

Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-07-04 11:13 Central
Daylight Time
Interesting ports on xxxxxx (xxxxx):
PORT STATE SERVICE
4531/tcp filtered unknown

Nmap finished: 1 IP address (1 host up) scanned in 0.953 seconds

C:\Documents and Settings\soda>

I'm scanning an Astaro distro, IPtables firewall I believe. The open port is a webadmin interface. I've always believed the -T option spread the scan over a period of time. The SYN should be a single packet, it wouldn't really be changed in any way by -T, right? The rate of SYN's being sent out should be changed, which is what I thought (making this confusing)

15 seconds versus .9 seconds to send out one packet makes a difference?

[Soda_Popinsky]

So I'm sniffing it out, and the main difference is that -T1 sends a single SYN, which is returned by SYN/ACK and responded to by RST.

-T5 Sent out 2 SYN's to that port immediately, both were followed up with SYN/ACKs (open), yet nmap says they're filtered.

I'm trying this against other ports/boxes but I'm not getting the same results. I'm just confused, that's all.

[Tiger Shark]

Sounds like a bug to me. You might want to skim the nmap users stuff and see if it has been mentioned and then report it if it hasn't. Any returning SYN/ACK should trigger an open result.

[mmkhan]

Hi all,
i checked the both commands but they are working fine for me.

[root@testm]# nmap -P0 xxx.xxx.xxx.xxx -T1 -p 5555

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-04 15:09 Central
Interesting ports on xxx (xxx.xxx.xxx.xxx):
PORT STATE SERVICE
5555/tcp open squid-http


Nmap finished: 1 IP address (1 host up) scanned in 15.518 seconds
[root@testm]# nmap -P0 xxx.xxx.xxx.xxx -T5 -p 5555

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-04 15:10 Central
Interesting ports on xxx (xxx.xxx.xxx.xxx):
PORT STATE SERVICE
5555/tcp open squid-http

Nmap finished: 1 IP address (1 host up) scanned in 0.447 seconds

[SirDice]

First off: I know nothing about IPTables

Perhaps this is some sort of anti-DoS setting? A couple of SYNs in a short period might trigger some delay.. This delay could be enough for nmap to think the port is filtered?

[cacosapo]

Originally posted here by SirDice
First off: I know nothing about IPTables

Perhaps this is some sort of anti-DoS setting? A couple of SYNs in a short period might trigger some delay.. This delay could be enough for nmap to think the port is filtered?

syncookies perhaps?

[the_JinX]

Originally posted here by cacosapo
syncookies perhaps?

That might actualy be it !!

I'll check some out tonight..

[Soda_Popinsky]

I've tried this on many other systems and ports without the same behavior. It's really looking like just a bug to me. Any more ideas on what could have set it off?

On -T5, it took 1.4 seconds (does the time column in ethereal represent seconds?) for the first syn/ack to respond to the first syn, 1.2 for the second syn/ack.

On -T1 it took .7 seconds to respond to it. I think the double SYN's from -T5 may have made it delay, possibly syncookies or some other TCP stack protection delayed it enough where nmap couldn't read it?

Does the -T5 option send out multiple syn's per port for you too? Is that normal and expected?

[rcgreen]

From the man page

Insane is
only suitable for very fast networks or where you
don't mind losing some information. It times out
hosts in 75 seconds and only waits 0.3 seconds for
individual probes. It does allow for very quick
network sweeps though .

T5==insane

[Soda_Popinsky]

where you don’t mind losing some information

That would explain the miss, but why does it send two SYN's? Shouldn't that slow down the scan (defeating the purpose)? It looks like that setting sending two packets instead of 1 is the only reason -T5 didn't pick it up. Which is bad, unless there's a reason for it sending two SYN's at once.