Snort Signature: ICMP Destination Unreachable Port Unreachable very noisy
 

I am running snort-2.9.0.5. I am recieving alot of alerts from Signature: ICMP Destination Unreachable Port Unreachable. The Destination of these alerts are my public DNS servers. I do have these DNS Servers listed in the snort.conf under "List of DNS servers on your network", but I still get thousands of alerts. What type of investigation should I do to verify that these alerts can be ignored or need attention. Also what should I do to tone down the amount of alerts I am recieving from this signature.

Where's the traffic coming from? Or, are they various source IPs?

Some potential answers may reside here. Read the responses, as they will more than likely offer some insight.

When I see these in BASE, it usually shows the real offending IP.

For filtering, do the same thing as you did here.

The traffic is coming from various source IP's. The Destination of these alerts are my DNS Servers.

Hi Unixfool, when your using snort what process to you go through to validate if the alerts you are getting are known good traffic or Malicious traffic that need attention. Since I've set snort up, I've been going through the alerts every morning. Some alerts alerts I can rule out right away because I know the source and destinations and know this is known good traffic, but other alerts I don't have a clue. I guess my problem is figuring out how to diagnose these alerts.

This signature for example "CHAT MSN messenger http link transmission attempt" My office uses MSN Messenger for in office chat, but I get alerts from this. The source is the live messenger servers, and the destination is my users workstations, not everybody, but a handful.

This Signature "WEB-CLIENT Portable Executable binary file transfer" also sends me alerts. The source IP's are various and the destination is my Astaro Security Gateway which is my HTTP and SMTP Filter. I also got a few alerts matching this signature "Signature: WEB-CLIENT PCRE character class double free overflow attempt" which has the Astaro Security Gateway as the destination as well.

I guess I'm just looking for a process to go through when these alerts come in to validate them. Some I am able to validate, but others not so much. Is there a process you go through to help you validate and diagnose alerts like I have above? Thank you for all your help thus far!

Well, I do this sort of thing for a living (since 2003).

There are various ways you can analyze these. It helps if you've seen the good aspects of the traffic (ie, if you've seen regular yet non-malicious MSN chat traffic before, use it as a reference). The trap that most people fall for is that the source and destination may both be trusted IPs. Well, a trusted host can become infected and pass malware to other hosts that it normally chats with. You should be able to find a signature that will sniff for certain malware that affects MSN chat. It basically depends on what the signature is designed to alert against. Compare the captured traffic against the signature/rule itself. In most cases, the sigs rely on regex, but this isn't always the case. There will sometimes be blatant false positives and negatives. Study up on signature anatomy (there should be some explanation at snort.org that explains the makeup of a Snort rule). Try to create your own rules based on packets you manually capture. Alter an existing rule to see if you can refine it for your environment.

A lot of sigs are designed to alert on the existence of the traffic itself (your MSN signature, for example). Since you know that your organization has a business need for MSN chat, you can probably disable that particular signature. I'm not sure on the latest and greatest features of Snort, so check to see if there's a way to filter out trusted hosts for specific signatures (that way, if you see malicious traffic coming from an untrusted IP, it will most likely be observed and not filtered). Check to see if there are sigs based on known malware that uses MSN chat as a conduit/vector.

There will be some that you won't be able to immediately validate. This is where I use google to search for answers. I also have a lab where I can study traffic. I will sometimes crank up an IRC client (for example), then visit an IRC server...the whole time, I'm logging traffic via tcpdump. When I'm done, I go back and peruse the logs and study them. That'll help with understanding how IRC protocol and how IRC traffic is logged (so that I know what I'm looking at when analyzing an incident). The same can be done for web traffic or any other protocol. Half the battle is learning how servers interact with their clients, as well as how the Snort rules are designed to alert. Sometimes you're going to find rules that just flat-out need to be disabled, if only because you know that your organization doesn't normally utilize a particular service. Sometimes you're going to see things you've never seen before (to this day, I still see things that challenge me)...these are the types of traffic that will force you to grow your experience. Leverage the Snort forums and other security forums. Sometimes, this forum won't be the proper place to get the highly technical details. What has been a good resource is http://taosecurity.blogspot.com/ (Richard Bejtlich's blog). Some of his blog entries are way above my head, while others are level with me...I take what I can understand.

I also bought quite a bit of books over the last 8-10 years. Basic networking books, as well as literature on apache and database administration. In addition to the basic books, I got OJT on monitoring (and administering) security devices such as enterprise-grade firewalls, IPSs, IDSs, proxies, and whatever else you can think of.