TCP SYN Host Sweep at 5.1.1p1

[darin.marais]

With SecMon 2.2, the TCP SYN Host Sweep (3030.0) fails to display the victim’s port in the console. The console shows <n/a> in the port field. The sensors are at version 5.1.1p1. The command “Show Events Alert Info” on the sensor reveals that the destination port is not capture by the sensor event.

upgrade history of the sensor:

* IPS-sig-S221-minreq-5.0-5

IPS-K9-patch-5.1-1p1.pkg

Is there a reason for no longer capturing the destination porton this signature?

[wsulym]

Was it capturing the port information *prior* to p1 or the last update applied? I'm just trying to get a grasp on if this is an issue with an update or maybe you just noticed it now and are wondering about how/why it disaplys what it does.

[scothrel]

The reason it does not show an IP address is that a host sweep, by definition, hits a bunch of hosts. I believe the raw alarm has 0.0.0.0 as the ip address; sounds like SecMon is changing this to n/a (correctly I would say).

I don't remember this alarm ever displaying all of the destination IPs.

[darin.marais]

i dont have a problem with the destination ip address, its the destination port that is not displayed. i can understand not having all of the destination hosts as this may be summerised but the destination port should remain constant across all of the hosts>>>

[darin.marais]

looks like i have the answer to my own question:

the answer is to modify the signature "storage key" to "attacker address and victim port". the default is only attackers address.

[wsulym]

It actually goes a little bit further than that, changing the storage key changes the behavior somewhat.

The 5.x sweep engine provides coverage for the following types of sweeps:

Host (Axxx)

Port (AxBx)

Service (Axxb)

If you change the 'storage-key' (NOT summary-key) from Axxx to Axxb the sigs will change behavior from a "host sweep" to a "service sweep". So more than just changing what the alert reports, you are also changing the sweep trigger.

Your change may be okay if that is the desired behavior.

Note that a service sweep will typically fire less than a host sweep because it is more restrictive (i.e. only counts unique on a specific port instead of any port).

[npham]

I noticed the same thing between our sensors running v4.1(5)S201 against our v5.1(1e)S237 sensors. The v4 sensors do store the victim port number.

Checking sig 3030 on the v4 sensor, the storage-key is indeed Axxb.

[normalit]

Is this ICMP traffic? If it's an ICMP packet then the port destination will be displayed as 0.

It will look like this:

192.168.1.1/0

[mhellman]

I'm not sure it ever did capture the port. See my post from back in October:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Security&topic=Intrusion%20Prevention%20Systems/IDS&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.1dd99469

Somebody from Cisco tried to explain it to me...but it doesn't make a lot of sense. Cisco did update the MySDN information to only say:

"This signature fires when a series of TCP SYN packets have been sent from one single host to a number of different hosts. This could, for example, be an attempt to map the network..."

I'm not sure about SecMon, but the Cisco Event Viewer NSDB copies do not match MySDN. This is unfortunate because MySDN is a pain to use.

[MARK BAKER]

This signature had me checking access-lists trying to figure out how TCP port 0 was getting to the hosts in the alert.

I agree that with the description of the signature that the port would be known and displayable.

FYI...CS-MARS displays the port as TCP/0 as well.