Category: bsd

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:

Allows all traffic from management addresses

Allows all ICMP and ICMPv6 traffic

Allows traffic to specific ports where we choose to provide service — in this case, SMTP, DNS, and HTTP.

Blocks everything else.

Fill in the IPv4 and IPv6 external addresses, define your interface, adjust the permitted services to match your environment, and you’re ready to go.

ext_if="em0"
ext_addr="{192.0.2.40, 192.0.2.41}"
ext_v6="2001:db8:0:12::2"

table <mgmt_hosts> const {172.16.0.0/24, 172.16.5.0/24}
table <v6_mgmt_hosts> const {2001:db8:1:4::2}

set block-policy return
set loginterface $ext_if
set skip on lo0

scrub in all no-df

block in all

pass in on $ext_if proto icmp all
pass in on $ext_if proto icmp6 all

pass in on $ext_if inet from <mgmt_hosts>
pass in on $ext_if inet6 from <v6_mgmt_hosts>

pass out on $ext_if inet from $ext_addr to any
pass out on $ext_if inet6 from $ext_v6 to any

#services we permit
pass in on $ext_if proto tcp from any to $ext_addr port {25,53,80}
pass in on $ext_if proto udp from any to $ext_addr port 53
pass in on $ext_if inet6 proto tcp from any to $ext_v6 port {53,80}
pass in on $ext_if inet6 proto udp from any to $ext_v6 port 53

Or, if you prefer: “WHMCS versus PHP.” Blogged for the next sysadmin searching Google.

$DAYJOB recently acquired WHMCS to help automate virtual server provisioning, billing, and so on. According to everything I’ve read, WHMCS runs just fine on FreeBSD, so I installed the prerequisites on a 9.0-i386 machine. As with any server for PHP-based Web sites, I verified that the server processed PHP with a simple phpinfo() page. I then grabbed the WHMCS tarball (no link, you must be a customer, sorry), extracted it into the directory, ran the setup program, fed in the database information and license key…

..and it wouldn’t run. Calling up the app resulted in a blank page. WHMCS provides troubleshooting instructions for this exact circumstance. I enabled the requested debugging, but couldn’t get WHMCS to produce an error. Adding a bogus argument to my phpinfo() test page made an error appear, so I was confident the failure to display an error message wasn’t a server configuration problem.

This comes down to FreeBSD’s PHP packaging.

When you install PHP on the popular varieties of Linux, you generally get a whole slew of PHP extensions with it. BSD-based systems only install exactly what you ask for: if you want PHP but don’t request any extensions, you won’t get any extensions.

I agree with this approach. Every piece of installed software needs patching and updating. Every piece of installed software is a potential attack vector. If I don’t need a piece of software, I don’t want it on my server.

WHMCS doesn’t list all of the required extensions. They assume you have a kitchen-sink PHP install. After some reading and research, I found that WHMCS runs fine with the following PHP modules and extensions installed. I’ve included the version numbers for reference, but you should be able to just pkg_add -r all of these by name.

php5-5.3.8
php5-bz2-5.3.8
php5-ctype-5.3.8
php5-curl-5.3.8
php5-dom-5.3.8
php5-extensions-1.6
php5-filter-5.3.8
php5-gd-5.3.8
php5-hash-5.3.8
php5-iconv-5.3.8
php5-json-5.3.8
php5-ldap-5.3.8
php5-mysql-5.3.8
php5-openssl-5.3.8
php5-pdo-5.3.8
php5-pdo_sqlite-5.3.8
php5-phar-5.3.8
php5-posix-5.3.8
php5-session-5.3.8
php5-simplexml-5.3.8
php5-tokenizer-5.3.8
php5-xml-5.3.8
php5-xmlreader-5.3.8
php5-xmlwriter-5.3.8
php5-zip-5.3.8
php5-zlib-5.3.8

I’d really like to trim this down to only what is strictly necessary to run WHMCS, but that information doesn’t seem to be available. I could methodically remove and reinstall extensions to see when WHMCS breaks, but I have better things to do than debug missing docs for a commercial PHP app.

On the plus side: now that WHMCS is installed, it’s really slick. I’m looking forward to using it. Actually, I’m looking forward to having other people use it for me, so I can do more interesting things than provision servers, accounts, and billing.

With BIND 9.8, enabling DNSSec resolution and verification is now so simple and low-impact there’s absolutely no reason to not do it. Ignore the complicated tutorials filling the Internet. DNSSec is very easy on recursive servers.

DNS is the weak link in Internet security. Someone who can forge DNS entries in your server can use that to leverage his way further into your systems. DNSSec (mostly) solves this problem. Deploying DNSSec on your own domains is still fairly complicated, but telling a BIND DNS server to check for the presence of DNSSec is now simple.

In BIND 9.8.1 and newer (included with FreeBSD 9 and available for dang near everything else), add the following entries to your named.conf file.

options {
...
dnssec-enable yes;
dnssec-validation auto;
...
};

This configuration uses the predefined trust anchor for the root zone, which is what most of us should use.

Restart named. You’re done. If a domain is protected with DNSSec, your DNS server will reject forged entries.

To test everything at once, configure your desktop to use your newly DNSSec-aware resolver and browse to http://test.dnssec-or-not.org/. This gives you a simple yes or no answer. Verified DNSSec is indicated in dig(1) output by the presence of the ad (authenticated data) flag.

For the new year, add two lines to your named.conf today. Get all the DNSSec protection you can. Later, I’ll discuss adding DNSSec to authoritative domains.