Search this site





Tripwire on Ubuntu

While looking over the default tripwire policy that comes with Ubuntu, I noticed someone decided that it was important to monitor all of /proc. So, if you use the default policy in Ubuntu, expect to get emails every time 'tripwire --check' runs becuase /proc doesn't stay constant.

The config that comes with tripwire's source code specifically skips monitoring /proc for obvious reasons, so it was someone downstream (debian? ubuntu?) who decided /proc should be monitored. Monitoring non-process directories in /proc on Linux is probably reasonable, but all of /proc is just silly. Here's the output of "tripwire --check" with the default ubuntu config:

< hundreds of lines of pointless /proc/PID/ entries lines edited out >
Terrible default setting. You're guaranteed to have this report every time even on a 100% idle system, because tripwire's process entry will show up different every time it runs.

Upgraded to ubuntu 8.10

Upgraded my workstation to ubuntu 8.10 without much stress. Horray.

Feels like firefox is running slower now, but that might just be perceived slowness or network crappiness. Still, I ran top(1) and saw some new 'chipcardd4' process waking up every few seconds and bursting cpu. It wasn't doing enough to cause problems, but I'd never seen it before. Checking strace showed it in a loop sleeping for 750ms, twice, then reading through /sys/devices/. Doing "sudo ./libchipcard-tools stop" made it go away.

Doesn't linux have inotify so programs don't have to do sleepy-loops checking the filesystem?

ssh honeypot.

Using slight variations on the techniques mentioned in my previous post, I've got a vmware instance running Fedora 8 that permits any and all logins. These login sessions are logged with script(1).

Fedora 8 comes with selinux enabled by default. This means sshd was being denied permission to execute my special logging shell. The logs in /var/log/audit/ explained why, and audit2allow even tried to help make a new policy entry for me. However, I couldn't figure out (read: be bothered to search for more than 10 minutes) how to install this new policy. In searching, I found out about chcon(1). A simple command fixed my problems:

chcon --reference=/bin/sh /bin/sugarshell
The symptoms prior to this fix were that I could authenticate, but upon login I would get a '/bin/sugarshell: Permission Denied' that wasn't logged by sshd.

There are plenty of honeypot software tools out there, but I really wasn't in the mood for reading piles of probably-out-of-date documentation about how to use them. This hack (getpwnam + pam_permit + logging shell) took only a few minutes.

As a bonus, I found a feature in Fedora's yum tool that I like about freebsd's packaging system: It's trivial to ask "Where did this file come from?" Doing so made me finally look into how to do it in Ubuntu.

FreeBSD: pkg_info -W /usr/local/bin/ssh
/usr/local/bin/ssh was installed by package openssh-portable-4.7.p1,1
Fedora: yum whatprovides /usr/bin/ssh
openssh-server.x86_64 : The OpenSSH server daemon
Ubuntu: dpkg -S /usr/bin/ssh
openssh-client: /usr/bin/ssh

Let's see what I catch.