Archive for May 2008
… As if you don’t have enough email to read as it is.
People commonly expect Snort to provide many systems that are well out of scope of it’s design, including :
- Event analysis UI’s
- Real-time e-mail alerts
- Graphical configuration tools
- The kitchen sink
- Reporting functions
The list goes on …
There are many external tools that provide all of these functions, please remember Snort is a high performance network intrusion detection/prevention engine and not a complete IPS solution alone. Many commercial offerings use Snort as the detection engine but bundle their own management and reporting framework around it, including <blatent plug> Sourcefire </blatant plug>.
Swatch is the most commonly used light-weight method of performing an active response when Snort raises an event, this included sending email. When I teach Snort classes I find that students quickly get to grip with how to use swatch, but still need a hand getting a formatted email out of the system.
To make this a more simple task, i threw together this simple script to provide nice email alerts with impact and advice on how to react to the event.
Let me know if you find it useful.
… and more tuning ideas
So here I am, stuck in another hotel bar, this time at the dark-end of Cornwall, sipping (carefully I may add) at the local tipple (Skinners Press gang cider). I have been taking some time to sift through snort forum postings and following the discovery of the normal “what the hell do I do about this alarm” calls for help, I thought I would take time-out to compile a list of top-tips to better deal with intrusion alarms.
We all know the situation, you are being alerted to new “stuff” happening on the network, you don’t recognize the alarm as obviously bad, or even obviously dismissible and are desperately trying to work out how much, or even if you should be concerned.
There are certain things you can do to enhance the process of dealing with and understanding new alarms you haven’t any experience in, and due to the shifting threat spectrum (/me slaps self around the face for extreme buzzword abuse, and to mitigate the effect of the cider) new alarms arrive all the time.
Without wanting to write a book on incident analysis, ill split this over a couple of blog postings as some of this advice is conceptual and some introduces methods of approaching the problem, and other tips are tool specific.
First, the bleeding obvious (if you don’t do this already, pick up your security hat and coat and head for the door).
Understand the alarm.
This is such an important point that I must state it even though it sounds obvious. What does the event message really represent? Be sure to read all documentation associated with the alarm. If your IDS is Snort, and used the VRT rules, you have luck on your side as Nigel does a good job of writing and keeping rule documentation current. It is essential that you understand what the writer of the rule wanted to bring to your attention. Your reaction should vary depending on what has occurred, and one hopes that they would have attached a realistic event message. If you consider a regular server-side attack, all of the following may be raised in separate alarms associated with a single flow.
Access, or discovery of a potentially vulnerable system on the protected network
Exploitation of a vulnerability
Discovery of a specific exploit
Malformed network packets
Successful attack response
One of the things that you should have in your favor (and unfortunately, or rather shockingly, this isn’t always the case with many commercial tools) is the ability to look at the detection “source”. This provides an undeniable method of knowing what was being searched for, and may yield more clues to the writers intent (if not already obvious).
Understand the source and target devices in the context of the alarm.
Is it an attack response coming from your network? or someone else’s? How this is evaluated is specific to the event.
Take a look at the packet(s) that raised the alarm for supporting evidence of suspicion.
Without access to the packet that triggered the event(s) you’re dead in the water here and you are flying blind. Was this alarm real or a “programming error” on behalf of the detection system. Take a look at the decoded packet, inspect it, check for the presence of supporting evidence that the alarm may be real. A NOOP sled or a shell call are trivial examples.
Understand the quality of the rule/signature that generated the event.
Check out how the rule was written, if your IDS doesn’t provide you with the detection source, you are dead in the water. Being able to justify WHY an event triggered a rule is imperative.
The slightly less than obvious … the “C” word.
Understand the alert in the context of the systems involved.
To qualify the potential impact of an “attack” against a target system we need to know what the target system is. In turns out that this can be a harder job than discovering the attack itself, evaluate the alarm against the Operating System, Services, and applications provided by the target.
Evaluate the event in the context of the organization.
What was the “application” being attacked. By application I refer the the purpose of the target system in the operation of the organization. IIS alone means nothing, what is being served over HTTP from this device, and how does it’s compromise effect the operation of the company.
Following the completion of this process TUNE! Can you automate this effort the next time this event is raised on …
A group of targets
Your whole network