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

[R E Wolff BitWizard nl (Rogier Wolff)]

Antonomasia wrote:
> Kyle Ferrio:
> 
> > Unfortunately, his last act was to rm -rf /var/log so I don't know
> > exactly how he got root.  Definitely a remote exploit, though.
> > Does anyone have advice on mirorring syslog to "secret" locations,
> > preferably encrypted?  Losing logs makes it hard to do a risk assessment.
> > For all I know, I'm still vulnerable after updating bind.
> 
> 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:

First of all, you should be assuming that the "bad guy" knows how your
system works. Worst-case attackers simply do, because they used to work
for you. In practise, the one attacker who guesses right gets in behind
your back....

The bandwidth of a serial line is seriously limited. 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.  A log entry has the relevant info, and thus ends up larger
than the 64-byte packet that came in. So now I could start sending
these packets at 1.4 Mbit, causing at least 1.6 Mbit of "logging
traffic" over the 115k2 serial line. 

Sure, you don't intend to log the full packetload of a T1. But in
practise there exists a packet that causes more log than it costs
bytes on the link. Primitively you'd send the same packet over and
over again. Most syslogs will however compress that to one entry every
minute: "Last entry repeated xxxxx times". But alternating two
different packets that generate different messages will work around
that. You will have to assume that a hacker can find a way to generate
more log than the bytes in the packets he's sending. 


If the log writes are blocking, then you've clogged up the whole
machine: Denial Of Service. (I -=know=- you're not planning on logging
that much. That's why you have to plan for it happening anyway.)

If the system drops logging messages that don't fit through the
logging pipe, the system must be dropping more than 90% of the logging
packets, so a hack that would normally end up in the log with two or
three lines has a bigger than 50% chance of getting dropped.

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". 

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...

Note that a 6G disk can hold around 60G of logging messages,
especially if someone is trying to flood your logging server, because
logs do compress pretty good (around 1 to 10). However, you can't
compress 200k of messages per second on a 486....... (My celeron 466
does 2M per second, so handling a T1 is OK, but 10mpbs is about the
limit.... :-)

				Roger.

-- 
** R E Wolff BitWizard nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
 "I didn't say it was your fault. I said I was going to blame it on you."