full-disclosure - Suggestion for IDS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed Sep 28 10:48:05 2005
From: peer at baden-online.de (Peer Janssen)
Subject: Suggestion for IDS

Valdis.Kletnieks@...edu wrote:

>On Wed, 28 Sep 2005 15:54:41 +0700, Fajar Edisya Putera said:
>
>>plan to install IDS to protect our resources
>>    
>>
>An IDS doesn't *protect* your resources, any more than a concealed
>video surveillance camera protects anything.  It may tell you who did it, and
>what they did, *after the fact*, but it won't *protect* you.
>  
>
Really? Is there no software package capable of withholding inspected 
packages until cleared by said IDS?

If I get it right, netfilter actually IS able to reject (and log) 
packages. Why should an IDS sniffing on a level higher up on the "OSI 
chain of command" be unable to do the same?

Dropping packets, closing ports and resetting connections (besides 
logging, maybe notifying users) look like natural useful reactions to 
the detections deliverad of an IDS to me.

Or are we just talking about definitions (regarding the "D" in IDS), 
instead of talking about IDPS-ses which the OP clearly seems to imply? 
(P for prevention)

So what are the IDPS-ses you recommend?

Peer