MARS - Unable to filter events to port 0

[b.carbery]

I get a lot of 'TCP SYN Host Sweep On Same Dest Port' events on my network that I want to filter out. All the events with destination port 0 are false positives since this is normal behaviour for many operating systems when starting a connection.

Unfortunately MARS does not allow me to filter these events since in the 'Tune' section a match destination port '0' is interpreted as match 'any'.

Has anyone else had this problem or is there a workaround?

I get literally thousands of these a day on a moderate sized network (2 class Bs)

[chris_stokes]

The default settings for the IPS Sig 3030 TCP SYN Sweep on same Dest Port will fire with a destination port of 0. I would recommended tuning the IPS signature on the sensor itself to start displaying the destination port before you start tuning out this signature on the MARS. On the 3030 sig on the sensor you should edit the following fields

Modify

1. Storage Key to "Attacker address and victim port"

2. Specify Port Range to "Yes"

3. Port Range "1-65535"

Once you do this you should be able to start recieving the true destination ports that are being targeted in the sweep.

[randytoni]

Hi Chris - saw this thread while looking for some info on IDS issues - question - if we tweak the IDS signature can i assume we'll lose this on the next signature update? if so, is there a way to permanently change this attribute?

thanks

-randy

[mhellman]

You should not lose the setting. Any customizations you make are saved into another file. Any changes Cisco makes go into a default configuration file. When the two are merged, your configuration values will overwrite the default values.

[randytoni]

great - thanks for the help

[marcabal]

User configurations are stored separately from the default settings from the signatures.

This allows us to change the default settings for the signature while still maintaining any tunings made by the user.

So user tunings Should be maintained across signature updates, engine updates, major updates, minor updates, service packs, and patches.

So any fields you modified will stay modified after the upgrade while other fields within that signature may be changed.

I say Should because we make every attempt to maintain the tunings during the upgrade, but just like any piece of software there could be a software bug that might prevent that from working. So it is always good to backup your configuration before applying an update.

But understand that there are also other file types than those listed above that do NOT attempt to maintain configuration. These are System Image files and Recovery Image files (Recovery keeps only a few configurations like IP, gateway, and hostname which are needed for remote connectivity). These files reformat the harddrive or compact flash before installation so user tunings will be lost. Because of the loss of tunings, these file types should NOT be used for standard upgrades. These file types should only be used when doing disaster recovery or trying to get the system back to manufacturing defaults.

When doing upgrades then signature updates, engine updates, major upgrades, minor upgrades, or service packs shoudl be used for doing the upgrade.

[randytoni]

Thanks for the additional info

Follow-up question - Why would the default setting for the "TCP SYN Host Sweep On Same Dest Port" be set to report destination port as "0" as opposed to the actaul dest port? Is there some reason this is not set to parse the true dest port by default? Wondering if changing the default would create any kind of operational concern on the IDS...?

Thanks again

Randy

[#8]

Regarding the "destination port '0' is interpreted as match 'any'" remark. I have also found this to be true and reported it multiple times to my sales rep. I think I am going to have top open a TAC case, because I don't think anyone has looked into the issue.

One workaround I figured out was to enter '00' instead of '0' into the tuning wizard. It seems the parser accepts this, although they might fix this "feature" in future releases.

--john