Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss Slammer Worm with Cisco expert Ido Dubrawsky. Ido is a Network Security Architect in Cisco Systems VPN and Security Business Unit. He is responsible for continuing development of Cisco Systems SAFE architecture design. Feel free to post any questions relating to Slammer Worm. Remember to use the rating system to let Ido know if youve received an adequate response.
Ido might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through March 12. Visit this forum often to view responses to your questions and the questions of other community members.
Since there was no specific signature to catch this worm (until afterwards), what development plans does Cisco have in the future that may 'catch' anomalous traffic?
I know that this is a heavy area for theoretical research, but I think the trend has to be towards detection of events 'out of the ordinary' rather than responding to something that matches a pattern: post-detection.
With regards to the slammer worm you are correct there was no signature available. The slammer worm was based on an vulnerability found last summer by David Litchfield. The worm exploited that vulnerability. So, the fact that there was no specific signature to catch this worm was not so much because no one knew the signature of the worm apriori; rather the signature of that vulnerability was well known...it's just that no one bothered to put that signature into their database because no one thought that it was a vulnerability worth exploiting (at least that's my guess).
Now, identifying new attacks by using the detection of events that are "out of the ordinary" is the basis of anomaly-based IDS. In very simple terms, the anomaly-based IDS monitors traffic on the network and develops a "picture" of the "normal" traffic to be expected on the network. The IDS then is able to detect malicious traffic because it is considered abnormal. The problem is that anomaly-based IDS tends to have a higher false-positive rate than signature-based IDS. Also, if a new application is installed on the network the IDS must learn the traffic pattern of the new application in order not to raise alarms every time it sees that traffic.
Anomaly-based IDS engines are getting better and better over time in their learning capabilities as well as in the reduction of false-alarms. It still has a long way to go. One of the better anomaly-based IDS engines available is Arbor Networks PeakFlow IDS. Anomaly based IDS are a little more susceptible to missing new attacks if they occur once or twice...that is if the attacker doesn't keep trying the attack over and over and over then the anomaly-based IDS can easily miss it. That's where signature-based IDS has its strength. In the future I would believe that the best IDS will be one that has the capabilities of both signature-based and anomaly-based IDS engines.
I wondered a bit about the priority level of the slammer worm signature in S39. Default was set to 5 and no summarizing . I f you enable this on a site with a good uplink it is an effective DOS against the sensor. Level 5 is also not a good idea, as long there is no filtering for incoming packets.
Next problem is, that two types of exploits are known. The more or less harmless slammer worm and an exploit that gives the attacker a shell. I suspected two signatures, just to distinguish between these attacks.
The choice of the alarm level set to 5 represents the potential severity of the attack. Because this vulnerability could provide an attacker with shell access to the host requires that this vulnerability and the exploit code used to take advantage of it be set to the most severe alarm level. This way the security personnel are informed of the gravity of the attack seen by the IDS. With regards to summarization I cannot say specifically why this was not set. Typically most of these exploits are not designed to be deployed in the fashion with which the slammer worm worked. So summarization on most exploits is not necessary. In this case the DoS was a side-effect of the speed with which the worm propagated -- an unforseen consequence. Almost any signature can cause a DoS against a sensor the sensor alarms on as many signatures as the slammer worm could create.
With regards to two exploits : one worm, the other a shell access -- the reason why there is only one signature is that they both exploit the same vulnerability. Therefore the code used to exploit is the same. The difference is the payload which is executed on the target host. There is no need to scan the payload in exploit code to determine whether to alarm or not. The exploit itself should be sufficient.
>In this case the DoS was a side-effect of the speed with which the worm
>propagated -- an unforseen consequence
Well the signature came out after the worm was launched. The packet rate was well known ( I made the same mistake with a custom signature, so I know the problem very well).
But you also wrote "summarization on most exploits is not necessary". Well, it it becomes necessary and is not setup, we have this DOS effect. So why do not setup summarization as default , with a high trigger point, just to protect the sensor for the case of a unforseen high hitter ?
>the reason why there is only one signature is that they
>both exploit the same vulnerability
Yes, you are right, but the consequenses are totally different. The worm is disturbing. If it hits a vulnerable host, the host itself starts scanning. This is a problem, but the security of your environment is not really compromised.
But the remote shell is a real problem. If someone gets a shell on my host , the maschine is compromised and most of the time the total network. And I need to know about it. But how can I notice this? The IDS delivers only one signature, so I'm not able to distinguish the attacks. The attack is totally hitten in the worm noise. The vulnerability is the same but the exploits and consequenses are totally different.
As a hacker I would just wait for the slammer worm packets. Exploit the sources of the packets, install a trojan and wait for the reboot . After that I have all the time I need and the IDS could not find the problem.
Cisco experts engage in discussions with you, our members, on specific
networking issues. Each event runs for a two-week period. Previous "Ask
the Expert" Q&As are listed below. Understanding Cisco ASR 9000 Series
Aggregation Services Routers Platform Arc...
As part of the Cisco Experts Bureau, we invite you to participate in the
Community's Special Contribution Programs. These programs are a unique
opportunity to spotlight your expertise that is specifically promoted
throughout some of Cisco's communications...