Sign in to follow this  
Followers 0
lattera

Proper Role of Intrusion Detection

11 posts in this topic

Medium- and large-size businesses everywhere are victims of countless hacking attempts. Attacks come from those that are curiously, chaotically, and financially motivated. As a security analyst for a successful company which grosses millions of dollars in profit, it is my job to ensure the security and integrity of the network. The company deals with retaining sensitive data for longer periods of time. Thus, preventative measures and proper response measures play a vital role in every aspect of the company.

We recently had a surprise penetration test. No one in the company (not even me) except the president of the company knew about the penetration test. The test was twofold: to find potential vulnerabilities in our web-based product and to see how the security team (mainly just me) handles a hack attempt. The security analyst started out with Nikto, generating thousands upon thousands of 404 errors. We first caught wind of the penetration test because of how loud Nikto is. We quickly firewalled that IP. The attacker then used a proxy and continued attacking. He was able to find valid login credentials after a few brute force attempts. We then learned something really important: our intrusion detection methods weren't up to par.

We rely on error emails (404 and 500/503) to tell us when an intrusion occurs. After monitoring emails for a while, we only know a handful of things: the IP, the date/time of the attack, and what types of attacks. We don't know if the attacker was successful. After a few hours of research, I was able to gather that the attacker successfully logged in. It really should not have taken hours just to find out if he logged in.

It was on that day that I fully realized just how important detection is as a method of protection. Instead of looking at data for hours and guessing potential outcomes, proper detection and logging allows the security team to make accurate, timely decisions. Even now, a few days later, I don't know what the attacker accomplished. Without an audit trail, there's no way for me to tell what happened or how. Intelligent detection should be a part of every company's security plan. Without it, time is wasted and the chance of being fully compromised is much greater.

So, to sum up, make detection a part of your security plan. Detection allows your IT department to know what's going on and what actions to take in an efficient, affordable manner. If intrusion detection and logging is not a part of your security strategy, you'll end up doing what I did: spent hours just trying to figure out whether the attacker successfully logged in.

Originally posted on my tech blog.

0

Share this post


Link to post
Share on other sites

Medium- and large-size businesses everywhere are victims of countless hacking attempts. Attacks come from those that are curiously, chaotically, and financially motivated. As a security analyst for a successful company which grosses millions of dollars in profit, it is my job to ensure the security and integrity of the network. The company deals with retaining sensitive data for longer periods of time. Thus, preventative measures and proper response measures play a vital role in every aspect of the company.

We recently had a surprise penetration test. No one in the company (not even me) except the president of the company knew about the penetration test. The test was twofold: to find potential vulnerabilities in our web-based product and to see how the security team (mainly just me) handles a hack attempt. The security analyst started out with Nikto, generating thousands upon thousands of 404 errors. We first caught wind of the penetration test because of how loud Nikto is. We quickly firewalled that IP. The attacker then used a proxy and continued attacking. He was able to find valid login credentials after a few brute force attempts. We then learned something really important: our intrusion detection methods weren't up to par.

We rely on error emails (404 and 500/503) to tell us when an intrusion occurs. After monitoring emails for a while, we only know a handful of things: the IP, the date/time of the attack, and what types of attacks. We don't know if the attacker was successful. After a few hours of research, I was able to gather that the attacker successfully logged in. It really should not have taken hours just to find out if he logged in.

It was on that day that I fully realized just how important detection is as a method of protection. Instead of looking at data for hours and guessing potential outcomes, proper detection and logging allows the security team to make accurate, timely decisions. Even now, a few days later, I don't know what the attacker accomplished. Without an audit trail, there's no way for me to tell what happened or how. Intelligent detection should be a part of every company's security plan. Without it, time is wasted and the chance of being fully compromised is much greater.

So, to sum up, make detection a part of your security plan. Detection allows your IT department to know what's going on and what actions to take in an efficient, affordable manner. If intrusion detection and logging is not a part of your security strategy, you'll end up doing what I did: spent hours just trying to figure out whether the attacker successfully logged in.

Originally posted on my tech blog.

What did you use to allow you to see the email error codes?

Are you going to impliment snort or another IDS? What other steps are you going to take?

0

Share this post


Link to post
Share on other sites

Even implementing an IDS like Snort won't allow the security crew to see if the attacker was successful or not. IDS' like Snort rely on simply parsing Apache logs and, if something fishy comes up, it posts the request they made.

0

Share this post


Link to post
Share on other sites

You could have the IDS automatically firewall attack IPs until you can review them, or at least have automatic account lockouts and a secure password policy to mitigate brute force attempts.

0

Share this post


Link to post
Share on other sites

How about making a system that regularly backups and checks for tampering of files that are normally modified / deleted when the intruder is successful, such as .bash_history? Obviously if the attacker is successful and a little careful, he will attempt to cover his ass and remove any traces of what he did.

0

Share this post


Link to post
Share on other sites

You should have been able to quickly determine whether or not they were able to login using actual credentials by simply checking log files. Syslog and other loggin daemons write out whenever someone logs in via ssh as well as their username and ip address. Having already known the ip you could have just grepped. I know that windows systems also record when users log in through their logging system which also should have been able to tell based on time. When you're dealing with a loud hacker who isn't attempting to exploit an actual bug but simply use valid credentials detection is relatively easy if they aren't quiet about it. If you're dealing with someone who is actually exploiting software, depending on whether or not they are crashing it and how loud the attack is, that's where it can be difficult to determine when they got in and what they actually did.

Systems like tripwire theoretically should help in detecting both of these instances, at least in determining what the attacker did, but I've never actually used it.

0

Share this post


Link to post
Share on other sites

If your on unix type systems, configure your login logs to report back to syslog by modifying /etc/syslog.conf etc, have splunk or whatever pull the syslogs back from all the devices to a central syslog server buried somewhere safe deep inside the network and watch the streams for "failed login" or whatever string. There should be a big flashing screen in your op's dept somewhere after more than 3 failed logins. Dont forget to tell ssh (and ftp if you still use it) to log to syslog too...

You can buy a network aware version of tripwire, but its commercial licensed and very expensive. It does plug into snort however and you get a realtime alert in your monitoring console that the system files have been monitored. Takes time to set up and decide what files are mutable and what arent to tune off the false positives but thats what being a good sysadmin is right? Depends on how much money they'll give you for toys... Id spend it elsewhere and stash the tripwire sums from the non network version off the box somewhere safe just to do a quick comparison if it did get p0wned...

Edited by MrFluffy
0

Share this post


Link to post
Share on other sites

Sorry for the late reply, been a very busy and completely random couple of days.

So I didn't really mean "Intrusion Detection" to be interpreted as an IDS, like Snort. I meant it in a more generic way, as a method of logging and auditing. I also didn't mean "logging in" as getting a shell or logging in via RDP (we're a Microsoft, no ssh, just RDP, heh). I meant logging into our product, a web app. We don't properly log failed and successful login attempts. Since IIS doesn't log POSTed data, we still don't know if he got in successfully and which accounts he got in with if he did get in.

0

Share this post


Link to post
Share on other sites

Sorry for the late reply, been a very busy and completely random couple of days.

So I didn't really mean "Intrusion Detection" to be interpreted as an IDS, like Snort. I meant it in a more generic way, as a method of logging and auditing. I also didn't mean "logging in" as getting a shell or logging in via RDP (we're a Microsoft, no ssh, just RDP, heh). I meant logging into our product, a web app. We don't properly log failed and successful login attempts. Since IIS doesn't log POSTed data, we still don't know if he got in successfully and which accounts he got in with if he did get in.

Your web appication should be doing that to a separate audit file you can check later even if you dont get something in your ids to scan that log for strings and generate a realtime alert that its happening (which you can do), its basic 101 security.

You might want to get them to roll other stuff into a review if it happens, like does it issue a warning banner, password complexity etc. Theres probably some policies they could adapt over at SANS, although you could come up with a list better just by sitting down and thinking about what information you might need afterwards from both your sysadmin and other hats perspective and using some common sense. Sounds like your already asking yourself the right questions. If they give you any crap over it, ask them what formal company policy is (assuming they dont have a coherent one...) and can they show you. If its a tight ship, they'll have it documented somewhere exactly what it should, and further there should be someone testing these things against those policies before they are put live. If they haven't then maybe your going to be their saviour :D

0

Share this post


Link to post
Share on other sites

Did they also pentrate your lan/company network or just obtain web application login credentials?

0

Share this post


Link to post
Share on other sites

They were able to gain access to areas of our web app they weren't supposed to. They didn't gain remote shell/desktop access.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0