Excellent IPTables firewall script

Last time I talked a bit about using pf as a firewall, on the various BSDs. Naturally, there are far more installations of Linux out there than there are of FreeBSD, OpenBSD, etc. The current firewall of choice on the linux platform is iptables. One of the best open source firewall configurations I've found using iptables is Arno's IPtables Firewall Script.

There are a few things that you want to keep in mind when you pick a firewall technology:

1) The firewall should be stateful - e.g. the firewall is programmed to distinguish legitimate packets for different types of connections. Only packets matching a known connection state will be allowed by the firewall; others will be rejected.
2) The firewall should be easy to configure
3) The firewall should allow you to easily determine what's going on when you look at the log files.

Arno's script does all of these things, and more. Give it a look.

Using pf as a Firewall

I've long been a fan of FreeBSD (although I also use a Mac, Linux, and Windows machine -- right tool for the job, and all that), and one of the things I like best about the various BSDs is the ease with which you can set up a stateful packet-filtering firewall. To put it simply, pf rocks.

Setting it up for the first time, though, can be a bit of a chore. If you are interested in giving pf a look, here's how you do it on FreeBSD.

Recompile your kernel
For the sake of argument, let's assume that we are going to be setting up a machine called "zeus" as a gateway server with a few simple services running on it. We first need to compile the pf stuff into the kernel, and then install our new kernel. First, get to the right directory:

[tcs@zeus] ~> su -
Password:
1:28PM up 60 days, 3:54, 1 user, load averages: 0.03, 0.01, 0.00
[root@zeus] ~# cd /usr/src/sys/i386/conf/

Now, copy the file GENERIC to some new file (I'm calling my zeus):

[root@zeus] ~# cp GENERIC ZEUS

Edit the file ZEUS and add the following lines just below "options ADAPTIVE_GIANT":

#PF Support
device pf #PF OpenBSD packet-filter firewall
device pflog #logging support interface for PF
device pfsync #synchronization interface for PF

#ALTQ Support
options ALTQ
options ALTQ_CBQ # Class Bases Queueing
options ALTQ_RED # Random Early Drop
options ALTQ_RIO # RED In/Out
options ALTQ_HFSC # Hierarchical Packet Scheduler
options ALTQ_CDNR # Traffic conditioner
options ALTQ_PRIQ # Priority Queueing

Now, we need to compile and install the kernel. Go to the /usr/src directory and execute this command:

make buildkernel KERNCONF=ZEUS

Wait (quite a while). When it's done, type this:

make installkernel KERNCONF=ZEUS

Wait a bit longer. Reboot. If it comes up, congrats -- you have a new kernel.

Enable PF in rc.conf
We need to tell the OS that we want to use pf. Enter the following in /etc/rc.conf

pf_enable="YES"
pf_rules="/etc/pf.conf" # rules definition file for pf
pf_flags="" # additional flags for pfctl startup
pflog_enable="YES" # start pflogd(8)
pflog_logfile="/var/log/pflog" # where pflogd should store the logfile
pflog_flags="" # additional flags for pflogd startup

Set up the firewall: pf.conf
The default rules for pf.conf are very, very detailed. We are going to ignore them, and make our own. First, back up the /etc/pf.conf file that is (probably) there by default:

cd /etc
mv pf.conf pf.conf.dist

Now, edit a new file called pf.conf and enter the file below (each service is mentioned in the comments preceding it):

# define our interfaces. Find yours by typing ifconfig as root
lo="lo0"
ext_if="fxp1" #your external nic
ext_gw="19x.xx.xx.254" #change this to the ip of your gateway router
int_if="fxp0" #your internal nic
oip1="19x.xxx.xxx.222" #change this to your external ip address

#clean everything up (reset to defaults)
scrub in

# nat for internal clients
nat on $int_if from 192.168.0.0/24 to any -> ($int_if)

# Pass/block rules

block in

pass quick on { $lo $int_if } all

# we shouldn't have to do this, but seem to have to on freebsd
pass out on $lo all

# allow ssh to local machine
pass in on $ext_if proto tcp to ($ext_if) port ssh keep state

Save, and you are ready to give things a try!

Helpful hints:

To enable the firewall rules:

pfctl -f /etc/pf.conf

To enable pf:

pfctl -e

To disable pf:

pfctl -d

Secure your ssh with PKI

It shocks me how many otherwise intelligent people leave port 22 wide open on their machines. In case you didn't know, this is the default port for ssh -- an widely used method of making connections to a machine from remote locations.

ssh is a wonderful system. The default install on virtually every unix like system out there (including Linux, the various BSDs, and Mac OS X) is inherently insecure, and subject to brute force attacks. We see these on our servers virtually every day. A brute force attack is shockingly simple to implement -- the attacker simply runs a script that tries many, many username/password combinations until they get in. Once they have an account, it's only a hop, skip and jump to root access.

Then bad things happen.

There are a number of ways to make it tougher for attackers, of course. First, configure your firewall to only allow incoming ssh requests from known, safe IP addresses. Additionally, you should implement PKI security on your ssh system. This is, fortunately, very simple to do.

The process is simple:

1. Generate your public/private key pair
   
2. Install the keys on the machines you are going to use to access the server
   
3. Modify your ssh server's config file to require known keys
   
4. Restart your server

We are going to generate RSA keys for our client. The public key will live on the remote server, and both keys will live on the client machine. For simplicity, we will generate our keys on the server, and then transfer them to our client machine. Log onto the server as the account you want to generate keys for, and then execute these commands:

server$ cd ~

server$ mkdir .ssh

server$ chmod 700 .ssh

server$ ssh-keygen -q -f ~/.ssh/id_rsa -t rsa

Enter passphrase (empty for no passphrase):

Enter same passphrpase again:

Entering a passphrase is optional.... but do it anyway.

Now lock down the file permissions...

chmod go-w ~/.ssh

Now copy the contents of .ssh directory to your client machine. Use a USB key or some other secure method, just to be safe.

Now we need to modify the /etc/ssh/sshd_config file for our ssh server. Mine looks like this:

Protocol 2
ListenAddress 192.168.5.100
HostKey /etc/ssh/ssh_host_rsa_key
SyslogFacility AUTHPRIV
AuthorizedKeysFile .ssh/id_rsa.pub
HostbasedAuthentication no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
Subsystem sftp /usr/libexec/openssh/sftp-server
AllowUsers tcs

This is a bare minimum. Note the items in red:

• your public key must exist in /home/yourhomedirectory/.ssh/id_rsa.pub
• ChallengeResponseAuthentication disables simple username/passwords to log on
• AllowUsers is another safety check -- only users who exist here will be able to log in regardless as to what keys they have.

Now, restart your sshd server, and give it a try.

Anti-spam for qmail: spamdyke

I have long been a fan of qmail. Yes, I know that it is long in the tooth, and there are a great number of fans of postfix and so forth out there, but say what you will about qmail -- it's solid as a rock, and incredibly fast. I am a big fan of it.

A few years ago I became a fan of the "cookbook" found on www.qmailrocks.org, but it is, sadly, a bit out of date. Nevertheless, careful perusal of various mailing lists and so forth has allowed me to keep up to date with my qmail installs and things are running along smoothly.

Recently, I found another weapon to use in the ongoing battle with spam: spamdyke (http://www.spamdyke.org). This is a great tool for a number of reasons:

• it works
• it does not require patching qmail
• it's free
• it brings a lot of functionality to the table that is just not in the standard qmail install (patched, qmailrocks version, etc.)

From the site:

spamdyke is a filter for monitoring and intercepting SMTP connections between a remote host and a qmail server. When a connection is established from a spam source (as determined by the active filters), spamdyke will reject the email -- qmail never sees it.
Beyond filtering, spamdyke offers a number of other features:

• spamdyke supports SMTP AUTH and will even provide SMTP AUTH to an unpatched qmail server.
• spamdyke supports TLS and will even provide TLS to an unpatched qmail server.
• spamdyke provides much better, much more complete logging than qmail, using syslogd.
• spamdyke can log all SMTP traffic to aid troubleshooting.
• Best of all, using spamdyke does not require patching or recompiling qmail!

Installation is trivial, and it works out of the box, as it were.

Some other qmail related links that might be of help to you if you are looking for a solid, easy to maintain system:

• FreeBSD Rocks! (http://www.freebsdrocks.net) - a step by step to installing qmail on FreeBSD. This is an excellent successor to qmailrocks.
• Setting up mailhubs (http://qmail.jms1.net/mailhub.shtml) - how to set up multiple incoming servers all delivering mail to a centralized mailbox machine. Excellent way to share the load on busy sites.

There are many other resources out there, and most of them are linked on the main qmail site (http://www.qmail.org).

Another alternative to Parallels: Q

A few days ago I was extolling the virtues of VirtualBox, an alternative virtualization package for Mac OS X that allows me to run FreeBSD, Windows, Linux & so forth on my Mac, without the need to reboot. Well, I just stumbled across another one with the rather memorable name of "Q". You can find it here: http://www.kju-app.org/kju/

I have not tried this package yet, but it looks promising. From their website:

Run Windows, Linux and a lot more Systems on your Mac. Q is a feature packed cocoa port of QEMU: Switch fast between guest PCs. Save and restart guest PCs at any stage. Easily exchange Files between Host and Guest. Q makes use of OS X most advanced technologies like openGL, quartz and coreaudio to accelerate your experience with your guest PC. Please remember: At the present state, QEMU is still considered ALPHA software.

Note the reference to the package being alpha software. I'm not quite ready to install it on the machine that I make my living with, but I'll keep an eye on it.

Use your Blackberry as a bluetooth modem on your Mac

As I mentioned a few days ago, I recently purchased a MacBook. I have been extremely happy with this machine in most respects. The only thing I miss is the ability to use it my Blackberry as a Bluetooth modem. Since I live in Canada, where the data charges are absolutely unreasonable (can you say $10.00/meg after the first meg of traffic??) this has not been a huge problem, but there is a certain sense of security knowing that if I absolutely have to, I can connect to the Internet and get to my servers wherever there happens to be cellular coverage.

Fortunately, I have successfully figured out how to do this. I found my information here and here, although neither post was 100% accurate for my setup. Thus, I decided to share my findings here.

My setup:

• MacBook (2GHz Core 2 Duo)
• Mac OS X 10.4.10
• BlackBerry Pearl (8100)
• Rogers cellular network

The first step is to download the Blackberry 8100 modem script. Save this to your desktop. If your Mac helpfully appends a .txt extension to the file, rename it so the .txt is missing. Move this file to your Library/Modem Scripts folder. Next, pair the Blackberry with your Mac. This is fairly simple.

First, make sure your Mac is "Discoverable" in the Bluetooth system preferences panel. Then, open the "Options" feature on your Blackberry (in the default interface, it looks like a wrench). Scroll down to Bluetooth, and click on it. Click the menu button (to the left of the scroll ball) and click "Add Device." Your Mac will show up. Choose it. In a few seconds, your Mac will generate a passkey and put it on your screen. Enter that into your Blackberry. The next screen on your Mac will give you two choices -- "Use with Address Book" and "Access the Internet with your phone's data connection". Make sure both are checked, and that you choose "Use a direct, higher speed connection..."

Next, your Mac will ask you for details about your setup. You'll get this screen:


Your Username is "wapuser1", your password is "wap" and your GPRS CID String is "internet.com" (no quotes on anything). Note that these settings are for Rogers Canada. Your mileage may vary.

Make sure you leave "Show modem status in menu bar" checked. Click continue, and you're done.

To connect to the Internet, just click on the phone icon in your menu bar and choose "Connect." To disconnect, go to the same menu and click disconnect.

NOTE: data charges in Canada are very, very high. Make sure you don't overdo it and get a massive phone bill at the end of the month.

DIY Network Attached Storage

After a (rather busy) summer, I have finally elected to return to my "do it yourself network attached storage" project. I've done some reasearch, and picked my operating system -- FreeNAS (http://www.freenas.org). Their site describes it thusly: "FreeNAS is a free NAS (Network-Attached Storage) server, supporting: CIFS (samba), FTP, NFS, AFP, RSYNC, iSCSI protocols, S.M.A.R.T., local user authentication, Software RAID (0,1,5) with a Full WEB configuration interface."

There are a number of things I really like about this implementation. First, it's tiny -- and I mean really, really small. A full implementation takes about 30 megs for the operating system, leaving the rest of your disk space available for storage. Secondly, it's based on FreeBSD, so you know it's going to be rock solid, and require very little maintenance. Finally, in a heterogeneous network, this is ideal -- it talks to everybody. We have Macs, linux work stations, and windows all trying to play nicely together. This solution is perfect for our needs.

Give it a look.  It's stable as a rock, and works like a charm.