Category: bsd

I secure my BSD servers with PF. In FreeBSD 9, PF has been updated to the same version as in OpenBSD 4.5.

I use lists in my PF configuration, as shown in this /etc/pf.conf snippet:

mgmt_hosts="{ 10.0.1.0/24, 172.19.8.0/24}"
...
pass in on $ext_if from $mgmt_hosts
...

When I have new management hosts, I add their IP address or subnets to the mgmt_hosts list. When PF reads this configuration file, every place that a rule references the list, an additional rule is created for each member of the list. Here, every subnet in the mgmt_hosts list gets a “pass in” rule. When I list these rules on a running FreeBSD 8 host, they’ll look something like this:

# pfctl -sr
...
pass in on em0 inet from 10.0.1.0/24 to any flags S/SA keep state
pass in on em0 inet from 172.19.8.0/24 to any flags S/SA keep state
...

Very useful for maintaining a readable rule file.

I updated a host to FreeBSD 9, and saw the following in my rules.

# pfctl -sr
...
pass in on vr0 inet from <__automatic_4c6aed29_0> to any flags S/SA keep state
...

Wait a minute. What is this __automatic crap? And where are my management hosts?

This version of PF automatically converts lists to tables. If you have a big rule set, using a table makes the rules shown by pfctl more readable. (I seem to recall that tables perform better than lists, but I can’t find a reference for that, so take that with a grain of sand.)

You can name tables, but tables created by PF have a name that starts with __automatic. To view all the tables, run:

# pfctl -sT
__automatic_4c6aed29_0
#

To see the hosts in this table, use pfctl’s -t and -T flags.

# pfctl -t __automatic_4c6aed29_0 -T show
10.0.1.0/24
172.19.8.0/24
#


Wow. This works, but it doesn’t look like fun. If I have to routinely type __automatic_4c6aed29_0, I will increase my subvocalized swearing by at least ten percent. But it does not interrupt service. Old rule sets continue to work. (I don’t mind needing to update my rules with a new OS version, but I need to know about it beforehand rather than just blindly updating.)

To make my life easier I can convert my PF rules to use tables instead of lists. Here’s the same pf.conf using a table instead of a list.

table <mgmt_hosts> const {10.0.1.0/24, 172.19.8.0/24}
...
pass in on $ext_if from <mgmt_hosts>
...

Unlike a list, a table is explicitly declared as a table. The name always appears in angle brackets.

I use the const keyword to tell PF that the contents of this table cannot be changed at the command line. PF tables can be adjusted at the command line without reloading the rules, which is a handy feature for, say, automatically blocking port scanners, feeding IDS data to your firewall, or DOSing yourself.

When I look at my parsed rules now, I’ll see:

# pfctl -sr
...
pass in on vr0 from <mgmt_hosts> to any flags S/SA keep state
...

I can now read my rules more easily.

(Bootnote: OpenBSD just came out with 5.0, so FreeBSD 9 is five versions behind. OpenBSD PF develops quickly. But thirty-month-old PF is better than a lot of other firewall software.)

I recommend using sudo for privileged access to systems. I also recommend requiring keys for SSH authentication, with agent forwarding to trusted systems. The default settings in these two programs collide head-on when you become superuser via sudo and want to copy files from one server to another with scp or sftp.

If you’re using an SSH agent, your environment contains the location of your authentication socket.

# env | grep SSH
SSH_CLIENT=192.0.2.2 51502 22
SSH_CONNECTION=192.0.2.2 51502 198.0.2.10 22
SSH_TTY=/dev/pts/1
SSH_AUTH_SOCK=/tmp/ssh-aJpJNwwOTk/agent.35699
#

When you copy files with scp(1) or sftp(1), the client checks for a SSH authentication socket. If the client doesn’t find one, and the user account doesn’t have a private key on this system, and the remote server doesn’t support password auth, the client will not be able to log in.

All as you would expect, right? But like any good firewall, sudo(8) removes all environment variables not explicitly permitted. To see what sudo(8) does to your environment, as well as all of sudo’s other settings, become root and run sudo -V.

# sudo -V
Sudo version 1.6.9p20

Sudoers path: /usr/local/etc/sudoers
Authentication methods: 'pam'
Syslog facility if syslog is being used for logging: local2
...
Environment variables to check for sanity:
TERM
LINGUAS
LC_*
LANGUAGE
LANG
COLORTERM
Environment variables to remove:
RUBYOPT
RUBYLIB
PYTHONINSPECT
...
Environment variables to preserve:
XAUTHORIZATION
XAUTHORITY
TZ
PS2
PS1
PATH
...

sudo sanity-checks some environment variables, deliberately strips others, and explicitly preserves a few.

To use agent forwarding for SSH authentication while running as root, add the SSH environment variables to sudo’s configuration. While I could restrict this by groups, I’ll make this a default setting. Call up visudo and add a new default.

Defaults env_keep += "SSH_CLIENT SSH_CONNECTION SSH_TTY SSH_AUTH_SOCK"

Exit superuser, use sudo to become superuser again, and your environment will retain your SSH environment.

While sudo can preserve any environment variables you wish, sudo strips the environment for very good reasons. Don’t retain environment variables unless you’re sure what they will do. And don’t retain easily-abused environment variables, such as LD_PRELOAD. If the superuser needs dangerous environment variables, put them in a separate configuration file and source that file after becoming superuser.

Like last week’s How to Lose your Job with SSH, Part 1, a less dramatic title for this would be Dynamic Port Forwarding with SSH, but that’s dreadfully dull.

Many corporations try to tightly secure their network. Connections to the outside world are strictly limited. If you have a single open TCP/IP port to the outside world, however, you can leverage this into blanket Internet access by using your SSH client as a SOCKS proxy. This is called dynamic forwarding.

SOCKS is a generic TCP/IP proxy. SOCKS tunnels arbitrary protocols, as long as the client program supports SOCKS. Many clients, including the major Web browsers, do.

To do this, you would SSH from your client on the protected network to a server on the public Internet. The client opens a SOCKS proxy on a TCP port on the local machine. When a client connects to this proxy, the traffic is forwarded across the Internet to the SSH server. The SSH server processes the request and feeds the data back to you. It’s not a terribly fast proxy, but it is encrypted and it will bypass the corporate firewall and Web proxies.

Use the -D flag to tell the OpenSSH client to use dynamic port forwarding. (You can do the same thing with PuTTY, but that’s a separate walk-through.)

$ ssh -D localaddress:localport hostname

If you don’t specify a local IP, the client automatically binds to 127.0.0.1.

Here, I open a dynamic proxy on port 9999 to the server pride.blackhelicopters.org

$ ssh -D 9999 pride.blackhelicopters.org

Leaving the SSH session up, now go to the Web browser on the local machine. Somewhere in the browser preferences you’ll find a place for proxy servers. Tell your browser it has a proxy at 127.0.0.1 on port 9999. Save the settings and start browsing the Internet. Your Web browsing will be slow, but it’ll get you on the Internet.

If I list a network-facing IP on my client, anyone who can connect to that port on the client can use my proxy.

$ ssh -D 10.10.10.105:9999 pride.blackhelicopters.org

This is, of course, a violation of the security policy at these security-sensitive companies. Doing it will get you fired.

As a network administrator responsible for such an environment, what can you do about this?

Most of these solutions require the network administrator to know what happens on his network. You must have basic network awareness, in advance, or you’ll never find these people.

And if you’re an end-user who creates his own SOCKS proxy in such an environment, gets caught, and gets fired for it, do let me know. I can always use a good laugh at someone else’s expense.

I didn’t find an up-to-date tutorial on how to set up a FreeNAS 8 iSCSI target, so I took notes as I set one up. Figuring this out by brute force is fairly straightforward: just keep adding iSCSI stuff until you can actually discover iSCSI targets. But for those of you who value your time, here’s how you do it.

1) Go to services, enable iscsi. Under iSCSI, choose Target Global Configuration. In Discovery Auth Method choose CHAP. Leave all other settings unchanged

2) It seems that FreeNAS doesn’t yet let you export a whole drive via iSCSI; you must create an extent. Under iSCSI, select Extents, then Add Extent. Name your extent, give it a path, and set a size.

3) On the Target Global Configuration, on the “authentication” tab, create an iSCSI user and assign it a secret

4) You need an iSCSI Portal. Click the Portals tab. This is where you define the iSCSI target. The default is to listen for iSCSI connections on all IP addresses, on port 3260. If you have multiple IP addresses, and want separate portals for each, be more specific.

5) You must authorize initiators. Choose “Authorized Initiator,” then “Add Authorized Initiator.” List the IP subnet of your initiators under Authorized Network.

6) Go to the Targets tab. Add a target.

7) Under “Associated Targets,” attach the extent to the target.

Now go to your iSCSI initiator and log in.

To create new iSCSI targets, create a device extent, add a target for that extent, and attach the extent to the target.

I won’t put any system on the Internet without some sort of packet filter or firewall. Especially not a file server containing important data. While I have a FreeNAS 8 box, it doesn’t come with a firewall. FreeBSD includes three firewalls, IPFW, IPF, and PF. Any one of these would do, but I’m most comfortable with PF, so I decided to add PF to my FreeNAS install.

This will not add a firewall to the GUI. You must manage your rules remotely. The FreeNAS backup will not back up your rules. The good news is, once your firewall works the rules don’t change very frequently.

First, get the appropriate kernel module. You’ll need the ISO for the version of FreeBSD that your FreeNAS is based on. FreeNAS 8.0 is based on FreeBSD 8.2. I’m running the amd64 version of FreeNAS, so I need the amd64 version of FreeBSD 8.2. The version must match as exactly as possible: your 8-stable amd64 desktop might work, but it might make your FreeNAS box crash and die.

Mount the ISO.

$ mdconfig -a -t vnode -f $HOME/FreeBSD-8.2-RELEASE-amd64-livefs.iso
md0
$ mount -t cd9660 /dev/md0 /mnt


I previously installed FreeNAS on a 2GB USB stick. For this process, I shut down my FreeNAS box and mounted the USB drive on my FreeBSD machine. You could work directly on the FreeNAS image and re-install it on the USB drive, or even work directly on the live FreeNAS box. I’m assuming you’re working on a USB stick.

$ mount /dev/da0s1 /mnt

Start by getting the PF kernel module from the ISO onto your USB drive.

$ cp /media/boot/kernel/pf.ko /mnt/boot/kernel/

Now for the tricky bit. FreeNAS is based on the FreeBSD diskless system. (Obligatory plug: I did half a chapter on diskless operation in Absolute FreeBSD.) It uses the /conf directory to create a series of memory-based filesystem overlays, creating a MFS /tmp, /etc, and so on. This means that any changes you make to, say, /etc/pf.conf will not survive a reboot. You must edit the original versions of these files, in /conf/base/etc.

In /conf/base/etc/rc.conf, add

pf_enable=YES


Put your pf.conf in the same directory. Configuring PF is left as an exercise for the reader.

Any firewall changes made to a running system must appear in /etc/pf.conf and in /conf/base/etc/pf.conf. I suggest changing the base file, and copying changes to /etc.