Response: A Good Security Design for an Office

9 Nov 2006

Russel Coker recently posted an article to his blog titled, “A Good Security Design for an Office“. It’s a very good read. There’s nothing earth-shattering in there, but plenty of gems that most people either forget about or never figure out.

There are a couple of things that I wanted to comment on (there is a lot of excellent information here, so read on):

The most obvious threat model is theft of hard drives. The solution to this is to encrypt all data on the drives.

Encrypting your data storage is an excellent defense mechanism, however, it is not a silver bullet that will magically make you secure. Russel doesn’t suggest that it is, but in my experience, most people will begin to think that it is.

The first level of this is to simply encrypt the partitions used for data, support for this is available in Fedora Core 6 and has been in Debian for some time.

I hadn’t noticed (yet) that Fedora Core 6 had added support for encrypted partitions. I’ll have to look into that support when I install FC6 on my notebook (look for a later article on that adventure).

As many of you know from my series of articles on my work blog on setting up encrypted partition support for Fedora, I’ve been using encrypted partitions for a long time.

Also, Debian isn’t the only distribution to provide this support. SUSE has had it in their installer for at least 7 years.

The more difficult feature is encrypting the root filesystem, …

SUSE’s support for encrypting partitions even works for encrypting root at install time.

… encrypting root means that important system files such as /etc/shadow are encrypted. Also if the root filesystem is encrypted then an attacker can’t trivially subvert the system by replacing binaries.

Excellent points.

Once the data is encrypted on disk the next thing you want to do is to make the machines as secure as possible. This means keeping up to date with security patches even on internal networks. I think that a viable attack method is to install a small VIA based system in the switch cabinet (no-one looks for new equipment appearing without explanation) that sniffs an internal (and therefore trusted) network and proxies it to a public network.

This can work so well because people still employ the crustacean model of security; a hard outer shell (border firewall) with soft, gooey innards (the internal environment).

The big problem with the crustacean security model is that firewalls have holes in them. They have to or else they would be useless. Also, the firewall only protects from things traveling through that particular piece of wire. So, if someone is on the inside, the firewall does nothing to them.

This isn’t just an issue of securing applications, it also means avoiding insecure protocols such as NFS and AoE for data that is important for your secrecy or system integrity.

When talking about insecure protocols, my first targets are usually things like FTP, Telnet & the “r-tools” (rsh, rlogin, etc.). But I’m glad that Russel chose to talk about NFS & AoE:

An option for using NFS is to encrypt it with IPSEC or similar technology.

This is a good option. IPSec (see also RFC2401) is very useful for a lot of places.

Another option that carries a larger number of benefits is to set up Kerberos on your network and use NFS v4 (see RFC3530 for all the gory details). Kerberized NFS is only supported in Linux for NFS v4. When Kerberized, not only is authentication for NFS operations protected, but everything going over NFS can be encrypted.

AoE can be encrypted with cryptsetup in the same way as you encrypt hard drive partitions, it doesn’t use IP so IPSEC won’t work but it is a regular block device so anything that encrypts block devices will work. I have been wondering about how well replay attacks might work on an encrypted AoE or iSCSI device.

AoE and iSCSI are both in the same boat, here. Neither protocol provides security mechanisms, which is a good thing. If they did, the additional overhead would affect their performance.

Russel has the solution exactly right, here: AoE and iSCSI devices are just block devices and can be utilized (including encryption) just like any block device.

Another important thing to do to secure your AoE and iSCSI systems is to isolate them onto their own dedicated networks, without interconnections to other networks. In other words, separate your storage networks from your communications networks. The main reason to do this is so that all of the available bandwidth is dedicated just to the AoE or iSCSI operations, but the security benefit is very important, too.

Security technologies such as SE Linux are good to have as well.

Probably more than 90% of the “solutions” found around the web for problems even remotely relating to SELinux, are to completely disable SELinux on your systems. It always goes something like, “In my opinion, SELinux is much more trouble than it’s worth, especially since it provides almost zero security benefit, so just turn it off. I do that first thing when I install [whatever].” This is so wrong!

The main benefits of SELinux come into play once someone breaks into a system. The observant reader may note that I said, “when,” not, “if.” With SELinux, even if they manage to get root access, they will still be limited to the bare minimum needed to allow the service they compromised to function normally and will be completely cut off from the rest of the system with no way out.

SELinux is an intimidating topic. I tell people that it looks much more complex than it really is. Once you wrap your brain around the basic concepts, it’s really quite easy to manage. Even if you don’t bother to learn how to write policy, troubleshooting and fixing 99.9% of the problems that actually occur with SELinux is very easy.

So, don’t turn it off. If you don’t know how to troubleshoot it, ask. Your local LUG mailling list should have plenty of people on it who can help you.

Prevent access to some hardware that you don’t need.

Great advice. Russel goes into some detail on this point in the article. I would recommend that you read it.

One thing that a commentor to Russel’s post mentions is the PAM module. I’ve known about this module for some time and have even toyed with it a bit.

I’m not currently using, but I want to be. It’s quite simple to use. I simply haven’t found the time to sit down and get it working with the various distributions that I have installed on my notebook. Sigh. Hopefully, I’ll get it done, soon. Maybe after I install FC6 on here.

Security monitoring systems are a good idea, unfortunately they can be extremely expensive.

Yes, they are and excellent idea and can be quite expensive. But, if you do a little shopping around and are a bit creative, you can put together a good monitoring solution on even a meager budget. I can recommend taking a look at Norther Video Systems for a great range of gear.

Don’t forget, though, monitoring systems do not only have to be comprised of audio/video systems. There are many other useful sensors available, too.

There has already been at least one recorded case of a webcam being used to catch a burglar. I believe that this has a lot of potential.

I agree, webcams have great potential to supplement physical security monitoring. In addition, they can be quite inexpensive while still providing acceptable quality. For example, I was at CompUSA just the other day and walked past the “webcam” aisle. There were several small, compact notebook models ranging from US$25 – US$99 each. Just remember, the hard part will be wire lengths with USB cables. powered hubs can help with that, though.

In conclusion:

  • Use the tools available (encryption, firewalls, PAM, IDS, etc.)
  • Never forget about physical security
  • It’s all about risk management
  • Even on a budget, there are simple things that can help out a lot

    So, give it some thought. If you’re not sure what to do or how to do, find a good, security-conscious person to help you out, hire a real security expert (I can recommend BT Counterpane).



Leave a comment

You can use these tags : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>