In regards to the packet dropping issue it's not clear whether you're asking
about host/NIC handling 100Mbig Full duplex, or if it's about the
possibility of not getting the packets in the first place due to bandwidth
limits. 

In the first case,requirements/metrics for sensor hardware can be found on
ISS web. Forums such as this (check the archives) contains lots of
real-world experiences of what worked, and what didn't. 

In the second case, it's simple: If you underspec your listening interface /
mirror port you will loose packets. As the song goes, 'Don't know where,
don't know when'. That's the complex part. If the sum traffic of mirrored
ports exceeds the mirror port capacity, packets will be lost. It could
happen burstily or sustained, depending on the switch being gentle &
buffering or not.

Other posters have dealt with placing sensors on the DMZ or just on the
firewall side. If you want to see intra-DMZ traffic, there's little you can
do about possible packet loss. A single port, not to mention the sum traffic
of all ports, exceeds your 100Mbit interface.

If you are only interested in the firewall side, I suggest making the
firewall and the sensor interfaces equivalent. This (almost, because
switches are fun) guarantees that whatever the firewall sees, the sensor
sees. 

If you're only listening on the firewall side, just take the switch out of
the equation - use a hub (or even better, a tap) on the firewall interface.
It's a lot less complex, and really guarantees that the sensor sees what the
firewall sees. 

=======
I see a lot of issues in this forum relating to bandwidth and probabilities
of packet drops, and in many cases I just don't undestand why. Why have
Gigabit or 100Mbit router & firewall interfaces if the ISP connection is
much slower? Why use full duplex on a link that won't have a colission in a
million years anyway? This causes a problem with IDS. More importantly - a
problem that is entirely optional. (It may even be advantagous to have
10Mbit local/downstream collission rather than burdening a stack somewhere
upstream with buffering). 

Same thing with switches - just because they're fun and useful in a lot of
places, they don't need to be where when a hub or tap does just as well. And
they shouldn't be used when the switch causes a problem. 

A third issue, the one that ties the above together, is
security-as-an-optional-extra. If you have IDS, chances are it's because
it's part of your security. You probably want to lower risk in some way. 

So why on earth would you take the chance of missing traffic because your
IDS can't keep up??
That is, if you have the option to limit the rates to what the IDS can
handle - so what if you loose some theoretical and generally unused
performance - or buy a bigger IDS. It would be nice if the best-effort
paradigm applied to what a particular IDS can identify, not to how much it's
beeing fed. 

Some may disagree, and to those who do, I'll offer a wonderfully
black-and-white non-sequiteur just to put a lid on it:  

How would you feel if your firewall stopped inspecting packets over a
certain bandwidth threshold? Not so good I'd bet. 

Anyway, I get the feeling technology lust sometimes go too far. Using a hub
really isn't a social faux pas. On that note, I wouldn't invest in two
spiffy SBus cards, so I have... a coax connection between two Sparcs at
home. The one sparc is an old IPX without the Weitek chip with IPTables on
Linux as well as snort. It works just fine, because my puny DSL connection
will never saturate that stuff. But, shhhh, don't tell anyone - I'll never
be envited to another party (no, no,not a LAN party). I'd go on, but it
seems a thicknet-AUI tap has just started emitting blue smoke...
=====

Regards,

Robert


-----Original Message-----
From: as dsf [mailto:xpidissii@;yahoo.com]
Sent: Wednesday, November 13, 2002 9:11 AM
To: [EMAIL PROTECTED]
Subject: [ISSForum] Basic IDS Deployment Questions


It happens that I am currently discussing a
implementation where I have a basic deployment of
Checkpoint Fw-1:

           
                     (Internet)
                          +
                        Router
                          + 
                     Firewall
                          + 
                + - - - - +- - - - -+
                +                   +
(TrustedZone-Switch)          (DMZ-Switch)




There's a firewall interface in every zone , that's in
every switch dedicated to each security zone.Each of
the switches is a Gigabit switch, with servers
connected to them with gigabit nics.IDS implementation
involves configuring an IDS Network Sensor in every
zone (Tz,Dmz,Public Zone)Questions:1.Mirroring:Is it
enough to mirror Firewall Interface on Network Sensor
for each zone or all of the ports in a given
switch.For instance, for DMZ switch with 10 servers
connected to it, should I mirror only the firewall
interface to DMZ-network sensor or should I mirror all
the 10 ports to it?Obviously , every server has one of
the firewall interface as default gateway.2.What if
set up network sensor with a 100FullDuplex interface,
is there any great chance nbetwork sensor drop a huge
amount of packets? Has anyone estimated this loss of
capture by network sensor?JaimeO.

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
_______________________________________________
ISSForum mailing list
[EMAIL PROTECTED]

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo
_______________________________________________
ISSForum mailing list
[EMAIL PROTECTED]

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo
_______________________________________________
ISSForum mailing list
[EMAIL PROTECTED]

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo
_______________________________________________
ISSForum mailing list
[EMAIL PROTECTED]

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to 
https://atla-mm1.iss.net/mailman/listinfo

Reply via email to