Category: Tech

The sudo(8) privilege management tool is very admin-friendly in that it logs successes and failures. I don’t really care when my users successfully use sudo. I do care when they use it unsuccessfully, however. A sudo failure indicates that either the user doesn’t know their system password, or they’re trying to use forbidden commands.

sudo keeps logs. The interesting thing is, successful log messages are of priority notice, while unsuccessful attempts are of priority alert. This opens up an easy way to improve security and customer service.

First, a user who cleverly gets root can edit your log files. forward your sudo logs to your logging host. Your users should not have access to your logging host.

First, split your sudo logs out into two logs. You can set sudo’s syslog facility, but as I’m always short on facilities, I tend to break sudo out via program name. Here’s a syslog.conf entry.

!sudo
*.* /var/log/sudo
*.alert /var/log/sudofail

Touch the files, restart syslogd, and /var/log/sudofail will contain only password failures and attempts to run forbidden commands. The two log entries are very different.

Sep 26 10:37:27 caddis sudo: mwlucas : command not allowed ; TTY=ttyp0 ; PWD=/home/mwlucas ; USER=root ; COMMAND=/sbin/reboot
Sep 26 10:53:09 caddis sudo: mwlucas : 3 incorrect password attempts ; TTY=ttyp0 ; PWD=/var/log ; USER=root ; COMMAND=/usr/bin/su

Separating this log out opens some interesting customer service possibilities. If you’re on OpenBSD, you can automatically have newsyslog email you the log of failures. Otherwise, you can set up a separate script to do that, or feed it to your alerting system, or whatever. Then have a helpdesk minion call the user in question and ask what they’re trying to do. Perhaps they’ve forgotten their password. Perhaps someone else got access to their account. Perhaps they’re having trouble. Maybe they need sudo -l explained to them.

The end user will either feel like you’re watching out for them, or realize that your sysadmin group watches the systems very closely.

Even if you don’t take proactive action, having sudo failures logged to a separate file simplifies digging through the logs.

I recently tried FreeBSD’s pkgng, based on Ivan Voras’ blog post. Days after getting the new machine set up, though, I got this in my daily status mail:


Checking for packages with security vulnerabilities:
Database fetched: Fri Aug 3 03:02:57 EDT 2012
apache-2.2.22_5 is vulnerable:
Apache -- Insecure LD_LIBRARY_PATH handling

WWW: http://portaudit.FreeBSD.org/bdab0acd-d4cd-11e1-8a1c-14dae9ebcf89.html

Where did this come from? A bit of poking around my system leads me to /usr/local/etc/periodic/security/410.pkg-audit. My first question is, where did this file come from? pkgng includes an equivalent to the old pkg_info -W:

$ pkg which /usr/local/etc/periodic/security/410.pkg-audit
/usr/local/etc/periodic/security/410.pkg-audit was installed by package pkg-1.0.r4

pkgng gives you an audit of your packages in the daily mail. Excellent. It’s a DragonFly feature that I really like, and long overdue in FreeBSD.

So, how to upgrade the insecure ports? Unfortunately, I’ve had to build apache from source. I can’t use packages. That means I need to build the new version from ports. I get the new version ports tree with:

# portsnap fetch extract

I like to use portmaster for managing my ports. I’m told it works with pkgng. Let’s find out. First, tell ports that we’re running under pkgng by setting a variable in /etc/make.conf:

WITH_PKGNG=yes

Now install portmaster:

# cd /usr/ports/ports-mgmt/portmaster
# make all install clean

But portmaster doesn’t seem to work with pkgng:

$ portmaster -L
===>>> Root ports (No dependencies, not depended on)
===>>> 0 root ports

===>>> 0 total installed ports
===>>> There are no new versions available

A bit of research shows that portmaster needs to be patched before it works with pkgng. (Portmaster has a large install base, the portmaster maintainer is very careful about not messing up existing users, and pkgng is still very young. I’m confident that portmaster will work with pkgng by the time pkgng becomes the default.) You can get the patch on github.

Now build portmaster with the patch.

# cd /usr/ports/ports-mgmt/portmaster/
# make patch
# cd work/portmaster-3.13.13
# patch < $HOME/patch-portmaster-pkgng
# cd ..
# cd ..
# make all install

I keep the patch in my home directory, because any time I want to rebuild portmaster I must reapply the patch. And if the patch fails, I must check for a new patch.

Try the new portmaster:

# portmaster -L
===>>> Root ports (No dependencies, not depended on)
===>>> pkg-1.0.r4
===>>> New version available: pkg-1.0.r5_1
===>>> portmaster-3.13.13
...

Much better.

I’ll start by upgrading pkgng itself, then my other ports. I use:

# portmaster -d --no-confirm pkg

Use whatever portmaster options you prefer, of course. With the pkgng patch, portmaster seems to behave exactly as you expect. But the only way we’ll know for sure is if you test pkgng in your environment and file bug reports with the appropriate maintainer.

I have a love-hate relationship with RADIUS. RADIUS is the cheap white glue of authentication. Just about everything speaks it, so you can use it as cheap glue to unify passwords across your gear. But it’s a finicky protocol, with lots of edge cases, and those edges can be SHARP.

Okay, perhaps it’s more of a tolerate-hate relationship. But still.

OpenBSD supports using RADIUS to authenticate user accounts. Why would you possibly want to do this? For one thing, if you’re using authpf, it gives you a way to easily synchronize firewall passwords with your Windows domain through the Microsoft Internet Authentication Service. It’s not ideal — ideal would be making all of your users use public key auth — but it’s better than nothing, reduces your support workload, and helps convince management that your firewall is a real solution.

I’m assuming you already have a RADIUS server. Mine is freeRADIUS-2.1.12, but any basic RADIUS server will work.

OpenBSD uses BSD authentication, a competitor to PAM. The RADIUS auth process is documented in login_radius(8), but I’ll walk through the basics.

Configure your RADIUS server to allow access from your OpenBSD box, and assign it a shared secret. My RADIUS server is 192.0.2.2, and my secret is the string Insubordinate. (It’s a lousy secret, but it’s just an example, and I’m tired.)

Create a directory for the server list, and set the permissions as per the man page.

# mkdir /etc/raddb
# chgrp _radius /etc/raddb/
# chmod 755 /etc/raddb/


Create the file /etc/raddb/servers. List each server, and its secret, on its own line.

192.0.2.2 Insubordinate

Now switch your default authentication scheme in login.conf.

#auth-defaults:auth=passwd,skey:
auth-defaults:\
        :auth=radius:\
        :radius-port=1812:\
        :radius-server=192.0.2.2:

The change should take effect immediately. Be sure you have a window logged in as root beforehand, so you can switch back if necessary. If you have trouble, check your RADIUS server’s debugging log, or use a packet sniffer to examine the actual RADIUS dialog.

Your host will now check every password against the RADIUS server. That includes root. You probably want to set up an auth-su class, or only have the authpf class use RADIUS, or some combination thereof. I really recommend requiring anyone who can get an actual shell to log in with public key authentication.

And for those who care, you now know exactly what part of Absolute OpenBSD I’m writing.

I will be at BSDCan 2012. In addition to poking my nose where it doesn’t belong, spouting insouciance and irrelevance, and derailing important technical discussions with tediously pointless anecdotes about my pet rats, I am teaching a course on SSH.

If you don’t have time to work your way through the SSH book, take a couple hours and and get dragged through it. The course will include material not included in the book, unless it goes too long, in which case I’ll spout off about extra material upon request.

The new FreeBSD Device Drivers book should be out by then, and the author will be there. (Pity poor Joe Kong. He came to BSDCan in 2007, just after his Designing BSD Rootkits came out. I spent the rest of the conference badgering him into writing the FreeBSD Device Drivers book. He spent five years on this project, and is done at long last. I’m sure he’s ready to shout “Ha! Lucas, I’m rid of your stupid project! I’m a free man!” Sadly for Joe, I have another three books he needs to write. Preferably immediately. If he resists my persuasive powers, I’m prepared to use brainwashing techniques.)

If you’re a reader of my blog, you need to go to BSDCan. We received so many excellent paper proposals this year that cutting the list down was physically painful. If you don’t yet have IPv6 up and running, attend the IPv6 tutorial. Or learn about PF. Not to mention two days of really interesting papers. And beer.

I’m deploying IPv6 for my employer. While getting corporate servers up on IPv6 is nice and all, of course I put priority on my own personal Web server.

Just because IPv6 is still populated mostly by early adopters, doesn’t mean we can neglect basic system security. That means that the server needs a packet filter for both IPv4 and IPv6. PF supports filtering both protocols in one ruleset.

The following is a unified IPv4/IPv6 PF ruleset for a small server. It: