linux security - Jan 2000 - Re: Security problems in bind -- persisting?

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.
This is recommended in such well-regarded places as Chapman & Zwicky's
book "Building Internet Firewalls", ORA, page 106.  When I came to do
this I could find no software so I wrote some (at work, unpublished).

Essentially what you want is a bit of serial traffic code lifted from the
HOWTOs in both a source and a sink:

source:
   syslog sends to a named pipe
   daemon copies named pipe down the serial link

sink:
   a config file to read
      This will list the serial ports to read, and their baudrates etc.
      Also a log rotation policy.  I coded a few, of which probably the
      best one was to rotate files at a (configurable) size and keep a
      (configurable) number of them.   With the constraint that no file
      is removed under an age of 3 months.
   a select() to see when there is new data on each serial port in use
      (I had it happily using 2, didn't try more.)
   a directory per serial port to store logfiles in, absolutely
      raw as they arrive, but separated out into different files 
      (at log entry joins) to keep file size small

There was also a metalog file recording log rotations on the data
streams (filenames, sizes and times).  By keeping this out of band it
could not be spoofed by anything coming down the serial line.
The metalog also contains a daily traffic summary that you can watch
to see easily if something is being flooded or a serial port has died.

It should only take a few days; even if you are new to serial port
programming as I am.


You can run bind non-root in a chroot jail.  Escaping from that is
supposed to be impossible.  I have confirmed that my (work) bind runs
as the "named" user in all 4 IDs shown by "cat
/proc/XXX/status".

Does anyone know adverse effects (beside added net traffic) of simply
not running bind ?

To make your kernel refuse double chroot()s even for root is this the test
people would do in fs/open.c ?
        if (memcmp(current->fs->root,
                   task[1]->fs->root,
                   sizeof(struct inode))) {

And what would be the best response to a failure ?  I'm logging and
sending a SIGKILL, but I suspect that's not ideal.


--
##############################################################
# Antonomasia   ant@notatla.demon.co.uk                      #
# See http://www.notatla.demon.co.uk/                        #
##############################################################

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

On Fri, 14 Jan 2000, Antonomasia wrote:
> Does anyone know adverse effects (beside added net traffic) of
> simply not running bind ?
Bind will have to run _somewhere_ so a safe installation of it
is needed anyway (prepackaged in RPM, if possible).

If you're using it for caching only, you can put something like
this in /etc/named.conf:

options {
	listen-on 127.0.0.1;
}

This will make sure that only the machine itself can use bind,
so remote attacks become impossible.

See http://www.isc.org/ for the full documentation on bind.

regards,

Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.