The matter of placing dual homed IDS's is very tricky because (IMHO) it
depends on what scaling tou're going to need.
Having holes in fw's for agent--console communications (even encrypted,
a la RealSecure) might be desirable on large scale deployments and
centralized management frameworks with all the usual problems (time,
resources, false positives, IDS tunnig and so on).
However, a small "network security management network" isolated from
internal network and only connected to the clients directly (switched
environment) with all the pieces for monitoring and reporting (syslog
servers, management consoles, small DB) might do the work and relief
some of future problems.
There are a few solutions for large traffic segments, most of them
hardware.
CISCO as a hardware based IDS very nice.
Consider to the fact that load balanced and redudant fw's can increase
response to requests and generate more traffic.
As for the scriptie kiddie, it can be very usefull for learning and
might allow better ACL's management and tunning.
The worst part is the time needed for this....
"Claussen, Ken" wrote:
>
> >From a security perspective, between the external interface and the ISP
> router will provide the most information about attacks from external
> sources. Be prepared for a lot of tuning though I have seen Napster produce
> false Back Orifice 2K alarms, and other such false positives. The only down
> side to this is it wont give you any information about internal attacks or
> compromises. If a system has already been compromised you will only see the
> return traffic to the attacker without a sensor on the inside also you only
> get half the picture. If this is a Win2K box then you could run several
> adapters in promiscuous mode, one on each segment, just make sure it has
> resources to spare, duall PIII 600, SCSI U160, 512MB PC133, should be able
> to monitor a LAN(100MB) and a WAN(Dual homed T1s) segment without dropping
> packets. Be sure to have a machine to Archive the logs to. One suggestion I
> would make is don't connect the sensor management interface directly to the
> Internal segment. Put the management station and internal interface of the
> sensor in a second DMZ. Then create Rules to limit traffic (FW-1) or set the
> priority higher than the public DMZ (PIX). If you are really paranoid or
> sensible, depending on how you look at it, then filter traffic (Router with
> ACLs) to and from this segment after leaving the firewall so a compromise
> wouldn't mean "Unchecked" access to the internal LAN. Setup a syslog server
> to monitor all the policy violations In theory an Unbound adapter presents
> no signature to the attacker, but what is theory today may not be tommorrow.
>
> Ken Claussen MCSE CCNA CCA
> "The Mind is a Terrible thing to Waste"
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of John Tannahill
> Sent: Saturday, January 20, 2001 9:25 AM
> To: [EMAIL PROTECTED]
> Subject: Placement of IDS Sensor
>
> Looking for opinion on placement of IDS sensor on a network segment which
> includes Firewall external interface and ISP router (there is no screening
> router behind ISP router). The IDS sensor nic on this segment would have no
> protocols bound to it (Real Secure network sensor). Operating system would
> be stripped down NT or Win2k. The issue is that second nic on sensor
> machine would go to management console on internal network - so compromise
> of sensor would allow direct uncontrolled access to internal network.
>
> Questions:
>
> - Is this deployment safe?
> - Is there any way to compromise this machine from Internet / ISP bearing in
> mind that there are no protocols bound to the nic and it is acting only in
> promiscouous traffic collection mode?
> - are there any tools which could identify the machine on the segment?
> - any suggested penetration tests?
> - would it be prudent to protect internal network by placing packet filter
> or basic firewall appliance between sensor machine and internal network
> (only traffic is IDS data collection and management)?
> - would deployment be safer with screening router between firewall and ISP
> router?
> - would more effective deployment of sensor(s) be on firewall's internal and
> DMZ interfaces (IDS would then not see traffic dropped or rejected by
> firewall)?
>
> Any thoughts are welcome
>
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
--
"And you may ask yourself,
Well ... How did I get here?"
- Talking Heads
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
