I have set up my IDS to block the connection of any traffic matching th Mydoom signature. It seems to be working, becuase when I go and do a "show shun" on the pix it shows a list of ones it has shunned. But our email server is still showing a lot getting through. I am wondering can you really block this type of traffic being that it is an email. Once it has been detected by the IDS, it's probably already through. It's not a stream of data. So is it doing any good for me to block it, or is there a better way?
Blocking viruses with your firewall is a bad idea in general. First, it can result in legitimate email getting blocked if you block all traffic from the source. Also, SMTP servers are very dilligent about trying to deliver mail. They will periodically retry sending an email until it gets through. So, you might remove a block only to have it get through again later. Your assumption about the initial virus getting through is also most likely correct. Using TCP resets suffers from the same problems. The best defense against these types of threats is to update and use anti-virus software on your incoming and outgoing email gateways. The signatures we provide for these types of signatures are really best utilized to detect hosts that are already infected with the virus.
I understand your concerns about the persistance of mail servers and blocking mail traffic at the firewall. I do have one question though about your statement. You indicated that the traffic would "get through later". How is that possible if every time I get a hit on that signature, the IDS is set to do a TCP reset (assuming my sensor is under untilized)?
For example, I have this signature set to do a TCP reset. I am currently seeing the events show up on the sensor by using a "show events". I also see on the switch that there is 200 incoming packets per firing of the signature. However, I still see these messages coming into my mail gateway, which is in turn cleaned by by antivirus software. Am I correct in assuming that if I am getting confirmed TCP resets that I should never see any of these messages in my mail gateway?
There are alot of assumptions here, but assuming your sensor is not overworked and it actually sees all the traffic <-> the mail server you shouldn't be getting any mail messages in your server queue. It's possible though that the reset packets aren't reaching the conversation endpoints even though they are sent. Without an understanding of your exact tolopogy, this is a difficult question to answer. You can take this offlist to email@example.com if you wish.
Not always true.
The sensor sees the packets at the same time that the server sees the packets.
If the email completed in the same packet (or the next packet if the connection is fast enough) as the one that fires the signatures, then the TCP Reset may tear down the connection, but the email may have already been completed and sent on the server.
So the TCP Reset would just prevent a second email being sent on the same connection, but in this case the email client would just reconnect again. The new connection would be analyzed and the email may finish before the TCP Resets get sent.
So the question in my mind is what good are these sensors then? If someone can send a malicious packet of information whether it is smtp or any other type of packet and it reaches its destination before the sensor can respond. What good are they doing? I might as well have them turned off. The only thing I could see them being useful for is acting as a notification device.
That is exactly what it is good for.
The sensor is an inrusion detection device.
It detects that an attack is in progress and notifies you.
For many years, notification was the primary role of the ids device.
Users had no idea when they were under attack. So the IDS devices initial role was to notify the user that an attack was underway and the user would then decide what steps needed to be taken.
The ids sensor can be compared to the alarm system on your house. The alarm won't prevent a burglar from getting into your house. It just notifies the alarm company so they can call you and/or the police to go and see what caused the alarm.
It has only been in the last year or so , that there has been a concerted effort in the industry to move from detection (with notification) to prevention (stopping the attack). Where the sensor would not only detect but would actually prevent the attack by dropping the packets before they get to the end device being attacked.
This is because the ids sensors are now becoming fairly reliable at detecting real attacks and not false alarming on activity that is normal in the network. The fear had been that the IDS would see normal traffic, think it was an attack, and incorrectly drop the packets causing major problems for the users. Only in the last year or so have users become confortable with the accuracy of the IDS sensors and are willing to operate them inline.
(Note: Of course there were some early adopters who were willing to take the risk as early as 2 or 3 years ago, but only in the past year or so has the general user been willing to make the step).
This prevention capability is often referred to as inline ids.
This is because it requires that the offending packet be transmitted through the sensor (hence inline), instead of just being copied to the sensor. When the sensor is receiving a copy of the packet there is nothing it can do to the original packet. But when the sensor is acting on the original packet as it passes through the sensor, then it can drop the original packet and prevent it from getting to the end system.
At this time Cisco offers 3 types of sensors that offer inline ids (intrusion prevention) capability.
1) The ids capability inside the IOS Firewall feature set for IOS Routers. (NOTE: This IDS capability is built into the IOS image itself, and should not be confused with the NM-CIDS which is ids module for the router that does not have inline capability)
2) Similar ids capability inside the Pix Firewall. (NOTE: Just like IOS IDS, the ids is built into the firewall image itself).
NOTE Both the ios ids and Pix ids features offer a subset of the signatures in the ids appliances and modules.
3) Cisco Security Agent which is a host based intrusion prevention product. It is software installed on the end host rather than on the network device. The packet still gets to the end system, but the CSA analyzes the packet and can drop it before it makes it to the other applications on the system.
The Cisco IDS Appliances and Modules do not currently opperate in an inline mode (intrusion prevention).
I can not comment on what future versions of the Appliances and Modules may or may not be capable of on an open forum like this.
Please contact you Cisco Sales Representative if you would like to know more about the future versions of the IDS appliances and modules.
AS a side note: As I stated in my earlier email, the sensor can not drop the offending packet, but it does have other response capabilities which can prevent additional attacks. The TCP Reset can be used to stop the current connection, and prevent a further attack in that connection. (The attacker may still create a second connection to continue the attack). The Block feature can be used to stop All traffic to and from the attacker ip address. This will stop further attacks on the existing connection as well as prevent new attacks from that IP address when blocks are properly implemented.
Awesome information here, mcerha, where can I find the signature you describe here to find the virus if it has already infected a system?