You can see which rules are triggering in /var/log/secure with something like:

grep snort /var/log/secure

You are looking for the sid (rule) number which is the middle number in an identifier like [1:2014492:5]. In this case 2014492. This should correspond to an sid number in one of the rules.

There aren't that may rule sets in the free snort rules. I'd attempt to systematically eliminate them one-by-one, unless it is causing a denial of service. Once you narrow it down it will be easier to fix the problem whether is false positives, or an actual attack.

The server hit 400% load again today. Again the logs were riddled with intrusion detection report updates. I've completely disabled the intrusion detection now as a last resort.

Well the next few weeks will tell if it misbehaves again. Thanks for the replies, much appreciated.

Assuming this is actually the source of the problem, you would need to look at the DNS rule in question and see if there are any throttling or threshold variables to tweak. Before doing that I would evaluate my DNS exploit exposure potential and see if just leaving it turned off is the best approach. It is probably a waste of CPU cycles if you are not running an externally accessible DNS server. Even so, I believe this type exploit is fairly rare and higjhly target-specific in the wild anyway so, low risk.

Hi

Thanks for your reply.

The "top" usage is coming from the intrusion detection. I've unchecked the "DNS exploit" rule from the intrusion detection tab. I'm hoping this resolves the issue as I'm not proficient in Linux to dig any deeper, ie: through the terminal. The server shouldn't be underpowered as it usually runs as 10-30 load, at its highest when archiving mail.

EDIT: Is there fix for Snort that can be easily applied?

This appears to be Snort misinterpreting common DNS chatter. Some patterns of browser behavior spawn numerous DNS queries very quickly triggering the alarms.

Don't worry about the server attacking itself. Really it is the report which is not clever enough. The IDS sometimed monitors replies and picks up on those to work out if it is being attacked. As an example of this it will look for failed login attempts on various services. The failure is detected by the reply from the server to the attacker. Unfortunately the report interprets the "from" as the attacker rather than then look up the triggered rule to see if it should be using the "from" or the "to" field as the attacker.

It could be that your server is under-powerwed for what you are doing. The other thing is have you enabled all the rule files? If you have there is is little point in enabling rule files for services you are not running or exposing to the internet. This could reduce the maount of processing which needs to be done by the server.

When wou are getting these high loads are you able to look at the "top" command to see what is using all the resources?