Sig# 3002 TCP SYN Port Sweep for slow scan detection

[npham]

Anyone try and modify sig 3002's parameter ResetAfterIdle and notice that no matter what high value you give it, the sig does not fire with a SYN port scan delaying for more than 66 seconds?

The default value for sig 3002,

ResetAfterIdle = 20

Unique = 5

This sig will fire after >5 (must be greater than 5 as scanning 5 ports does not fire the sig) ports have been scanned, where the between port SYN attempt is no longer than 20 seconds.

Now try and tune the sig to catch a scan that delays for 2 minutes between port attempts.

ResetAfterIdle = 120

Using nmap, scan ports 1 to 6 delaying 67 seconds between attempts.

nmap -sS -v -n -P0 --scan_delay 67000 10.1.1.1 -p 1-6

The sig would not fire for me. However, with a delay of 66 seconds, it does.

nmap -sS -v -n -P0 --scan_delay 66000 10.1.1.1 -p 1-6

I ask, Bug?

[nikhil_m]

Any update on this ?

[craiwill]

I'd like to reproduce your problem here in our lab so I can to get a little better insight into what's going on. I'll need a little more information though. What version of hardware and software are you trying this on? Also, what does your test network look like? Are you trying this on a closed quiet network with no other traffic, is this sensor seeing real world traffic while you attempt this, etc...

The more scenario information you can provide, the better.

[npham]

Reproduced on a 4250XL, and 4250SX. Running 4.1(4)S94. Same situation occurred on a sensor with moderate real-world traffic, and a sensor seeing minimal traffic.

We do not have a spare sensor to conduct thorough testing in a lab. We recently started using the new 4.x codebase and I've been slowly working my way through the Cisco signatures tuning them on our networks. Just finding anomolies with the product. Some I'm able to work around, others I need you guys to fix. ;-)

[craiwill]

We are currently trying to replicate this situation in the lab but have yet to experience this problem. We will continue to investigate this.