03-17-2006 07:16 AM - edited 03-10-2019 01:55 AM
With SecMon 2.2, the TCP SYN Host Sweep (3030.0) fails to display the victims 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?
03-17-2006 10:28 AM
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.
03-17-2006 01:28 PM
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.
03-18-2006 05:09 PM
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>>>
03-20-2006 05:28 AM
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.
03-22-2006 08:08 AM
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).
07-07-2006 10:29 AM
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.
03-23-2006 11:54 AM
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
03-22-2006 07:48 AM
I'm not sure it ever did capture the port. See my post from back in October:
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.
07-07-2006 05:04 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: