-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> -----Original Message-----
> From: Hidek, Seth (US - San Francisco) [mailto:shidekDC.COM]
> Sent: Friday, January 19, 2001 3:00 PM
>
> I have noticed two major issues arise in integration of the
> IDS to the enterprise which are interesting discussion points.
>
> [...]
> 2)The second is the ability of the IDs to dynamically
> reconfigure the firewall. While some systems have this
> ability, it remains an organizational choice as to whether to
> allow this ability, and the damage it can cause the IT
> department if the IDs were to shut down a connection (ie, an
> execs e-mail or business application) without a management
> decision. I am curious as to people's experience with a
> more granular approach as to what connections the IDS would
> be able to terminate, and any pros and cons associated with
> this functionality.

Seth,

I have a few thoughts on your second point since I'm very much
exploring that right now. I'm using Snort for my IDS and some
self-cooked batch files that automagically reconfigure my firewall.
When mentioning that, I always get the same response from folks on
the net, mainly 'what if someone spoofs the root DNS server'. I'm
getting tired of responding to these folks...

I think the ability to reconfigure your firewall is great, if
implemented properly. Such a system should:

a) Be able to respond quickly (mine currently takes 3-4 seconds, but
I hope to bring it down with a rewrite of the scripts that instead of
watching the snort log file will actually listen to syslog messages).
The reason is obvious, the faster the response, the sooner you can
'turn off' an intrusion attempt.

b) Be flexible enough to assign blocking criteria to individual
signatures. My system does that by including the amount of time an IP
address should be blocked within the snort rule set. The reason is
simple. A Wingate or Proxy scanner can be blocked for long periods of
time (I use a week) since these type of attacks are clear, meaning
the false positive rate is low. Other signatures with a high false
positive rate, like supposedly malicious content in an email, should
be blocked for short amount of time so that the system can recover
quickly in case of a false positive (i.e. email from that IP address,
which may be a list server, get blocked only for 5-15 minutes. After
that mail starts flowing again. This short interruption is reasonable
for email purposes, but a pain in the neck to someone who was indeed
telnetting into SMTP).

c) Provide a white list. By that I mean a list of IP addresses that
never get blocked, such as root DNS servers. If the script detects a
Netbus scan from a.root-servers.net, which most likely is spoofed,
then it should not configure the firewall to block this connection.
Certain other mission critical connections (source IP's of external
management stations) can be included here as well.

d) And it should of course provide a huge, manual override switch in
case you have to regain control :)

Having the ability to decide IF and HOW LONG an IP address gets
blocked allows you to obviously reduce your risk of successful
attacks by blocking offenders, while at the same time minimize the
risk in doing so (the famous shot in the foot). But this is as good
as it gets. You still depend on the IDS for proper identification of
possible attacks. There is a risk associated with everything, I'd
rather take the risk of not getting email for a short while, then
risking an intrusion.

Regards,
Frank

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.8
Comment: PGP or S/MIME encrypted email preferred.

iQA/AwUBOmz+I5ytSsEygtEFEQL36wCfQtVS94gtb6W1lKQCo8kj3gFTJh0An0gE
VOHSUZCH7t06H0edM/Dud85x
=yVW3
-----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]