For FreeBSD/Heimdal users who wish to use Kerberos to authenticate users with OpenLDAP, you’ve likely run into a big of a snag when using more recent (v1.0 or higher) version of Heimdal. This all stems from a security-related change that exists in lib/roken/issuid.c. The test is quite simple and basically detects whether or not the current process has been ‘tainted’ via uid/gid changes. According to the FreeBSD man page for issetugid(2), this specifically means:

• A process is tainted if it was created as a result of an execve(2) system call which had either of the setuid or setgid bits set (and extra privileges were given as a result) or if it has changed any of its real, effective or saved user or group ID’s since it began execution.

or, in other words, anything that was executed as root and later drops privs, like slapd. The reason this is problematic for us is that OpenLDAP relies on the environment variable KRB5_KTNAME to set which keytab to open. If a process was considered tainted, Heimdal will ignore this variable and use the system default.

I’ve seen various patches to the Heimdal libraries/OpenLDAP code that all workaround this issue, but I was interested in a more elegant solution and something that did not require me to maintain my own set of patches to deal with each time I went to upgrade code.

My solution was to simply utilize the chroot option with OpenLDAP. For FreeBSD users, you can simply do the following:

1. Change the default location of saslauthd’s socket, build OpenLDAP with SASL support:

echo “SASLAUTHD_RUNPATH=/usr/home/ldap/var/run/saslauthd”>>/etc/make.conf
echo “WANT_OPENLDAP_SASL=yes”>>/etc/make.conf

• You will need to rebuild openldap and/or saslauthd if the ports for these were already installed.

2. Create the required directory structure and copy some required files:

mkdir -p /usr/home/ldap/usr/local/etc/openldap /usr/home/ldap/dev /usr/home/ldap/lib /usr/home/ldap/usr/lib /usr/home/ldap/etc/gss /usr/home/ldap/var/run/openldap /usr/home/ldap/var/db/openldap-data /usr/home/ldap/usr/local/lib/sasl2 /usr/home/ldap/usr/local/libexec/openldap /usr/home/ldap/var/run/saslauthd
cp /etc/localtime /usr/home/ldap/etc;cp /etc/group /usr/home/ldap/etc

3. Update /etc/fstab by appending the required entries to /etc/fstab and mounting the new mounts:

cat /path/to/fstab-ldap >> /etc/fstab
mount -a

4. Create empty files in key locations to ensure that the ports framework does not delete these directories during upgrades. This is important as we will break our nullfs mounts if the original directories are removed:

touch /usr/local/lib/sasl2/.do_not_delete /usr/local/libexec/openldap/.do_not_delete /var/run/openldap/.do_not_delete

5. Copy over /etc/passwd and /etc/master.passwd to /usr/home/ldap/etc and update:

cp /etc/master.passwd /usr/home/ldap/etc; cp /etc/passwd /usr/home/ldap/etc; pwd_mkdb -d /usr/home/ldap/etc /usr/home/ldap/etc/passwd; vipw -d /usr/home/ldap/etc

• $EDITOR will open and you should then delete any non-default users that aren’t essential to OpenLDAP. (Make sure you leave the ldap user). The -d argument to vipw instructs vipw to work on the files in /usr/home/ldap/etc instead of the default (/etc)

6. Create a new krb5.conf inside the root with the required contents:

echo “[libdefaults]”>/usr/home/ldap/etc/krb5.conf
echo " default_keytab_name = FILE:/usr/local/etc/openldap/ldap.keytab">>/usr/home/ldap/etc/krb5.conf

• You will likely want other customizations to this file. For example, specifying the default_realm option.

7. Copy your keytab for OpenLDAP to /usr/local/etc/openldap/ldap.keytab

8. Add the following to /etc/rc.conf:
syslogd_flags=“-l /usr/home/ldap/var/run/log”
slapd_flags=“-r /usr/home/ldap”

9. Start saslauthd/slapd and do some testing.

Monitoring vSphere/ESX in nagios is fairly easy. For FreeBSD users, you’ll need to do the following:

1. Install nagios:

cd /usr/ports/net-mgmt/nagios-devel && make install clean

• Note: nagios-devel is only required until 3.2.4 is released as there is a servicedependency fix that will be incorporated into 3.2.4 that makes it easy to do the type of servicedependency that is used in vsphere.cfg.

2. Install the vmware-vsphere-cli port:

cd /usr/ports/net/vmware-vsphere-cli && make install clean

3. Download the check_esx3.pl plugin from op5 and place it in /usr/local/libexec/nagios

4. Configure any remaining components of nagios for your environment.

5. Use vicfg-user from the vmware-vsphere-cli port to add a nagios user to each of your ESXi hosts:

vicfg-user -server esxihost -username root -e user -o add -l nagios -p securepassword -r read-only

6. Create a file called vmware_authfile in /usr/local/libexec/nagios (and make sure it’s only readable by the nagios user) with the following contents:

username=nagios
password=securepassword

7. Add the vSphere configuration/dependency config file into your nagios config files and edit as needed. You’ll want to add your own hosts, just follow the existing format. The magic will automatically add the required tests/dependencies as long as the additional hosts follow the same format as the sample esxihost.

8. Add the vSphere checkcommands for nagios to your config as well.

9. Reload nagios and you should end up with vSphere monitoring!

Sample Output

• Note: check_esx3.pl also includes additional ability to monitor VMs and other information by having it connect to vCenter. You should easily be able to add in these additional tests if you want them by following the existing samples.

Tried to configure snort to log to a remote MySQL box and came to the rapid realization that snort did not support doing so via SSL.

The attached diff(1) will force snort to require SSL for MySQL connections. You may find it here.

NOTES:

• If you’re chrooting snort, you’ll need to have devfs mounted therein for /dev/urandom. Under FreeBSD, you would simply edit /etc/fstab and add a line similar to the following:
  none /path/to/snort/chroot/dev devfs rw 0 0
  • Then run ‘mount -a’ to mount it.
• You’ll need to copy your certificates into the root.
• If you wish to make a non-SSL connection, you’ll need to undo the patch.
• Make sure you did not leave the private key world readable.

UPDATE:

• Database output functionality is being deprecated in snort in favor of utilizing unified2 with barnyard2.

An experimental port of TrueCrypt has been added to the FreeBSD ports tree. Additional details can be found here.

Improve reliability with CARP and redundant DNS on two boxes. Almost everyone already has (at least) two nameservers, so why not add CARP into the mix to make it appear as if they’re always available?

This setup assumes two nameservers. Both nameservers will have a total of 3 IPs assigned to them, two of which are the floating CARP IPs and one of which is a unique management IP for each box. Each nameserver will be the CARP backup for the other nameservers primary nameserver IP. If one goes down, the other will assume responsibility for the IP.

You’ll need to assign your nameservers two new IPs (to be used for management) and take the original pair of IPs and we’ll use those for the carp interfaces.

1. Rebuild/install your kernel with:
device carp

2. Edit /etc/rc.conf to add:
cloned_interfaces=“carp0 carp1”
ifconfig_carp0=“create”
ifconfig_carp1=“create”

3. Setup the CARP interfaces:

I set the vhid’s to be the last octet of the floaty IP, however, you can set them to be whatever you want as long as they match on both boxes.

On ns1:
Create /etc/start_if.carp0 with the following:
#!/bin/sh
ifconfig carp0 vhid XX advbase 1 advskew 10 pass supersecretpasswordhere netmask

Create /etc/start_if.carp1 with the following:
#!/bin/sh
ifconfig carp1 vhid YY advbase 2 advskew 10 pass othersupersecretpasswordhere netmask

Then run:
chmod go-rwx /etc/start_if.carp*;chmod +x /etc/start_if.carp*

On ns2:
Create /etc/start_if.carp0 with the following:
#!/bin/sh
ifconfig carp0 vhid YY advbase 1 advskew 10 pass supersecretpasswordhere netmask

Create /etc/start_if.carp1 with the following:
#!/bin/sh
ifconfig carp1 vhid XX advbase 2 advskew 10 pass othersupersecretpasswordhere netmask

Then run:
chmod go-rwx /etc/start_if.carp*;chmod +x /etc/start_if.carp*

• carp0 on both boxes will be its PRIMARY IP whereas carp1 will be the SECONDARY IP on both. In a non-failover scenario, this means that carp0 on both boxes should show up as MASTER and carp1 should show up as BACKUP.

4. Ensure named is configured to bind to the management IP (for zone transfers, etc.), ns1.ip and ns2.ip (on both boxes!) or ensure that it listens on *.

5. Add net.inet.carp.log=2 to /etc/sysctl.conf for some extra logging info.

6. Reboot. Your primary box should come up with ns1.ip as MASTER and ns2.ip as BACKUP. Your secondary box should come up with ns2.ip as MASTER and ns1.ip as BACKUP. Check ifconfig and dmesg to confirm.

• Note: CARP traffic is multicast and you may need to alter firewalls as appropriate to allow it. The destination is VRRP.MCAST.NET/224.0.0.18.
  For defining masters/slaves, etc. in bind you will want to reference the management IPs of the boxes, not the floating CARP addresses.

• Note: You can actually skip using the start_if.* files if you elect to put the ifconfig statements into rc.conf. In order to limit access to your CARP authentication key, you would need to change the permissions on rc.conf which could be bad in certain situations.

• ESX Note: If you’re trying to do this with a box in VMware, you’ll need to disable the vSwitch security features (accept: promisc, forged transmits, mac changes). This is not advisable in production as any VM on that switch can sniff traffic from any other VM. For my setup at home, I simply allocated a second NIC and a second vSwitch and made the security changes on the dedicated vSwitch. No other VMs should share this other vSwitch where the security features have been disabled.