UNIX Administratosphere

I’ve been seriously considering the fitPC for my own purposes. Currently, the DHCP server (ISC) and the web proxy (Squid) in my home network are two separate servers running versions of Red Hat or CentOS. Both are slimline computers, but otherwise are standard in their configuration: standard hard drives, standard motherboards, etc. I think it might be safe to assume that this also means standard power consumption (200-250 watts, I’m guessing).

Along with the wattage is the noise as well. With the two servers and two desktops running (and a rackmountable switch), that is a lot of fans and a lot of noise (more than non-techies would realize!).  That’s four computers with 200-250 watts each (high estimate) - for 800-1000 watts of power consumption.

This doesn’t even take into account what it would be like with the Sun SparcStation 20 or the UltraEnterprise 1 started up - I shudder to think how much power they take up (and I know how noisy they are….).

A 5-watt computer with no fan (silence!) would be very nice. The things that are most appealing about the 5-watt fitPC are the silence, the minimal power drain, and the standard configuration. Many computers that fall into this category are in fact, embedded systems - small memory, small flash drives, and so on - often with specialized software (even if it is open source).

The fitPC is a standard system, so it will run anything that will run on an Intel 586-based system.

The company is in Israel, and until recently was the only source for their product. They appear to have been overwhelmed with orders sometime in November, but are going as fast as they can.  I’ve no idea if they are backed up now or not. They’ve also introduced resellers apparently: System Industrie Electronic AG in Austria, Anders Electronics in the United Kingdom, and CompuLab Embedded Systems in the United States.  None of the resellers has the fitPC listed as available, but presumably if you contact the right people from their list, everything will be just fine.

They have a set of forums that are excellent, and serve as an excellent resource for purchasers and owners of fitPC systems.

One of the questions that comes up on the forums is: Does the fitPC work well with X where X is:

• FreeBSD (only if USB installation is fixed)
• FreeDOS (unanswered so far)
• CentOS (one successful report)
• Ubuntu Server (still trying)
• PCLinuxOS (just fine!)
• Windows 2003 Server (not too badly)

It comes with either Windows XP or Ubuntu (an optimized Gentoo is also available). The listed cost is $285 US.

Having programmed in COBOL, I can say its not so bad as people think it is - and it remains a powerful force in the business world.  Thousands of lines of COBOL are being used every day.  (Of course, no one ever says thousands of lines of COBOL are being developed every day, but that’s another kettle of fish….)

Having also worked in RPG, and in APL (slightly), I can say without reservation that COBOL is not so bad.  The worst that people can say is that it takes 300 pages to write a program that C can do in one line - and they’re right.  Oh, well - can’t win ‘em all eh?

Turns out that back in September, Fujitsu updated their three COBOL compilers: one for .Net, one for Windows, and one for UNIX (including Solaris Sparc!).  It also turns out that they have released (again) a previous version for personal educational use - and at no cost!  I caught wind of this via esotechnica.  It may well be that Fujitsu has provided the easiest way to get started in COBOL anywhere.

If I’d've had Fujitsu COBOL on Microsoft Windows XP (for instance) back during my COBOL class days, they’d probably have called it cheating (heh!).

If you want to stay with open source projects, you could always use tinyCOBOL, OpenCOBOL, or GNU COBOL… although I think GNU COBOL is dead (the project was to create a COBOL compiler front-end for GCC).  TinyCOBOL and OpenCOBOL appear to be quite active (I actually packaged the tinyCOBOL RPMs for a while).

Anybody ever use COBOL for system administration?  I doubt it - but who am I to say?  Maybe that important network manager is written in COBOL and we just don’t know it…

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.

The find command is a very demanding command, and can slow a system way down - and can take a long time as well. There are some ways to avoid these drawbacks.

First, when the urge strikes you to use find / -name "somename" - just don’t do it. This will take a very long time and will notably slow the system down. If you are using the GNU findutils, you may have the program locate on your system, which is much faster. Otherwise, you can use print the output from a find / command (run during off hours) and search the file with grep whenever you have a need to.

Secondly, you may wish to avoid using the -exec parameter. This parameter will run a command on each file that is found. Each time a file is found and printed, the find command loads this specified command, gives it the filename, and runs the command - which is very inefficient. GNU find has the ability to stack filenames together, but that still is not enough.

The most efficient way is to use xargs instead:

find . -mtime -1 | xargs ls -ld

This will combine all of the files together (as much as possible) and will run the binary image of the command as many times as necessary to handle it - without reloading the command at all. Of course, if you have GNU findutils, the builtin -ls option may be even faster!

find . -mtime -1 -ls

You can also manipulate where things go in the command output, or replicate items more than once, and so on. The operation of xargs is simple once you understand it, but the power is tremendous, and it is on all UNIX/Linux platforms. Check out the xargs(1) man page from OpenBSD.

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.

If you are willing to pitch in and help FreeBSD, why not donate to the FreeBSD Foundation? Of course, if you don’t want to help FreeBSD, there are other worthy causes that are close to open source and to free software:

• The OpenBSD Foundation - dedicated to funding the OpenBSD family of projects (such as OpenSSH, OpenBGPD, OpenNTPD…)
• The Free Software Foundation (FSF) - the creators of the GPL and funders of the GNU Project
• The Electronic Frontier Foundation (EFF) - dedicated to protecting freedoms in a digital age
• The Mozilla Foundation - the funding for Mozilla, Firefox, Thunderbird, Seamonkey, and more
• The Apache Software Foundation - the non-profit behind the Apache web server, Apache Tomcat, Apache Ant, Apache Cocoon, and more
• Computer Professionals for Social Responsibility (CPSR) - dedicated to promoting the responsible use of computer technology

With the notable exception of the OpenBSD Foundation, all of these groups should be classified as 501(c)(3) charitable organizations by the U.S. Internal Revenue Service. The OpenBSD Foundation is a Canadian non-profit, so that’s different.

Two that are struggling the most probably are the CPSR and the OpenBSD Foundation.  Both are small and not often in the limelight - even though OpenSSH is used by virtually every UNIX and Linux variant on the planet.

All of these are worthwhile - why not donate - or join today?  Perhaps your (US) employer might even match your donation to one of these 501(c)(3) charitable organizations.

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).