Log

Chkrootkit is a tool that searches for rootkits, trojans and other signs of break-ins on your system. Like most security scanners, it sometimes generates false positives. Chkrootkit doesn't have a native way to filter those out. From the FAQ:

[Q:] chkrootkit is reporting some files and dirs as suspicious: `.packlist', `.cvsignore', etc. These are clearly false positives. Can't you ignore these?

[A:] Ignoring some files and dirs could impair chkrootkit's accuracy. An attacker might use this, since he knows that chkrootkit will ignore certain files and dirs.

This is true, but getting an email every day is simply too annoying, and makes me skip chkrootkit generated emails on occasion because "It's probably a false positive anyway". So here's a small guide for setting up a filtering of chkrootkit's output.

First, we create a file /etc/chkrootkit.ignore which will hold a bunch of regular expressions that will match everything we don't want to be warned about. For instance, I've got a machine that needs to have a dhcp client installed. Chkrootkit keeps on generating emails with these lines:

eth0: PACKET SNIFFER(/sbin/dhclient[346])
eth1: PACKET SNIFFER(/usr/sbin/dhcpd3[1008])

So what we do is create the file /etc/chkrootkit.ignore and put the following in it:

/etc/chkrootkit.ignore

^eth0: PACKET SNIFFER\(/sbin/dhclient\[[0-9]*\])$
^eth1: PACKET SNIFFER\(/usr/sbin/dhcpd3\[[0-9]*\]\)$

In order to test if the rules we created are correct, we put the two lines with false positives in a separate file (/tmp/chkrk-fp.txt) and run the following:

test:

[root@sharky]/etc# cat /tmp/chkrk-fp.txt | grep -f /etc/chkrootkit.ignore
eth0: PACKET SNIFFER(/sbin/dhclient[346])
eth1: PACKET SNIFFER(/usr/sbin/dhcpd3[1008])

The lines that should be filtered out of the chkrootkit output should appear here. If nothing appears, or if not all of the lines that you want to filter appear, there's a problem. Refine your regular expressions in /etc/chkrootkit.filter until it works.

Now we need to modify the chkrootkit cronjob so that the false positives are filtered. To do this, we edit /etc/cron.daily/chkrootkit. Below is a patch that shows what should be changed. You can apply the patch with the 'patch' command, or you can manually add the lines that start with a '+', replacing the lines with a '-'.

--- /home/root/foo      2007-11-21 11:53:58.532769984 +0100
+++ /etc/cron.daily/chkrootkit  2007-11-21 11:54:00.689442120 +0100
@@ -1,27 +1,28 @@
 #!/bin/sh -e

 CHKROOTKIT=/usr/sbin/chkrootkit
 CF=/etc/chkrootkit.conf
+IGNOREF=/etc/chkrootkit.ignore
 LOG_DIR=/var/cache/chkrootkit

 if [ ! -x $CHKROOTKIT ]; then
   exit 0
 fi

 if [ -f $CF ]; then
     . $CF
 fi

 if [ "$RUN_DAILY" = "true" ]; then
     if [ "$DIFF_MODE" = "true" ]; then
-        $CHKROOTKIT $RUN_DAILY_OPTS > $LOG_DIR/log.new 2>&1
+        $CHKROOTKIT $RUN_DAILY_OPTS | grep -v -f $IGNOREF > $LOG_DIR/log.new 2>&1 || true
         if [ ! -f $LOG_DIR/log.old ] \
            || ! diff -q $LOG_DIR/log.old $LOG_DIR/log.new > /dev/null 2>&1; then
             cat $LOG_DIR/log.new
         fi
         mv $LOG_DIR/log.new $LOG_DIR/log.old
     else
-        $CHKROOTKIT $RUN_DAILY_OPTS
+        $CHKROOTKIT $RUN_DAILY_OPTS | grep -v -f $IGNOREF || true
     fi
 fi

Next, we try running chkrootkit, to see if anything shows up:

[root@sharky]/etc/cron.daily# ./chkrootkit
[root@sharky]/etc/cron.daily#

There is no output, so our false positives are now being ignored.

I didn't know it, but (Open)SSH supports setting up a Socks5 proxy:

-D [bind_address:]port
  Specifies a local ``dynamic'' application-level port forwarding.
  This works by allocating a socket to listen to port on the local
  side, optionally bound to the specified bind_address.  Whenever a
  connection is made to this port, the connection is forwarded over
  the secure channel, and the application protocol is then used to
  determine where to connect to from the remote machine.  Currently
  the SOCKS4 and SOCKS5 protocols are supported, and ssh will act
  as a SOCKS server.  Only root can forward privileged ports.
  Dynamic port forwardings can also be specified in the configura-
  tion file.

Socks5 is pretty neat, as it allows you to proxy stuff without the server having to know anything about the way the client works. For instance, if we give the following command:

$ ssh -N -D 127.0.0.1:8080 todsah@sharky.electricmonk.nl

We can now tell all kinds of clients such as web browsers and instant messaging clients that there is a Socks5 proxy running on the localhost at port 8080. SSH will forward all connections made to port 8080 to the sharky.electricmonk.nl host (all encrypted of course).

So, say we tell Pidgin that it should connect your MSN account through the Socks5 proxy at localhost:8080 by opening the Accounts (Ctrl-A) → Click MSN account → click Modify → Advanced tab → Proxy options → Proxy type = SOCKS5 and setting it to Host: localhost, Port: 8080. Now, when we reconnect to our MSN account, all MSN traffic will be routed over an encrypted SSH tunnel to the sharky.electricmonk.nl host, and will enter the public Internet from there.

This works great if you don't trust the network you're currently on, but don't have access to a VPN for instance. You also don't have to specify a single forward for each application/port like you have to do when you use ssh -L. You can use the same SOCKS5 proxied port with multiple applications, as long as they understand SOCKS5.

Theo de Raadt on virtualisation security:

> Virtualization seems to have a lot of security benefits.

You've been smoking something really mind altering, and I think you
should share it.

x86 virtualization is about basically placing another nearly full
kernel, full of new bugs, on top of a nasty x86 architecture which
barely has correct page protection. Then running your operating
system on the other side of this brand new pile of shit.

You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can't write operating
systems or applications without security holes, can then turn around
and suddenly write virtualization layers without security holes.

> Anything we can do to increase security, *including* setting up VMs (of any
> flavor) is an improvement [that also increased hardware utilization].

This last sentence is such a lie.

The fact is that you, and most of the other fanboys, only care about
the [that also increased hardware utilization]. The yammering about
security is just one thing — job security. You've got to be able to
sell increased harwdare utilization in a way that does not hang you up
at the end of the day.

Of course, de Raadt is right… in his own tiny little world at least. Running services which would normally run on multiple machines on multiple hypervisored instances on a single host machine would indeed be less secure than running them from multiple physical machines.

But running multiple applications on virtualized machines which would normally run on a single machine is more secure, simply because it adds another layer of protection.

But, as usual, de Raadt's complete ineptitude when it comes to communications totally negates any point he's trying to make and only serves to rile up people against his cause.

It's the chrooted story all over again. Yes, chroot isn't completely secure. Yes, chroot isn't meant as a security construction. Yes, running multiple services on a single machine that would normally be run on several separate physical machines is less secure. That doesn't mean chroot (and virtualisation for that matter) can't add an extra layer of security if used properly!

Theo de Raadt's problem is that he views security the way cryptography experts view cyphers: as an absolute. But security isn't like math. It's not absolute. There are right and wrong ways of doing security. De Raadt is like that security consultant who says: "You must have randomly generated passwords consisting of at least eighteen characters, lower and upper case, numbers and symbols, nothing repeated twice, completely unique and changed every week, or your being insecure!", all the while ignoring the fact that that kind of password policy will only force people to write down passwords on a yellow-note under their keyboards. In theory, they're right. In practice, they're wrong. These people become blinded by their own viewpoint. Just as these so-called security consultants are blinded by their belief that strong passwords equal security, so is Theo de Raadt blinded by his belief that virtualization doesn't improve security.

Perhaps it's time to stop listening to de Raadt, and start listening to people with a broader overview of the situation.

So, I've read there's another virus on the loose. *g* When will this end? I'll tell you: never. At least, not until these virusses do some radical damage. They aren't destructive enough against the right targets. Right now, these virusses do create a lot of problems and damage to infrastructures and companies. The problem is, home users don't give a shit. There are lots of sites out there which educate the people on how to avoid such virusses, but do they read them? Do they learn from previous virusses? Hell no. Why should they care, all the virus does is replicate. It doesn't delete all their digital camera pictures, mp3's, downloaded movies or porn, so they don't give a rat's ass.

When the propagators of these virusses, the home users, start feeling the pain caused by these virusses, then they will take the time to think for a couple of seconds and do something about it. E.g. install and REGURALY UPGRADE their virusscanners, stop clicking of everything that say's click me, run the WSH files that will protect their inboxes from crap.

Disclaimer: I haven't actually looked at how MyDoom propegates at all, so I might be totally off on this. But since I'm not seeying as much as a glimp of this virus, I suspect it spreads in the usual fashion