topic Re: TCP SYN Host Sweep at 5.1.1p1 in Network Security

TCP SYN Host Sweep at 5.1.1p1

darin.marais — Sun, 10 Mar 2019 09:55:56 GMT

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?

Re: TCP SYN Host Sweep at 5.1.1p1

wsulym — Fri, 17 Mar 2006 18:28:55 GMT

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.

Re: TCP SYN Host Sweep at 5.1.1p1

scothrel — Fri, 17 Mar 2006 21:28:59 GMT

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.

Re: TCP SYN Host Sweep at 5.1.1p1

darin.marais — Sun, 19 Mar 2006 01:09:55 GMT

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

Re: TCP SYN Host Sweep at 5.1.1p1

darin.marais — Mon, 20 Mar 2006 13:28:26 GMT

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.

Re: TCP SYN Host Sweep at 5.1.1p1

mhellman — Wed, 22 Mar 2006 15:48:15 GMT

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.

Re: TCP SYN Host Sweep at 5.1.1p1

wsulym — Wed, 22 Mar 2006 16:08:00 GMT

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).

Re: TCP SYN Host Sweep at 5.1.1p1

normalit — Thu, 23 Mar 2006 19:54:38 GMT

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

Re: TCP SYN Host Sweep at 5.1.1p1

MARK BAKER — Fri, 07 Jul 2006 12:04:12 GMT

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.

Re: TCP SYN Host Sweep at 5.1.1p1

npham — Fri, 07 Jul 2006 17:29:23 GMT

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.