named inside a FreeBSD jail
If you’ve ever tried to run named inside a FreeBSD jail you’ve seen this error:
/etc/rc.d/named: WARNING: devfs_domount(): Unable to mount devfs on /var/named/dev devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted
The reason for this is that by default in FreeBSD named tries to run within a chroot. The chroot for named requires /dev/zero, and /dev/random, so the rc script that starts named tries to mount a devfs for named. The problem is that jails cannot mount, for obvious reasons.
The quick solution is to tell FreeBSD not to try to run named within a chroot. The idea is that a jail is good enough. You can do this by seting:
named_chrootdir=""
within the JAIL’S /etc/rc.conf.
The other option is to create the chroot dir for named from the host system for the jail before you start it. This really doesn’t have too much of a benefit. But it’s possible by issuing the following commands from the host system for your jail:
# mount -t devfs devfs /jails/jailhost.whatever.com/var/named/dev/ # devfs -m /jails/jailhost.whatever.com/var/named/dev/ rule -s 1 applyset # devfs -m /jails/jailhost.whatever.com/var/named/dev/ rule apply path null unhide # devfs -m /jails/jailhost.whatever.com/var/named/dev/ rule apply path random unhide
Once you’ve done that, you can start named in the jail, and you’ll have named running inside a chroot within a jail. This doesn’t quell the error messages, but you can trust that they’re irrelevant, or if you feel like it, you can patch /etc/rc.d/named within the jail to not try to create/destroy chroots. Find these lines of code:
# Mount a devfs in the chroot directory if needed
#
umount ${named_chrootdir}/dev 2>/dev/null
devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
devfs -m ${named_chrootdir}/dev rule apply path null unhide
devfs -m ${named_chrootdir}/dev rule apply path random unhide
and make them look like this:
# Mount a devfs in the chroot directory if needed
#
#umount ${named_chrootdir}/dev 2>/dev/null
#devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
#devfs -m ${named_chrootdir}/dev rule apply path null unhide
#devfs -m ${named_chrootdir}/dev rule apply path random unhide
Now you have to maintain this stupidity, if your mergemaster changes /etc/rc.d/named, but I guess it’s nice not to see errors. You also can’t start your jails automatically at boot, because the chroot won’t exist yet… So…. whatever.
Stopping SSH SPAM with PF!
If you’ve put a server accepting SSH connections on the internet you’ve probably noticed a TON of failed login attempts from various IP addresses and various (seemingly generic) usernames. If not, you probably should have, and you may not be up to running a server if you don’t look at logs from time to time.
Either way, there’s a quick & easy way to try to stop these annoying bots or whatever they are from bugging your server with PF. Basically, on your rule where you pass SSH connections in through the firewall you can set a ‘max-src-conn-rate’ or maximum source connection rate. What this does is triggers something to happen when a host connects faster than a certain rate of allowed new connections. In our case we’ll want to dump these users into a table that blocks everything from them. So we create the table:
table <ssh-bruteforce> persist
The rule to drop people who are clearly spamming into our ssh-bruteforce table is:
pass in on $ext_if inet proto tcp from any to any port ssh flags S/SA keep state (max-src-conn-rate 4/30, overload <ssh-bruteforce> flush global)
Where the connection rate is 4 connections in 30 seconds (4/30). From this point on, you just want to block them. You can do that with:
block in log quick on $ext_if from <ssh-bruteforce>
Now anybody who tries to esablish connections faster than the rate specified in the pass rule gets dumped into that table, and blocked from accessing anything at all on your server. 
mhoran++
