Monday, September 17, 2012

Hardening Mountain Lion

After spending some time installing Mountain Lion (OS X 10.8), from scratch rather than over my old Lion installation, the usual question arises: How to harden it?

Of course, I can't find my notes from hardening Lion back in the days. I guess I'll use the blog as an excuse to keep notes this time. Feel free to use my notes and reasoning as an inspiration or motivation, but keep in mind that everybody's risk profile differs. I may prefer paranoid settings over convenience and you don't, or vice versa.

Also, most certainly, my considerations below are incomplete. And for the most part, I'm assuming a single user (myself) and don't bother too much with defining password policies, etc.

The Obvious

There are some obvious security settings - those that you can find by clicking through the System Preferences options. Here are my thoughts on those:
  • Users & Groups
    • I set passwords for my users. I also use a non-admin user for my daily work. The OS X elevation mechanism seems to work just fine for installing software, etc., although non-admin users are not in /etc/sudoers by default. So I create a separate user that has "Allow user to administer this computer" enabled, and disable it from the one that I use on a daily basis. Or the other way around.
    • Strangely, it seems like the guest user came enabled by default. Disable it.
    • "Set Master Password" for encryption under Preferences (the little wheel below the user list). Probably not a bad idea if you are prone to forgetting your account passwords. Now you have one more to forget. ;-)
  • Desktop & Screen Saver
    • Mine starts after 20 minutes.
  • CDs & DVDs
    • I usually ignore them.
  • Bluetooth
    • Uncheck "Discoverable". Turn it off if you don't use it.
  • Sharing
    • I don't enable any sharing unless I specifically want to use it for something.
  • Software Update
    • Automatically check for updates.
  • Security and Privacy
    • General
      • "Allow applications downloaded from:" - This pertains to Apple's Gatekeeper functionality. Of course, there's (still) software out there I'd like to use that hasn't been officially signed, so I ended up choosing "Anywhere". But I am usually pretty aware of what I'm installing and where it comes from, and don't have other users using the laptop.
    • FileVault
      • I don't see a reason not to use this. Maybe a little performance hit? Ah well.
    • Firewall
      • Enable it. "Block all incoming connections" is always a tough call when you use the system in a hostile environment. I leave it unchecked, most of the time, and check the list of applications that have been added with individual settings every now and then.
      • Disable "Automatically allow signed software to receive incoming connections".
      • Check "Enable stealth mode".
    • Privacy
      • Personal preference, I suppose.
    • Advanced… (the button on the bottom)
      • I let it "Automatically update safe downloads list" and "Disable remote control infrared receivers" (don't have any). 

Existing hardening guidelines

It's a little early to expect that anybody has analyzed Mountain Lion to the extent that they can publish a comprehensive hardening guide. Apple has not published Security Configuration Guides or Common Criteria guidance material since Snow Leopard. Sadly, since they used to be well-written and useful. So, let's see what we can scavenge from the Snow Leopard Security Configuration Guide:
  • Setting an EFI (Extensible Firmware Interface) password to prevent unauthorized booting into single-user mode
  • you can use 'sudo visudo' to add non-admin accounts to /etc/sudoers (like the unprivileged one you are using for daily work)
  • pwpolicy lets you define a password policy
  • stripping suid bits from executables (pg. 151 ff.), I did it for the following (if anybody has taken the time to investigate what Apple has added since Snow Leopard that might be worthy of disabling, let me know :)):
    • /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
    • /bin/rcp
  • chmod 700 for users' home folders (supposedly breaks Apple file sharing and web sharing?)
  • block Bonjour advertisements, and use ipfw to block incoming Bonjour traffic
The University of Texas also has a nice compilation of useful tips: https://wikis.utexas.edu/display/ISO/Mac+OS+X+Server+Hardening+Checklist

Other things

I use a virus scanner, always have. I don't believe in the immunity of OS X from malware. I use eset.

OpenDNS is also a great idea.

Safari has additional security and privacy settings to consider, if you use it.

To-Do's

It might be worthwhile to reason about ipfw rules to further tighten down the OS X firewall. The Snow Leopard Security Configuration Guide contains instructions on how to do that. Similarly, going through the list of daemons and user agents on the system and determining which ones could be disabled should be interesting.

Saturday, August 11, 2012

Safer Internet Cafe Access for Your Email

I'm a big fan of one-time passwords for (email) accounts when I am traveling without my own laptop / tablet / smartphone. If you are in some part of the world perusing a computer in an Internet cafe to access your email account, there might be / likely is (depending on your level of paranoia) at least some sort of spyware or keyboard loggers hanging out on that PC, ready to steal your password when you type it in.

The next best thing is some sort of two-factor authentication. Many services offer this these days (Google, eBay, some OpenID providers, like Symantec's (ex-Verisign) Personal Identity Portal). Depending on one's needs, this doesn't even involve carrying a RSA SecurID token in your pocket. It could just be a soft token on your phone that generates time-sensitive codes. Logging into an account then typically requires your password (one factor) and something else. Something else involves a factor that is different in nature from the first one. The different categories include knowledge (like, your password), possession (a token that generates codes or holds a cryptographic key, for example), and a person's individual properties (such as fingerprints or the iris pattern of your eye). But I divert. Really, in my internet cafe scenario, two-factor authentication is just a means to an end. I care less about having two factors, and more about having any factor at all that cannot simply be recorded and reproduced without having my token or my biometric properties. The problem with this is that biometric authentication isn't ripe for use over the Internet, and that I don't necessarily want to drag an (electronic) token of some fashion on the trek with me.

So, one-time passwords. A list of passwords that can each only be used once, and can be carried around on a piece of paper. My mail host, Tuffmail, which I love for its reliability and geek factor, doesn't support any. My backup solution for accessing emails while traveling in remote parts of the world is forwarding my email to Gmail, and (mis-)using Gmail's two-factor authentication.

You should use Google's 2-step authentication anyway. (Enable it in the authentication settings.) With that comes a list of "Backup verification codes", 10 of them, that are - essentially - one-time passwords that can be used in lieu of the regular second authentication factor. (In other words: if you aren't carrying your phone with you or don't want to pay for receiving text messages abroad.) So, you've got ten logins to your Google account with your regular password and one of the backup verification codes each. If somebody intercepts a logon on a borrowed computer, they won't be able to re-use those credentials after you have logged out. Without the second factor, your password won't help them. (Make sure you uncheck the box that designates the current computer as a "trusted" computer when logging in. And change your regular Google password when you get home.)

Thursday, July 19, 2012

Securing Your Public WiFi Usage with pfSense IPsec Tunnels

Coffee shops, airports, and other public areas are dangerous places, as far as using their wireless Internet hotspots is concerned. This article is a mixture of both telling you about some of the philosophy I apply toward using public wireless networks, and providing some actual technical references for setting up the particular solution that I have implemented to address it. Pick whichever pieces you are interested in and skip through the rest of it.

Most of us have heard at least a little bit about the potential for random folks being hooked into the same WiFi network as ourselves at the coffee shop, and intercepting our devices' communication with the rest of the world. If the network sessions established by the individual apps and web browser on my laptop or smart phone are not properly secured, they might be able to read my email, intercept the password my banking app sends to my online bank, or make me think that I'm talking to the server I intended to reach while it's really the attacker on the couch across the room that I am handing my personal information to.

A prominent example of this is Firesheep, which was created in order to demonstrate how easy it is for someone else connected to the same WiFi network to hijack unprotected HTTP sessions between your web browser and, say, Facebook. Granted, many of the larger service providers have addressed this problem by now, but as an end-user you don't really know that every app you use implements proper encryption (and server authentication) technology. In particular when we are talking about mobile devices like my iPhone. Unless you are geeky enough to hook up a network sniffer and know how to figure it out on a technical level, you are dependent on the app developer doing the right thing, which doesn't always happen.

This is less of a problem for my network at home, where I likely have the local loop between my Internet Service Provider and my wireless router to myself, making it harder (but of course not impossible) for somebody to get into the middle of things. It's easier to sit in a coffee shop and fish for random network connections of interest, rather than getting close to my home and hooking into a "properly secured" wireless network or my DSL wires.

My remedy? I have a separate firewall device sitting between my DSL router and my home network. For one, it allows for more control of the network traffic that's happening between my home network and the Internet. But in the context of this article, it also allows me to set up VPN connections from my mobile devices (phone, table, laptop, ...) to the firewall, and from there not just into my home network (if I wanted), but also back into the Internet. The trick is to configure my mobile devices in a fashion that ensures that all traffic originating from the device is routed through the encrypted VPN tunnel to my firewall, and from there enters the spheres of the Internet. All that the attacker sitting in the coffee shop then gets to see is an encrypted connection between my device and my firewall, with no opportunity to get into the middle of it.
Purple connection can be intercepted by the bad guy. The blue one is encrypted by an IPsec tunnel to my firewall, and then forwarded from there (without the IPsec encryption) to the App / Web Servers. The bad guy can't read it.
Technically, this works for me as follows: A while ago, I came across the open source firewall software pfSense, based on the FreeBSD operating system. In order to install it, you need dedicated computer hardware, not just your WiFi or cable/DSL/whatever router. Fortunately, there is an extremely slick solution to this, if you are willing to invest about $200. ALIX systems are micro boards with AMD CPUs designed in Switzerland to run network devices, like wireless routers. I ordered mine from Mini-Box.com, which also sells aluminum enclosures for the boards. All you then need is a CF card (remember, those big cards used in early digital cameras?) to store your operating system on, which you can get from Amazon or the like.

My ALIX box, housing my pfSense firewall. CD-ROM for scale.
I'll spare us all the basics of setting up a pfSense firewall. There is plenty information out there on the Internet, and I have to admit that you should have a basic idea of what it is that I am talking about before you commit to setting up your own firewall. The remaining question that I had to piece together was how to set up a VPN server on the pfSense box that would forward all the traffic from my mobile devices (which, shockingly, are all Apple devices - an iPhone and iPad, and a MacBook Pro) to the firewall and from there to the Internet, and how to configure VPN clients on said mobile devices.

I chose to look at IPsec, one of several VPN technologies that pfSense supports, because there seems to be wide-spread, built-in support with many client operating systems. In particular, it appears that pfSense will work with Cisco IPsec clients, and everything that emulates such clients. There is a great how-to on the pfSense website, which includes both instructions for setting up an IPsec server on your pfSense firewall, and configuring the client side of things. What it doesn't tell you is that when defining the Phase 2 of the IPsec tunnel, you need to select "none" for the local network in order to force the client to route all traffic through the VPN server, and that you need to disable the advertising of available networks to clients. (Otherwise, the client will connect to the VPN server on the firewall, but will only route traffic to it that is destined for the local home network, rather than all traffic that is originating from the client.) At least those were the configuration settings that I was initially missing for success.

Now, whenever I'm using a wireless network that I don't trust (which are most of them ;-)), I'll use the native iOS or OS X client to establish an IPsec connection to my firewall at home, and can care a little less about who else is connected to the same hotspot. (Somebody should comment here on how to set up clients on other operating systems, like Windows and Android...)

Other side effects? Circumventing filtering mechanisms of whoever is controlling the part of the Internet that I'm currently connected to. As long as I can establish the VPN tunnel to my home firewall, all traffic channeled through it is (only) subject to the filtering that my home network is exposed to. Which, in the US, is to date rightfully not much.

There are, of course, some unknowns remaining. If my mobile device isn't protected properly against active attacks from the network I'm connected to, establishing a VPN tunnel won't help me with that. A personal firewall (on full-fledged devices) or faith (in case of mobile devices) may. And attackers can still get to me in other ways. And of course, if somebody is motivated enough to actually infiltrate more central parts of the Internet in order to get to my networking sessions, this won't help either. My IPsec tunnels are just addressing one particular risk out of many.