nmap oddity

:hello:

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.

Quote:

---

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

---

Quote:

---

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?

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.

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.

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

Quote:

---

[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

---

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?

Quote:

---

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?

Quote:

---

Originally posted here by cacosapo
syncookies perhaps?

---

That might actualy be it !!

I'll check some out tonight..

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?

From the man page

Quote:

---

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
:cool:

Quote:

---

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.

Soda, what does your Ethereal capture filter look like? I see 2 SYN packets used with T1 & T5.

--TH13

I haven't been touching the filters, and only 3 packets were sent during the T1 scan. SYN - SYN/ACK - RST. The T5 scan makes 6 packets.

I haven't seen T1 send 2 SYNS right off the bat yet. Only T1 has been doing that.

Hey Hey,

I'm seeing a single SYN on each one... then a SYN ACK back.. and then the RST...

Here are the packet captures I did.. named for the various commands that I ran.... You can compare them with yours if you so desire.

Peace,
HT

I should been a little more clear...

Each test yielded 1 SYN (total of 2) for each test. In other words, I had the same results as HTRegz.

This gets me thinking that perhaps the packet capture library version may have something to do with the varied results people are seeing. No proof yet but some testing could eliminate or validate the theory...

I'm seeing the same thing as HTRegz and th13. No matter what I do to the timing only one SYN is sent out.

The only thing I can find that will allow you to send two SYN packets is using the -PS option in addition to the standard -p option.
-PS sends a TCP SYN ping to a specified port.