[linux-security] Re: Security problems in bind -- persisting?

[Zygo Blaxell <zblaxell linuxmaster hungrycats org>]

In security.redhat.linux-security, you wrote:
>Antonomasia wrote:
>> As for safe logging I suggest serial lines onto a standalone box.
>
>Lots of people suggest this. However, this is not all that good a
>suggestion. Let me explain why:
>[...]
>The bandwidth of a serial line is seriously limited. 

There's some steps you can take to increase the effective bandwidth
over a plain serial line:

1.  Compression before transmission over the serial line.  zlib makes it
relatively easy to do this even in a perl script.  You could probably
get away with just filtering through 'gzip -9' but if the attacker can
kill the gzip process quickly enough (i.e. in the current 4K or 8K of
compressed output block) then you lose the messages.  Major disadvantage:
it's trivial to corrupt the data stream beyond recovery.

2.  Use an ethernet card (100BaseT if necessary) with a dedicated
connection to the log listener as a "serial line", with a very carefully
secured box as your listener.  The secure box shouldn't be running
a network stack when plain 'tcpdump -s1536 -w- > logfile' will do.
Major disadvantage: more bandwidth for your log server means more
bandwidth for your attacker too.

>If you for
>example have a server sitting on a T1 (1.5 Mbit right?) then you could
>"ping" 64 byte packets to the firewall which would start logging these
>as they come in. For example these can be syn packets to a firewalled
>off port.

3.  Choose your dataset to be logged carefully.  Use a bit of data
analysis on the machine generating the logs:  is this a recognizable
traffic pattern, such as a port scan, smurf attack, ping flood?  Log the
results of the analysis plus some fixed-size random subset of the data
involved (enough to verify that the analysis was correct, but not enough
to fill the disks before you plan to have them filled).  I don't know of
any off-the-shelf tools that will do this; I just start with a perl script
reading system logs and tweak it whenever something new is thrown at me.

Of course one problem with all of these solutions is that the attack could
be successful before the log data gets to leave the attacked machine.
Secure logging relies on having a secure exposed system to begin with.

I've lost count of the number of times I've found a web server dead
in the morning because someone found a new DOS attack that kills the
network stack instantly.  Logs?  What logs?  The only way I'd be able
to capture information about that sort of attack would be to attach a
machine with no OS-level network stack to an unswitched hub and simply
store a ring-buffer of the last N gigabytes of raw network traffic that
went by, for N = (gigabytes of bandwidth per second) * (maximum number
of seconds between noticing a problem and stopping the raw traffic log).

>The "When disk full: drop newer messages" policy allows the hacker to
>fill your disk with innocent stuff, and then hack you.
>
>The "when disk full, rotate the older messages out of the way" allows
>the hacker to first hack you and then push those events off the
>logging horizin by generating lots of innocent stuff after the fact...

In general, an unattended box cannot have a secure, reliable logging
facility unless it has really _rigid_ performance limitations to go
with it.  If the logging bandwidth is exceeded, the machine should halt
until it is cleared.  If the logging disk fills up, the machine should
power off until it is emptied.  If that creates a denial-of-service
problem, then you need more logging bandwidth, a better log dataset, or
an adjustment of your security policy to match your available resources.

>Now, having a high bandwidth channel to your logging server isn't
>a fixall either. Then you have to worry about how fast a hacker can
>fill your logging disk, and possibly start calling sysops out of their
>bed if such an attack is detected as "in progress". 

Your logging disks have to be big enough to collect information for the
time between when an attacker launches an attack and when your 24x7
live human monitoring notices the attack in progress and takes steps to
stop it.


-- 
"It's almost like we're doing Windows users a favor by charging them money
for something they could get for free, because they get confused otherwise."
 - Larry Wall.  GPG at home: 2B32546D21A50DB220C8  AF101D4A610E69722DEE
                GPG at work: CC25D2141B4B276751B9  51E558DD13B9875BC08E