SELinux is a mandatory access control (MAC) system available in Linux kernels as of version 2.6. Of the Linux Security Modules available, it is the most comprehensive and well tested, and is founded on 20 years of MAC research. SELinux combines a type-enforcement server with either multi-level security or an optional multi-category policy, and a notion of role-based access control.

Most people who have used SELinux have done so by using an SELinux-ready distribution such as Fedora, Red Hat Enterprise Linux (RHEL), Debian, or hardened Gentoo. These enable SELinux in the kernel, offer a customizable security policy, and patch a great number of user-land libraries and utilities to make them SELinux aware.

If you’re like many users who simply want the system to work as before, but a bit more securely, you can query and manipulate SELinux by using familiar applications and by writing security policies using a higher level language. However, these methods can be insufficient when something breaks — such as when kernel and user-space get out of sync. Also, these methods might even hinder the UNIX® engineer from understanding how SELinux is actually working. Finally, the engineer and the security community should understand that there are appropriate ways to use SELinux outside of the conventions in use by current distributions.

In this article, learn how to convert a system that is initially completely unaware of SELinux into one that enforces SELinux. You also learn how to enforce a few simple access policies.

Preliminaries

To get started, you need:

• QEMU, a freely available and easy-to-use processor emulator. It is an excellent way to play with new kernels or system images without doing harm to your real system. You can download it from the QEMU download page.
• Gentoo, a source-based Linux distribution. Gentoo is ideal for this exercise, since you can install it under a running system regardless of the distribution. Find the latest version at the Gentoo download page.

Create a disk image by typing:

qemu-img create -f raw gentoo.img 2G

The next step is to start up QEMU to partition the raw disk image and format a single partition. This requires some sort of Linux boot CD. Knoppix will do, as will a Gentoo liveCD. You can download a Gentoo liveCD as follows:

wget ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo/releases/x86/current/installcd/install-x86-minimal-2006.0.iso

For easier future reference — and less typing — you might want to rename the image:

mv install-x86-minimal-2005.1.iso gentoo.iso

The following command instructs QEMU to use gentoo.iso as its CD, use gentoo.img as its hard disk, and boot from the CDROM:

qemu -hda gentoo.img -cdrom gentoo.iso -boot d

Just hit Return for the default kernel. Then, type the following to partition the disk image:
Listing 1. Partition a disk image

fdisk /dev/hda
n
p
1
(return)
w

The above listing creates a single new (n) primary (p) partition beginning at block 1 (1) and ending at the default ending block, which is the last block on the file system. It then writes (w) the new partition table to the disk image.

Now, you will be returned to the shell prompt in QEMU. Here, type:

mkfs.ext2 /dev/hda1

You may have to do that twice in order to give udev a chance to create the device. Then, shut down by typing:

poweroff

This returns you to your real system’s shell. If it does not, and hangs for a long time, hit Ctrl-c to end it.

The next step is to lay a basic distribution down on the disk image. One reason Gentoo is a great fit for this exercise is because you can simply download and extract a “stage 3″ image, giving you a functional Gentoo system. You should find a local mirror from which to download a stage 3 tarball. An example location, if you are located near Sandia National Laboratories, is:

wget ftp://mirror.iawnet.sandia.gov/pub/gentoo/releases/x86/current/stages/stage3-x86-2006.0.tar.bz2

This file contains a compressed archive of a full Gentoo system. To extract this into your disk image, first mount the disk image onto your system. The following listing mounts the empty file system and expands the tarball onto it.
Listing 2. Extract Gentoo tarball onto disk image

su  (give root password)
ORIG=`pwd`
mount -oloop,offset=32256 gentoo.img /mnt
cd /mnt
tar jxf $ORIG/stage3-x86-2005.1.tar.bz2

While the image is still mounted, there are a few more preliminaries to take care of. The /etc/fstab file instructs the system which file systems to mount where. For this simple system, no boot or swap entries are needed. The following listing removes those and inserts a correct entry for the root partition. It also sets the password for the root user. Make sure that when running passwd, you pick a password you remember. Security is not a concern for this toy system, so “password” will do.
Listing 3. System preliminaries

mv /mnt/etc/fstab /mnt/etc/fstab.orig
sed -e '/[BR]OOT/d' -e '/SWAP/d' /mnt/etc/fstab.orig > \
   /mnt/etc/fstab

cat >> /mnt/etc/fstab << EOF
/dev/hda1 / ext2 noatime 0 1
EOF

chroot /mnt
passwd
exit

cd $ORIG
umount /mnt

A kernel is needed for the QEMU image to boot. Simply compile this with SELinux support now, even though you won’t be using SELinux just yet. Grab a copy of linux-2.6.14.tar.bz2 (or the latest version) from kernel.org and extract it:

wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.tar.bz2
tar jxf Linux-2.6.14.tar.bz2

Then, change into the Linux-2.6.14 directory and configure the kernel, like so:

cd linux-2.6.14
make defconfig
make menuconfig

Make sure to enable at least the following options:
Listing 4. Excerpts from kernel .config

CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_SECURITY=y

CONFIG_SECURITY=y
CONFIG_SECURITY_CAPABILITIES=y
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1

Now, compile this kernel using the following command:

make
cp arch/i386/boot/bzImage ..

Surely, you’d like to test this system before converting to SELinux. You can do this using this command:

qemu -hda gentoo.img -kernel bzImage -append "ro root=/dev/hda1"

Look around, add some users, and play with your system. When you’re done, shut it down using poweroff. Now, you’re ready to begin converting this system to SELinux.

Converting to SELinux

To convert this system to one that supports and enforces SELinux, you need to modify the program that begins booting the system, /sbin/init, and add a few other pieces of software to build SELinux policy and interact with SELinux.

SysVinit

Begin by grabbing a clean copy of SysVInit. Download version 2.86 from ftp://ftp.cistron.nl/pub/people/miquels/sysvinit/sysvinit-2.86.tar.gz, or look for the latest version on the SysVinit page on freshmeat. You can download a patch (sysvinit-init.c.diff) in the zip file available in the Downloads section, below; this patch will be applied on top of the file init.c using the procedure in Listing 5. This patch causes the SELinux policy to be loaded at boot. It introduces a flag no_selinux, which is set to 1 if the boot command includes -p. If that flag is set, a warning is given and boot proceeds as normal. Otherwise, the function load_policy(), which is defined further in the patch, is called.
Listing 5. Partition a disk image

wget ftp://ftp.cistron.nl/pub/people/miquels/sysvinit/sysvinit-2.86.tar.gz
cd sysvinit-2.86
cd src
patch -p0 < $ORIG/sysvinit-init.c.diff
make init
(su)
mount -oloop,offset=32256 $ORIG/gentoo.img /mnt
mv /mnt/sbin/init /mnt/sbin/init.good
cp init /mnt/sbin/init
umount /mnt
exit

The function load_policy() mounts an instance of the selinuxfs file system on the directory /selinux, and opens the file /etc/policy.bin for reading. Note that both /selinux and /etc/policy.bin are arbitrary names so long as any userspace tools that might want to use them agree on the naming. When an SELinux policy is compiled, the binary version will need to be copied to /etc/policy.bin. Next, load_policy() mmap()s the file /etc/policy.bin, and calls security_load_policy, which is defined immediately above load_policy. It, in turn, opens the file /selinux/load, which is a file in the selinuxfs file system, for writing, and writes the entire contents of /etc/policy.bin into /selinux/load. This is how the binary policy will be loaded into the kernel at boot.

Creating a policy

SELinux is a flexible access control system whose access decisions are guided by an administrator-definable policy. Policies depend on the layout and configuration of files on the system. Distributions that support SELinux come with a predefined policy. While it is possible to edit the policy, you generally edit policy only to the extent of excluding whole chunks of policy relating to software not installed on the system. More detailed policy editing generally belongs to the realm of SELinux experts. However, in this exercise, you will define your own policy.

Because new object classes and permissions are introduced from time to time, policies end up being somewhat dependent on kernel versions. The program located in mdp.tar.gz (in the zip file in the Downloads section, below) will automatically construct a dummy policy based on your kernel version. Since it will need to analyze the kernel source, you will need to point it at the source tree that you used to compile the kernel for the QEMU image. Extract mdp.tar.gz into $ORIG/ and enter the resulting directory, mdp/.

Type:

./build.sh -k ../linux-2.6.14.

This compiles the program mdp and runs it with the kernel directory as an argument. mdp in turn looks at the object classes and permissions that the kernel knows about and creates an SELinux policy containing this data. The resulting policy will have one SELinux user, one SELinux role, and one SELinux type. The single type will be applied to all files, kernel objects, and processes, and will have full access to itself. We will play with customizations to this policy later, but for now it is sufficient to initialize and use SELinux.

When build.sh runs mdp, it will create several files. You need policy.conf and file_contexts. The former is the text representation of the policy, the latter contains the instructions for how to label the file system.

I’ll defer a comprehensive study of policy.conf for now, so skip the first five or six hundred lines to this line:

type base_t;

This is the only type defined in this policy. The next line:

role base_r types { base_t };

defines a single role, base_r, which is associated with type base_t. This means that a process in role code_r may run under domain base_t. Next comes a long list of allow statements, one specifying each object class, giving the process under domain base_t access to the object classes of type base_t for all permissions defined for the class.

Next, the policy defines a user, user_u, which is associated with role base_r. A process that is running as SELinux user user_u, then, can run under role base_r. You’ve already seen that base_r is associated with type base_t, so these two statements together make user_u:base_r:base_t a valid context, meaning a process will be allowed to run under that context.

The next few lines are also of interest. The first:

sid kernel user_u:base_r:base_t

assigns the single valid context to the first process on the system. Two lines later, you see:

sid unlabeled user_u:base_r:base_t

which assigns the same context to any files that are otherwise unlabeled.

Now take a look at the file called file_contexts. It contains two lines. The format is:

<regexp> <context>

where regexp is a regular expression used to compare against file names, and context is an SELinux context to apply to a file if it matches the regular expression. The line:

/.* user_u:base_r:base_t

is used to assign the context to all files on the system.

Installing SELinux userspace

The next step is to install some code that will compile the SELinux policy, which you’ve written in text form, to the binary format, which the kernel requires, as well as a program to label your root file system. The source is available through CVS from SourceForge by using the command shown in Listing 6:
Listing 6. Check out SELinux userspace source

su
mount -oloop,offset=32256 $ORIG/gentoo.img /mnt
cd /mnt/usr/src
cvs -z3 -d:pserver:anonymous@cvs.sf.net:/cvsroot/selinux co -P \
nsa/selinux-usr

Copy the plain text policy onto the disk image, like so:

cp -r $ORIG/mdp /mnt/usr/src

Enter the nsa/selinux-usr directory, and compile libsepol, checkpolicy, libselinux, and policycoreutils, as follows:
Listing 7. Compile SELinux userspace code

chroot /mnt
cd /usr/src/nsa/selinux-usr/
cd libsepol/
make && make install
cd ../libselinux/
make && make install
cd ../checkpolicy/
make && make install
cd ../policycoreutils/
make && make install

If you encounter an error during the last step, make certain that setfiles is installed by typing this:
Listing 8. Install setfiles

cd setfiles
make
make install

Now, to compile the policy, use the checkpolicy program like this:
Listing 9. Compile SELinux policy

cd /usr/src/mdp
checkpolicy -o policy.bin policy.conf
cp policy.bin /etc/
exit  # exit chroot
exit  # exit root shell

Relabeling the file system requires booting into the virtual machine. Remember to specify the -p option for now, so that /sbin/init will not attempt to load an SELinux policy:

qemu -hda gentoo.img -kernel bzImage -append "ro root=/dev/hda1 -p"

SELinux interacts with userspace programs through its own file system, selinuxfs. The userspace programs expect this to be mounted under /selinux. Create the /selinux directory and relabel the file system, as follows:
Listing 10. Relabel the file system

mkdir /selinux
cd /usr/src/mdp
setfiles file_contexts /
poweroff

Finally, you can reboot under SELinux!

qemu -hda gentoo.img -kernel bzImage -append "ro root=/dev/hda1"

Studying the SELinux policy

SELinux makes access decisions based on the security contexts assigned to processes, files, and other objects. SELinux provides interfaces for querying these contexts and, given the required access rights, to set them. For instance, SELinux reports process contexts through the procattr interface. If you type:

cat /proc/$$/attr/current

you see the context of the current process ($$). By using the script pidctx.sh (see the zip file in the Downloads section, below), you can easily view the context of all processes on the system. The script simply prints the /proc/<pid>/attr/current file for each process on the system.

SELinux stores file contexts using extended attributes. Most persistent file systems under Linux (ext2, ext3, jfs, xfs, etc.) support extended attributes, though reiserfs is an unfortunate notable exception. These are (name, value) pairs of data that are associated with inodes, where the name is separated by periods into namespaces. The SELinux extended attributes are in the security namespace and identified by “selinux”, so the full name of the xattr value is “security.selinux”. A new set of system calls allows userspace to query and set extended attributes. The system call to query an xattr is getxattr(2). It takes a file name, an attribute name, a buffer in which to return the value of the xattr, and the size of the provided buffer.

The showctx.c file simply runs through all the file names provided as command line arguments and prints the value of the security.selinux extended attribute, provided that it exists, is readable, and fits within a reasonable size.

You can download showctx.tar.gz from the zip file in the Downloads section, below, and extract showctx.c. Then get it into your QEMU machine some way. One way is to shut down the QEMU image and then do this:
Listing 11. Install showctx

(su)
mount -oloop,offset=32256 $ORIG/gentoo.img /mnt
cp showctx.c /mnt/usr/src
umount /mnt
exit

Now start QEMU, if it is not already running. To compile showctx, type:

gcc -o showctx showctx.c cp showctx /bin/

Now you can type:

showctx / /tmp /home /root /usr/src

Of course, you’ll see the same context for each file. The next section makes this somewhat more interesting by enhancing the policy.

Back to top

Playing with SELinux policy

Secret type

You’ll create a secret directory, /secret, under which SELinux should allow no process to read. Begin by actually creating the directory and a few files under the directory:

mkdir /secret echo "hello, world" > /secret/helloworld echo "You can't see me" > /secret/dontlook

In the SELinux policy, now create a new type, secret_t, to which the other type, base_t, has no permissions. First, you define the type by adding:

type secret_t;

after the declaration of base_t in policy.conf. In addition, since the files of type secret_t will be of role base_r, the role base_r must be allowed to associate with secret_t. The line following the one you just added reads:

role base_r types { base_t };

Edit this to read:

role base_r types { base_t secret_t };

Now, to recompile this policy, type:

checkpolicy -o policy.bin policy.conf
cp policy.bin /etc/

Next add the following lines to the file_contexts file:
Listing 12. File contexts for /secret

/secret user_u:base_r:secret_t
/secret/helloworld user_u:base_r:base_t
/secret/.* user_u:base_r:secret_t

This tells the system that the directory /secret, and any file name underneath it, should be of type secret_t, except for the file /secret/helloworld, which should still be of type base_t. To assign these contexts on disk, use setfiles:

setfiles file_contexts /

Oh no, an error! SELinux doesn’t yet know about the type secret_t. It is, in fact, possible to dynamically reload the SELinux policy. For now, however, for the sake of simplicity, just reboot the QEMU image. Of course, since a bootloader was never installed, a simple reboot won’t work. Therefore, you need to type poweroff to shut down the QEMU image. If the window does not disappear after “Power down” is printed, then Ctrl-c the qemu command. Rerun the qemu command to restart it. Then try running the above setfiles command again.

Verify that the policy reload worked:

showctx / /secret /secret/helloworld /secret/dontlook cat /secret/dontlook

But wait! You can see the secret types.

This is the result of one of the compile time kernel options, CONFIG_SECURITY_SELINUX_DEVELOP. This option defaults SELinux into non-enforcing mode. To verify this, type:

cat /selinux/enforce

which should return 0. To set SELinux into enforcing mode, type:

echo 1 > /selinux/enforce

You could do this automatically at boot through an init script if you wanted to, as in Listing 13, or simply compile a kernel without SELINUX_DEVELOP support.
Listing 13. Set SELinux enforcing mode on boot

cat >> /etc/rc.d/selinux-enforce << EOF
#!/bin/sh
echo 1 > /selinux/enforce
EOF
chmod ugo+x /etc/rc.d/selinux-enforce
rc-update add default selinux-enforce

Now that SELinux is in enforcing mode, try browsing under /secret again. Note that even though your process context has the rights to read /secret/helloworld, you can’t actually read it because you cannot get past /secret. A hardlink to the file could, of course, bypass this. This is not true for other files under /secret/, because the files themselves are unreadable.

Conclusion

In this article, you’ve seen how to reproduce much of the work that has already been done in some distributions to incorporate SELinux. If it seemed daunting, rest assured — by simply installing a fresh copy of recent Fedora, you can be running SELinux so transparantly that you may not even know it is installed. The point of this excercise, then, was not to persuade you that security is intrusive, but rather to explain some of what goes on behind the scenes in a properly integrated SELinux system.

Introduction
Firstly FreeBSD refers to both a kernel and userspace tools making it a whole operating system (userspace tools being the basic programs like shells and copy/move commands), this is different to Linux which is just a kernel and distros are technically called GNU/Linux to show that it is using the GNU userspace tools. You can install the GNU userspace tools on FreeBSD and you can also get GNU/FreeBSD hybrids such as the Debian GNU/kFreeBSD, and there was work on a Gentoo/FreeBSD but it never went anywhere, although there not really used much. Theres also not a huge point in either since all the userspace tools are based on the original Unix ones and try to mee POSIX standards etc %90 of the functionality is the same. There are some differences, for instance ‘ls –color’ on FreeBSD is ‘ls -G’, some commands require the flags to be in the correct order so ‘cp /directory /somewhere -rf’ won’t work as -rf is at the end instead of the start befoure the directories, when hitting the down arrow at the end of a man page it will exit on FreeBSD.

The other important difference between BSD’s and Linux is the license they use, Linux uses the GPL and BSD uses the BSD license. The GPL is actually more restrictive but in a way that is designed to guarantee everyones overall freedoms, by enforcing that the source remains open when redistributed. The BSD license basically says you can do whatever you want provided you keep the credits in, including taking the source and closing it or relicensing it. Apple took the FreeBSD userspace tools for OSX (and the Mach microkernel)

The difference in the kernels means that hardware is going to behave differently, device names in /dev/ are diffrent for starters. Ethernet cards have names that match the device model, for instance instead of “/dev/eth0″ you might have “/dev/re0″. My harddrive is “/dev/ad10s1″ instead of “/dev/sda1″ There will be differences in the hardware that is supported, wifi is apparently better on FreeBSD although there has been a lot of work in the Linux area recently and some of the drivers have been ported across (leading to some controversy due to the relicensing of BSD code under the GPL, although it has apparently been resolved).

The overall system feels fairly similar to Slackware and Gentoo, except with better package management IMHO.

Installing
Installing isn’t particularly hard, if you have installed either, its not a Ubuntu style userfriendly distro so you do need to partition and such but it didn’t require heaps of planning and was fairly hassle free. There is also the handy FreeBSD handbook which is actually fairly good, normally when I get told to read opensource documentation I find a bunch of out of date or setup in a completely different way by everyone but the guide writers. You can get away with only getting the 1st CD since that contains the basic system and if you don’t choose much in the way of packages you won’t need the others. If however you do get asked to insert the 2nd or 3rd CDs, at that stage you can just ctrl+c and reboot into a working distro and use ‘sysinstall’ to make any additional changes. Set the root password with ‘passwd’ and add a user account with ‘adduser’.

One installed you need to setup stuff, once again if your a Gentoo user this is familiar. FreeBSD has binary packages that can be retrieved automatically via ftp by using the ‘pkg_add -r ‘ command. FreeBSD however also can compile packages from source using ports, this is similar to Gentoo’s portage which was heavily inspired by ports. Ports seems a simpler and more stable system than portage with which I have had problems maintaining when updating packages can break or lock other packages.

Firstly I had some problems with my USB keyboard, in the end I had to disable USB legacy in the BIOS which was blocking BSD from using it for some reason, this has the unfortunate side effect of disabling the keyboard in the boot loader but its not needed for now.

Ports
Ports is the system that FreeBSD uses to get source code for packages, compile and install it. It is similar to Portage as it used ports as inspiration. Compiling from source has advantages over using binary packages. For instance patent issues aren’t a problem because its the source code, I am not a lawyer but source code itself cannot be patented as its a blueprint not an actual thing, and compiling the code your self is possibly ok since you can apparently violate patents for personal use (not too sure on that, some talk here, at the very least it means that to enfoce the patent requires going after individuals rather than FreeBSD so home users are unlikly to be at risk (unless patent lawyers frequent your premises), it also allows for people in countries without such laws access to the code), but as I said I’m not a lawyer and haven’t bothered to find much in the way sources. Secondly you get more control over what features you want in your program and thirdly you can optimize the program for a specific architecture.

Setting up ports, If you want to grab a new snapshot of ports you will need to run ‘portsnap fetch’ followed by ‘portsnap extract’. If you already have “/usr/ports” perhapses because you chose it when the installer asked you can apparently ‘cd /usr/ports’ followed by ‘make update’. This should use portsnap to update it. The full was about a 50mb download when I did it with ‘portsnap fetch’.

Ports has a similar thing to Gentoo’s portage useflags called KNOBS, you can see a whole list of them in /usr/ports/KNOBS. I believe you can also set CFLAGS like in Gentoo although I havn’t bothered.

Desktop
If your using it on the desktop you will need to install xorg and a desktop environment, you can “pkg_add -r gnome2″ to do that, which should pull in all the dependencies. Alternatively to build from source: cd /usr/ports/x11/gnome2 && make install clean
If you want to use gdm add gdm_enable=”YES” to /etc/rc.conf. If you don’t want Gnome you can so whatever other environment you want, Fluxbox, XFCE, KDE, etc… You will need to edit ~/.xinitrc and add “gnome-session”, “fluxbox” or whatever. You can then ‘startx’. At this point there will be a bunch of programs you need to install either from ports or with pkg_add -r such as firefox, pidgin, vlc (although totem should be in if you did gnome2), music players, etc…

Shell
The default shell csh might not be to your liking, a lot of people are experienced with bash which is the choice of most Linux distros although personally I prefer zsh which has better tab completion and fancy prompts included. ‘pkg_add -r zsh’ or ‘pkg_add -r bash’ or install them from ports. Then run ‘chsh’ which will give you a vi window, change the “Shell: /usr/bin/csh” to “Shell: /usr/local/bin/zsh”. Bash users will need to change it to bash obviously. If vi is a problem for you, you can probally edit ‘/etc/passwd’ with whatever you want. You will need to setup your shell rc, ~/.zshrc for zsh (although it has a config window on first time login).

Sound
You will probably need to enable sound, Theres a handy howto here, but basically ‘kldload snd_driver’, ‘cat /dev/sndstat’, look for the driver name right after “kld”, add DRIVERNAME_load=”YES” to /boot/loader.conf

Mount Linux ext3 Drive
Mounting your Linux drive, add the following entry to /etc/fstab: /dev/ad10s2 /mnt/ubuntu ext2fs rw 0 0 with whatever changes you need for your device name or mount point. You will need to make the mount point to with ‘mkdir /mnt/ubuntu’. If you get the error “mount: /dev/ad10s2 : Invalid argument” this could be because your drive is unclean, you will need to install the /usr/ports/sysutils/e2fsprogs/ and run ‘fsck.ext3 /dev/ad10s2′ (Assuming your using ext3).

NTFS read/write with NTFS-3g
Mounting a NTFS drive with read/write is a bit more work, you need to install ‘/usr/ports/sysutils/fusefs-ntfs’, however it needs the userspace source. You can get this with ‘sysinstall’ choosing “Configure>Distributions>src>All”, this will grab all the source its probably not all required but I couldn’t find the specific package and its handy to have the rest around anyway. Once you have that you can ‘ntfs-3g /dev/ad10s1 /mnt/windows’. Adding an fstab entry is again a bit problematic. Under 7.0 the mount command has had hardlinks to what it can call, mount_ntfs-3g isn’t in that list so you either need to patch mount or rename the current mount_ntfs, and link ntfs-3g in its place. Without that this was throwing an “mount: /dev/ad10s1 : Operation not supported by device” error.

nVidia drivers
The drivers work quite well on FreeBSD 7.0 but only on i386 (64bit is out of luck thanks to closed source nvidia drivers, 64bits OS is mostly useless anyway), the official ones refuse to install for me but the ones in ports work. Firstly you need the kernel source code installed, if you followed the NTFS-3g instructions above you will have the source already. If not you can specify just the base and sys source in sysinstall which is all thats needed for the drivers. Then cd /usr/ports/x11/nvidia-driver && make install clean Add this to /boot/loader.conf nvidia_load="YES" Now you need an xorg.conf file, by default BSD just relies on the autoconfig magic in the latest xorg releases so we need to force it to generate one with: Xorg -configure then copy the newly created xorg.conf.new to /etc/X11/xorg.conf. If you don’t want to edit the xorg by hand cd /usr/ports/x11/nvidia-xconfig && make install clean then nvidia-xconfig will change the “nv” driver to “nvidia”.

Compiz Fusion
Firstly if your on nVidia hardware you need to enable some xorg.conf settings, you can do them with nvidia-xconfig if you installed it above nvidia-xconfig --composite && nvidia-xconfig --render-accel && nvidia-xconfig --add-argb-glx-visuals -d 24

Now install Compiz with: cd /usr/ports/x11-wm/compiz-fusion && make install clean When you want to start it use LIBGL_ALWAYS_INDIRECT=1 compiz --sm-disable --replace ccp and for the Emerald decorationsemerald --replace. I had some problems with emerald not starting right away and drawing no decorations but after a while it loaded fine without me noticing and now starts fine. You will probably want to make Compiz start automatically, there are various guides on Compiz around that give you different ways. The config programs should be in System>Preferences for Compiz and Emerald, otherwise use ‘ccsm’ and ‘emerald-theme-manager’.

updatedb
For those of you who use ‘locate’ command to find files, you will probably want to update the database, you might have already noticed that ‘updatedb’ isn’t a command. The actual command is ‘/usr/libexec/locate.updatedb’ but this will give you a warning as running it as root will expose hidden files that only root or specific users should see to the database (not such a problem for single users), you can however run the cron job manually for a safer database with: /etc/periodic/weekly/310.locate

Flash
One of the main problems with Desktop FreeBSD is that Flash has no native port for FreeBSD thanks to Adobe (Even though there is a Solaris port thanks to Sun working with Adobe, you can have your say on the flash development blog, also an online petition exists for what little use they are with over 5000 signatures(and spam bots)). There has been some talk on the mailing lists of a native FreeBSD port.

The only real solutions seems to be to use Flash 7 or possibly Windows Firefox under Wine ☹ (PC-BSD Apparently ship a Windows Firefox PBI)

If you want to try the Linux version of Flash 9 which freezes for me (and everyone apparently), you need to install the Linux plugin /usr/ports/www/linux-flashplugin9 and the wrapper /usr/ports/www/nspluginwrapper/. Then run nspluginwrapper -v -a -i to register the plugin. Check in ‘about:plugins’. Alternatively you can try Flash7 with a wrapper, there is also another wraooer /usr/ports/www/linuxpluginwrapper but it wouldn’t install for me.

ETQW [unsolved]
I though I would give ETQW a go under FreeBSD, unfortunately I ran into problems with the Linux compatibility layer, I’ll post the steps here in case its of use to someone trying to do something similar or can offer a solution.

Firstly the installer didn’t give the default path but entering one works however it then failed to make the path so you need to make it manually, then it failed to read from the cdrom (although I didn’t really look into it since you can just copy the files across manually, possibly manually mounting it manually would have solved it). Copy the correct files into the base directory.

When running the etqw binary I get an error about missing sdl libraries “./etqw.x86: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory”, You can fix this with cd /usr/ports/devel/linux-sdl12/ && make install clean

You will need to brand you etqw binaries as Linux ones, change to your etqw directory and run brandelf -t linux * also brandelf -t linux pb/* might be needed.

Then run: portmaster emulators/linux_base-fc4 to get all the Linux compatibility stuff installed (if using portmaster you need /usr/ports/ports-mgmt/portmaster/ installed)

Then there I got “./etqw.x86: error while loading shared libraries: /usr/local/lib/libX11.so.6: ELF file OS ABI invalid”, make sure that /usr/ports/x11/linux-xorg-libs/ is installed.

For the error “./etqw.x86: error while loading shared libraries: libjpeg.so.62: ELF file OS ABI invalid”, make sure you have “/usr/ports/graphics/linux-jpeg”. You can also try ‘sysctl kern.fallback_elf_brand=3′. But those didn’t work for me, I notice that etqw ships its own libjpeg, I tried replacing that with the /usr/compat/linux/usr/lib/libjpeg.so.62 one it seems to work but now I get another error “./etqw.x86: error while loading shared libraries: /usr/local/lib/libX11.so.6: ELF file OS ABI invalid”, possible its loading the ones in /usr/local/lib instead of /usr/compat/linux/usr/X11R6/lib/libX11.so.6 but I don’t know and thats about all I can think of now.

Also make sure you have linux_enable=”YES” in /etc/rc.conf and run ‘/etc/rc.d/abi restart’ to enable the compatibility layer stuff if you didn’t already have it done.

Wine
Wine works fine under FreeBSD, to install: cd /usr/ports/emulators/wine && make install clean

Mounting samba shares
Firstly you need to install Samba with /usr/ports/net/samba3/ && make install clean then you can manually mount it with the following: mount_smbfs //username@host/share /mnt/mointpoint

the -o options that you use in Linux such as username, password, credentials don’t work on FreeBSD’s version. If you want to make it automated, edit /etc/fstab and add: //username@server/share /mnt/mountpoint smbfs rw 0 0 Then edit /etc/nsmb.conf and check the example near the end. Alternatively you can put them in ~/.nsmb.conf for a per user solution.

Strong encryption software such as PGP Was (possibly still is) regarded as a sensitive “munition” or some such rubbish, and export is not allowed – as if publicly available software could possibly be restricted to national borders. I am told that copies have managed to creep out and if you are outside Canada or the US and want the software you can get it.

It seems that the following international site (though it is old) ignored the wishes and laws of the US government on this matter: The International PGP Home Page. The search engines can no doubt find hundreds more of these scofflaw sites. Imagine that!

I believe attempts to restrict encryption software and undermine its widespread use represent the fear by “Big Brother” that the era of universal easy snooping is coming to an end. I assert that no organization has the right to read all my mail, listen to all my phone messages and generally track every aspect of my life at will. This assertion is meaningless unless I can enforce the remaining shreds of my privacy using convenient unbreakable encryption.

If EVERYONE encrypted EVERYTHING they sent as a matter of course, the snoops would be OUT OF BUSINESS and, in my view, the world might be a slightly better place …

I guess it depends on who you are more afraid of: bad guys in the government or bad guys out of the government. Granting sweeping authority to the government might be useful temporarily (“our” bad guys) but it is virtually impossible to get them to relinquish their powers once granted. That is, often, how governments become blatant dictatorships: not at the point of a gun but accepted willingly, a step at a time, by a fearful populace and impatient leaders.

Sermon and paranoia aside, this stuff is just WAY COOL. MUCH better than secret decoder rings.

It works as follows:

Encryption keys are created in pairs. Either key can be used to unbreakably encrypt a message. However only the OTHER key in the pair can decrypt that message. Typically one key of the pair is made public (such as the one below) and the other kept very secure and private.

If you want to send me a secure message, you use my public key to encrypt it and then only my private key can unscramble it.

If you want to digitally “sign” the message, so I know you actually sent it and the message was not altered in transit, you encrypt information about the message using your private key. This is done automatically by your copy of the PGP software.

When I receive the message I decrypt the message using my private key. I know that no one else could have read this encrypted message.

If I wish to verify authenticity (i.e. that you sent it and not someone pretending to be you) I then decrypt the signature using your public key and compare the information there to the corresponding info from the message I received. Once again, this is done automatically by the PGP software. Only you could have signed it using your private key. The signature contains info about the message to verify that you were looking at the same message I received when you encrypted it to my public key.

Unbreakable encryption. Unforgeable signature. Verification that the encrypted message arrived unaltered and came from you. All of these details are handled by the software, and most popular mail clients also support PGP plugins to automate the encryption/decryption process.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.9 (GNU/Linux)

mQENBEq+yYcBCAC1jiVnvDip7OWnynUp5ATWo9u/h3ji7xGm6uw1SfIGjnJsqd2J
TQi0D4dooCUbDqSXbUvoRqG6+WgcbVBe5i40eBDQGmrrcdXVt/SokZ6fdLOdaXQB
aNgT/+F5DSlSAN//OUlDCBzSFVgubI2UEj6CB8wxzbGSHvRqeBQr1sEJyL8J8/oA
lN4uJ/aSqpNCYPqoGqB04Q4txEJzIW617Du+RBx5KhxD2H4Jjt2ELaMQEiQsZU0+
UwEeAers/fkEMch/72pD+oaJTcQxuPsPYPVTWWaL1t2DxF142GSIC4c4BF31ZtU3
gmu73SwVWfM2hWctGI/1Xk0PS7Ceg0lKbk8jABEBAAG0NEFuZHJldyBLZW50b24g
TWl0Y2hlbGwgPGFuZHJldy5taXRjaGVsbEB3ZGlkYXRhLm5ldD6JATwEEwECACYF
Akq+yYcCGyMFCQlmAYAGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRBmyb6MWLa5
T25OB/9e3L6KDBgHc6cjmQMX2qIyJJmM+NtwCmxuKeVWHCGXZwi/ZztMM0z1IARF
1fjV8RJX4QwEtbCovw5ejGZw/NssLHDs8M3s39pEF0KQTD+8MuZlO0PX5AfcWwGE
R8K31BIjBZLWMZK17vsTxZrFuqv0VfJc2s8tds51U6F5k1uVkXPf2R2AaL5q24hm
lK1PrkxljBOovh4Dsi0s1JsQxIbdydEn402mC6IYFc2Bynbr/sFuW8d409LRTKan
1VNR6BwO+yzGOZqL49OhF06Cu6nvo0BJhz/4wA0UR7223DA9UsrW143hKS7fheZ6
PBFGSktXPzG5+ymcsaowBFGLxnaYuQENBEq+yYcBCAD8mCwktNjKjW6B3tG2ylu/
EdT+dLfGpzw4p6hjXoAMfTVqn7pVdJChxnMXOmRiiih6CAlgVt6aCaISMcgENy1A
7oz4diRCNiWIksdgM8HUt/fxgIPotObQPyCPMd1Bd0aFh5g13QotP3K0Ax0BJTPE
W1ECnZxE+dA0kmzpGUikKIQmOEX0SlED+IqTfat4WtKrllJ+SgK/M2jmh7CeTjbq
NghxnIYphccfBzDmzU6VqtMZRULJgOv0KGW4hXBeO0ve1nhMIMOMUrdjQ4prZNdN
JNtMaUuo/4Dl9wF+HAMDInQKPukahu/9XjVrFPc+xWuGq/nU8PlTONqMbHokMjW/
ABEBAAGJASUEGAECAA8FAkq+yYcCGwwFCQlmAYAACgkQZsm+jFi2uU8r1wgAqK4W
B9XcVHp/yD4COebYtUeYNlav1RVIPquCmmYChWDy0gGQ9WF5mfODAdxPFVyn78Ow
cGBd0hvrHGnpM2SpFbsmSGx81T0A4bDRrkht45bawWjoKTLs0vdCPuqmGa1cxDqG
r6bXywS0zkAHqMA43YaNb2iqyp2q/DTS6geIvZB6fSJC4eAX+jSV+s9e+lLnQwOZ
WkHlqhsawp4bR9sWoBaEJEvW0iEmuilRradAt0PKNm1f6KrwVperDj7oQLuPmR6N
nUJWXf5mTatcMtCK9Od6wF06iEhHHV9lf0Erqpxsts7sBzd7+w0yUmAzxv6RnrKT
3PAaKzoAlYyh4Tsrvw==
=XNjJ
-----END PGP PUBLIC KEY BLOCK-----

“Unbreakable” is a pretty strong claim. Currently only the smallest key pairs (perhaps a couple of hundred bits) can be cracked by brute computational force in the civilian world – and that only with the expenditure of costly amounts of computer time. Obviously this is not a static record and also there are supercomputer resources and techniques classified by governments that are unavailable to civilians. However mathematicians think that the difficulty in cracking a key pair is not linear in the key size, but exponential in the number of bits in the key. A 3072 bit key would not be 48 times harder to crack than a 64 bit key – it might be 1000000000000000 times harder.

Most Diffie-Helman keys are 3072 or 4096 bits and RSA keys should be 2048 bits (for backward compatibility with older software.)

Phil Zimmerman, the author of the original PGP software, has this to say :

An expensive and formidable cryptanalytic attack could possibly be mounted by someone with vast supercomputer resources, such as a government intelligence agency. They might crack your public key by using some new secret mathematical breakthrough. But civilian academia has been intensively attacking public key cryptography without success since 1978. Perhaps the government has some classified methods of cracking the conventional encryption algorithms used in PGP. This is every cryptographers worst nightmare. There can be no absolute security guarantees in practical cryptographic implementations.Still, some optimism seems justified. The public key algorithms, message digest algorithms, and block ciphers used in PGP were designed by some of the best cryptographers in the world. PGPs algorithms have had extensive security analysis and peer review from some of the best cryptanalysts in the unclassified world.

Besides, even if the block ciphers used in PGP have some subtle unknown weaknesses, PGP compresses the plaintext before encryption, which should greatly reduce those weaknesses. The computational workload to crack it is likely to be much more expensive than the value of the message.

Zimmerman’s conservative and careful statement aside, and with all due respect to the computing community, no one involved in this business seems to believe that anyone can now or will in the near future crack big key encryption by brute force. No one seems to think the encryption techniques themselves carry subtle weaknesses that would make them vulnerable to a “smart” attack.

There are, however, conventional “spy” techniques that could work rather easily and cheaply if your messages are a valuable target. These all involve physical invasion, break-ins or other monitoring of the computer on which the encryption occurs. Each item can be dealt with and security breaches detected and corrected. Each time you solve a potential problem you make the software more cumbersome to use but more secure : “Bug” searches, no windows in the room, locks on all doors, security guards, electromagnetic screening, software checksum monitoring, keeping keys on different media, no direct internet connection etc. etc. etc.

You must decide how valuable your data is and to what lengths you are willing to go to obtain incremental increases in security. Examples of things that can go wrong:

• Your Private Key Could Be Compromised
  When you access your private key you must enter a passphrase to verify that you are “you” and not someone who has stolen or copied the key file from your computer. If this passphrase is known and someone has copied your keyfile they can decrypt messages meant for your eyes only and sign messages as “you.” This passphrase can be found by :
  • Guessing : don’t use a short or obvious pass phrase.
  • Finding a “post-it note” with the phrase on it
  • Someone can look over your shoulder (also through a camera or a telescope through a window.)
  • They can watch your fingers type.
  • Someone with physical access to your computer can run software on your computer (invisibly in the background and available for free on the internet) that records ALL keystrokes, thereby compromising your pass phrase.
  • Your keyboard when you type and your monitor when it creates an image emit electronic signals that someone in a van in your parking lot can pick up with a dish antenna pointed at your office. Yes they CAN do this.
  • Someone can replace the copy of the PGP software by something else that looks and acts the same to you but is NOT and saves information (such as the passphrase the next time you use it) or sends information to someone else for retrieval.

• Your Decrypted Messages Can Be Found
  • After you decrypt a message you might want to save it. If you save it unencrypted, someone with physical access to the machine can copy it. PGP allows you to encrypt the contents of a directory on your hard drive to manage this risk.
  • Even after you delete a message, it still is on the hard drive. The only thing deleted is the pointer to the file that shows up when you do a directory listing. Until it is physically overwritten it is easy to resurrect. A feature of PGP allows you to take care of this.
  • If you use a virtual memory scheme, things in RAM are often swapped out temporarily to the hard drive. You would not know about this copy, and it would be there for an expert to find until overwritten. Don’t use virtual memory if this is a worry.

As a final note, I reproduce a comment contributed to a forum on the topic by an individual who calls himself “Anonymous Coward.” It is interesting to see the things people who spend a lot of time thinking about security have to say.

It’s physically impossible to securely remove plaintext data on a magnetic medium without destroying the media. The data is always there, no matter how many times you write over it because there is more than one atom involved on the part of the medium where a given bit is written, and you never change the magnetic properties of all the atoms involved in storing that given bit.A well funded attacker will be able to recover every bit of data ever written to the medium, and establish chronological order of writes per bit on the disk. The number of times you overwrite or otherwise wipe the files is irrelevant

Also, random data is a less secure means of obscuring existing data than random actual day to day files because the entropy of the data you’re trying to hide, and the entropy of the noise you’re using to cover it up with differ so greatly. With a chronological record of the bits written in a volume (given, only available to the most sophisticated and well funded attacker), and a search for entropy, it is a quite simple task to recover any data that was ever represented on the media.

These tools only obscure the data from poorly funded, inept attackers. If those are who concern you given your threat model, then OK. Else the NSA is having a great belly laugh at your expense.

If you would like true file security, you need a cryptographic filesystem on a fresh drive. Ensure that the keys to decrypt said partition and your passphrase are stored on a separate media (cd-r perhaps) which you can shred using a cross-cut shredder (one that makes fingernail clipping sized chunks) before being burned.

Keep this disk on you at all times, or be able to account for it at all times. Your reaction time for removing your key media, turning off your machine, shredding and then burning said media must be less than the time between your detecting an attacker on the premises and their reaching the machine.

Your browser cache, saved emails and chat logs can be used as cribs to crack the encryption on your partition. never write them to disk, even in encrypted form.

In general, never write plaintext to your hard drive, and keep the keys off of your hard drive if keeping people from reading data that was ever at any time written to it is important to you.

Happy Encrypting!

Even though the key ideas behind DNSSEC have been intro-duced quite some time ago DNSSEC has not yet seen large scale deployment. This is in large part due to the anticipated overhead of DNSSEC. While the overheads have been reduced by the introduction of the delegation signer model, it is still not clear if they are bearable.  Therefore we in this post we examine the actual overheads of DNSSEC. We first examine how the packet sizes of an DNS trace increases if DNSSEC would be used. Then we explore the CPU and memory overheads imposed by DNSSEC by re-playing a DNS client trace in a testbed initialized with roughly 100,000 zones.

Introduction

How do I find out what OpenSSL version I’m running?

How do I get a list of the available commands?

How do I get a list of available ciphers?

Benchmarking

How do I benchmark my system’s performance?

How do I benchmark remote connections?

Certificates

How do I generate a self-signed certificate?

How do I generate a certificate request for VeriSign?

How do I test a new certificate?

How do I retrieve a remote certificate?

How do I extract information from a certificate?

How do I export or import a PKCS#12 certificate?

Certificate Verification

How do I verify a certificate?

What certificate authorities does OpenSSL recognize?

How do I get OpenSSL to recognize/verify a certificate?

Command-line clients and servers

How do I connect to a secure SMTP server?

How do I connect to a secure [whatever] server?

How do I set up an SSL server from the command line?

Digests

How do I create an MD5 or SHA1 digest of a file?

How do I sign a digest?

How do I verify a signed digest?

How do I create an Apache digest password entry?

What other kinds of digests are available?

Encryption/Decryption

How do I base64-encode something?

How do I simply encrypt a file?

Errors

How do I interpret SSL error messages?

Keys

How do I generate an RSA key?

How do I generate a public RSA key?

How do I generate a DSA key?

How do I create an elliptic curve key?

How do I remove a passphrase from a key?

Password hashes

How do I generate a crypt-style password hash?

How do I generate a shadow-style password hash?

Prime numbers

How do I test whether a number is prime?

How do I generate a set of prime numbers?

Random data

How do I generate random data?

S/MIME

How do I verify a signed S/MIME message?

How do I encrypt a S/MIME message?

How do I sign a S/MIME message?

For further reading

Comments welcome

Introduction

The openssl command-line binary that ships with the OpenSSL libraries can perform a wide range of cryptographic operations. It can come in handy in scripts or for accomplishing one-time command-line tasks.

Documentation for using the openssl application is somewhat scattered, however, so this article aims to provide some practical examples of its use. I assume that you’ve already got a functional OpenSSL installation and that the openssl binary is in your shell’s PATH.

Just to be clear, this article is strictly practical; it does not concern cryptographic theory and concepts. If you don’t know what an MD5 sum is, this article won’t enlighten you one bit—but if all you need to know is how to use openssl to generate a file sum, you’re in luck.

The nature of this article is that I’ll be adding new examples incrementally. Check back at a later date if I haven’t gotten to the information you need.

How do I find out what OpenSSL version I’m running?

Use the version option.

$ openssl version

OpenSSL 0.9.8b 04 May 2006

You can get much more information with the version -a option.

$ openssl version -a

OpenSSL 0.9.8b 04 May 2006

built on: Fri Sep 29 18:45:58 UTC 2006

platform: debian-i386-i686/cmov

options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) blowfish(idx)

compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT

-DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -march=i686

-Wa,–noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2

-DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM

OPENSSLDIR: “/usr/lib/ssl”

How do I get a list of the available commands?

There are three built-in options for getting lists of available commands, but none of them provide what I consider useful output. The best thing to do is provide an invalid command (help or -h will do nicely) to get a readable answer.

$ openssl help

openssl:Error: ‘help’ is an invalid command.

Standard commands

asn1parse ca ciphers crl crl2pkcs7

dgst dh dhparam dsa dsaparam

ec ecparam enc engine errstr

gendh gendsa genrsa nseq ocsp

passwd pkcs12 pkcs7 pkcs8 prime

rand req rsa rsautl s_client

s_server s_time sess_id smime speed

spkac verify version x509

Message Digest commands (see the `dgst’ command for more details)

md2 md4 md5 rmd160 sha

sha1

Cipher commands (see the `enc’ command for more details)

aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb aes-256-cbc

aes-256-ecb base64 bf bf-cbc bf-cfb

bf-ecb bf-ofb cast cast-cbc cast5-cbc

cast5-cfb cast5-ecb cast5-ofb des des-cbc

des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb

des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb

des-ofb des3 desx rc2 rc2-40-cbc

rc2-64-cbc rc2-cbc rc2-cfb rc2-ecb rc2-ofb

rc4 rc4-40

What the shell calls “Standard commands” are the main top-level options.

You can use the same trick with any of the subcommands.

$ openssl dgst -h

unknown option ‘-h’

options are

-c to output the digest with separating colons

-d to output debug info

-hex output as hex dump

-binary output in binary form

-sign file sign digest using private key in file

-verify file verify a signature using public key in file

-prverify file verify a signature using private key in file

-keyform arg key file format (PEM or ENGINE)

-signature file signature to verify

-binary output in binary form

-engine e use engine e, possibly a hardware device.

-md5 to use the md5 message digest algorithm (default)

-md4 to use the md4 message digest algorithm

-md2 to use the md2 message digest algorithm

-sha1 to use the sha1 message digest algorithm

-sha to use the sha message digest algorithm

-sha256 to use the sha256 message digest algorithm

-sha512 to use the sha512 message digest algorithm

-mdc2 to use the mdc2 message digest algorithm

-ripemd160 to use the ripemd160 message digest algorithm

In more boring fashion, you can consult the OpenSSL man pages.

How do I get a list of available ciphers?

Use the ciphers option. The ciphers(1) man page is quite helpful.

# list all available ciphers

openssl ciphers -v

# list only TLSv1 ciphers

openssl ciphers -v -tls1

# list only high encryption ciphers (keys larger than 128 bits)

openssl ciphers -v ‘HIGH’

# list only high encryption ciphers using the AES algorithm

openssl ciphers -v ‘AES+HIGH’

Benchmarking

How do I benchmark my system’s performance?

The OpenSSL developers have built a benchmarking suite directly into the openssl binary. It’s accessible via the speed option. It tests how many operations it can perform in a given time, rather than how long it takes to perform a given number of operations. This strikes me a quite sane, because the benchmarks don’t take significantly longer to run on a slow system than on a fast one.

To run a catchall benchmark, run it without any further options.

openssl speed

There are two sets of results. The first reports how many bytes per second can be processed for each algorithm, the second the times needed for sign/verify cycles. Here are the results on an 2.16GHz Intel Core 2.

The ‘numbers’ are in 1000s of bytes per second processed.

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes

md2 1736.10k 3726.08k 5165.04k 5692.28k 5917.35k

mdc2 0.00 0.00 0.00 0.00 0.00

md4 18799.87k 65848.23k 187776.43k 352258.73k 474622.63k

md5 16807.01k 58256.45k 160439.13k 287183.53k 375220.91k

hmac(md5) 23601.24k 74405.08k 189993.05k 309777.75k 379431.59k

sha1 16774.59k 55500.39k 142628.69k 233247.74k 288382.98k

rmd160 13854.71k 40271.23k 87613.95k 124333.06k 141781.67k

rc4 227935.60k 253366.06k 261236.94k 259858.09k 194928.50k

des cbc 48478.10k 49616.16k 49765.21k 50106.71k 50034.01k

des ede3 18387.39k 18631.02k 18699.26k 18738.18k 18718.72k

idea cbc 0.00 0.00 0.00 0.00 0.00

rc2 cbc 19247.24k 19838.12k 19904.51k 19925.33k 19834.98k

rc5-32/12 cbc 0.00 0.00 0.00 0.00 0.00

blowfish cbc 79577.50k 83067.03k 84676.78k 84850.01k 85063.00k

cast cbc 45362.14k 48343.34k 49007.36k 49202.52k 49225.73k

aes-128 cbc 58751.94k 94443.86k 111424.09k 116704.26k 117997.57k

aes-192 cbc 53451.79k 82076.22k 94609.83k 98496.85k 99150.51k

aes-256 cbc 49225.21k 72779.84k 82266.88k 85054.81k 85762.05k

sha256 9359.24k 22510.83k 40963.75k 51710.29k 56014.17k

sha512 7026.78k 28121.32k 54330.79k 86190.76k 104270.51k

sign verify sign/s verify/s

rsa 512 bits 0.000522s 0.000042s 1915.8 23969.9

rsa 1024 bits 0.002321s 0.000109s 430.8 9191.1

rsa 2048 bits 0.012883s 0.000329s 77.6 3039.6

rsa 4096 bits 0.079055s 0.001074s 12.6 931.3

sign verify sign/s verify/s

dsa 512 bits 0.000380s 0.000472s 2629.3 2117.9

dsa 1024 bits 0.001031s 0.001240s 969.6 806.2

dsa 2048 bits 0.003175s 0.003744s 314.9 267.1

You can run any of the algorithm-specific subtests directly.

# test rsa speeds

openssl speed rsa

# do the same test on a two-way SMP system

openssl speed rsa -multi 2

How do I benchmark remote connections?

The s_time option lets you test connection performance. The most simple invocation will run for 30 seconds, use any cipher, and use SSL handshaking to determine number of connections per second, using both new and reused sessions:

openssl s_time -connect remote.host:443

Beyond that most simple invocation, s_time gives you a wide variety of testing options.

# retrieve remote test.html page using only new sessions

openssl s_time -connect remote.host:443 -www /test.html -new

# similar, using only SSL v3 and high encryption (see

# ciphers(1) man page for cipher strings)

openssl s_time \

-connect remote.host:443 -www /test.html -new \

-ssl3 -cipher HIGH

# compare relative performance of various ciphers in

# 10-second tests

IFS=”:”

for c in $(openssl ciphers -ssl3 RSA); do

echo $c

openssl s_time -connect remote.host:443 \

-www / -new -time 10 -cipher $c 2>&1 | \

grep bytes

echo

done

If you don’t have an SSL-enabled web server available for your use, you can emulate one using the s_server option.

# on one host, set up the server (using default port 4433)

openssl s_server -cert mycert.pem -www

# on second host (or even the same one), run s_time

openssl s_time -connect myhost:4433 -www / -new -ssl3

Certificates

How do I generate a self-signed certificate?

You’ll first need to decide whether or not you want to encrypt your key. Doing so means that the key is protected by a passphrase.

On the plus side, adding a passphrase to a key makes it more secure, so the key is less likely to be useful to someone who steals it. The downside, however, is that you’ll have to either store the passphrase in a file or type it manually every time you want to start your web or ldap server.

It violates my normally paranoid nature to say it, but I prefer unencrypted keys, so I don’t have to manually type a passphrase each time a secure daemon is started. (It’s not terribly difficult to decrypt your key if you later tire of typing a passphrase.)

This example will produce a file called mycert.pem which will contain both the private key and the public certificate based on it. The certificate will be valid for 365 days, and the key (thanks to the -nodes option) is unencrypted.

openssl req \

-x509 -nodes -days 365 \

-newkey rsa:1024 -keyout mycert.pem -out mycert.pem

Using this command-line invocation, you’ll have to answer a lot of questions: Country Name, State, City, and so on. The tricky question is “Common Name.” You’ll want to answer with the hostname or CNAME by which people will address the server. This is very important. If your web server’s real hostname is mybox.mydomain.com but people will be using www.mydomain.com to address the box, then use the latter name to answer the “Common Name” question.

Once you’re comfortable with the answers you provide to those questions, you can script the whole thing by adding the -subj option. I’ve included some information about location into the example that follows, but the only thing you really need to include for the certificate to be useful is the hostname (CN).

openssl req \

-x509 -nodes -days 365 \

-subj ‘/C=US/ST=Oregon/L=Portland/CN=www.madboa.com’ \

-newkey rsa:1024 -keyout mycert.pem -out mycert.pem

How do I generate a certificate request for VeriSign?

Applying for a certificate signed by a recognized certificate authority like VeriSign is a complex bureaucratic process. You’ve got to perform all the requisite paperwork before creating a certificate request.

As in the recipe for creating a self-signed certificate, you’ll have to decide whether or not you want a passphrase on your private key. The recipe below assumes you don’t. You’ll end up with two files: a new private key called mykey.pem and a certificate request called myreq.pem.

openssl req \

-new -newkey rsa:1024 -nodes \

-keyout mykey.pem -out myreq.pem

If you’ve already got a key and would like to use it for generating the request, the syntax is a bit simpler.

openssl req -new -key mykey.pem -out myreq.pem

Similarly, you can also provide subject information on the command line.

openssl req \

-new -newkey rsa:1024 -nodes \

-subj ‘/CN=www.mydom.com/O=My Dom, Inc./C=US/ST=Oregon/L=Portland’ \

-keyout mykey.pem -out myreq.pem

When dealing with an institution like VeriSign, you need to take special care to make sure that the information you provide during the creation of the certificate request is exactly correct. I know from personal experience that even a difference as trivial as substituting “and” for “&” in the Organization Name will stall the process.

If you’d like, you can double check the signature and information provided in the certificate request.

# verify signature

openssl req -in myreq.pem -noout -verify -key mykey.pem

# check info

openssl req -in myreq.pem -noout -text

Save the key file in a secure location. You’ll need it in order to use the certificate VeriSign sends you. The certificate request will typically be pasted into VeriSign’s online application form.

How do I test a new certificate?

The s_server option provides a simple but effective testing method. The example below assumes you’ve combined your key and certificate into one file called mycert.pem.

First, launch the test server on the machine on which the certificate will be used. By default, the server will listen on port 4433; you can alter that using the -accept option.

openssl s_server -cert mycert.pem -www

If the server launches without complaint, then chances are good that the certificate is ready for production use.

You can also point your web browser at the test server, e.g., https://yourserver:4433/. Don’t forget to specify the “https” protocol; plain-old “http” won’t work. You should see a page listing the various ciphers available and some statistics about your connection. Most modern browsers allow you to examine the certificate as well.

How do I retrieve a remote certificate?

If you combine openssl and sed, you can retrieve remote certificates via a shell one-liner or a simple script.

#!/bin/sh

#

# usage: retrieve-cert.sh remote.host.name [port]

#

REMHOST=$1

REMPORT=${2:-443}

echo |\

openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |\

sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’

You can, in turn, pipe that information back to openssl to do things like check the dates on all your active certificates.

#!/bin/sh

#

for CERT in \

www.yourdomain.com:443 \

ldap.yourdomain.com:636 \

imap.yourdomain.com:993 \

do

echo |\

openssl s_client -connect ${CERT} 2>/dev/null |\

sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ |\

openssl x509 -noout -subject -dates

done

How do I extract information from a certificate?

An SSL certificate contains a wide range of information: issuer, valid dates, subject, and some hardcore crypto stuff. The x509 subcommand is the entry point for retrieving this information. The examples below all assume that the certificate you want to examine is stored in a file named cert.pem.

Using the -text option will give you the full breadth of information.

openssl x509 -text -in cert.pem

Other options will provide more targeted sets of data.

# who issued the cert?

openssl x509 -noout -in cert.pem -issuer

# to whom was it issued?

openssl x509 -noout -in cert.pem -subject

# for what dates is it valid?

openssl x509 -noout -in cert.pem -dates

# the above, all at once

openssl x509 -noout -in cert.pem -issuer -subject -dates

# what is its hash value?

openssl x509 -noout -in cert.pem -hash

# what is its MD5 fingerprint?

openssl x509 -noout -in cert.pem -fingerprint

How do I export or import a PKCS#12 certificate?

PKCS#12 files can be imported and exported by a number of applications, including Microsoft IIS. They are often associated with the file extension .pfx.

To create a PKCS#12 certificate, you’ll need a private key and a certificate. During the conversion process, you’ll be given an opportunity to put an “Export Password” (which can be empty, if you choose) on the certificate.

# create a file containing key and self-signed certificate

openssl req \

-x509 -nodes -days 365 \

-newkey rsa:1024 -keyout mycert.pem -out mycert.pem

# export mycert.pem as PKCS#12 file, mycert.pfx

openssl pkcs12 -export \

-out mycert.pfx -in mycert.pem \

-name “My Certificate”

If someone sends you a PKCS#12 and any passwords needed to work with it, you can export it into standard PEM format.

# export certificate and passphrase-less key

openssl pkcs12 -in mycert.pfx -out mycert.pem -nodes

# same as above, but you’ll be prompted for a passphrase for

# the private key

openssl pkcs12 -in mycert.pfx -out mycert.pem

Certificate Verification

Applications linked against the OpenSSL libraries can verify certificates signed by a recognized certificate authority (CA).

How do I verify a certificate?

Use the verify option to verify certificates.

openssl verify cert.pem

If your local OpenSSL installation recognizes the certificate or its signing authority and everything else (dates, signing chain, etc.) checks out, you’ll get a simple OK message.

$ openssl verify remote.site.pem

remote.site.pem: OK

If anything is amiss, you’ll see some error messages with short descriptions of the problem, e.g.,

• error 10 at 0 depth lookup:certificate has expired. Certificates are typically issued for a limited period of time—usually just one year—and openssl will complain if a certificate has expired.
• error 18 at 0 depth lookup:self signed certificate. Unless you make an exception, OpenSSL won’t verify a self-signed certificate.

What certificate authorities does OpenSSL recognize?

When OpenSSL was built for your system, it was configured with a “Directory for OpenSSL files.” (That’s the –openssldir option passed to the configure script, for you hands-on types.) This is the directory that typically holds information about certificate authorities your system trusts.

The default location for this directory is /usr/local/ssl, but most vendors put it elsewhere, e.g., /usr/share/ssl (Red Hat/Fedora), /etc/ssl (Gentoo), /usr/lib/ssl (Debian), or /System/Library/OpenSSL (Macintosh OS X).

Use the version option to identify which directory (labeled OPENSSLDIR) your installation uses.

openssl version -d

Within that directory and a subdirectory called certs, you’re likely to find one or more of three different kinds of files.

1. A large file called cert.pem, an omnibus collection of many certificates from recognized certificate authorities like VeriSign and Thawte.
2. Some small files in the certs subdirectory named with a .pem file extension, each of which contains a certificate from a single CA.
3. Some symlinks in the certs subdirectory with obscure filenames like 052eae11.0. There is typically one of these links for each .pem file.

The first part of obscure filename is actually a hash value based on the certificate within the .pem file to which it points. The file extension is just an iterator, since it’s theoretically possible that multiple certificates can generate identical hashes.

On my Gentoo system, for example, there’s a symlink named f73e89fd.0 that points to a file named vsignss.pem. Sure enough, the certificate in that file generates a hash the equates to the name of the symlink:

$ openssl x509 -noout -hash -in vsignss.pem

f73e89fd

When an application encounters a remote certificate, it will typically check to see if the cert can be found in cert.pem or, if not, in a file named after the certificate’s hash value. If found, the certificate is considered verified.

It’s interesting to note that some applications, like Sendmail, allow you to specify at runtime the location of the certificates you trust, while others, like Pine, do not.

How do I get OpenSSL to recognize/verify a certificate?

Put the file that contains the certificate you’d like to trust into the certs directory discussed above. Then create the hash-based symlink. Here’s a little script that’ll do just that.

#!/bin/sh

#

# usage: certlink.sh filename [filename ...]

for CERTFILE in $*; do

# make sure file exists and is a valid cert

test -f “$CERTFILE” || continue

HASH=$(openssl x509 -noout -hash -in “$CERTFILE”)

test -n “$HASH” || continue

# use lowest available iterator for symlink

for ITER in 0 1 2 3 4 5 6 7 8 9; do

test -f “${HASH}.${ITER}” && continue

ln -s “$CERTFILE” “${HASH}.${ITER}”

test -L “${HASH}.${ITER}” && break

done

done

Command-line clients and servers

The s_client and s_server options provide a way to launch SSL-enabled command-line clients and servers. There are other examples of their use scattered around this document, but this section is dedicated solely to them.

In this section, I assume you are familiar with the specific protocols at issue: SMTP, HTTP, etc. Explaining them is out of the scope of this article.

How do I connect to a secure SMTP server?

You can test, or even use, an SSL-enabled SMTP server from the command line using the s_client option.

Secure SMTP servers offer secure connections on up to three ports: 25 (TLS), 465 (SSL), and 587 (TLS). Some time around the 0.9.7 release, the openssl binary was given the ability to use STARTTLS when talking to SMTP servers.

# port 25/TLS; use same syntax for port 587

openssl s_client -connect remote.host:25 -starttls smtp

# port 465/SSL

openssl s_client -connect remote.host:465

RFC821 suggests (although it falls short of explicitly specifying) the two characters “<CRLF>” as line-terminator. Most mail agents do not care about this and accept either “<LF>” or “<CRLF>” as line-terminators, but Qmail does not. If you want to comply to the letter with RFC821 and/or communicate with Qmail, use also the -crlf option:

openssl s_client -connect remote.host:25 -crlf -starttls smtp

How do I connect to a secure [whatever] server?

Connecting to a different type of SSL-enabled server is essentially the same operation as outlined above. As of the date of this writing, openssl only supports command-line TLS with SMTP servers, so you have to use straightforward SSL connections with any other protocol.

# https: HTTP over SSL

openssl s_client -connect remote.host:443

# ldaps: LDAP over SSL

openssl s_client -connect remote.host:636

# imaps: IMAP over SSL

openssl s_client -connect remote.host:993

# pop3s: POP-3 over SSL

openssl s_client -connect remote.host:995

How do I set up an SSL server from the command line?

The s_server option allows you to set up an SSL-enabled server from the command line, but it’s I wouldn’t recommend using it for anything other than testing or debugging. If you need a production-quality wrapper around an otherwise insecure server, check out Stunnel instead.

The s_server option works best when you have a certificate; it’s fairly limited without one.

# the -www option will sent back an HTML-formatted status page

# to any HTTP clients that request a page

openssl s_server -cert mycert.pem -www

# the -WWW option “emulates a simple web server. Pages will be

# resolved relative to the current directory.” This example

# is listening on the https port, rather than the default

# port 4433

openssl s_server -accept 443 -cert mycert.pem -WWW

Digests

Generating digests with the dgst option is one of the more straightforward tasks you can accomplish with the openssl binary. Producing digests is done so often, as a matter of fact, that you can find special-use binaries for doing the same thing.

How do I create an MD5 or SHA1 digest of a file?

Digests are created using the dgst option.

# MD5 digest

openssl dgst -md5 filename

# SHA1 digest

openssl dgst -sha1 filename

The MD5 digests are identical to those created with the widely available md5sum command, though the output formats differ.

$ openssl dgst -md5 foo-2.23.tar.gz

MD5(foo-2.23.tar.gz)= 81eda7985e99d28acd6d286aa0e13e07

$ md5sum foo-2.23.tar.gz

81eda7985e99d28acd6d286aa0e13e07 foo-2.23.tar.gz

The same is true for SHA1 digests and the output of the sha1sum application.

$ openssl dgst -sha1 foo-2.23.tar.gz

SHA1(foo-2.23.tar.gz)= e4eabc78894e2c204d788521812497e021f45c08

$ sha1sum foo-2.23.tar.gz

e4eabc78894e2c204d788521812497e021f45c08 foo-2.23.tar.gz

How do I sign a digest?

If you want to ensure that the digest you create doesn’t get modified without your permission, you can sign it using your private key. The following example assumes that you want to sign the SHA1 sum of a file called foo-1.23.tar.gz.

# signed digest will be foo-1.23.tar.gz.sha1

openssl dgst -sha1 \

-sign mykey.pem

-out foo-1.23.tar.gz.sha1 \

foo-1.23.tar.gz

How do I verify a signed digest?

To verify a signed digest you’ll need the file from which the digest was derived, the signed digest, and the signer’s public key.

# to verify foo-1.23.tar.gz using foo-1.23.tar.gz.sha1

# and pubkey.pem

openssl dgst -sha1 \

-verify pubkey.pem \

-signature foo-1.23.tar.gz.sha1 \

foo-1.23.tar.gz

How do I create an Apache digest password entry?

Apache’s HTTP digest authentication feature requires a special password format. Apache ships with the htdigest utility, but it will only write to a file, not to standard output. When working with remote users, it’s sometimes nice for them to be able to generate a password hash on a machine they trust and then mail it for inclusion in your local password database.

The format of the password database is relatively simple: a colon-separated list of the username, authorization realm (specified by the Apache AuthName directive), and an MD5 digest of those two items and the password. Below is a script that duplicates the output of htdigest, except that the output is written to standard output. It takes advantage of the dgst option’s ability to read from standard input.

#!/bin/bash

echo “Create an Apache-friendly Digest Password Entry”

echo “———————————————–”

# get user input, disabling tty echoing for password

read -p “Enter username: ” UNAME

read -p “Enter Apache AuthName: ” AUTHNAME

read -s -p “Enter password: ” PWORD; echo

printf “\n%s:%s:%s\n” \

“$UNAME” \

“$AUTHNAME” \

$(printf “${UNAME}:${AUTHNAME}:${PWORD}” | openssl dgst -md5)

What other kinds of digests are available?

Use the built-in list-message-digest-commands option to get a list of the digest types available to your local OpenSSL installation.

openssl list-message-digest-commands

Encryption/Decryption

How do I base64-encode something?

Use the enc -base64 option.

# send encoded contents of file.txt to stdout

openssl enc -base64 -in file.txt

# same, but write contents to file.txt.enc

openssl enc -base64 -in file.txt -out file.txt.enc

It’s also possible to do a quick command-line encoding of a string value:

$ echo “encode me” | openssl enc -base64

ZW5jb2RlIG1lCg==

Note that echo will silently attach a newline character to your string. Consider using its -n option if you want to avoid that situation, which could be important if you’re trying to encode a password or authentication string.

$ echo -n “encode me” | openssl enc -base64

ZW5jb2RlIG1l

Use the -d (decode) option to reverse the process.

$ echo “ZW5jb2RlIG1lCg==” | openssl enc -base64 -d

encode me

How do I simply encrypt a file?

Simple file encryption is probably better done using a tool like GPG. Still, you may have occasion to want to encrypt a file without having to build or use a key/certificate structure. All you want to have to remember is a password. It can nearly be that simple—if you can also remember the cipher you employed for encryption.

To choose a cipher, consult the enc(1) man page. More simply (and perhaps more accurately), you can ask openssl for a list in one of two ways.

# see the list under the ‘Cipher commands’ heading

openssl -h

# or get a long list, one cipher per line

openssl list-cipher-commands

After you choose a cipher, you’ll also have to decide if you want to base64-encode the data. Doing so will mean the encrypted data can be, say, pasted into an email message. Otherwise, the output will be a binary file.

# encrypt file.txt to file.enc using 256-bit AES in CBC mode

openssl enc -aes-256-cbc -salt -in file.txt -out file.enc

# the same, only the output is base64 encoded for, e.g., e-mail

openssl enc -aes-256-cbc -a -salt -in file.txt -out file.enc

To decrypt file.enc you or the file’s recipient will need to remember the cipher and the passphrase.

# decrypt binary file.enc

openssl enc -d -aes-256-cbc -in file.enc

# decrypt base64-encoded version

openssl enc -d -aes-256-cbc -a -in file.enc

If you’d like to avoid typing a passphrase every time you encrypt or decrypt a file, the openssl(1) man page provides the details under the heading “PASS PHRASE ARGUMENTS.” The format of the password argument is fairly simple.

# provide password on command line

openssl enc -aes-256-cbc -salt -in file.txt \

-out file.enc -pass pass:mySillyPassword

# provide password in a file

openssl enc -aes-256-cbc -salt -in file.txt \

-out file.enc -pass file:/path/to/secret/password.txt

Errors

How do I interpret SSL error messages?

Poking through your system logs, you see some error messages that are evidently related to OpenSSL or crypto:

sshd[31784]: error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106)

sshd[770]: error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106)

The first step to figure out what’s going wrong is to use the errstr option to intrepret the error code. The code number is found between “error:” and “:lib”. In this case, it’s 0407006A.

$ openssl errstr 0407006A

error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01

If you’ve got a full OpenSSL installation, including all the development documentation, you can start your investigation there. In this example, the RSA_padding_add_PKCS1_type_1(3) man page will inform you that PKCS #1 involves block methods for signatures. After that, of course, you’d need to pore through your application’s source code to identify when it would expect be receiving those sorts of packets.

Keys

How do I generate an RSA key?

Use the genrsa option.

# default 512-bit key, sent to standard output

openssl genrsa

# 1024-bit key, saved to file named mykey.pem

openssl genrsa -out mykey.pem 1024

# same as above, but encrypted with a passphrase

openssl genrsa -des3 -out mykey.pem 1024

How do I generate a public RSA key?

Use the rsa option to produce a public version of your private RSA key.

openssl rsa -in mykey.pem -pubout

How do I generate a DSA key?

Building DSA keys requires a parameter file, and DSA verify operations are slower than their RSA counterparts, so they aren’t as widely used as RSA keys.

If you’re only going to build a single DSA key, you can do so in just one step using the dsaparam subcommand.

# key will be called dsakey.pem

openssl dsaparam -noout -out dsakey.pem -genkey 1024

If, on the other hand, you’ll be creating several DSA keys, you’ll probably want to build a shared parameter file before generating the keys. It can take a while to build the parameters, but once built, key generation is done quickly.

# create parameters in dsaparam.pem

openssl dsaparam -out dsaparam.pem 1024

# create first key

openssl gendsa -out key1.pem dsaparam.pem

# and second …

openssl gendsa -out key2.pem dsaparam.pem

How do I create an elliptic curve key?

Routines for working with elliptic curve cryptography were added to OpenSSL in version 0.9.8. Generating an EC key involves the ecparam option.

openssl ecparam -out key.pem -name prime256v1 -genkey

# openssl can provide full list of EC parameter names suitable for

# passing to the -name option above:

openssl ecparam -list_curves

How do I remove a passphrase from a key?

Perhaps you’ve grown tired of typing your passphrase every time your secure daemon starts. You can decrypt your key, removing the passphrase requirement, using the rsa or dsa option, depending on the signature algorithm you chose when creating your private key.

If you created an RSA key and it is stored in a standalone file called key.pem, then here’s how to output a decrypted version of the same key to a file called newkey.pem.

# you’ll be prompted for your passphrase one last time

openssl rsa -in key.pem -out newkey.pem

Often, you’ll have your private key and public certificate stored in the same file. If they are stored in a file called mycert.pem, you can construct a decrypted version called newcert.pem in two steps.

# you’ll need to type your passphrase once more

openssl rsa -in mycert.pem -out newcert.pem

openssl x509 -in mycert.pem >>newcert.pem

Password hashes

Using the passwd option, you can generate password hashes that interoperate with traditional /etc/passwd files, newer-style /etc/shadow files, and Apache password files.

How do I generate a crypt-style password hash?

You can generate a new hash quite simply:

$ openssl passwd MySecret

8E4vqBR4UOYF.

If you know an existing password’s “salt,” you can duplicate the hash.

$ openssl passwd -salt 8E MySecret

8E4vqBR4UOYF.

How do I generate a shadow-style password hash?

Newer Unix systems use a more secure MD5-based hashing mechanism that uses an eight-character salt (as compared to the two-character salt in traditional crypt()-style hashes). Generating them is still straightforward using the -1 option:

$ openssl passwd -1 MySecret

$1$sXiKzkus$haDZ9JpVrRHBznY5OxB82.

The salt in this format consists of the eight characters between the second and third dollar signs, in this case sXiKzkus. So you can also duplicate a hash with a known salt and password.

$ openssl passwd -1 -salt sXiKzkus MySecret

$1$sXiKzkus$haDZ9JpVrRHBznY5OxB82.

Prime numbers

Current cryptographic techniques rely heavily on the generation and testing of prime numbers, so it’s no surprise that the OpenSSL libraries contain several routines dealing with primes. Beginning with version 0.9.7e (or so), the prime option was added to the openssl binary.

How do I test whether a number is prime?

Pass the number to the prime option. Note that the number returned by openssl will be in hex, not decimal, format.

$ openssl prime 119054759245460753

1A6F7AC39A53511 is not prime

You can also pass hex numbers directly.

$ openssl prime -hex 2f

2F is prime

How do I generate a set of prime numbers?

Pass a bunch of numbers to openssl and see what sticks. The seq utility is useful in this capacity.

# define start and ending points

AQUO=10000

ADQUEM=10100

for N in $(seq $AQUO $ADQUEM); do

# use bc to convert hex to decimal

openssl prime $N | awk ‘/is prime/ {print “ibase=16;”$1}’ | bc

done

Random data

How do I generate random data?

Use the rand option to generate binary or base64-encoded data.

# write 128 random bytes of base64-encoded data to stdout

openssl rand -base64 128

# write 1024 bytes of binary random data to a file

openssl rand -out random-data.bin 1024

# seed openssl with semi-random bytes from browser cache

cd $(find ~/.mozilla/firefox -type d -name Cache)

openssl rand -rand $(find . -type f -printf ‘%f:’) -base64 1024

On a Unix box with a /dev/urandom device and a copy of GNU head, you can achieve a similar effect, often with better entropy:

# get 32 bytes from /dev/urandom and base64 encode them

head -c 32 /dev/urandom | openssl enc -base64

Make sure you know the trade-offs between the random and urandom devices before relying on them for truly critical entropy. Consult the random(4) man page on Linux and BSD systems, or random(7D) on Solaris, for further information.

S/MIME

S/MIME is a standard for sending and receiving secure MIME data, especially in e-mail messages. Automated S/MIME capabilities have been added to quite a few e-mail clients, though openssl can provide command-line S/MIME services using the smime option.

Note that the documentation in the smime(1) man page includes a number of good examples.

How do I verify a signed S/MIME message?

It’s pretty easy to verify a signed message. Use your mail client to save the signed message to a file. In this example, I assume that the file is named msg.txt.

openssl smime -verify -in msg.txt

If the sender’s certificate is signed by a certificate authority trusted by your OpenSSL infrastructure, you’ll see some mail headers, a copy of the message, and a concluding line that says Verification successful.

If the messages has been modified by an unauthorized party, the output will conclude with a failure message indicating that the digest and/or the signature doesn’t match what you received:

Verification failure

23016:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest

failure:pk7_doit.c:804:

23016:error:21075069:PKCS7 routines:PKCS7_verify:signature

failure:pk7_smime.c:265:

Likewise, if the sender’s certificate isn’t recognized by your OpenSSL infrastructure, you’ll get a similar error:

Verification failure

9544:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify

error:pk7_smime.c:222:Verify error:self signed certificate

Most e-mail clients send a copy of the public certificate in the signature attached to the message. From the command line, you can view the certificate data yourself. You’ll use the smime -pk7out option to pipe a copy of the PKCS#7 certificate back into the pkcs7 option. It’s oddly cumbersome but it works.

openssl smime -pk7out -in msg.txt | \

openssl pkcs7 -text -noout -print_certs

If you’d like to extract a copy of your correspondent’s certificate for long-term use, use just the first part of that pipe.

openssl smime -pk7out -in msg.txt -out her-cert.pem

At that point, you can either integrate it into your OpenSSL infrastructure or you can save it off somewhere for special use.

openssl smime -verify -in msg.txt -CAfile /path/to/her-cert.pem

How do I encrypt a S/MIME message?

Let’s say that someone sends you her public certificate and asks that you encrypt some message to her. You’ve saved her certificate as her-cert.pem. You’ve saved your reply as my-message.txt.

To get the default—though fairly weak—RC2-40 encryption, you just tell openssl where the message and the certificate are located.

openssl smime her-cert.pem -encrypt -in my-message.txt

If you’re pretty sure your remote correspondent has a robust SSL toolkit, you can specify a stronger encryption algorithm like triple DES:

openssl smime her-cert.pem -encrypt -des3 -in my-message.txt

By default, the encrypted message, including the mail headers, is sent to standard output. Use the -out option or your shell to redirect it to a file. Or, much trickier, pipe the output directly to sendmail.

openssl smime her-cert.pem \

-encrypt \

-des3 \

-in my-message.txt \

-from ‘Your Fullname <you@youraddress.com>’ \

-to ‘Her Fullname <her@heraddress.com>’ \

-subject ‘My encrypted reply’ |\

sendmail her@heraddress.com

How do I sign a S/MIME message?

If you don’t need to encrypt the entire message, but you do want to sign it so that your recipient can be assured of the message’s integrity, the recipe is similar to that for encryption. The main difference is that you need to have your own key and certificate, since you can’t sign anything with the recipient’s cert.

openssl smime \

-sign \

-signer /path/to/your-cert.pem \

-in my-message.txt \

-from ‘Your Fullname <you@youraddress.com>’ \

-to ‘Her Fullname <her@heraddress.com>’ \

-subject ‘My signed reply’ |\

sendmail her@heraddress.com

For further reading

Though it takes time to read them all and figure out how they relate to one another, the OpenSSL man pages are the best place to start: asn1parse(1), ca(1), ciphers(1), config(5), crl(1), crl2pkcs7(1), dgst(1), dhparam(1), dsa(1), dsaparam(1), ec(1), ecparam(1), enc(1), errstr(1), gendsa(1), genpkey(1), genrsa(1), nseq(1), ocsp(1), openssl(1), passwd(1), pkcs12(1), pkcs7(1), pkcs8(1), pkey(1), pkeyparam(1), pkeyutl(1), rand(1), req(1), rsa(1), rsautl(1), s_client(1), s_server(1), s_time(1), sess_id(1), smime(1), speed(1), spkac(1), ts(1), tsget(1), verify(1), version(1), x509(1), x509v3_config(5).

Quoting from RFC 4033:

The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System.

The really interesting bit is that DNSSEC strives to do so using the current nearly unmodified DNS protocol, including caching, wildcards, forwarders etc. This is a massive challenge.

Compare an HTTP proxy, like squid, which makes no attempt to cache encrypted HTTPS data. When accessing HTTPS through a proxy, a direct connection is made through the proxy to the origen webserver.

DNSSEC in contrast attempts to preserve authentication and integrity even through caches. This is possible because DNSSEC does not guarantee exclusivity, it does not actually encrypt data.

But it is a massive challenge nonetheless.

First steps

The first step is obvious: sign records, and make sure the signature and the record itself are both cached, and delivered with answers. This is just like what happens when you add a PGP signature to an email message.

To this goal, DNSSEC has invented the RRSIG record type, the Resource Record Signature, and it is indeed sent with answers, it looks like this:

   a.z.w.example. 3600 IN MX  1 ai.example.
   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
                              4kX18MMR34i8lC36SR5xBni8vHI= )

This is the MX record of a.z.w.example, which points to ‘ai.example’, followed by its signature. You can see in the RRSIG that this is a signature of the MX record of a.z.w.example.com, that the signature algorithm is number ’5′.

The next number we’ll address later – it has to do with wildcards. I think this example, lifted from the RFC, is wrong btw.

The next number is the original TTL, followed by the expiry of the signature (20040509183619), followed by the date this signature was generated (20040409183619).

The next number, 38519, is the ‘tag’ if the key used to generate this signature. This is needed because there might be more keys available to sign records.

The next label, ‘example.’ is the owner of the key used to sign this record, which should be equal to the name of the zone containing the record.

This all then is followed by the actual base64 encoded signature of all the above.

Where do we get the key?

We’ve seen how we can sign a DNS record, but that leaves the important question of where to get, and more importantly, how to trust the key used to sign.

We’ll start out simple by describing the DNSKEY record, which as the name implies, contains a key, or in fact the public part of an asymmetrical key.

   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
                                          kfzj31GajIQKY+5CptLr3buXA10h
                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
                                          742iU/TpPSEDhm2SNKLijfUppn1U
                                          aNvv4w==  )

This specifies the example.com key. 256 means that his is a ‘Zone Key’, 3 is there to signify the protocol version and must always be 3. The next number, 5, is one we saw earlier, and it denotes the algorithms used. This is then followed by the actual key.

Note that the key tag, 38519 in the previous example, is hidden in the base-64 encoded key. There are tools available that add the tag as a comment to the zone.

This is all fine, but can we trust this key? We can query the key from the example.com zone, but as long as we get both the key and the signature over the same network, no real security is being added.

There are two interesting ways out of this dilemma. One is to retrieve the key using unspecified out-of-band means, like via a PGP signed message, or via ssh to a trusted host. That key can then become an ‘anchor’ for you.

The second way is to have an existing ‘anchor’ sign your keys. In an ideal world the root-zone would be the anchor, and everything would flow from there.

So, are we done now?

Sadly, no. We also need to be able to deny the existence of a record securely. Now, this is a real problem. The way DNS denies the existence of a record is to send an empty authoritative answer packet, which is smart as far as it goes, but it leaves us with a problem: there is nothing to sign.

HTTPS does not have this problem as it does secure transport, not secure message, so it can simply send a ’404′ response over its secure channel.

As noted the DNSSEC people are among the smartest in the world so they’ve figured out a solution: the ‘Next Secure’ NSEC record, known in its previous flawed incarnation as NXT.

Fundamentally it works like this: we have three records, called A, B and D. If a question comes in for C, we return the NSEC record that says that the ‘Next Secure’ record after B is D, which proves there is no C.

And because we CAN sign the NSEC record, this is secure. The NSEC record in the case above would look like this:

   b.example.com. 86400 IN NSEC d.example.com. (
                                   A RRSIG NSEC)

Note the ‘A RRSIG NSEC’. This is where things get more complicated. This means that b.example.com has an A, RRSIG and an NSEC record.

Besides complete non-existence, there is also the case the record exists, but not the associated type. This happens for example when querying for an AAAA record for a host which has only an A record. Again, the normal DNS response is to send out an empty answer, which cannot be signed. In this case we again send out the NSEC record which lists which types DO exist, allowing the recipient to prove there is no AAAA record.

The trust chain

We previously noted that we can designate keys as ‘anchors’, once we have verified their authenticity using non-DNS means. It is impracticable to do this for all millions of domains though. So we need a way to have trusted keys (anchors) sign further keys, in hopes of one day having a signed root.

The proper place for such a signature is in the parent zone, of course, and for this purpose, DNSSEC has invented the Delegation Signer (DS) record. The size of the ccTLD zones is already worrisomely large, so the DS record only contains a hash of the signed zone.

The record looks like this:

   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                              98631FAD1A292118 )

This is the delegation signature, which would typically live in the .com zone, which corresponds to this DNSKEY in the example.com zone below:

   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
                                             fwJr1AYtsmx3TGkJaNXVbfi/
                                             2pHm822aJ5iI9BMzNXxeYCmZ
                                             DRD99WYwYqUSdjMmmAphXdvx
                                             egXd/M5+X7OrzKBaMbCVdFLU
                                             Uh6DhweJBjEVv5f2wwjM9Xzc
                                             nOf+EPbtG9DMBmADjFDc2w/r
                                             ljwvFw==
                                             ) ;  key id = 60485

Note how the key id was added as a comment here. Also note that the above makes no sense unless the DS record itself is signed with an RRSIG record with a key we do trust.

So if we have configured the .COM key as an anchor, we would also trust the DS record for dskey.example.com and henceforth also the signatures in the example.com zone, and so forth.

It is all very pretty.

This sounds reasonable, are we done?

Sadly, no. Encryption keys need to be changed every once in a while, especially if they are short, as they tend to be in DNS.

Using the scheme above, any change in key would have to be agreed with the registry (parent zone), which takes time to to process. Furthermore, the registry is probably not willing to change the key around a lot as they have better things to do.

So we invoke the magic incantation ‘there is no problem in computing that cannot be solved by another layer of indirection’, and add another layer of indirection.

This is called the ‘Key Signing Key’ (KSK), and that is the one that is ‘blessed’ by the parent zone. We then use the KSK to sign our Zone Signing Keys (ZKSs), which are used to sign our actual records. Note the plural, more about this later.

So the actual setup has, in addition to the DS and DNSKEY records shown above an additional layer in the form of another DNSKEY, which is signed with an RRSET based on the DNSKEY we already had. The key signed by our parent has the ‘Secure Entry Point’ flag set to designate it as the key to start with.

Key rollovers

As stated above, there is a real need to change keys every once in a while, both regularly or in a hurry if they keys have been compromised.

During a change of keys, a situation might exist were caches still carry the old signatures, but resolvers can’t find the associated keys to authenticate them with.

The solution for this is to make sure multiple keys and signatures are around, and only change one set at a time.

This needs to be done very carefully though, as any mistake will lead to ‘bogus’ data in DNSSEC parlance, which means that your records have signatures, but they can’t be verified. Security-aware clients will now drop your data.

There are two proposed modes for ZSK rollover, which are detailed in DNSSEC Operational Practices by Olaf Kolkman: ‘Pre-publish key set Rollover’ and ‘Double Signature Zone-signing Key Rollover’, and yet more modes for KSK rollover.

Wildcards

Previously, DNSSEC took the labour-saving decision to not support wildcards. Wildcards in DNS synthesise records, which means that there is an infinite amount of signing to do in theory.

But then the DNSSEC people had a smart idea: make an RRSET state how many labels it covers. This means that ‘www.example.com’, synthesised by ‘*.example.com’ is followed by a synthesised RRSET signing ‘www.example.com’. However, this signature is then invalid, since it was signed as ‘*.example.com’. Now what?

Remember the unexplained number in the RRSET record? That is the amount of labels the RRSET covers, which would in this case be 2. The receiving nameserver can derive from this that the record ‘www.example.com’ was synthesised from ‘*.example.com’, and check the signature accordingly.

The problem of privacy, zone enumeration: NSEC3

Warning: This section has not been proofread and may very well be incorrect! – However, findings are based on actual lab test results.

This is sort of ironic. DNSSEC was meant to improve DNS Security, but over time it became clear it simultaneously lowered it in other ways.

Many DNS operators do not allow their zones to be transferred, as the full contents of a zone are considered private, and often provide hackers with clues on how to hack a network.

Recall how DNSSEC employs the NSEC record to securely deny existence of a zone, by signifying that no records exist between two records that do. So, the NSEC “covering” the domains ‘a.example.com’ and ‘c.example.com’ proves there is no ‘b.example.com’ record.

It turns out that if we start out from one NSEC record, we can find the next, and so on, therefore emulating a full zone transfer! By hopping from the “lower” part of the cover to the upper, we find a chain of NSEC records that lists the entire zone contents.

The upshot of this is that there is no longer the ability to restrict full access to a zone, as malicious users can simply hop all the NSEC records, and get the same thing.

This has meant that several large domain registries have stated that they cannot deploy DNSSEC in its present form, for example because of strict implementations of the EU privacy directive.

As stated before, the DNSSEC authors are pretty smart and know a lot about cryptography, so they’ve found a solution to this problem: NSEC3

In principle, this works just like regular NSEC, except that it operates on strong cryptographic hashes of domain names. By sending an NSEC3 response that covers the *hashes* that come before and after the hash of the record a query was sent for, the same proof of non-existence is available, without making it possible to enumerate the entire zone. One could enumerate the hashes, but as these are strong, they can’t be converted back into domain names.

This is pretty smart, but also means the authoritative nameserver should keep the list of NSEC3 records in correct sorted order available. Things quickly get mighty complicated when wildcards are involved as well.

Additionally, the authoritative server has to do a lot more work, as it has to hash each question it can’t immediately find an answer for to see which NSEC3 it should emit to prove non-existence.

Yes we are done

Ok, if you’ve made it through the above, I suggest reading the DNSSEC HOWTO by Olaf Kolkman, which should now make sense.

So is it all worth it?

The big worries to me are:

• Huge answer records, making DNSSEC act as a packet-amplifier.

• Complexity of key-rollover procedures. Automated key-rollover appears to be covered by patents.

• Complexity of recursion process. Serving DNSSEC records is complex enough as it is, with NSEC taking the complexity-crown from the LOC record, but the recursing process is truly very hard.

• The biggest worry: DNSSEC complexity is sure to cause secure unavailability of domain names, leading DNSSEC users to either turn it off or ignore its warnings.

Many of the worries above could be addressed with good toolsets and client library support, but the last and first factors will always remain. DNS often operates under the hood, many applications have no way to communicate with their end users.

For example, how would a MTA react to ‘Bogus’ data? Hold the email? Bounce it back to the original author asking for instructions? Send it anyhow? Policy is hard to set.

So, you decide!

DNS represents the abbreviation for a Domain Name Server which is used to interpret domain names such as www.yourdomain.com into an Internet Protocol (IP) address. The Internet Protocol address consists of numbers such as 107.60.132.4 that give the domain a unique identification. An IP address is one-of-a-kind and unique so it can be used to trace Internet activity back to the PC user as well as identify the exact location of a website. Domain names are used to identify websites because they are easier to remember than a series of numbers that make up an IP address.

How DNS Hijacking Works.

DNS hijacking is used by hackers with malicious intent who redirect or “hijack” the DNS addresses to bogus DNS servers for the purpose of injecting malware into your PC, promoting phishing scams, advertising on high traffic websites, and any other related form of criminal activity.

Once the DNS address is hijacked to a bogus DNS server, it translates the legitimate IP address or DNS name into the IP addresses of malicious websites. DNS hijacking can occur with any website large or small and turn those websites into malicious websites without the knowledge of the Web surfer.

Since the website owners depend upon legitimate DNS server that are issued by their Internet Service Providers (ISP), DNS hijackers use malware in the form of a Trojan to exchange the legitimate DNS server assignment by the ISP with a manual DNS server assignment from a bogus DNS server.

When Web surfers visit the reputable websites with legitimate domain names, they are automatically hijacked to a malicious website that is disguised as the legitimate one. The switch from the legitimate DNS server to the bogus DNS server goes unnoticed by both the surfer and the legitimate website owner. This opens up the malicious website to perform any criminal act that the hacker wishes because the user thinks they are on the real website.
Other Dangers of DNS Hijacking

Another danger of DNS hijacking occurs when the surfer is unaware that they are on a bogus DNS server. If the user continues to surf on the bogus DNS server and they search for other websites, they most likely will end up visiting more malicious sites.

For example, let’s say that they search for a website and the domain is non-existent due to a misspelling typed during the search. Generally a legitimate DNS server will display an error message or provide site suggestions that relate to what the user typed into the search. With a bogus DNS server, instead of the error message they will be directed to yet another malicious website because the server has been created for the purpose of performing criminal acts. Regardless of what is typed in, it malicious websites replace the error message.

DNS hijacking also promotes click fraud with such programs as Google Adsense. Since there are numerous DNS servers that are bogus, they form a network of websites which results in a lot of traffic. When you get a lot of traffic you of course get a lot of people clicking which results in click fraud. The hackers can rack up a lot of money with click throughs from programs like Google Adsense who pay a commission for each click.

Preventing DNS Poisoning in Linux

If you don’t think the recent discovery of the DNS cache-poisoning flaw is bad news and needs to be addressed as soon as possible, let me repeat what Paul Mockapetris, DNS’ (Domain Name System) inventor, had to say about this security hole: Patch your DNS servers right now.

CERT can tell you about the technical details of DNS cache-poisoning, here’s what an attack on a DNS server can mean to you according to Dan Kaminsky, a researcher at security services firm IOActive: The vulnerability could allow attackers to redirect Web traffic and e-mails to systems under their control.

In other words, you click on your bookmark for Google and you end up at a site that looks like Google but is loaded down with malware. Or, you go to what looks like your bank site, the URL is the right one for your bank, but when you enter in your account ID you’ve just given it to a rip off artist.

With violated DNS servers you will be unable to trust the Internet. None of your net-based programs — e-mail, Web browser, media-player, whatever – would be trustworthy.

The only solution is to update your DNS servers and to do it now. Almost all the major operating system vendors have already released patches for the problem.

For Linux servers in specific, that means you need to upgrade BIND. If you’re still using BIND 8, or, God-forbid, any earlier versions, since these are hopelessly outdated, you should upgrade to BIND 9.

BIND 9 is years old but some ISPs and companies are still using it. If you’re using an older Linux distribution for DNS, you may need to update BIND by hand from the source code.

More About The Alternatives and Best Practices: What are the preventative measures?

When searching for ways to increase DNS awareness we can look to Dr. Stephen Crocker, Internet pioneer and Chair of the ICANN committee. He highlighted in a recent Computer World interview with Patrick Thibodeau, that good practice involves more diversity and a need for a wider set of implementations of BIND. His suggestion may be more important than ever considering that just last week security researchers discovered new vulnerabilities in BIND 4 and 8. In particular, they found that BIND 8 is vulnerable to two separate DDoS attacks. The first involves the way BIND 8 servers handle invalid DNS lookup requests and the other occurs when an attacker causes a BIND 8 server to cache SIG resource record elements with invalid expirations. “We know that many people are running obsolete versions of BIND, and the older versions have critical bugs,” said Crocker. Clearly, keeping up to date with the most recent version of BIND is a fundamental best practice that administrators should follow. But is the most recent version enough?

For example, the version 9.2.2 release of BIND, is indeed a major rewrite of many aspects of the underlying BIND architecture. With regards to DNS security issues, BIND 9.2.2 offers increased vigilance by acting as an authoritative server for DNSSEC secured zones. In brief, the IETF’s DNSSEC protocol is designed to stop DNS “hijacking”, as is the case when a hacker tampers with a site’s DNS information and misdirects users to an alternate server. Implications of such “hijacking” would involve hackers sending users to a ‘bogus’ website posing as the company’s legitimate site and possibly extracting confidential information such as credit card numbers or personal identification. Mark Kosters, VeriSign’s VP of Research and DNSSEC expert says, “We are glad to see that Incognito is integrating DNSSEC within DNS Commander. We see the deployment of DNSSEC as one of the most critically important enhancements on core security on the Internet in these times of increased hacker activity and consequent security awareness.”

Kosters does make a valid point; however, it is important to understand that DNSSEC may be years away from being fully implemented. So, in the short run, the fundamental shortcomings of BIND still remain. We are then left with the burning question, “What do we do in the meantime?”

Interactive Week’s Charles Babcock points out that, “With few exceptions, Web sites have such a server in front of them running BIND and directing traffic. The DNS server is typically outside the corporate firewall with minimal protection and, thus, is a frequent target for hackers since 80 to 90 percent of the copies of BIND in use contain one of a dozen known vulnerabilities.” For this reason, it is important for network administrators to be aware of proprietary BIND alternatives.

A lot of times, administrators use BIND because it is free and they’re either not concerned about reliability or not aware of the risks of open source software. With businesses becoming more dependent on both their internal network and Internet presence to operate efficiently, support customers, and drive new revenue, reliability and quality of service is critical. For this reason, enterprises and ISPs need to consider implementing proprietary DNS software that is available only as compiled code, which makes it more difficult to discover vulnerabilities as compared to open source code. Because DNS is based upon well-established standards, core DNS functionality is not an issue with proprietary solutions as long as they meet these standards. Solutions, such as Incognito’s DNS Commander, can be highly-extensible, robust, and cost-effective, domain management solution that are secure BIND/MSDNS alternatives. Also, proprietary solutions tend to have performance improvements, feature enhancements, and are easier to deploy and use compared to BIND. After all, these vendors need to have better product in order to maintain a successful business. Often, simply introducing a proprietary secondary DNS server as a backup to the network can greatly increase DNS resilience.

As an example, the UK Ministry of Defense recently communicated their need for a secure DNS solution. General Dynamics, the contractor responsible for the UK MOD’s BOWMAN project, evaluated several prominent DNS solutions, including BIND, as part of their selection process. It was concluded that, “Given the needs of the BOWMAN program, the proprietary DNS alternative that Incognito develops had the best fit in terms of features, reliability, and security,” said Andrew Greenslade, BOWMAN Product Manager at General Dynamics Canada. “Integrating a DNS alternative into the BOWMAN program will fulfill General Dynamics’ mandate to provide a secure, reliable, and robust DDNS solution.” With a deployment that includes thousands of administrators directly managing DNS in a possibly hostile combat environment, an easy-to-use management interface with superior redundancy and diagnostic tools are critical requirements that alternative solutions are offering.

Another DNS alternative includes taking advantage of a two-pronged solution. Radware, a Mahwah, N.J.- based company, points out that their Web Server Director (WSD) solution provides comprehensive IP application security and optimization. To illustrate, a combined solution would have a Radware WSD deployed between the Internet and several DNS Commander servers. The WSD would be configured with a Virtual IP address and root server databases are updated to point to this Virtual IP address (VIP) and other VIPs for redundancy. The WSD hides the IP addresses of the DNS Commander servers behind it, providing security from attacks, and WSD also load balances DNS requests across these servers for optimized DNS operation.

Aside from using a two-tiered virtual IP solution that works to prevent DDoS attacks from reaching the DNS server, many DNS experts assert that mirroring the root server data can also be a simple and cost effective way to secure that information. The Washington Post recently reported, “that many of the nation’s top e-commerce companies mirror information contained in the root servers to safeguard their operations from DDOS attacks.”

This is a valid point because firms that mirror root data will inherently be more secure because they will rarely need to query the root servers. In the case of a DDoS attack where the root servers are affected, a company with a root mirror will be able to continue daily operations and will likely not feel the effects of a DDoS.

Allan Liska, Security Engineer for Symantec’s managed security division, highlights that mirroring the root data is not overly complicated in BIND, but can still be very cumbersome and time consuming. “If BIND is running on a server with other services there could be a problem with not having enough space to implement it. On the other hand, if the company has a dedicated DNS appliance with more than enough storage space to hold the 30+ million records hosted on the root servers, it is a much simpler task.”

Looking Forward

Despite the current market’s lack of enthusiasm with technology, the greatest opportunities lie ahead solving the most pressing issues of the Internet – security, access, and identity. The most recent DDoS attacks have revealed a great deal about the vulnerabilities of DNS, and although experts assert that the next hackers attempting an attack will use this information for their advantage, it is also necessary to utilize such revelations for improving DNS security. Armed with such knowledge and increased public pressure, the stimulus to incorporate best practices in DNS management should be a number one priority on everyone’s security agendas. The warning signs are everywhere.

What is RSA/DSA authentication?

SSH, specifically OpenSSH (a completely free implementation of SSH), is an incredible tool. Like telnet or rsh, the ssh client can be used to log in to a remote machine. All that’s required is for this remote machine to be running sshd, the ssh server process. However, unlike telnet, the ssh protocol is very secure. It uses special algorithms to encrypt the data stream, ensure data stream integrity and even perform authentication in a safe and secure way.

However, while ssh is really great, there is a certain component of ssh functionality that is often ignored, dangerously misused, or simply misunderstood. This component is OpenSSH’s RSA/DSA key authentication system, an alternative to the standard secure password authentication system that OpenSSH uses by default.

OpenSSH’s RSA and DSA authentication protocols are based on a pair of specially generated cryptographic keys, called the private key and the public key. The advantage of using these key-based authentication systems is that in many cases, it’s possible to establish secure connections without having to manually type in a password.

While the key-based authentication protocols are relatively secure, problems arise when users take certain shortcuts in the name of convenience, without fully understanding their security implications. In this course, we’ll take a good look at how to correctly use RSA and DSA authentication protocols without exposing ourselves to any unnecessary security risks. In my next course, I’ll show you how to use ssh-agent to cache decrypted private keys, and introduce keychain, an ssh-agent front-end that offers a number of convenience advantages without sacrificing security. If you’ve always wanted to get the hang of the more advanced authentication features of OpenSSH, then read on.

How RSA/DSA keys work

Here’s a quick general overview of how RSA/DSA keys work. Let’s start with a hypothetical scenario where we’d like to use RSA authentication to allow a local Linux workstation (named localbox) to open a remote shell on remotebox, a machine at our ISP. Right now, when we try to connect to remotebox using the ssh client, we get the following prompt:

% ssh drobbins@remotebox

drobbins@remotebox’s password:

Here we see an example of the ssh default way of handling authentication. Namely, it asks for the password of the drobbins account on remotebox. If we type in our password for remotebox, ssh uses its secure password authentication protocol, transmitting our password over to remotebox for verification. However, unlike what telnet does, here our password is encrypted so that it can not be intercepted by anyone sniffing our data connection. Once remotebox authenticates our supplied password against its password database, if successful, we’re allowed to log on and are greeted with a remotebox shell prompt. While the ssh default authentication method is quite secure, RSA and DSA authentication open up some new possibilities.

However, unlike the ssh secure password authentication, RSA authentication requires some initial configuration. We need to perform these initial configuration steps only once. After that, RSA authentication between localbox and remotebox will be totally painless. To set up RSA authentication, we first need to generate a pair of keys, one private and one public. These two keys have some very interesting properties. The public key can be used to encrypt a message, and only the holder of the private key can decrypt it. The public key can only be used for encryption, and the private key can only be used for decryption of a message encoded by the matching public key. The RSA (and DSA) authentication protocols use the special properties of key pairs to perform secure authentication, without needing to transmit any confidential information over the network.

To get RSA or DSA authentication working, we perform a single one-time configuration step. We copy our public key over to remotebox. The public key is called “public” for a reason. Since it can only be used to encrypt messages for us, we don’t need to be too concerned about it falling into the wrong hands. Once our public key has been copied over to remotebox and placed in a special file (~/.ssh/authorized_keys) so that remotebox’s sshd can locate it, we’re ready to use RSA authentication to log onto remotebox.

To do this, we simply type ssh drobbins@remotebox at localbox’s console, as we always have. However, this time, ssh lets remotebox’s sshd know that it would like to use the RSA authentication protocol. What happens next is rather interesting. Remotebox’s sshd generates a random number, and encrypts it using our public key that we copied over earlier. Then, it sends this encrypted random number back to the ssh running on localbox. In turn, our ssh uses our private key to decrypt this random number, and then sends it back to remotebox, saying in effect “See, I really do hold the matching private key; I was able to successfully decrypt your message!” Finally, sshd concludes that we should be allowed to log in, since we hold a matching private key. Thus, the fact that we hold a matching private key grants us access to remotebox.

Two observations

There are two important observations about the RSA and DSA authentication. The first is that we really only need to generate one pair of keys. We can then copy our public key to the remote machines that we’d like to access and they will all happily authenticate against our single private key. In other words, we don’t need a key pair for every system we’d like to access. Just one pair will suffice.

The other observation is that our private key should not fall into the wrong hands. The private key is the one thing that grants us access to our remote systems, and anyone that possesses our private key is granted exactly the same privileges that we are. Just as we wouldn’t want strangers to have keys to our house, we should protect our private key from unauthorized use. In the world of bits and bytes, this means that no one should be able to read or copy our private key.

Of course, the ssh developers are aware of the private keys’ importance, and have built a few safeguards into ssh and ssh-keygen so that our private key is not abused. First, ssh is configured to print out a big warning message if our key has file permissions that would allow it to be read by anyone but us. Secondly, when we create our public/private key pair using ssh-keygen, ssh-keygen will ask us to enter a passphrase. If we do, our private key will be encrypted using this passphrase, so that even if it is stolen, it will be useless to anyone who doesn’t happen to know the passphrase. Armed with that knowledge, let’s take a look at how to configure ssh to use the RSA and DSA authentication protocols.

ssh-keygen up close

The first step in setting up RSA authentication begins with generating a public/private key pair. RSA authentication is the original form of ssh key authentication, so RSA should work with any version of OpenSSH, although I recommend that you install the most recent version available, which was openssh-2.9_p2 at the time this course was written. Generate a pair of RSA keys as follows:

% ssh-keygen

Generating public/private rsa1 key pair.

Enter file in which to save the key (/home/drobbins/.ssh/identity): (hit enter)

Enter passphrase (empty for no passphrase): (enter a passphrase)

Enter same passphrase again: (enter it again)

Your identification has been saved in /home/drobbins/.ssh/identity.

Your public key has been saved in /home/drobbins/.ssh/identity.pub.

The key fingerprint is:

a4:e7:f2:39:a7:eb:fd:f8:39:f1:f1:7b:fe:48:a1:09 drobbins@localbox

When ssh-keygen asks for a default location for the key, we hit enter to accept the default of /home/drobbins/.ssh/identity. ssh-keygen will store the private key at the above path, and the public key will be stored right next to it, in a file called identity.pub.

Also note that ssh-keygen prompted us to enter a passphrase. When prompted, we entered a good passphrase (seven or more hard-to-predict characters). ssh-keygen then encrypted our private key (~/.ssh/identity) using this passphrase so that our private key will be useless to anyone who does not know it.

The quick compromise

When we specify a passphrase, it allows ssh-keygen to secure our private key against misuse, but it also creates a minor inconvenience. Now, every time we try to connect to our drobbins@remotebox account using ssh, ssh will prompt us to enter the passphrase so that it can decrypt our private key and use it for RSA authentication. Again, we won’t be typing in our password for the drobbins account on remotebox, we’ll be typing in the passphrase needed to locally decrypt our private key. Once our private key is decrypted, our ssh client will take care of the rest. While the mechanics of using our remote password and the RSA passphrase are completely different, in practice we’re still prompted to type a “secret phrase” into ssh.

# ssh drobbins@remotebox

Enter passphrase for key ‘/home/drobbins/.ssh/identity’: (enter passphrase)

Last login: Thu Jun 28 20:28:47 2001 from localbox.gentoo.org

Welcome to remotebox!

%

Here’s where people are often mislead into a quick compromise. A lot of the time, people will create unencrypted private keys just so that they don’t need to type in a password. That way, they simply type in the ssh command, and they’re immediately authenticated via RSA (or DSA) and logged in.

# ssh drobbins@remotebox

Last login: Thu Jun 28 20:28:47 2001 from localbox.gentoo.org

Welcome to remotebox!

%

However, while this is convenient, you shouldn’t use this approach without fully understanding its security impact. With an unencrypted private key, if anyone ever hacks into localbox, they’ll also get automatic access to remotebox and any other systems that have been configured with the public key.

I know what you’re thinking. Passwordless authentication, despite being a bit risky does seem really appealing. I totally agree. But there is a better way! Stick with me, and I’ll show you how to gain the benefits of passwordless authentication without compromising your private key security. I’ll show you how to masterfully use ssh-agent (the thing that makes secure passwordless authentication possible in the first place) in my next course. Now, let’s get ready to use ssh-agent by setting up RSA and DSA authentication. Here step-by-step directions.
RSA key pair generation

To set up RSA authentication, we’ll need to perform the one-time step of generating a public/private key pair. We do this by typing:

% ssh-keygen

Accept the default key location when prompted (typically ~/.ssh/identity and ~/.ssh/identity.pub for the public key), and provide ssh-keygen with a secure passphrase. Once ssh-keygen completes, you’ll have a public key as well as a passphrase-encrypted private key.
RSA public key install

Next, we’ll need to configure remote systems running sshd to use our public RSA key for authentication. Typically, this is done by copying the public key to the remote system as follows:

% scp ~/.ssh/identity.pub drobbins@remotebox:

Since RSA authentication isn’t fully set up yet, we’ll be prompted to enter our password on remotebox. Do so. Then, log in to remotebox and append the public key to the ~/.ssh/authorized_keys file like so:

% ssh drobbins@remotebox

drobbins@remotebox’s password: (enter password)

Last login: Thu Jun 28 20:28:47 2001 from localbox.gentoo.org

Welcome to remotebox!

% cat identity.pub >> ~/.ssh/authorized_keys

% exit

Now, with RSA authentication configured, we should be prompted to enter our RSA passphrase (rather than our password) when we try to connect to remotebox using ssh.

% ssh drobbins@remotebox

Enter passphrase for key ‘/home/drobbins/.ssh/identity’:

Hurray, RSA authentication configuration complete! If you weren’t prompted for a passphrase, here are a few things to try. First, try logging in by typing ssh -1 drobbins@remotebox. This will tell ssh to only use version 1 of the ssh protocol, and may be required if for some reason the remote system is defaulting to DSA authentication. If that doesn’t work, make sure that you don’t have a line that reads RSAAuthentication no in your /etc/ssh/ssh_config. If you do, comment it out by pre-pending it with a “#”. Otherwise, try contacting the remotebox system administrator and verifying that they have enabled RSA authentication on their end and have the appropriate settings in /etc/ssh/sshd_config.

DSA key generation

While RSA keys are used by version 1 of the ssh protocol, DSA keys are used for protocol level 2, an updated version of the ssh protocol. Any modern version of OpenSSH should be able to use both RSA and DSA keys. Generating DSA keys using OpenSSH’s ssh-keygen can be done similarly to RSA in the following manner:

% ssh-keygen -t dsa

Again, we’ll be prompted for a passphrase. Enter a secure one. We’ll also be prompted for a location to save our DSA keys. The default, normally ~/.ssh/id_dsa and ~/.ssh/id_dsa.pub, should be fine. After our one-time DSA key generation is complete, it’s time to install our DSA public key to remote systems.

DSA public key install

Again, DSA public key installation is almost identical to RSA. For DSA, we’ll want to copy our ~/.ssh/id_dsa.pub file to remotebox, and then append it to the ~/.ssh/authorized_keys2 on remotebox. Note that this file has a different name than the RSA authorized_keys file. Once configured, we should be able to log in to remotebox by typing in our DSA private key passphrase rather than typing in our actual remotebox password.
Resources

* Be sure to visit the home of OpenSSH development.

* Take a look at the latest OpenSSH source tarballs and RPMs.

* Check out the OpenSSH FAQ.

* PuTTY is an excellent ssh client for Windows machines.

* You may find O’Reilly’s SSH, The Secure Shell: The Definitive Guide to be helpful.

* Read Addressing security issues in Linux on developerWorks for an overview of data encryption and many other security topics.

* Browse more Linux resources on developerWorks.

* Browse more Open source resources on developerWorks.

In computer networking, port knocking is a method of externally opening ports on a firewall by generating a connection attempt on a set of prespecified closed ports. Once a correct sequence of connection attempts is received, the firewall rules are dynamically modified to allow the host which sent the connection attempts to connect over specific port(s). A variant called Single Packet Authentication exists, where only a single ‘knock’ is needed, consisting of an encrypted packet.

The primary purpose of port knocking is to prevent an attacker from scanning a system for potentially exploitable services by doing a port scan, because unless the attacker sends the correct knock sequence, the protected ports will appear closed.

This is usually implemented by configuring a daemon to watch the firewall log file for said connection attempts then modify the firewall configuration accordingly. It can also be performed by a process examining packets at a higher level (using packet capture interfaces such as pcap), allowing the use of already “open” TCP ports to be used within the knock sequence.

The port “knock” itself is similar to a secret handshake and can consist of any number of TCP, UDP or even sometimes ICMP and other protocol packets to numbered ports on the destination machine. The complexity of the knock can be anything from a simple ordered list (e.g. TCP port 1000, TCP port 2000, UDP port 3000) to a complex time-dependent, source-IP-based and other-factor-based encrypted hash.

A portknock daemon on the firewall machine listens for packets on certain ports (either via the firewall log or by packet capture). The client user would carry an extra utility, which could be as simple as netcat or a modified ping program or as complicated as a full hash-generator, and use that before they attempted to connect to the machine in the usual way.

Most portknocks are stateful systems in that if the first part of the “knock” has been received successfully, an incorrect second part would not allow the remote user to continue and, indeed, would give the remote user no clue as to how far through the sequence they failed. Usually the only indication of failure is that, at the end of the knock sequence, the port expected to be open is not opened. No packets are sent to the remote user at any time.

While this technique for securing access to remote network daemons has not been widely adopted by the security community, it has been integrated in newer rootkits.

Benefits of port knocking

Consider that, if an external attacker did not know the port knock sequence, even the simplest of sequences would require a massive brute force effort in order to be discovered. A three-knock simple TCP sequence (e.g. port 1000, 2000, 3000) would require an attacker without prior knowledge of the sequence to test every combination of three ports in the range 1-65535, and then to scan each port in between to see if anything had opened. As a stateful system, the port would not open until after the correct three-digit sequence had been received in order, without other packets in between.

That equates to approximately 655354 packets in order to obtain and detect a single successful opening. That’s 18,445,618,199,572,250,625 or over 18.4 quintillion packets. On the average attempt it would take approximately 9.2 quintillion packets to successfully open a single, simple three-port TCP-only knock by brute force. This is made even more impractical when knock attempt-limiting is used to stop brute force attacks, longer and more complex sequences are used and cryptographic hashes are used as part of the knock.

When a port knock is successfully used to open a port, the firewall rules are generally only opened to the IP address that supplied the correct knock. This is similar to only allowing a certain IP whitelist to access a service but is also more dynamic. An authorised user situated anywhere in the world would be able to open the port they were interested in to only the IP that they are using without needing help from the server administrator. They would also be able to “close” the port once they had finished, or the system could be set up to use a timeout mechanism, to ensure that once they change IP’s, only the IP’s necessary are left able to contact the server.

Because of port knocking’s stateful behavior, several users from different source IP addresses can simultaneously be at varying levels of the port knock. Thus it is possible to have a genuine user with the correct knock let through the firewall even in the middle of a port attack from multiple IP’s (assuming the bandwidth of the firewall is not completely swamped). To all other IP addresses, the ports still appear closed and there is no indication that there are other users who have successfully opened ports and are using them.

Using cryptographic hashes inside the port knock sequence can mean that even sniffing the network traffic in and out of the source and target machines is ineffective against discovering the port knock sequence or using traffic replay attacks to repeat prior port knock sequences.

Even if somebody did manage to guess, steal or sniff the port knock and successfully use it to gain access to a port, the usual port security mechanisms are still in place, along with whatever service authentication was running on the opened ports.

The software required, either at the server or client end, is minimal and can in fact be implemented as simply as a shell script for the server or a Windows batch file and a standard Windows command line utility for the client. Overhead in terms of traffic, CPU and memory consumption is at an absolute minimum. Port knock daemons also tend to be simple enough that any sort of vulnerability is obvious and the code is very easily auditable.

With a portknock system in place on ports such as the SSH port, it can prevent brute force password attacks on logins. The SSH daemon need not even wake up as any attempt that is made without the correct portknock will bounce harmlessly off the TCP/IP stack rather than the SSH authentication. As far as any attacker is concerned, there is no daemon running on that port at all until they manage to correctly knock on the port.

The system is completely customisable and not limited to opening specific ports or, indeed, opening ports at all. Usually a knock sequence description is tied with an action, such as running a shell script, so when a specific sequence is detected by the port knock daemon, the relevant shell script is run. This could add firewall rules to open ports or do anything else that was possible in a shell script. Many portknocks can be used on a single machine to perform many different actions, such as opening or closing different ports.

Because the ports appear closed at all times until a user knowing the correct knock uses it, port knocking can help cut down not only on brute force password attacks and their associated log spam but also protocol vulnerability exploits. If an exploit was discovered that could compromise SSH daemons in their default configuration, having a port knock on that SSH port could mean that the SSH daemon may not be compromised in the time before it was updated. Only authorised users would have the knock and therefore only authorised users would be able to contact the SSH server in any way. Thus, random attempts on SSH servers by worms and viruses trying to exploit the vulnerability would not reach the vulnerable SSH server at all, giving the administrator a chance to update or patch the software. Although not a complete protection, port knocking would certainly be another level of defense against random attacks and, properly implemented, could even stop determined, targeted attacks.

Port knocking generally has some disregard in the security world, given that early implementations basically consisted of a number of ports that had to be hit in order. However, the best of modern portknock systems are much more complex, some using highly secure cryptographic hashes in order to defeat the most common attacks (such as packet sniffing and packet replay). Additionally, portknock systems can include blacklists, whitelists and dynamic attack responses as can any internet service, however, even the simplest of port knocks controls access to a system before attackers are able to hit a service that allocates memory, CPU time or other significant resources and also acts as a barrier against brute-force attempts, automated vulnerability exploits etc.

Port knocking does not generally lower the security of a system overall. Indeed, it provides another layer of security for minimal overhead. In the worst case scenario, however, the port knocking software can introduce a new security problem or lower security due to risk compensation.

Disadvantages of port knocking

If for some reason or other the port knocking daemon dies, you are left with a system you cannot connect with. This is also known as a single point of failure. However, to help mitigate this problem, modern port knocking implementations include a process monitoring daemon that will restart the port knocking daemon if it dies. This issue doesn’t affect xtables-addons’ in-kernel libxt_pknock module.

Another problem is that an attacker can lock out any known IP addresses e.g. the administrator by sending packages with spoofed IP address to random ports. For server to server communication this could be especially harmful because IPs are well known and sometimes can’t be changed easily. This could be prevented by using cryptographic hashes.

Also, an important consideration is that due to the way TCP/IP routes packets, there is a very real probability that individual packet components of the individual ‘knocks’ arrive out of sequence, or that some are dropped entirely. This means that legitimate requests have the potential to be “incorrect” in the eyes of the server, and that this must be dealt with by the client (a resend etc.)

Practical uses of port knocking

Now that we know what port knocking is, Let’s discuss it in a practical use evironment…

Port knocking as technique is used for a long time now and many implementations are already out there. Although, for my specific use none of them seemed to be appropriate.

Requirements (or why no other port knocking solution worked for me):
Knocking and service must share the same port (for example – let’s suppose you have a computer behind some router or firewall and have no access to this device; all you do have is one forwarded port to your computer – let’s say for ssh as most commonly used for system administration). I guess you can see now where the problem is with other implementations of port knocking: lack of ports that can be used for knocking.

Also, as I prefer a portable solution that is deployable anywhere (without any additional software clients) I want to make it possible so that it can be used with simple tools available on any system.

I’m trying to make this as simple as possible so all I’ll use is iptables. Why? Imagine a following scenario: something gets broken on a port knocking script/program/server and it’s not listening to knocks anymore. There comes a need for a visit to the computer to fix this directly as our ssh connection don’t let us do it remotely anymore. If iptables gets broken there is no firewall anyway so you’ll have a completely different set of problems, at least connecting to fix it wouldn’t be one of them.

One thing that is needed beside plain iptables is their recent module – either compiled in or as separate module. Few words about recent module parameters used here:

–name [name] defines a name of the list
–set puts the source IP matched in a list defined by –name (if name is not defined all matches go in some default list)
–rcheck does a rulecheck on a IPs from list
–seconds [seconds] is used to filter out the list for IPs seen within the indicated number of seconds
–hitcount [hits] filters out the list for minimum number of packets from some IP, can be combined with seconds to make the filtering more accurate

OK, so we’ll start with a standard firewall passing new ssh connections (I’ll use the iptables-save format as it’s easier to tweak the firewall and set comments though you can make this also with usual iptables commands) – port 22 is passed thru without any additional checks:

# pass established connections
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
# pass new ssh connection
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT

For starters we’ll need to start listening on this port:

# pass established connections
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
# listen to new connections on ssh port
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -m recent –set –name sshknock -j LOG “knock knock: ”
# pass new ssh connection
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT

Now, after initiating a ssh connection we have a entry in /proc/net/ip_recent/sshknock list showing us the address and main parameters of the packet. As connection was initiated one rule later and all later packets were are picked up by ESTABLISHED state rule that’s all we’re going to get for now.

So let’s start filling in this list with new packets by dropping them instead of accepting and also enabling the port knocking mechanism:

# pass established connections
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
# if at least 2 new packets inside 5 seconds open ssh port
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -m –rcheck –name sshknock –hitcount 2 –seconds 5 -j ACCEPT
# listen to new connections on ssh port
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -m recent –set –name sshknock -j LOG “knock knock: ”
# pass new ssh connection
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j DROP

We might stop at this as we have achieved our goal – 2 packet knock in a short amount of time is needed to open the port which will go under a radar for most port sniffers marking it as filtered port (of course, tweaking with more knocks and probably larger timespan is recommended to be more sure).
But, as we have a very well known port here which is targeted quite often let’s add an additional twist to this. By simply bombing the ssh port it will open without any defense at all.

# pass established connections
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
# if more then 2 new packets inside 3 seconds arrive drop
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -m –rcheck –name sshknock –hitcount 2 –seconds 3 -j ACCEPT
# if at least 2 new packets inside 5 seconds open ssh port
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -m –rcheck –name sshknock –hitcount 2 –seconds 5 -j ACCEPT
# listen to new connections on ssh port
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -m recent –set –name sshknock -j LOG “knock knock: ”
# pass new ssh connection
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j DROP

Another line to firewall is added – but what does it actually do?
If someone attempts to flood the port with packets it will refuse to open; and instead of only having number and time of knocks defined also rate at which these knocks must be employed is set – sending them at too high or too low frequency has no effect on opening the port – exactly 2 knocks is needed for 3rd packet to get to ssh server inside 3 – 5 seconds of the first knock.

So there it is, port knocking with only a few additional rules to iptables. Knocking packets can be generated with a simple telnet or ssh client. It most certainly isn’t the complete solution for the security and maybe isn’t as secure as some other port knocking solutions (additional encryption of the knocks, more complicated schemes of knocking) but it’s easily deployable and rises the security of the system significantly.

Optimist: The glass is half full.
Pessimist: The glass is half empty.
Engineer: The glass is twice the size it needs to be.

I’ve told that line at parties many times and have always gotten a laugh. Tell it to a group of senior engineers who have heard it a hundred times, though, and you’ll get a polite, stony silence at best.

Though it is humorous and when first explained to me it was done so with humour, if you honestly consider the statement, it is in fact very true.  The truth is, as engineers we are expected to think quick, act (certainly not react) quicker and implement solutions even faster.

As such, we must constantly be aware of potential problems.  As well as plausible and realistic solutions.  In my case, my clients expect solutions wherever and whenever needed, and that’s as it should be.  Today, with laptops this not exactly hard to accomplish.  With that said, an internet connection can sometimes be hard to come by.

Well, a known connection anyway.  Most people look at a cellphone as exactly that, but the truth is, it is likely just a modem.  That’s right, 96% of the cell providers in the world simply provide a network connection.  Then based on services purchased network access is granted or restricted.

I’m going to show you what I mean, using a WindowsMobile device as an example.  My carrier is AT&T.  I have a basic “phone only” data plan.  A data plan of some sort is required.  This provisions a gateway to your account which grants you access to access networks external to your provider.

Many phones have restrictions which are internally provisioned by your provider.  WindowsMobile 6.1 stores these settings in the registry of your device.  There are two sections we will need to adjust.

In the ConnectionSharing section make sure your settings match this:

The above settings ensure no phone based restrictions are preventing your phone from sharing its connection.

With AT&T I also needed to enable the connection “AlwaysOn” flag.

Next, you’ll want to check and ensure your default phone data connection is being used for InternetSharing requests.

At this point you need an Internet Connection Sharing software package on your phone if it did not ship standard.  Google can assist you there.

Then you’re all set. Enjoy