In an effort to spare others the pain that I’ve gone through in the past week, here are some helpful pointers for avoiding giving an attacker an “easy” way in to your systems.

Don’t assume that because you lock down your network traffic at the firewall that you can avoid any of these issues.

0. I originally thought I didn’t have to mention this, but you’re already not allowing any unencrypted login access to the system, right? No telnet, no rsh/rexec/rlogin, no unsecured IMAP/POP3? You’re sure? You’d better be sure.

1. Whatever you do, block X11 traffic everywhere you can.  At the border.  On the individual hosts.  At any intermediary routers.  If you’re running a thin-client lab and the host server is on a different subnet, make an exception.  Otherwise, shut it the hell down. When a remote X app is needed, it can be tunneled by SSH.

2. Don’t automatically enable ForwardX11 or ForwardX11Trusted in SSH.  If you connect to a compromised host, you could very well be doomed.  It’s not that hard to toss an -X or -Y onto the command line when you really _do_ need to fire up a remote X app.

3. Never, ever, under any circumstances, allow root logins via ssh.  PermitRootLogin no is your sshd friend.  If you absolutely must allow root to log in, choose between without-password (only public key authentication) or forced-commands-only (which will only allow you to run commands and not get an actual shell, again by public-key authentication only.)

4. Never, ever, under any circumstances, use the same administrator/root password on more than one machine.  If you’re using LDAP or NIS, exclude all privileged users from your directory.  This does mean you need to keep a store of these passwords somewhere, if you have a lot of them. I’d suggest gpg-encrypting them onto a USB stick on a trusted host. We’re looking at PDAs that will allow us to lock/encrypt data on them, too (more useful). Change the root passwords periodically. A tool like apg (A Password Generator) is your bestest friend. I run it like:

   apg -n 10 -m 8 -x 8 -t -a0 -MNCl

   This will generate ten pronounceable eight-character passwords that will include at least one numeric, one capital letter and lowercase letters. Some people really want to have non-alpha-numeric characters in passwords, too. For that, just change the -MNCl to -MNClS and be happy with symbols.

5. On any machine that’s not meant for general use, disallow all but the absolute necessary logins (i.e., only admin staff).  On top of that, disallow SSH password authentication, and force all your staff to use public-key authentication.  Ensure that staff have workstations that have workstation-local home directories, to prevent the private keys from leaking out to insecure hosts.  This way, even if a password gets cracked, an attacker still can’t easily log in to these locked-down hosts without brute-forcing an SSH DSA private key.

6. Consider a career other than Systems Administration.

Apple’s Boot Camp has been creating quite a flurry of online activity. Honestly, far more than it is probably worth, but since, hey, this is Apple allowing you to run Windows on a Macintosh, it’s easy to understand why everyone’s panties are in a twist.

In between dealing with the multitudinous wildfires we have at work, which I’m still not really wanting to talk about, I manage to surface for a few minutes each day to try, in vain, to catch up on my email and RSS subscriptions. With so much buzz about Boot Camp, I was waiting to hear from John Gruber, given his very well-formed thoughts, reasoning and opinions on matters. I didn’t have to wait long, as he’s just posted an article with his thoughts on Boot Camp.

Reading through, I found something I simply had to quote here:

Right now, it’s a dual-boot situation, which is obviously less than ideal. It’s not hard to imagine, though, that the version of Boot Camp Apple is building into the upcoming Mac OS X 10.5 (a.k.a. Leopard) will be a concurrent virtualization tool — i.e. that Windows (and perhaps any other PC OS) could be hosted within a running Mac OS X session, obviating the rather annoying need to reboot to switch between OSes.

Mac OS X as a host to multiple guest virtualized systems leveraging the hardware virtualization capabilities of the Intel Core CPUs, running guest operating systems at near to full hardware speeds. All running without having to sacrifice a working, productive session in Mac OS X just to run an app or session in another OS. From the very day of the announcement of the Intel switch by Apple last year, I have been fervently hoping for this as a capability, and if I tune my Reality Distortion Field Detector just so, I think I can hear Jobs saying that it’ll be true.

As someone that lives in several OS environments for a living (Mac OS X, Linux, Windows XP), such an announcement would pretty much seal the fact that I’m buying Apple for my personal systems pretty much forever. I drool in anticipation.

What do you think?

I learned, via a mailing list I’m on about Apple’s “BootCamp”.

As a friend of mine said:

“Apple introduces huge security hole to Intel-based Macs.”
I can’t wait for the trojan that modifies the Mac OS partition from Windows to run things as root.

Indeed.

Laziness extends to authentication and authorization systems, too. At my last job, we started out with five or so primary systems that people needed access two, and a bunch of supporting systems that nobody logged into directly. It was, at the time, no big deal to go ahead and create an account for someone on those five or so machines. That changed over the course of a year or so, when we suddently had 20, 30 and then more systems people needed to use, depending on what they were doing. Had we the foresight, we would have set up something back in the early days to centralize the management and control of user and group accounts. Where I am now, there’s at least NIS to tie everything together. It’s not the most robust technology for a network, but it does the job and will keep doing the job until we get around to LDAP.

LDAP, though, is truly the “bee’s knees”, as all the cool kids are saying these days. (I would call it the cat’s pajamas, but I did that and all the student workers looked at me like I had three heads. Cerberus, or Kerberos, depending on who you ask and whether or not you’re at MIT, has three heads, but that’s another article.) Right off the bat, LDAP offers some important things over NIS that make me positively giddy in anticipation.

First, given appropriate access rights, you can update an LDAP master from anywhere, over the network, securely. This means we can divorce our user creation tools from the “master” server and run them, well, anywhere. This means we no longer have to run them as root. This means we don’t have to have people log on to our master server directly (which is a security risk) to maintain user accounts. We can make a web-based tool if we really wanted to (and I think we do.)

Second, we can restrict it on both the servers and the clients so that LDAP connections only ever go over SSL links. This is, in and of itself, enough of a reason to move to LDAP over NIS in our security-concious world, and I’d be lying if I said it wasn’t at least part of our reason for moving to it.

Third, we can enforce unix “shadow” password expiration policies. I can’t find a way to do this in NIS, though it may be as simple as creating a “shadow” NIS map.

So, you can think of it being the perfect Lazy solution. With a bit of work, you can drastically reduce your workload while, at the same time, helping out your security situation a bit. Hell, I’ll take that any day!

I think, sometimes, that the truth is quite funny. Take, for instance, the goal of every systems administrator I have ever known (including myself): do nothing. Seriously. For sysadmins, a good day is a day when we get to do absolutely nothing but catch up on personal email, read our favorite magazines and web sites, play some foosball or pinball or even a little ping pong, have a beer or two at lunch out at the pub with some friends, and go home feeling like you didn’t really do anything, and feeling happy about it. It is this vision of the perfect day that drives us to pursue all manner of projects in hopes that we can someday get to have slow days every day.

The other day, I complained about one of the tools we lazy sysadmins use when we have more than, oh, say, three systems to maintain: cfengine. At my last job, we had something like 45 systems, and I was wishing we could get just enough time to put cfengine into place. Where I work now, we manage something north of 40 systems (various flavors of Linux and some Solaris) and I had the fortune of walking into a working cfengine deployment. Hooray, someone else did the hard part! Having had the joy of using cfengine for managing large numbers of systems, I never want to go without it again. It’s an amazing and efficient tool for rapidly and easily distributing all manner of configurations across a huge number of systems. It can also, at times, be an amazing and efficient tool for rapidly and easily distributing all manner of broken configurations across a huge number of systems, but that’s a story for another day.

Another tool we’re using extensively is RedHat’s kickstart. Taken from the much more capable Jumpstart from Sun, kickstart is, really, enough to get a system off the ground and mostly configured for what you want. There’s a bit of work we need to do on our kickstart server yet, and our tools for generating new kickstart configurations aren’t quite up to the quality we’d like, but all in all, it’s a serious time-saver. Instead of having to sit there and answer all the questions and configure a package set, we just boot the system off a CD, tell it to do a kickstart boot, and walk away. Depending on the system and what type of install we’re doing, the system will be ready, all on its own, in twenty minutes to an hour.

The real strengths, however, come into play when you combine the kickstarts with cfengine. In about an hour, not only do you have a new system install, but you’ve got it completely configured, along with optional software installs. How cool is that? Sure, coming up with a totally new configuration for a new class of machines can be a pain, but once that’s done, you can crank out as many of them as you want in very short order indeed. And, not only that, but you can then manage it from that point forward from your central infrastructure and ensure it’s a good citizen.

In case you couldn’t tell, I really like cfengine and kickstart. They make me happy, because they allow me (and my coworkers) to spend more time doing real productive work instead of playing box jockey. If you manage more than five machines or so, you owe it to yourself to check into cfengine. If you build machines more than once a month, you owe it to yourself to check into kickstart (or Jumpstart, if you’re a Sun Solaris shop.) Don’t cheat yourself out of valuable time.