String match for new worm?

[gpoer]

Does anyone have a string match that they created for the new attack which is simultaneously trying several different known IIS exploits. We tried *[/][Mm][Ss][Aa][Dd][Cc]* and it didn't alarm on anything...

If someone else has a string match that is working would they mind sharing?

thanks,

Geoff

[klwiley]

There is no need to write anything new to catch this worm in action. The following signatures will fire if you have an ogoing infection:5081, 3215, 5124, 3216, 5114. The one that I recommend you follow is the 5081 signature. All of them will fire in nearly the same quantities, but the 5081 has the most fidelity.

[gpoer]

Well I was hoping that wasn't the case... We are not seeing any hits on those signatures... at all :(

I guess we have a bigger problem!

Thanks,

Geoff

[crossmanj]

Be thankful it hasn't gotten there yet....

We're at 35,000 IIS based attacks alone - and each attacker launches 16 attacks!

This reminds me of a question I wanted to ask. What about the limitations of 1000 objects per map in the Director? Can that be bypassed? I hate getting pegged so many times like this....

[brenden]

I would like to know how to bypass the 1000 limit too! Im sick and tired of having to delete everytime 1000 is reached.

Only course is to turn off those signatures!

Brenden

[scothrel]

It is my understanding that the 1024 object limit is a limitation of HPOV and there is nothing we can do to change it. Alternative solutions, to remove the need to use HPOV, are in development.

Scott

PS: no, I don't have an ETA, but it will be worth the wait.

[marcabal]

The 1000 limit is a hard coded limit based on the number of pixels available in the window.

Refer to the 2.2.3 User's Guide:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids7/unix_cfg/advanced.htm#29043

As for the number of alarms, I would recommend downgrading their severity level to level 2 until the worm is under control. By default the level 2 alarms are logged on the director in the /usr/nr/var/log.* file, but do not show up on the OV maps, and will therefore not fill up your maps. Then you can look through the logs for those alarms instead of using the OV maps.

You could also change the AlarmThrottle for these alarms to Summarize or even Global Summarize. Refer to: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids6/13346_01.htm#xtocid228675

Other users have setup exclusions of these alarms from External addresses to Internal addresses. Since they have little they can do about external infected machines but would like to know when their internal machines are infected. This generally helps to reduce a large portion of the alarms.

[ishah]

Hi,

The 4230 might pick these signatures up but what about the IDSM which is still stuck at version 2.5

Does anyone have a signature for that ?

[klwiley]

The IDSm will also detect this worms propagation. Once again signature 5081 should be your focus as it has the most fidelity.

[jballay]

What methods are available for tuning the fidelity down? Here's what I'm looking for.... I'd like to see all the source IPs of the attacks, but only have one alert logged to the DB and event viewer.

[klwiley]

This something that we have attempted to allow by adding the Summary and Global Summary commands. Unfortunately these summarize either based on the storage type of the siganture in question (in the case of NIMDA this is the session the attack occured in) or by the signhature name. The Summary mode is basically equivalent to Fire Once in the case of a session based signature. Global summarization will not help as all source IP's will be collapsed and replaced with a zero. So unfortunately we have no way of helping you at this time.

We have encountered something here that we never expected to encounter and have learned from it. We will explore a method to improve our summary alarm aggregation so that the user hase more control over the storage method. Thank you for your input.

KLW