Re: R: Reactive Firewalls

[Rick Smith <rsmith () securecomputing com>]

At 11:47 AM +0100 2/15/98, Franco RUGGIERI wrote:
> I joined this mailing list to learn, so I apologize in advance if my
> message is too trivial.

OK, I'll try an answer:

> > From what I read on this thread I wonder if a possible step ahead (not
> *THE SOLUTION*) could be a firewall (I don't know if there are any) which,
> upon recognition of an ongoing attack or when its logfile is full, makes
> basically four things:

> 1) yell like an eagle to warn the administrator (as usual)

OK

> 2) shut off its connection to the net

This is where the dispute arises. This interrupts work in progress. In some
environments, the risk of a penetration might not be as severe as the loss
resulting from interrupting some business activity. This is a local
decision, and it depends on the purpose and use of the Internet connection.
Traditionally, Internet connections were conveniences for companies, and
"real" work took place via other channels. But if the Internet is essential
to getting work done, then any service interruption could be serious.

> 3) pass the firewalling task on to another firewall; this will reduce to a
> minimum the service interruption, though, probably, cryptographic sessions
> and authentication processes still in flight, and the likes, will have to be
> restarted;

I don't see the benefit of this. How is it different from simply restarting
the existing firewall? That has essentially the same effect -- you stop all
connections, including the attacker, and everyone starts over. Once things
are running again, the attacker can continue the attack, just as the
legitimate users reestablish their connections. In fact, the confusion
caused by the shutdown and restart may allow the attacker to better
disguise the attack. If the second firewall is intended to provide extra
log storage space, then we're simply deferring the problem. There's nothing
to prevent logs in both machines from filling up.

> 4) automatically start a procedure that saves the logfile (e.g. on a PC
> connected via serial line, ...

If a system is unattended, automatic, and it keeps logs, then it must have
a strategy for reacting to the problem of running out of log space. Sending
it to another machine is not a solution, it simply defers the problem until
the other machine runs out of storage, too. In fact, that approach could
set the stage for a worse problem by tying up even more of the site's
storage capacity. It can be very difficult to respond to an attack if you
don't have any storage available for working on the system. While this
might slow down the attacker, it definitely slows down the defenders.

Rick.
rsmith () securecomputing com