msgbartop
msgbarbottom

29 Sep 09 Loop Mount .iso in FreeBSD

I needed to mount an .iso file this morning, which I’ve done dozens of times in Linux, and I realized the command I’d normally use in Linux does not work. For example:

Linux

mount -o loop image.iso /mnt

This works fine in Linux and lets you “mount” the .iso file as if it were burned and in the drive. This does not work on FreeBSD. You get an error like:

mount: image.iso mount option is unknown: Invalid argument

FreeBSD

The solution (the only one I’ve found so far) is to use a much more in-depth command like:

mount_cd9660 -o ro /dev/$(mdconfig -a -t vnode -f /path/to/file.iso) /mount-point

Hopefully this little note helps someone else have less trouble than I did in mounting .iso images in FreeBSD.

Tags: , , , ,

10 Jul 09 Configure FreeBSD To Use Blowfish Password Format

I’ve been spending a lot of time lately researching FreeBSD security solutions. Topics such as pf (packet filter), system hardening, etc. One of the tips that I thought I’d share here is a method of configuring your system to use blowfish encryption for passwords as opposed to the default MD5. If you are on a system that has a lot of users it might be prudent to update the encryption type to make your stored passphrase safer.

Configure /etc/login.conf

The password format is stored within the /etc/login.conf file. The default value being “md5″. To update your configuration to use blowfish instead make the following change to your file:

-       :passwd_format=md5:\

+       :passwd_format=blf:\

After you’ve made this change you’ll need to rehash the login database, which is done using the cap_mkdb command:

cap_mkdb /etc/login.conf

At this point any newly assigned passwords will be created using blowfish instead of MD5. Any existing accounts will retain their MD5 password hash until the password is reset.

Tags: , , ,

06 Jul 09 pf (packet filter) Documentation

I’m looking for some good pf (packet-filter) documentation if anyone has anything to suggest. I’ve added a second FreeBSD machine to my public-facing network, and may be adding a third soon. I want to make sure that my firewall is setup properly but I’m not very familiar with pf. Can anyone suggest a book, online document, etc that has good examples for setting up pf?

Tags: , ,

06 Jul 09 Upcoming in FreeBSD 8.x

A friend of mine shot me this article today (What’s cooking for FreeBSD 8?), which is a pretty detailed outline of the things coming up for FreeBSD 8. I have to say, some of the things have got be excited! Some of the highlights that I want to see:

There is actually quite a bit more, but those are the immediate ones that look like they’d noticeably affect me. I’d really love to have FreeBSD setup on a VPS via Xen, with Jails for each of my services. Currently I have that setup at home (jails), but its on old hardware that takes forever to compile. Parallel Ports Build would sure be a nice improvement, assuming the hardware can handle it (which my current hardware cannot).

To any of you other FreeBSD users out there, what are you excited for in the list and why?

Tags: , , ,

12 Jun 09 JailKit : How To Create SSH Jails

Not long ago we rebuilt a number of servers within our production environment at work, migrating from FreeBSD to CentOS. One of the requirements in this migration was that we needed a server that would act as an SSH-only Jail on the new platform. This meant I needed to setup a system where users could SSH into a machine but the only thing they could do on that machine was SSH back out again. We used this as our “bounce” machine. Users would have outside access to their Desktops or other machines only by way of this secured SSH-only machine.

The solution I found was a tool called “JailKit“, which allows you to create chroot jails is a very simple way. Below I’ll outline the requirements for installing JailKit and using it to create an SSH chrooted “Jail”.

Step 1: Install JailKit

I was unable to find an up to date package for JailKit on CentOS, so I did the following to install from source:

yum install gcc make
wget -c http://olivier.sessink.nl/jailkit/jailkit-2.7.tar.bz2
tar xf jailkit-*.tar.bz2
cd jailkit-*
./configure
make
make install

Step 2: Configuration

Once you have JailKit built and installed you’ll need to configure it to provide the needed libraries and devices for your chroot SSH setup. Below is an example configuration I used for a JailKit setup on CentOS 5 x86_64 (using JailKit 2.5 at the time). Note: This is not the entire configuration. These three sections, uidbasics, ssh and basicshell required minor changes and this was the end-product of those changes:

[uidbasics]
comment = common files for all jails that need user/group information
libraries = /lib/libnsl.so.1, /lib64/libnsl.so.1, /lib/libnss*.so.2, /lib64/libnss*.so.2
regularfiles = /etc/nsswitch.conf
emptydirs = /home

[ssh]
comment = ssh secure shell
executables = /usr/bin/ssh
includesections = netbasics, uidbasics
devices = /dev/urandom, /dev/tty, /dev/null

[basicshell]
comment = bash based shell with several basic utilities
executables = /bin/sh, /bin/bash, /bin/ls, /bin/cat, /bin/chmod, /bin/mkdir, /bin/cp, /bin/cpio, /bin/date, /bin/dd, /bin/echo, /bin/egrep, /bin/false, /bin/fgrep, /bin/grep, /bin/gunzip, /bin/gzip, /bin/ln, /bin/ls, /bin/mkdir, /bin/mktemp, /bin/more, /bin/mv, /bin/pwd, /bin/rm, /bin/rmdir, /bin/sed, /bin/sleep, /bin/sync, /bin/tar, /bin/touch, /bin/true, /bin/uncompress, /bin/zcat, /usr/bin/id
regularfiles = /etc/motd, /etc/issue, /etc/bash.bashrc, /etc/bashrc, /etc/profile
directories = /usr/lib/locale/en_US.utf8
users = root
groups = root
includesections = uidbasics

Step 3: Populate The Jail Environment

Once these changes are made JailKit should be configured to provide the needed libraries and devices to your SSH chroot. You can now generate the chroot by using these two commands:

jk_init -v -f /home/chrootusers/ ssh
jk_init -v -f /home/chrootusers/ basicshell

Step 4: Generate Users

The final step in an SSH-chroot Jail setup is the creation of users. This step is a bit more complicated due to the fact that the users need to be created within the chroot setup and on the host system itself. The users will never have access to the host system, but that is where the initial authentication happens. Once they are authenticated they are pushed into the chroot jail and have limited permissions.

This script assumes two things that you should be aware of. If your configuration doesn’t match you’ll need to update the script accordingly:

  1. This script assumes your chrooted jail home directories will be in /home/chrootusers/.
  2. This script assumes group-based SSH restrictions using a system group called sshaccess.
  3. This script also attempts to create storage restrictions using filesystem quotas, but succeeds if quotas are not enabled. (See Appendix for information on enabling quotas.)

Here is the script:

#!/bin/bash
#
# This code is released under the Public Domain.
# create jailed ssh accounts
# christer.edwards@gmail.com
# usage: ./chroot-jail username 'passwdhash'
#

## sanity checks
if [ $# -ne 2 ]; then
echo "This application requires two arguments: username 'passwdhash' (single-quotes required)"
exit 1
fi

if [ ! -d /home/chrootusers/./home/ ]; then
echo "This application assumes installation to /home/chrootusers"
exit 1
fi

getent passwd $1 &>/dev/null
if [ $? -eq 0 ]; then
echo "User $1 already exists on host system. Please remove and re-create using this tool."
exit 1
fi

getent group sshaccess &>/dev/null
if [ $? -ne 0 ]; then
echo "This application assumes 'AllowGroups sshaccess' restriction in /etc/ssh/sshd_config. sshaccess group missing"
exit 1
fi

## creation
echo
echo "Creating User and Jailed Home Directory"
echo
useradd -m -d /home/chrootusers/./home/$1 -s /usr/sbin/jk_chrootsh -p $2 $1

echo "Adding User to 'sshaccess' Group"
echo
gpasswd -a $1 sshaccess &>/dev/null

JAILUID=$(id -u $1)
JAILGID=$(id -g $1)

echo "Creating Required Internal Jail Passwd and Group Files"
echo
echo "$1:x:${JAILUID}:${JAILUID}::/home/$1:/bin/bash" >> /home/chrootusers/etc/passwd
echo "$1:x:${JAILGID}:" >> /home/chrootusers/etc/group

echo "Applying Quota Restrictions"
setquota -u $1 10240 15360 0 0 /home || echo "Unable to Apply Quota Restrictions. Are Quotas enabled?"

If you create all of your users using this script you should save yourself a fair amount of headache. Between the user-creation script and the JailKit tools, creating SSH chrooted jails becomes a very simple task.

Appendix: Enabling Quotas

When I first implemented this JailKit setup in production I invited a few of the users to do their worst to break out of the jail or otherwise interfere with the system and other users. One of the potential problems that we found was that of drive space. Because there were no storage limitations for the chrooted users, one user could create large files and interfere with the others (or the host system) by filling up the drive. Below I’ve outlined how to activate filesystem quotas on Red Hat Enterprise or CentOS machines and apply a 15M hard limit to your chrooted users:

Configure usrquota

Quotas are a filesystem-based feature that needs to be activated within the fstab. To activate the use of persistent quotas append the term “usrquota” to the mount options of /home/ in your fstab. Example:

/dev/LocalVol/HOME    /home    ext3    defaults,usrquota    1 2

Activate usrquota

Once this is configured the following four commands will install, configure and activate quotas.

yum install quota
mount -o remount /home/
quotacheck -cmu /home/
quotaon /home/

At this point you aren’t applying any limits to the user (yet), but the quota management system is on and active. If you create your users using the script above they will be given a 10M soft limit (after 10M they will be given a warning) and a 15M hard limit (absolutely no more disk writes). You can change these values (last line in the script) based on your needs.

Tags: , , ,

23 Mar 09 FreeBSD Security Update: 7.1-RELEASE-p4 Available

For those using FreeBSD, there has been another security update to the 7.1 release family.  According to the UPDATING file:

20090323:       p4      FreeBSD-SA-09:06.ktimer, FreeBSD-EN-09:01.kenv
Correctly sanity-check timer IDs. [SA-09:06]
Limit the size of malloced buffer when dumping environment
variables. [EN-09:01]

If you’re interested in applying this update to your system, here is the method I use:

csup -g -L2 cvsup.freebsd.org /usr/share/examples/cvsup/standard-supfile
cd /usr/src
make buildkernel && make installkernel
make buildworld && make installworld
reboot

There are other methods for keeping your base system updated, but I prefer the compiling method. What other methods might you suggest?

Tags: ,

06 Mar 09 Update: Weekly Update Reporting Via Portmaster

Not so long ago I wrote about how you can configure FreeBSD to email you regarding available updates on a weekly basis.  This is something that I have had in place for a while now, and I really enjoy the ability to keep things on the patched (read: bleeding) edge.  Recently I found a small issue with the setup I had been using.  I wanted to share the fix with anyone that may have been doing the same thing.

First of all, let me tell you about the issue I came across.

When I would recieve an email regarding available updates I would connect to the FreeBSD Jail and use portmaster -a -d to apply all available updates.  I noticed that the number of updates applied did not match the number of updates listed in the email.  Odd.  Well, after thinking about it for a bit I realized what the problem was.

The cron job (as seen in the previous post) was running at the same time on the FreeBSD host as well as the FreeBSD Jail.  Why is that a problem, you ask?  Remember the slight variation in the host cronjob verses the jail.  The host system is pulling down the updated ports tree before it compares and emails any available updates.  The problem is introduced because the jails start doing their comparison and email reporting right away, while the host system is fetching and applying the updated tree.  Oops!  The ports tree update isn’t finished fast enough for the jails to actually have the new information.

The solution I came up with is a very simple one.  Simply update the cron daily run time on the host to give it an adequate headstart from the jails.  On my systems the /etc/crontab files now look like this:

HOST:
# Perform daily/weekly/monthly maintenance.
1   2   *   *   *   root    periodic daily
15  4   *   *   6   root    periodic weekly
30  5   1   *   *   root    periodic monthly

JAIL:
# Perform daily/weekly/monthly maintenance.
1   3   *   *   *   root    periodic daily
15  4   *   *   6   root    periodic weekly
30  5   1   *   *   root    periodic monthly

If you didn’t notice the change look closer. It’s a very small fix. The “periodic daily” row on the host is now set to run at 2:00am while the same field is set to 3:00am on the jail. I’m sure that is more than enough time for the host to update the ports tree before the jails start to do their reporting.

In conclusion, if you’re using a similar reporting system you’ll likely want to apply this small change as well.  Giving the host system enough time to update the ports tree will be critical in getting updated, accurate information within the jail systems.

Tags: , , , ,

23 Feb 09 Wordpress Permalink Support: FreeBSD + Lighttpd

I love FreeBSD for how efficient and minimalistic it can be.  For my web servers I like to add to this efficiency by using Lighttpd instead of the larger, older, Apache.

The one little issue with Lighttpd vs Apache is getting all the same module support setup for all the little tweaks that you’ve come to enjoy.

I should mention that Lighttpd supports many of the same modules that Apache does, and once you learn how they work I think they are even more intuitive than Apache’s config.  One of the most important to me is the mod_rewrite for use with my Wordpress blogs.  As you can see from the URL I use fancy addresses for my posts.  %date%/%name%, etc.  I think this is more user friendly (not to mention Google-friendly) than something like php?=53.  What kind of URL is that?

In any case, a very simple way to achieve this in Lighttpd is to use the following single line in your lighttpd.conf file:

## added for WP pretty URLs
server.error-handler-404 = "/index.php"

Again, I’d argue this is much simpler than a dozen lines in an .htaccess file and gives you the same results.  It’s like magic!

Perhaps I’ll do a few more posts regarding other aspects of Lighttpd configuration as it compares to Apache.  Things like mod_redirect, mod_auth, mod_alias, etc.  Until then, if you haven’t tried out Lighttpd you really should!

Tags: , ,

21 Feb 09 Weekly Update Notifications via Portmaster

Update: I have suggested a minor improvement to this setup.  Read More

For some time now I’ve been maintaining about a dozen FreeBSD jails, each running a different set of services. Everything from email to BIND, DHCP to nagios. One of the difficulties of trying to maintain so many servers has been tracking and applying updates, particularly servers that use the ports system which is updated so frequently.

The solution that I’ve come up with is to use portmaster inside a weekly cron job to notify me of available updates on each machine. This requires a slightly different cron job on the host system that within the jails. Here is an example of what I’m running within each:

#!/usr/local/bin/bash

/usr/sbin/portsnap cron
/usr/local/bin/ezjail-admin update -P

/usr/local/sbin/portmaster -L | egrep -B1 ‘(ew|ort) version|Aborting|installed|dependencies|IGNORE|marked|reason:|MOVED’ | grep -v ‘^–’ | mail -s “Portmaster Weekly Check for $(hostname)” admin@domain.tld


#!/usr/local/bin/bash

/usr/local/sbin/portmaster -L | egrep -B1 ‘(ew|ort) version|Aborting|installed|dependencies|IGNORE|marked|reason:|MOVED’ | grep -v ‘^–’ | mail -s “Portmaster Weekly Check for $(hostname)” admin@domain.tld

As you can probably tell, the only major difference between the two is that the cron job as run on the host system also updates the ports tree prior to checking for updates. The cron job within the jail system simply runs the check.

I save these two scripts inside /etc/periodic/weekly/999.portmaster and make them executable.  From that point on I’m notified via email regarding updates available to my installed ports.

I’d be interested in hearing what solutions others have come up with for monitoring and maintaining ports updates from so many FreeBSD servers.

Tags: , , ,

23 Dec 08 dhcpd inside ezjail

I have had all kinds of problems getting dhcpd running properly inside a FreeBSD jail.  I finally got it running this morning and wanted to document what I’ve done in hopes that I can recreate it.

On the host system I had to allow sockets within jails.  This is done by adding this line to your /etc/sysctl.conf:

security.jail.allow_raw_sockets=1

The above will make it a persistent change, but you’ll also need to make it an immediate change using the sysctl tool directly:

sysctl -w security.jail.allow_raw_sockets=1

Within the jail I then installed the net/isc-dhcp30-server port.  I configured this with just two of the available options.

  1. Allow sockets instead of bpf (jails-only)
  2. Use base openSSL

After this was compiled I configured my /usr/local/etc/dhcpd.conf and added the following lines to my /etc/rc.conf:

## dhcpd options
dhcpd_enable=”YES”
dhcpd_flags=”-q”
dhcpd_conf=”/usr/local/etc/dhcpd.conf”
dhcpd_ifaces=”"
dhcpd_withumask=”022″

The last thing that always caught me was that I never saw any log output in the /var/log/messages.  Turns out, at least on my installation, it doesn’t log there.  It does however log to /var/log/all.log, which is where I found that it was actually working.

I hope this works for the rest of you.  I had trouble with it for the longest time.

Tags: , , ,