According to "Neil J. McRae" <neil@COLT.NET>:
> Travis,
>
> I more or less agree but often by the time you know about the
> DOS often the machine you need to get access too won't respond
and
> you can't then manually implement the filters without taking
the machine
> off the network for a period of time.
My apologies for the pre-morning-coffee post -- I should have
been a little more clear there. I consider it a self-caused
denial of service if you shun access to important hosts or
regular clients based on a false positive. Any attack that is
shunned and can be spoofed, then, can be used to block access to
arbitrary hosts just because the IDS thinks they're doing
something nefarious. This is where the "DoS yourself" line came
from ...
For a public web site, as an example, I'd start by running nmap
scans with forged source addresses of AOL's proxy servers, or the
root nameservers, in an attempt to cause the end user of the NIDS
system to block themselves off from some set of hosts, or write a
quick tool to send an http get that included
"GET /scripts/..%255c../winnt/system32/cmd.exe" (even though the
box on the other end might or might not be NT) in an attempt to
get false shuns that caused large-scale service disruption.
Depending on how the NIDS is configured, it might also be
interesting to spoof internal hosts and see if you could get
traffic to them blocked at the border.
What it comes down to is that I don't trust the IDS to write an
ACL intelligently, or to differentiate between an attack that
might have been spoofed and one that could not have been spoofed.
I'd rather see someone developing an ACL that'll talk to my
border routers and automatically put in my pre-defined rate-limit
ACL in response to a flood rather than trying to block traffic
from an arbitrary host based on the entire signature set ...
Cheers.
-travis
>
> Regards,
> Neil
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:08 EDT