Andres, just want to check on 2b there. A UDP attack cannot be blocked
by a non-inline network IDS because there's no way to stop it because
UDP is connectionless (I hadn't thought of that, good point). I'm not
too sure on the terminology but for the TCP aspect I'm assumeing
in-line means the IDS is on the same wire whereas the non-inline IDS
you mention is just monitoring the traffic but isn't between the
attacker and target, which is why it can't just drop the traffic. Is
that right?
On 6/25/05, Andres Riancho <andres.riancho@gmail.com> wrote:
First you have to separate the two different appliances.
1) Firewalls are rule based and they block what YOU have configured
, so unless they have a OS / TCP / IP / etc problem in the firewall it
will drop all traffic that you have defined on your ACL's.
2) IDS's can be placed in several places.
a) If a host IDS (not in promisc mode) detects a packet that
matches an attack from his policy and has a rule configured to drop it ,
it will do it.
b) If a network IDS ( not in inline mode and in promisc mode)
detects a packet that matches an attack from his policy and has a rule
configured to drop it , it will try its best. What's this ? When the
attack is TCP based , some IDS's send RST packets to sender and
destination in order to close the connection and mitigate the attack
,but when the attack is UDP based , you cant drop the connection and the
attack will get to its destination.
c) If a network IDS ( inline mode - briged ) detects a packet
that matches an attack from his policy and has a rule configured to drop
it , it will do it. All attacks can be droped , UDP / TCP / etc.
Cheers,
Andres Riancho
Ishay wrote:
Hi
Here is theoretical question:
Can you think on possible scenario in which firewall/ids will detect
that he has been compromised but he won't be able to block it?
Thanks,
Ishay
--
"To catch a theif, think like a theif. To catch a master theif, be a
master theif."
