Firewall Wizards mailing list archives
RE: DMZ best practices
From: David LeBlanc <dleblanc () mindspring com>
Date: Wed, 27 Jan 1999 09:11:28 -0500
At 09:11 AM 1/22/99 +0100, Security wrote:
Of course, an ID sensor outside the firewall is potentially vulnerable. When the ID sensor has a second NIC you can monitor a network segment with no protocol stack involved (on the first NIC) while also using an out-of-band channel (on the second NIC) for communication with the ID sensor. When there is a firewall between the second NIC and the internal network, you have a well-protected ID configuration. I have seen several discussions about cutting the transmit wires of the cable between the ID sensor and the monitored network. In this case, the ID sensor is physically secured.
This is a bit of an interesting problem - it is quite common to run an IDS with no stack attached, as it makes the IDS only vulnerable to its own bugs on that interface. I wouldn't recommend cutting the transmit wires, as you might want your IDS to respond to certain inputs. One scenario would be to put the IDS reporting and control channels (2nd NIC) on a private network. At this point, if someone can manage through physical access, or even operator error to reattach the stacks to the external interfaces, we now have a nice conduit to go right around the firewall. A method I'd prefer would be to set things up so that the IDS control needs to reach out through the firewall, but such that the control interface is still protected. You still have the same problem, but then if the worst case happens and the stack gets reattached and your IDS suddenly turns into a router, they don't have a direct conduit to the soft, juicy insides.
You can monitor the DMZ with a sensor inside the DMZ. This is a proper solution, but in my opinion, a well-protected sensor outside the firewall does the same.
Something to consider here would be how detailed your decodes would be - the sensor outside the firewall would very likely be looking at the most traffic, so you'd probably want to reduce the number of decodes to get better performance. The DMZ should be seeing less traffic, and so should have more things being checked for. David LeBlanc dleblanc () mindspring com
Current thread:
- RE: DMZ best practices, (continued)
- RE: DMZ best practices Andreas Haug (Jan 20)
- Re: DMZ best practices John Kozubik (Jan 20)
- Re: DMZ best practices Security (Jan 20)
- Re: DMZ best practices Dominique Brezinski (Jan 21)
- RE: DMZ best practices Bill_Royds (Jan 21)
- RE: DMZ best practices Andreas Haug (Jan 26)
- Re: RE: DMZ best practices Robert MACDONALD (Jan 21)
- Re: RE: DMZ best practices Joseph S D Yao (Jan 26)
- RE: DMZ best practices Security (Jan 26)
- RE: DMZ best practices Dominique Brezinski (Jan 26)
- RE: DMZ best practices David LeBlanc (Jan 27)
- DMZ best practices Arjen Rijpma (Jan 26)
- RE: DMZ best practices John Kozubik (Jan 28)