Tuning Snort with Host Attribute Tables - CSO Online - Security and Risk

Tuning Snort with Host Attribute Tables - CSO Online - Security and Risk.

Here is an article I wrote for CSO magazine, thought the readers of my blog might like to check it out as well.

I was asked to write a fairly technical article for CSO magazine about Snort, the problem is, which part of Snort do you write the article for?  An article about Snort can be very technical or not so technical.  One of the advantages of having Open-Source software.

In any case, enjoy.

Applying "Getting Things Done" to IPSs

Getting Things Done, or "GTD" for short, as I've blogged about before, several times, is a method of personal organization with a focus on accomplishing tasks.  It's great for applying to email (Inbox Zero) and it's great for organization of your personal life (read some of the articles I've written before, particularly this one).

Some IDS and IPS courses and teachers will tell you to turn on everything, and log everything because that's the only way you'll find anything.  I don't disagree with that, but there are several problems with this philosophy, design, bandwidth, dropping packets, time, money, and performance.  Just to name a few.  Plus, who wants to sit there and look for everything.  Most IDS analysts I know are just trying to keep their head above water.  They want to just figure out a better way to deal with the information that is coming in, not increase the amount of information coming in.  Some people have this same problem with email, which is why I am such and advocate to Inbox Zero and GTD to learn to deal with the increased amount of information that we are being subjected to.

What if we took this same philosophy to IDS/IPS?  While this can primarily work with a Snort based device, such as Sourcefire, it can work with about anything.

Step One:  Turn everything off.
Yup.  Just as a test, create a new IPS policy and turn everything off, if you can.  (If you can't then just move on to Step 2.)  Now the focus of this exercise is only to turn on what is relavant to you, so that's what we are going to do, reset expectations.

Step Two:  Use RNA
(If you don't have RNA, obviously you can skip this step, but go ahead and read it so that you know what you are missing.)  Go to your new policy, use your RNA Recommended Rules Configuration to essentially tie the IPS policy to a certain sensors or series of sensors.  RNA Recommended Rules will take the vulnerabilities that RNA has detected in Realtime (or that it received via the Host API or Qualys or Nessus or Nmap...) and uses the information to give you suggestions about what to turn on in your network.  Use the R3 (RNA Recommended Rules) to provide you those recommendations and then go over them with the common sense test.  As you know RNA tells you what you could be vulnerable to.  Your system is "Guilty until Proven Innocent", hopefully you can take the time and tell your system what your network is not vulnerable to, but lets leave that for another day right now.  Turn on the rules that are relevant to you and your network.  Don't turn on ICMP Port Unreachable.  You'll see why in Step Five.

Step Three:  Turn on any rules that are relavant.
Want to look for Spyware?  Turn on the spyware rules.  Want to look for Chat clients?  Turn on the chat rules, etc.

Step Four:  Push the policy, and wait.
Give the new policy 24 hours if you are on a slow network, or maybe just let it run over your lunch period.  Let the policy run on your network for an acceptable amount of time, you be the judge with your common sense hat.

Step Five:  Look at your alerts.
Now, go back and look at your alerts.  Time to start cleaning out.  For each event I want you to follow a flow, I want you to decide if it is an actionable alert.  Are you going to physically do something with this event?  Are you going to report it to the Desktop security people?  Are you going to block the port at the firewall?  Update the Antivirus?  What are you going to do with the event?

If you think about the next "actionable" event you are going to do with the alert, and you decide, well, I am going to do nothing with the event, then shut the rule off.  No point in running a rule if you aren't going to react to it's logging.  Do you allow AOL Instant Messenger on your network, and your AIM rules are alerting?  What are you going to do about it?  You allow it right?  So you are going to do nothing?  Okay, then shut the rule off.

What if you don't want to shut off the rule, but only want to shut it off going to a particular machine?  Well, the suppress it based on IP.  What if you don't want to shut off a rule, but it's alerting too much?  Then threshold it.  My point is, do something.

Do that for all the events in the period that you set in Step Four.  Do this once a day, and after you do it, at the end of each time, repush your policy, then do it again the next "period".  Do this for several days.  This step, in case you haven't noticed will need to be done every day.  Every update there will be new things for you to explore and catch.  Begin at the beginning.

Step Six:  What are you going to DO now?
Now, you have a bunch of alerts you intend to do something with.  Now, do you create trouble tickets?  Do you start working with various teams?  You get the point.

Step Seven: Now that your head is above water, you can experiment
After you have done the first six steps satisfactorily to a point where you can handle your IDS and IPS, you can deal with anything that comes in.  You have a process, now you have best practices.  Now, you can turn on rules that you are interested in.  Things that you don't (or might) have to deal with.  Things that you may have had on before but never got a chance to look at.  Rules that alert on obfuscated javascript for instance.  You can go play.

Warning:  Just a word before you start this process. Warn your coworkers and boss that you are about to become much more efficient and start filing more tickets.  Because you will.

Oh, and make backups of your policies before you make changes.  In fact, create new policies based off of your old ones and work off the new ones.



Please leave comments below.

IPS's don't just send RST packets.

Commenting on an email I read earlier today, some people apparently still have the misconception that an IPS simply sends an RST packet, and therefore, shortly after a session that is taking place between two parties should die.

Nope.

A real IPS, in my opinion, has full control of the traffic.  Cable one, exits firewall, enters port 1 on IPS, cable 2, exits port 2 on IPS and goes to switch.

While the traffic is passing through the IPS, the engine (in Sourcefire's case -- Snort) makes the decision if the traffic that entered port 1 should be allowed to go out port 2 and vice versa.

Can Sourcefire's devices send RST packets?  Sure!  But why would you want to give away where your IPS was on the network?  Why not just silently drop the connection into the big bit bucket in the sky and go on about your day?

Oh.  And do this at >10 Gig a second?  Yeah it's awesome.


Please leave comments below.

McAfeee Avert Labs Blog: W32/Xpaj Botnet Growing Rapidly

Read the below on Google Reader, figured it was easy enough to write some SNORT(r) rules for:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"VIRUS W32/Xpaj Botnet infection"; flow:to_server,established; uricontent:"up.php"; content:"a=g2"; rev:1; sid:1000000;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"VIRUS W32/Xpaj Botnet Infection"; flow:to_server,established; uricontent:"stamm/"; content:"stamm.dat"; depth:0; within:9; rev:1; sid:1000001;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"VIRUS W32/Xpaj Botnet Infection"; flow:to_server,established; uricontent:"plugin/"; content:"plugin.dat"; depth:0; within:10; rev:1; sig:1000002;)


Two weeks ago I blogged about a new virus–W32/Xpaj–found in the wild by McAfee researchers and actively spreading around the world. Since then we have closely monitored the change in spread and severity of the virus, improved generic detection for future W32/Xpaj instances, and added cleaning and proper repair for all the files infected by the virus. Today I want to share more news related to this threat.
Further analysis has revealed some interesting details about the malicious behavior of W32/Xpaj. The Virus is building a widespread “zombie” network, by taking control thousands of Internet-connected computers. The new botnet is in its infancy, although thousands of machines have been infected during last two weeks. The botnet infects computers around the world and has spread across many countries. The attacks are mostly aimed at enterprises, but they have now spread to consumer machines as well. Based on multiple characteristics and our own research, the virus is most probably the work of eastern European cybercriminals.
Most bots are connected to a central location from where one machine can control the entire botnet. W32/Xpaj, on the other hand, deploys several control channels to communicate and control its bots. It employs the same techniques used by Srizbi and Conficker; that is, it uses randomly generated DNS names for backup control servers. Even though W32/Xpaj does not know where the control server is, it knows how to search for it, making it possible to predict which host is in use on a given day.
To prevent botnet hijacking, W32/Xpaj accepts only digitally signed payloads and commands. Malware authors use a cryptographic hash (MD5 algorithm) to validate the authenticity of any payload received from the control server).

Our analysis has not revealed any cryptology system to protect the payload, thus there is a chance for a rival to take control of the entire botnet.
The W32/Xpaj variants we analyzed use a sophisticated domain-generation algorithm to create and query the list of random domains starting on September 24. The virus first tries to resolve the domain name to an IP address. If that succeeds, it sends an HTTP request in the form of a string:
/GET /up.php?a=g2&cm=15A91F71
The malicious host responds with the path to a binary containing further instructions and code to be executed:
http://[infected]/stamm/stamm.dat
http://[infected]/plugin/plugin.dat
The first binary containing malicious instruction has already been received by all W32/Xpaj-infected machines. The virus stores the downloaded encrypted binary in the Windows folder. After decryption, the malicious code executes and instructs the virus to gather information about the infected machine and report to the server, sending the victim’s IP address, machine name, host process, registry records, current home page, and even fonts and path variables.

Every time an infected machine receives a payload and executes malicious code, a marker (a file with a random name) is created in the Windows folder, preventing the virus from executing the same payload twice.

Botnets grow and evolve quickly. We measure them by the number of compromised computers under their control. However, proactive virus detection and following these simple recommendations will help prevent your computer from becoming a part of a botnet:

• Keep your anti-virus software up to date
• Apply all the latest security patches and keep your operating system up to date
• Set up a firewall to block unauthorized access while you are connected to the Internet. Use strict firewall policies and allow only those connections–both incoming and outgoing–that are absolutely necessary for your business.

Although many security vendors struggled to release new signatures and cleaning support for this virus, McAfee customers are already protected. You will hear a lot more from us in the coming months, so stay tuned and keep reading our blogs.
Thanks to Abhishek Karnik, Rachit Mathur, Di Tian, Ivan Teblin, and Adrian Dunbar for their help in analyzing and defeating this threat.

Please leave comments below.

Why is your IDS outside your firewall?

Stop that. You’re doing it wrong.

This is a very puzzling situation that I run across quite often, more often than I should. I thought i’d bring up a few points as to why, I view, IDSs outside of Firewalls, to be a bad thing.

Allow me to play Devil’s Advocate here for a minute, present a few arguments, then allow me to rebuttal them. I am not insulting anyone that has their sensors outside the firewall. But I ask to you please reconsider. Here you go:

1. We place a sensor outside of our firewall to see what’s “out there in the wild”.

First off, the Internet is not plugged into one big hub. Network traffic that is destined for somewhere else is not going to be seen by your network. Only networks that you advertise as yours will receive the traffic that you intend. Placing a sensor outside of a Firewall because you think you are going to see traffic “floating” by, is just plain wrong.

Second of all, if you have a "Deny all, permit by exception" policy on your Firewall -- as you should -- only allowing things into the network that you explicitly want people to access remotely, you will only see UDP based attacks on the outside. So, you will simply pick up a lot more SQL Slammer attempts at your gateway. Confused? What do I mean?

If you have a state-ful Firewall, denying access to your network prevents a valid 3-way handshake to be exchanged with a host you EXPLICITLY allow access to from the outside, you will never receive any more attacks on a TCP basis. Your IDS will sit there and track SYN packets all day, attempting to track sessions, never receive SYN-ACK’s, and purging that session from the state table upon timeout. Maybe your Firewall will send an ICMP Admin Prohibited response if you have it configured to do so, however, most Firewalls simply drop silently. After all, why would you want the attacker that is coming after you to know you have a Firewall, and exactly what hop it is in the network?

This is a waste of IDS resources, time, and money. (Time = money.)

2. “We put the IDS outside the firewall because if an attacker is going to attack our network, they are going to attack the firewall first.”

(Yes, this is an actual quote. I do have permission to repeat it, as long as I don’t tell anyone who said it. Actually, the person who told me this was simply repeating what his network admin had told him.)

If you told me that statement above, I would assume three things.

First: The management interface to your Firewall is accessible from the Internet.

Second: If it is, what is the condition of the rest of your network, because I can most likely attack it easier.

Third: Obviously you are willing to sacrifice your IPS. (by putting it outside) What is the difference between an IPS and a Firewall in this context?

I say they are both security devices, and are both vital to the protection of the network. If I am an attacker, I am not going to attack your firewall. I am going to try and find a way THROUGH your firewall, install some kind of backdoor, then get in through that, or better yet, have the backdoor opened for me from the inside. You obviously allow some ports open on your firewall so I am going to go in through those first. I’d rather go after your SSH server, FTP server, HTTP server, hell, i’d rather attack your printer than to go after your firewall. That is, of course, assuming your management interface isn’t sitting in the DMZ, and has a password of “password”.

3.  It’s the only aggregation point we have where all the traffic comes together!

Okay, fair enough, I’ll allow this argument. However, I am assuming then, that this is just a temporary solution until you can either afford to buy more sensors, or build more SNORT® boxes. It should only be a temporary solution and you should really concentrate hard on moving your IPS inside of your firewall, perhaps get traffic to the IPS/IDS with taps or multiple spans. Utilizing multiple detection engines on one machine is a good way to do that. A sensor sitting outside the firewall is never the solution, for two or three really good reasons I just talked about above.

I am sure I can probably think of some more, but that’s enough for now.