RE: IDS White Papers/DocumentsFrom: Matthew Travis Sibley (firstname.lastname@example.org)
- Previous message: Rory: "RE: Certificate logon on Unix"
- In reply to: email@example.com: "IDS White Papers/Documents"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Matthew Travis Sibley" <firstname.lastname@example.org> To: <email@example.com>, <firstname.lastname@example.org> Subject: RE: IDS White Papers/Documents Date: Mon, 29 Oct 2001 20:29:54 -0800 Message-ID: <DPEPIJFAKAOJEGOMHJHKMEDGCAAA.email@example.com>
I can tell you that you have your work cut out for you. It all depends upon
what you are wishing to see. When implementing an IDS solution, most people
want to see/detect as much as possible. There are a few issues: Host based
IDS sensors, network based IDS sensors, or both. Ideally you would want
both. You also want an IDS that is statefull. This will help detect
situations where there is 'all response' and 'no stimulus'. For example, if
you are only seeing ICMP echo responses trying to go inbound to your
network, and see no sign of it's corresponding ICMP echo request leaving,
then something is wrong. Possibly, these inbound packets are crafted.
Someone could have spoofed your network's IP as the source of an ICMP echo
request, and you are seeing the responses. It could mean TFN activity(not
good). Or maybe the presence of a loki trojan somewhere(very not good).
Point being, if your sensors are not statefull, you get very little if no
concept of proper stimulus and response. As for where to put these sensors,
think of it this way: IDS outside the firewall, you see everything as
intrusion attempts. Inside the firewall you see intrusion successes. One
might argue that you need only be concerned with successful intrusions.
Another arguement would be that prevenative steps via monitoring failed
attempts and reconnaissance helps nip intrusions in the bud. An ideal
solution is a full featured statefull IDS package using both host based and
network based sensors placed in the highest traffic areas (near routers and
firewalls), both inside and outside your packet filtering device or
firewall. And remember, care must be gived when implementing signature
filters that do not create too many false positives, or false negatives for
that matter. If it came right down to whether you had to choose between
inside or out? I would choose outside, because I like to be able to see who
is knocking at my door.
As for white papers and documents? You could try www.sans.org.
From: firstname.lastname@example.org [mailto:email@example.com]
Sent: Monday, October 29, 2001 1:01 AM
Subject: IDS White Papers/Documents
Any help with the following greatly appreciated!
Can anyone point me in the right direction for good white papers/documents
on deciding where to locate an IDS on a network?
The background to this is that I want to implement an IDS on a network which
has an incoming/outgoing Internet connection for all users. There is
currently a firewall protecting this connection, but I want to know whether
I should locate the IDS in front of or behind the firewall? Should the IDS
be placed in a DMZ or not?
(As you can tell, I am new to all this!)
Never pay another Internet phone bill!
Freeserve AnyTime, for all the Internet access you want, day and night, only
£12.99 per month.
Sign-up at http://www.freeserve.com/time/anytime