UNIX Administratosphere

Passwords are the first line of defense into almost every computer and every server. Some do use One-time Passwords, Keycards, or biometric sensors - but they are the unusual ones.

Let’s go back to basics, and figure what our requirements are. If we wax a bit, and dream up the ultimate set of requirements for strong passwords, it might look something like this:

The passwords must be easy to remember. If you can’t remember it, you may be caught short and not be able to log in. If you have to write it down, someone could see it or snatch the sticky note. Also, if a user has to write their password down, they are likely to write it down where all the world can see it.

The password must have a random character distribution. This is different than being random you might note. A fully random password means that a password of all ‘A’s is equally possible to any other; what we really want is a random distribution of letters within the password (I hope I said that right!). In that case, all ‘A’s would be impossible as the distribution is all on the letter A. The ideal would be random letter distribution, but an English (or native language) letter distribution would probably be suitable.

Writing down the password must not give it away. This is one I’ve not seen anywhere, but it would be nice.

A new password must be easy to generate. Ever have to come up with a suitable password? Of course… but how long does it take to come up with one that is both secure and easy to remember?

So how do we come up with passwords and adhere to our given requirements?

My thoughts are: use a phrase you can remember (easy to remember) and then write it down in a series of boxes - that is, in a 6×6 grid for example.  With such a grid, you could then write in a sentence (left to right), then read the letters in a different order (perhaps top to bottom, over one, bottom to top, over one, top to bottom …).  In essence, you are memorizing a simple and easy password and a pattern - then typing in the resulting text.  Left over characters could be Xs or Zs or numbers or special characters.

I can’t speak to the strength of this method, but I suspect it is pretty strong.  You could even “clip” the password at a certain number of characters while using a large phrase - which would make it stronger perhaps, since the entire phrase would not be used.

If this interested you, you may also be interested in Diceware: a method of using dice to select words (for a passphrase) in a wordlist.  There are some interesting ideas on how to make the passphrase stronger, and so on.  However, my idea requires no additional materials at all and results in a seemingly random set of characters for a password.

When root is locked out of a system, it can be a real problem. It’s even worse when you are root, yes?

There are many legitimate reasons this can happen:

• You purchased a used system with operating system installed, and the root login is unknown.
• The root password expired. (This has happened!)
• You have taken on a new system as a system administrator, and no one knows what the root password is (or what the box is, or what it does…)
• You have taken on a job as a new system administrator, and the previous administrator didn’t leave all of the passwords.
• You just plain forgot the system password (uhoh…).

We are going to assume that single user mode is locked out or not available. We are also going to skip talking about taking the system down (which is going to be necessary in any case).  We are also going to assume that you have legitimate physical access to the system.

In most situations, the system admin’s adage holds true: if you have physical access to the box, then there’s no stopping you from breaking in.  That’s why many operating systems make it fairly easy to access the system with physical access - and this is the reason you must physically secure your servers.  Putting them behind locked doors is the easiest and best way to go.  With physical access, it generally becomes easy to get into the system.

If you can access single user mode (such as booting HP-UX with “hpux -is” or booting Linux with “linux single“) then you can do all of the password recovery steps quite easily.

No matter what the operating system, if you have physical access to the system itself, then it is generally possible to crack it. There is a method that will work with any system:

1. Convert the disk into a “secondary” data disk in some fashion.
2. Boot into another operating system that can read and write the now secondary data disk.

There are several ways to do this. One way is to use a bootable floppy, CDROM, or DVDROM to enter into a maintenance mode, then access the original boot disk in the system. Sun Solaris has this capability using the install disk, as does Red Hat Enterprise and OpenSUSE. There are also bootable floppies and CDROMs that run on Linux all over everywhere.

Another way is to physically extract the hard disk from the system, and to use it as a data disk on another (identical) system. Macintosh laptops have this capability “builtin”: it’s called Target Mode, and turns the laptop into a large disk on a Firewire connection to a desktop or other system.

Remember, however, that the Macintosh uses NetInfo to manage its data; you’ll probably have to manipulate the NetInfo database on the other system in some fashion, or at least, turn it off.  That’s currently beyond our knowledge (but who knows…).

Under HP-UX, the boot disk is probably a single volume group, vg00: this volume group would have to be vgexported and vgimported in some fashion. The LVM structures would have to be accounted for.

Once the once bootable system is correctly mounted (read and write) as a data disk on another system, the easiest thing to do (with UNIX and Linux) is to change root’s password to null, by making the password entry empty in the /etc/password file. With NT, you may be able to extract the SAM file and use a cracker like L0pht to reveal the password.

With OpenVMS, the steps are more complicated, but the concept is the same: use a different security environment (an alternate UAF) and change the password in the original environment (the original UAF). First, alter the booting process to make OpenVMS boot into a sysboot> prompt. At this prompt, enter the command to use an alternate UAF:

sysboot> set uafalternate 1
sysboot> continue

The username and password to login will be null, so login by pressing enter until the prompt appears. Then we need to go about changing the password entry for SYSTEM:

$ define/system/executive sysuaf sys$system:sysuaf.dat
$ set def sys$system
$ run authorize
Authorize> modify system/password=newpass/nopwdexp
Authorize> exit

Then restore the alternate UAF setting back to zero so that the system UAF will be used on reboot:

$ run sys$system:sysman
sysman> param use current
sysman> param set uafalternate 0
sysman> param write current
sysman> exit

Then reboot the system and the SYSTEM password should be newpass.

This sequence hints at one reason a root password might “go bad” - if your root password expires, then you are undone. These steps still work, but instead of changing the password, one will have to reset the expired account so you can login again.

With OpenSUSE, things are very easy. Select your favorite package manager (I tend to use which ever one comes up first!) and install the RPM for opie - under the group Productivity/Security.

Install the RPM, and all of the opie tools are available. Using opie to control your one-time passwords (OTP) has been discussed before, and nothing changes under OpenSUSE. However, installing OTP into PAM requires changing a different file (/etc/pam.d/common-auth). Add to the end of this file the following:

auth sufficient pam_opie.so use_first_pass

This should be enough to allow the use of OTP in most normal situations. The other directions are as they were presented in a previous blog post. Namely: use opiepasswd to create the initial key and password, and use opiekey to generate a list of upcoming OTP keys if desired.

Well, it turned out that installing OPIE went smoother once I figured out what was causing the RPM rebuild to fail.

I took the source RPM from OpenSUSE, and installed it onto the Fedora system:

rpm -ivh opie-2.4-630.src.rpm

This installs the files in their appropriate locations in the RPM build tree. In Red Hat distributions, this means /usr/src/redhat: the spec file goes into /usr/src/redhat/SPECS, and the sources and patches go into /usr/src/redhat/SOURCES.

Then I had to remove a line from the spec file (opie.spec) that read:

%debug_package

Otherwise, the Fedora RPM suite complained thusly when built using rpmbuild:

error: Package already exists: %package debuginfo

Building the binary RPM consists of:

rpmbuild /usr/src/redhat/SPECS/opie.spec

The RPMs will be created in RPMS/i386.

Installing the RPMs is then very straightforward:

rpm -Uvh opie-2.4-630.i386.rpm

These steps bring us to the point where we now have opie available (and installed as an RPM). The rest is configuring opie. In the file /etc/pam.d/system-auth, add a line under the line that mentions pam_unix.so:

auth sufficient pam_opie.so use_first_pass

This line adds support for one-time passwords during logins - including most all forms of logins. However, some login programs do not handle the extra output and requirements well. KDM (related to XDM) perhaps does not handle it the best: a message is put up, and then it goes away without any indication that the password request has changed.

In any case, to support a user with OTP requires initializing their OTP key. This is done with:

opiepasswd -c user

This initializes the password and OTP for the specified user. This command should only be used in a secure environment (such as over SSH or on the system console). It will ask for a new password to create (only needed for a few things, but important) and then generates your secret password (along with the sequence number and the seed). All three of these things will be needed when using OTP calculators. Remember that your secret password is just like any other normal password: that is, it must be kept secret. The sequence number and seed are not enough to get in, and the generated OTP are not enough either (though they should also be kept secret).

It is possible to generate a list of the next series of OTP passwords to use; for example:

$ opiekey -n 5 -5 499 my9999
Using the MD5 algorithm to compute response.
Reminder: Don’t use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
495: KAY TRY GLOM NOVA CALF KIM
496: OVAL JADE RUNT LATE MIT JAKE
497: MYRA COED LIND TO GREY FIG
498: NESS WAKE BLOC COAT GAIT ROWE
499: CLAW GAGE HOST MARK FAIN PAP

However, do not do this over an insecure line - such as from telnet, xterm, rsh, and so forth - as your secret pass phrase will be sent in the clear. Whenever using an OTP password calculator, make sure that your password is not seen by others, whether on the wire or in person: again, it is just like a regular password and should be treated as such. The generated passwords should also be kept secret; however, during use secrecy is not required. That’s because as soon as it is typed in, it is no longer valid.

Setting up OPIE (One-time Passwords In Everything) in OpenSUSE was easy: there is a opie RPM in the standard repository, and it installs cleanly and easily.  Then it is just a matter of initializing the database and modifying the PAM configuration to match.  Then each user is added to the database (/etc/opiekeys) one at a time.  I’ll describe the exact process on OpenSUSE at a later time.

Insufferingly, it appears that Fedora (and Red Hat) do not offer any form of one-time passwords anywhere - and certainly not OPIE.  RPMs for opie are exclusively for OpenSUSE and for the Polish PLD distribution (both of which seem to have everything).  How extremely frustrating!  This sounds like a good time to switch my home system from Fedora 5 to OpenSUSE 10.3.

OpenSUSE has supported LVM, XFS, KDE, and many other technologies when Red Hat staunchly refused to.  Even now, OpenSUSE support for all of these is much more integrated and time-tested than Red Hat’s.

Lest I sound like I hate Red Hat - I don’t - and that’s what makes it so frustrating.  Grrr….

The search for one-time passwords for HP-UX and for OpenVMS was even more fruitless.  HP-UX apparently has a third party skey package available; OpenVMS has nothing - though it could be added through programming the ACME interface (which provides similar capabilities to PAM - though perhaps not as flexible).

It looks like the BSDs aren’t a lot better: FreeBSD has OPIE built into the core (with a full section on OPIE in the FreeBSD Handbook on it); NetBSD and OpenBSD do not appear to have it (!).

Looks like my settling in to FreeBSD and OpenSUSE has paid off.  I don’t even need to suggest Debian - Debian has everything - and OPIE is no exception.  And of course, Ubuntu follows suit as well.

I’ve been trying out one-time passwords (OTP) - and they work well. Not as hard as I thought it would be. I found several resources as well. The incomparable Dru Lavigne described one-time passwords (under FreeBSD) quite well, then went on to describe setting up PAM for OTP. The directions are transferable to Linux and others. Michele Baldessari had a stupendous description on setting up OTP under Ubuntu - and taking advantage of a OTP password calculator built into Gnome Terminal (who knew?).

There are also OTP calculators for X, for Palm Pilots, for MacOS X, and cross-platform using Java (and even on mobile phones using Java). However, generating passwords is intensive, so slower platforms will not be helpful (such as older Pilots and most mobile phones). Generating multiple strings of passwords and storing them in a safe place is still a valid way to store passwords.

I’ll go into more detail later about how I set up OpenSUSE to use OTP (simple really).

The NSA is, of course, the United States National Security Agency. It’s their job to a) keep the nations computers secure; b) find out how to break everyone else’s (ah, the dichotomy of national intelligence!). Thus, some of the best computer security minds are at the NSA - it was the NSA that brought us SELinux (and still does!).

They also have a vast array of security guides available for download. These include guides on securing Solaris 8 and 9, MacOS X 10.3 and 10.4, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and more.

Use a security guide next time you secure a box - and not necessarily just one. Do some research. Implement all of the security you can on all of your boxes - even if it is not on the Internet. One day, someone might just crack through - then all of your internal systems will be at risk. Each system should be able to withstand an assault without falling.

Using a tiny, quiet, fanless personal computer has many benefits. My use scenario goes something like this:

Bring in the computer, plug into the network - turn on the computer and access the network. This necessitates Power over Ethernet (PoE) but we’re dreaming, right? It also doesn’t say anything about a keyboard and monitor and mouse - but hey, those are already taken care of, right?

This computer would be small enough to slide in a desk drawer, or under a desk, or hide in a bookcase. From this point, we can perform security analysis and penetration testing.

An alternate scenario might go like this:

Same computer but with wireless and battery operation: but now it is in our hands, in the data center. With a simple USB key attachment to a server, we are now accessing the server console over a wireless network link, with full access to the server and network.

There isn’t such a device yet - though some of the large PDAs like the Nokia 770 (and its successors, the Nokia N80o and the Nokia N810), the Sharp Zaurus, and others come close. However, PDAs are “embedded” devices which typically means: small size, battery power, limited memory, low power, limited secondary storage, and low speed CPU.

Small non-PDA computers tend to have massive “expansion” capabilities (that is, massive amounts of ports such as USB, Ethernet, Firewire, SVGA, and so forth). These computers tend to use the Mini-ITX form factor (Jeff Atwood has an excellent description of the various small to pico-sized form factors, including a relative size graph). Such a computer still tends to be less powerful than its desktop counterparts (especially if designed for a fanless environment), but remains much more powerful than the PDA-class machines currently available.

You can buy such machines premade, though they are not from the mainstream manufacturers normally:

• CappuccinoPC makes many, but may be best known for its Cappuccino PC (about the size of a CD player). However, they have a vast array of others as well.
• LinuTop sells a computer designed to run from a USB key (presumably, Linux-based)
• The Kuro Box is a cheap computer (under $200) without hard drive, and is closer to the embedded system than the others - and is non-Intel based (either ARM or PowerPC currently). TheKuro Box is actually made by Buffalo but is sold in the United States by Revogear.
• The fitPC is a low-power low cost computer in a book-sized unit.
• The retailer Directron seems to have a lot of micro-sized computer equipment.
• Stealth Computer Corporation has a wide range of tiny computers they call Little PCs.

Of special note is the site mini-itx.com which includes news about the Mini-ITX platform, a gallery of projects, a Mini-ITX FAQ, and a store to boot. The projects give you just a tiny idea of what can be done with such a small platform: you could embed it into a biscuit tin, or into an antique typewriter (an Underwood No. 5 - with working “keys”!), or into a teddy bear, or into a case made of Legos, or even into a Macintosh SE/30 case. There are dozens more - or you can create your own.

Of course, none of these tiny computers have monitors or keyboards or mice - all of which are big and require lots of space. There are a few alternatives:

• Use a wireless connection from the tiny computer to a small handheld computer (like the Nokia and Sharp models listed above)
• Use VNC on startup with a connection to a remote, listening, VNC client. This requires an advanced (or recent) server and client to use this special mode (connections are usually made from client to server, not the reverse).
• Use a reverse shell connection, connection a shell on the tiny computer to a listening port on a remote computer. This requires special handling: methods of creating a reverse shell are explained nicely in this article by Julius Plenz.
• Use a serial or wireless connection from the tiny computer to a laptop (but then you could use the laptop alone - or perhaps the laptop is older and slower…)

These are only some ideas; I’m sure that you can come up with your own. What could you do with a tiny but powerful computer with lots of ports and expansion?

This is not as far fetched as it sounds; every Macintosh OS X system comes configured in this way: it is impossible to log in as root.

How does one do things as root then? I shall reveal the secret…

First of all, one needs to make sure that the program sudo is available and correctly configured. It must be configured to allow you (or the system owner) to switch to root. Best to test this directly before doing anything to the root account.

Once you have verified that you can switch to root using sudo, then it is time to actually lock the root account. Before doing so, open a root shell using sudo or a direct log in as root. Then execute:

# passwd -l root

There! Now no one can log in as root - don’t you feel much better? Well…. you can become root (by using sudo) but logging in directly as root is impossible.

If passwd does not recognize the -l option, then just put an asterisk (*) into the password field, wherever it is. HP-UX, Linux, and Solaris all recognize the -l option; FreeBSD uses the -l option for a different purpose.

For FreeBSD (and quite probably, OpenBSD and NetBSD as well), use the vipw command to lock out not only the root account, but the toor account as well. The toor account is identical to the root account (including userid) but allows user customization.

When combined with the wheel group, this will lock down your root account quite effectively. Just don’t stop there: remember to use multiple defenses. However, that’s a topic for another day.

Update: This is most useful in situations where a normal user will always have access (workstations come to mind).  If your normal users are authenticated via NIS, or Active Directory, or LDAP, don’t do this! If root logins are locked out, and none of the users can log in…….. then what?  Uh oh….

Many versions of UNIX do not support the wheel group at all. Hewlett-Packard’s HP-UX is one of these. The main focus and purpose of a wheel group can be summarized thus: Not everyone should be able to run the su command.

To accomplish this does not require a lot. First, the wheel group must be created. Add the group to the /etc/group file:

wheel:*:0:root,dgd

It is not necessarily required that the wheel group occupies userid 0 - but it is entirely appropriate. Don’t forget to add yourself (your normal userid) to this group. Next step is to check the su command:

# ls -ld `which su`
-r-sr-xr-x 1 root bin 19588 Mar 20 2005 /usr/bin/su

Note that this binary is suid; this must be preserved in order for su to work properly. However, the permissions and group ownership must change in order for the wheel group to work properly. Two things must be changed:

1. World permissions (”other”) must be revoked
2. Wheel group members must be able to execute this command

These requirements can be satisfied in this manner:

# chmod 4550 `which su`
# chown root:wheel `which su`

This is only the beginning - but satisfies the initial requirements. The rest is optional, but makes things easier for the administrators in the wheel group. In particular, change the permissions on log files to allow those that are members of the wheel group to read them without having to use switch to root.