To really understand what is going on in your network, you must do more than deploy security devices, you must also monitor your security situation on a constant basis. Intrusion detection monitoring is a major trend in the security industry.
Adaptive and Behavioral Approach to New Threats
Submitted by LogError 2004-12-13 Privacy, Security 9 Comments
This would definitely be a positive thing. I remember my VISA card was misused about a year ago. VISA contacted me about 1 day after the misuse occurred before I even knew about it. They asked me if I made such and such purchase…I said no, and it was all taken care of. I asked them, how’d they know I didn’t purchase it. They said, it didn’t match my buying pattern.
I don’t know what they used, but it worked out well for me.
It would be nice to see this applied to networks. Not just on the enterprise side, but on my PC for many things. If someone has been hacked and its transmitting data to some ip address that doesn’t match their profile…let them know about it, or even block it.
I guess we see what they come up with first
I’ve constantly heard the argument how IDS is a positive thing because “it can detect intrusions so you know how you were broken into, bleh bleh bleh”.
Every article I’ve seen assumes wrongly that the IDS itself is secure though, which is definately not true. The code required to program a IDS system is a lot more complex then code to design a firewall, and because of this, its often prone to exploits.
Even worse, IDS leaves many false positives, so the end result is a 200meg log file, which may not even contain any real attacks, and is too long to sift through to find how the system was compromised anyway.
In fact, a very large amount of firewall exploits these days are due to IDS systems built in. Anyone remember the blackice worm that spread through the blackice IDS system corrupting thousands of computers harddisks?
IDS is just another attack vector, and because of its nature, I actually suggest that if ppl do use it, its not on the same system as their servers, but a seperate one.
Most people would find stuff like tripwire more useful on their servers then IDS (depending on the server), because then you can tell when files have been compromised. File system layers like winfs will also help security though as well because they keep a history so will be able to determine exactly which changes were made to a file on which date.
IDS is good.. but dont run it on your server, and ensure that at the least you are using Stack guards on the system, and preferably something like SElinux too
The article is a fine advertisement for Global Data Guard but, it also has some merit. Keeping IDS signatures fresh and the false positives to a minimum is hard work. Too hard.
A reliable anomaly based system would be great. It would require minimal tuning and still provide alarms for unusual behavior. The problem is that so far, anomaly based systems are slow because of the processing requirements. These systems have also proved to be just as tedious to maintain as signature based systems because, as stated in the article, they must be constantly retrained.
So, the question is: Is this Global Data Guard system the answer? Obviously The CEO of Global Data Guard thinks that it is but, I’m not putting much faith in his obviously biased opinion. I’m also not willing to spend $6,000 to find out, even if that is a small amount for a reliable system of this type.
This brings us to the next question: Has anyone found a reliable anomaly based IDS yet? Also: Are there any open source anomaly based IDS that are worth trying or showing promise?
Anyone? Anyone? Beuller? Beuller?
Unfortunately, with an IDS, you’re only as good as your patterns. An IDS by itself is not effective when you have to correlate all of the data. You need to associate your network device log data with events also, as your average large enterprise network has so many proxies, sinks, and sources of data that you have to program the system to associate multiple conditions at once with multiple criteria.
One other thing that will knock out most IDS systems is SSH or SSL. Unless you’re running Key escrow on your IDS servers (and most security-conscious admins won’t open up a second avenue of risk, plus it really knocks up your CPU usage), a pattern-based IDS system is useless. If someone really wants to get into your systems, they’re not going to run nmap or do something that a script kiddie would do. They’re going to impersonate legit traffic and get in that way, and do their damage over a secure channel.
Adaptive systems which combine events from logs and associate them with events, like TriGeo Contego (www.trigeo.com), and the system that the state of New Jersey has, Protego (www.protegonetworks.com) are more effective as they combine a centralized logging facility with the IDS portion (and they don’t sit on the firewall). Protego is apparently using Oracle as their back-end DB. I would hope to heck that they really locked that one down .
This means you can output your Firewall, Proxy, Tripwire or AIDE logs, or any other logs you choose over syslog or syslog-ng, collect them, and then associate them with IDS and firewall events. If you have a Windows box, you can even use Kiwi Syslog or the open-source equivalents to send log data to these machines as it happens.
This is much more effective than just looking at IDS patterns, because you have the other patterns that indicate issues but appear to be legit traffic to an IDS (ssh, failed logins, changed files, and source/destination ports for a chain of events across multiple servers). When you have a pattern match here, then you can pull up the traffic.
IDS systems are decent at what they do, and do have their place. However, they are not the be all end all. Systems which can combine logs and run them through tests that way, much like Trigeo, Protego, and some of the Snort mods that I cannot remember now, get you better answers.
IDS can be bypassed with techniques like fragmentation etc.
You will most often catch small-time kiddies attempting breakins using common exploits. Real threats are usually hard to detect and IDS using signature/patterns are helpless against the latest vulnerabilities.
I would say that the current trend of IDS is not installed solely on a single server. Instead users usually spread their IDS sensor through out the network perimeter and servers(not installed in the same machine) to monitor certain entity.
These data collected from entities/nodes aorund network would later be correlate at ‘central analyzer’. Note that central analyzer, most of the time, will not be a single node, instead it might be multiple machine to improve performance.
The challenge here is of course to collect correct data in timely manner (fast) and send to the analyzer.
Wouldn’t however the increased cost of a distributed IDS system outway the benefits of it?
IDS can be bypassed with techniques like fragmentation
If I’m using OpenBSD’s pf on my firewall, I can set the packet filter to ‘scrub’ the packets (either coming or going). If I scrub incoming packets on my external interface(s), can I be reasonably confident that I am closing down fragmentation-based attacks? I think that the answer is yes, at least ususally. I understand that scrubbing will reassmble fragements when possible and drop fragments that cannot be reconstructed. Does anyone know if this is correct?
If fragmentation is a technique used by attackers, why can’t the IDS detect fragmentation and characterize the fragmented packets? The characteristics of the fragments could then be part of its signature?
there are pros and cons. IDS is a statistical approach. its not hard and fast like a packet filter. again, like so mant technologies, they are only useful in the hadns of those that undertstand them and their limitations. personally, recognising common probes and attacks and then re-actively and temporarily shutting off the source of those attacks works well.
myself i think its an asset to have trained and IDS to your network. it can alert you when someone from accounts is epeatedly trying to log into the backend database servers .. or when your new intern is trying to send out malformed packets!