Yes an IDS will not detect everything. What it does detect should be usefull and give you an idea of how many people are looking at your network. I recommend "snort" for a network IDS and "tripwire" for a local machine IDS. Logwatch is also a good program to have installed on your local machines. http://www.snort.org http://www.tripwire.com http://www.whitehats.com (ids information and snort rules update) http://www.icewalk.com/softlib/app/app_00341.html (logwatch) Thomas Biege wrote:
On Tue, 9 Jan 2001, Nix wrote:
At 09:25 PM 6/01/2001 +0000, you wrote:
Thomas, Can you advice us a IDS that dont suck? I just use Linux at home so I'll probably keep using many things that suck, at least for try to learning how they suck, but others may need to know other IDS apps, for corporate use. http://website.lineone.net/~offthecuff/HIDS.htm (http://www.networkintrusion.co.uk)
btw ... also many commercial stuff suck, in this case vulnerability scanners: http://www.nwc.com/1201/1201f1b1.html
IMHO IDS systems are close to worthless. At best they lets you know that you have already been broken into
That's what a IDS is designed for. For preventing intrusions you have to patch your system and have a good security infrastructure.
Often pattern matching network based IDS are not that usefull, because they just detect attacks, that could be avoided by a packetfilter and a good administrator. NIDS, that use statistical methods or strict-misuse detection (mjr called it buglar alarm detection, AFAIK) may also be able to provide information about unknown attacks, but they produce to much false alarms. Encrypted network traffic is bad for the old sensor (promisc interface) based NIDS approach (these IDS are nevertheless able to detect malicious packet header), but network node NIDS (every host has a agent, that reads the unencrypted data from the stack above the encryption layer) are able to read network traffic, that is encrypted by IPSec or other VPN technologies. Unfortunately application layer encryption, like SSH, couldn't still be read.
Host based IDS don't have these limitations. Most of the time they analyse log files, syscalls and access to system objects (Solaris: BSM Logging, AIX: Audit Logging, NT: Event Logging (?)) They are also able to see attacks, that happen on the console or over a dial-in/serial tty.
There are some more pros and cons I don't want to discuss. But I think it's better to have a IDS, then not to.
I think a IDS is just worthless, if you buy one, that isn't able to fit our needs and if you don't know the strong and weak parts of you product. If you have a pattern matching ID system, then keep your rule/pattern database up to date or it will become worthless too!
at worst, they breed a dangerous false sense of security.
That's not the fault of the IDS. :-)
As a greater percentage of network traffic is being encrypted every day, and an IDS cannot "see" into encrypted traffic, it means that your IDS has a huge blind-spot.
see above.
This is only going to get worse. Test out any of the IIS exploits if you don't believe me (the unicode exploit is a good example because it works against IIS4 and IIS5) this exploit will sail straight past your IDS without raising a murmur, allow you to execute arbitrary programs on the target machine, and even download the servers Private SSL key. FUN!
Hiding attacks for IDS remebers me of hiding virus code for virus scanners. It's the old game on another level. Pattern matching IDS are worthless aginst people w/ a little skill, that's true. But what if you run IIS in a sandbox to analyse it's sys-/libcall bahavior? You will detect it.
BTW, what's about adding a new pattern to your IDS's database?
Bye, Thomas -- Thomas Biege, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: thomas@suse.de Function: Security Support & Auditing "lynx -source http://www.suse.de/~thomas/thomas.pgp | pgp -fka" Key fingerprint = 09 48 F2 FD 81 F7 E7 98 6D C7 36 F1 96 6A 12 47
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com