One of the main questions many people have about IDS is, what is the difference between Host based IDS (HIDS) and Network Based IDS (NIDS)?
This is a topic that can be discussed in great detail...and i don't have time at the moment to explain everything, so I am hoping people here with IDS experience can express their ideas and opinions.
The first type of IDS is the Network based IDS. This type of IDS is deployed at strategic places in the network infrstructure (sometimes outside the firewall, in the DMZ, or various places throughout the internal network) to capture traffic going across the wire, and comparing it to a database of known attack signatures. If the packets are inspected, and there is a match to the signature database. Many types of actions can be taken, including alerts to the administrator, sending a RST to the attacking host to kill the connection, or even dynamically modifying firewall rules to block the connection (although this is often very risky because of the probablility that valid traffic will be blocked from the network if a false positive is detected. NIDS can most similarly be compared to a sniffer on steroids.
Types of NIDS include Snort, Cisco NIDS, and Netprowler
HIDS is a bit different than NIDS in the aspect that it is run as a service or agent on the protected host. HIDS does not insoect traffic that is not directed at the host it is protecting!!
Instead, the HIDS agent monitors settings on the machine, like critical system files (/etc/passwd, the NT SAM file, etc), registry settings, file checksums, or just about any other parameter you define. When an attack is made to a machine, the agent will typically block the connection, log a record of the session, report it back to a central management console, and of course alert the admin of the problem. HIDS also has another distinct characteristic, it can inspect encrypted traffic, because the traffic is actually decrypted before the agent inspects it. NIDS on the other hand can't do anything about encryption.
Types of HIDS, include Tripwire, Cisco HIDS, and Symantec ESM
A false positive is when an attack is detected that is not really an attack, and is valid traffic on the network. All IDS's will detect false positives at one time or another. It is the admins jobs to tune out these false positives, and only alert on real attacks.
For those who want to see a good real-world application for IDS, visit the Honeynet project homepage at http://project.honeynet.org
Of course the Honeynet project is about much more than just IDS, but it will give you some examples of how the IDS can be used, and what information can be gathered from them.
Well there is certainly much more to come...I am out of time now...:)...but please feel free to add to this post with any experiences you guys have had, and I will keep adding as I get time.
February 11th, 2002, 04:41 PM
Good post iNViCTuS !
February 11th, 2002, 05:11 PM
a good post iNViCTuS.
Also there is such a thing as a false negative. This is when the detector did NOT pick up an attack though it may or may not have been in the signature files.
Common problems are when attacks are when attack "encapsulation" occurs. One of the things this can mean is the data stream bundles an embedded attack.
I like this forum. :D
February 11th, 2002, 08:19 PM
Very true about the false negatives. This can happen in several ways, but most commonly because signature files are not kept up to date.
The encapsulation attack is also a very interesting concept that I think we should explore further. Maybe u (or myself when I get a chance) can write an eplanation of how this is possible, and what effect it can have.
Very good post :)
February 12th, 2002, 01:46 AM
I'll just cover a few brief concepts of the encapsulation technique. (I've been on the various 'puters for 13 hours now - my eyes are tired. I think I may look like a red eyed dragon)
With this form of transmission, you can piggyback a command set into the normal appearing data that is sent between hosts. Consider ipx tunneling over ip. Here you have one protocol carrying another inside it. The analogy is not perfect but useful. You can send remote commands of ipx (actually spx in this instance) wrapped inside a tcp session. In this way one protocol carries the other to the awaiting zone where the ip traffic is no longer used and ipx continues on its merry way to do your bidding. Yes! You can do this over the internet or an ip only network.
Now with embedded command sets you can "hide" what you really want to do inside an innocuous looking transmission. The accepting host(s) believe they see allowed traffic types but - aha! you have deceived them. Your humble page requests and other poking around seems all innocent. It's kind of the same idea as using port 80 for sending non http traffic.
I remember doing this at a cracking course (all legal of course) and the server was unaware of what we were really sending. The cisco router cooperated as well since it was passing allowed traffic. Haven't done it since but when I get more time I'd like to go back at this because it rocks. :D
Hope to get into this more, later but for now.
February 12th, 2002, 04:37 PM
This definately sounds like it could be an interesting topic. I don't know how the IDS would react in a situation like this. I guess there is only one way to find out.