w32.conficker.worm - detection and blocking with a IPS 4235

[dslocombe]

We have an IPS 4235 system with IPS-K9-5.1-8-E3 Engine and sig file IPS-sig-s368-reg-E3 in fron of our Firewall. We also (unfortunately) have the w32.conficker worm which is causing a DDOS and flooding the network with TCP 445 traffic. We are trying to set up the IPS to block this traffic before it hits our Firewall so that we can restore external WAN links.

The IPS system sucessfully detects this 445 traffic as signature ID 1302 and fills the event log, but even though we have enabled "deny connection inline" in the "signature configuration" - it still does not seem to block the 445 traffic. Has anyone seen this before, and could they advise us on how to effectively block this traffic?

[jon.humphries]

Hi,

Is the IPS configured as an inline or promisc ?

At a guess it is matching Sig. 1302 due to the amount of TCP syn's it is sending looking for other hosts to infect.

I think you should look at customizing a signature based upon attributes unique to the signature. Then depending on the IPS topology decided whether to deny inline or block connection on perimeter devices.

Alternatively if promisc mode you could send TCP reset.

HTH

Jon Humphries

Nextiraone UK

[dslocombe]

Thanks Jon,

The IPS is configured in line - and yes it does detect on Sig. 1302. We are not sure how we could customise a signature as we do not understand the attack attribute (apart from port 445 to random IP addresses). WE have tried setting the signature to "Deny in line" i.e. act like a filter - but it does not seem to work???

[mdreelan]

Did you turn on the other "deny" options? TCPReset, etc.?

[dslocombe]

Yes we have "Deny Attacker In Line", "Deny Attacker Service Pair InLine", "Deny Attacker Victim Pair Inline", "Deny Connection InLine", Deny Packet InLine", but we are still seeing 445 worm tarffic on the outside interface......

[mdreelan]

Can you confirm this interface is (1) being monitored correctly? Is this a new configuration?

[attmidsteam]

Have you tried 'deny attacker inline' as the action on the signature?

What does 'sh stat denied-attackers' provide for details?

[dslocombe]

this didn't give us any denied attackers (see below);

NWWIDS1# sh stat denied-attackers

Denied Attackers and hit count for each.

Statistics for Virtual Sensor vs0

Denied Attackers with percent denied and hit count for each.

NWWIDS1#

[dslocombe]

We've tried all the deny options, how'ever we think the problem is that the W32Conficker worm / virus signature does not seem to be included in S368, as a result the IDS just picks up the TCP timeout and not the worm.

[jon.humphries]

Hi,

Regardless of what the Signature fire's on you should still be able to set an action.

I could set it to fire on receiving any tcp syn and request a deny attack inline. If it is not working then I would question the configuration not the signature attribute.

A google search found this information regarding the worm. It seems to download a file via a random HTTP port. Perhaps you could look at using the AIC HTTP engine, and matching on the filename with a regex.

“This malware mostly spreads within corporations but also was reported by several hundred home users. It opens a random port between port 1024 and 10000 and acts like a web server. It propagates to random computers on the network by exploiting MS08-067. Once the remote computer is exploited, that computer will download a copy of the worm via HTTP using the random port opened by the worm.”

Have you checked that there are no event action overrides configured that would overwrite your condition ?

Also have you ensured that the IPS is configured to never block certain address ranges ?

If you are seeing the signature fire then we can assume that the traffic flow has been setup correctly.

We cannot just block based on port 445 as we will be denying genuine RPC traffic. However we could customise the signature to fire based around a combination of the HTTP post or get. Or peer to peer RPC traffic.

HTH,

Jon Humphries

Nextiraone UK

[jon.humphries]

Hi again,

Also reading your post again , have you considered as a temporary measure setting up some kind of class-map on the Wan router's or if it is a Cisco Firewall (ASA/Pix or IOS) configuring MQC to drop the traffic there ?

I know this kind of deafeats the objective of having an IPS, but at least it will give you some time to test why the IPS is not firing.

It honestly sounds to me like either a configuration over writing the conditions you are setting, or a bug in the code.

Jon Humphries

NextiraOne UK