MacSecure.com
A Mac Security Blog

Rich over at Securosis and some other folks have been working on a set of rules for the Leopard firewall (ipfw) that would be restrictive without breaking everything completely.  The ruleset has been tweaked extensively now and takes a lot of things into account.   I’ll be testing it out tonight, but it looks great so far.     I’ll see if I can import these rules via Waterroof — or if not, just drop them in by hand.   Note:  Certain values need to be customized to your own environment!  Don’t just drop these in and expect it to work 100% !

Part two (part one is here) of an expanding series where I’m providing an overview of some of the InfoSec tools that I use on a daily basis on my Mac. Down the line I’ll expand this series and write up each tool in more detail.

Nessus

Despite the controversy about Nessus going proprietary in 2005, it remains one of the gold standards for network vulnerability scanning. Installed as a server (nessusd) and a client (typically just called nessus), the client has options to control what hosts are scanned and what specific services and vulnerabilities it scans for. Some of the things Nessus can detect are services that have vulnerabilities, common misconfigurations, and default passwords — among about a thousand other things. As a note, Nessus has been known to break a services / tip over a server now and then. It’s not something you want to point at your production server during business hours! Tenable Network Security now owns Nessus and sells a commercial version and support.

SSH / SFTP

There’s not much to say — where there once was Telnet, now there’s SSH. I have SSH (previously via iTerm — no using the Leopard Terminal) sessions up just about 24×7 on my Mac, as well as my work Dell. From remote shell access, to tunneling through firewalls, to SFTP, and on and on. Wherever possible, it’s almost always advisable to run SSH instead of Telnet. I know some things have been written about it, but the Leopard Terminal seems good so far.

VNC

Originally developed at AT&T labs, the name “vnc” is really a number of things, including a server, a client, and even a protocol. VNC (Virtual Network Computing) was designed to allow a remote graphical desktop session without much overhead. VNC (the protocol) isn’t natively encrypted, but is commonly tunnelled over SSH. On the Mac you can run a VNC server for remotely controlling your Mac (from another Mac, a Windows PC, or even a Linux box). Some of the more common Mac VNC clients are: JollysFastVNC and Chicken of the VNC. I’d previously used CotVNC, but I’m now using JollysFastVNC most of the time.

Syslog Server and KiwiLog Viewer

One of the things that has a more limited use until you need is is a syslog server. All Unix servers, all Cisco network devices, your home Wi-Fi router, and even your Mac can send system logs to a syslog server — but wait, there’s more! Mac OS X Leopard has a syslog server included, that can receive logs from all of those other devices. My Wi-Fi router (as well as other devices) all send Syslog to one of my Macs. The Kiwi Log Viewer for Mac is a free utility that makes looking through syslog files much, much more convenient by color coding them, as well as allowing for easy searching.

Mac OS Disk Utility

While the Windows and Linux platforms have TrueCrypt for creating encrypted disks and volumes, the Mac port of TrueCrypt still seems to be a way off. For most uses however, it’s possible to use the Mac OS Disk Utility to create an encrypted, mountable volume without too much trouble. In Leopard, the Disk Utility has been upgraded to allow for 256-bit AES encryption, which is a little slower, but much more secure. For securing personal data, this method works well. What TrueCrypt does that doesn’t exist on the Mac yet is that when data is encrypted, it doesn’t create an ‘encrypted file’ that can be identified, therefore a casual user looking for your ’sensitive’ files wouldn’t ever know that your ’secret’ data existed.

I’m sure the 10.5.1 update (which just rolled out to Software Update today) will be dissected on all of the Mac forums and blogs, but in the Security section of the release notes, there are a few highlights that were noteworthy:

• The “Block All Incoming Connections” setting I talked about here has now been changed to read “Allow only essential services.”   Without having installed it yet, I believe that’s still going to mean ‘anything running as root, plus the MDNS and a few other things.’
• Another change to the Application Firewall related to code-signing and parental controls
• Patches for all of the recent security issues.

There are a few other things I’ll need to look at later tonight, but this is a start.   I’ll do some of the netcat testing again to verify the firewall change item.

Every blog has a ‘Top 10′ list of something — and I’m fairly sure that someone has probably even done a “Top xx Mac Security Tools” list, but I figured I’d go with the list of the tools that I use the most, and then as time permits, go through and write up something about using each tool in more detail.

Read the rest of this entry »

This is the last Leopard firewall post for a while…

Over the last week or two of Leopard firewall discussions across the web, quite a bit of info has come out about how the Leopard firewall works, and what’s going on ‘under the hood’ when you change the options under System Preferences.

The firewall used by OS X is ipfw, the FreeBSD sponsored open source firewall package. Contrary to the limited configuration options presented in the System Preferences Security section, ipfw is extremely configurable and sophisticated. Whole books could be written about configuring ipfw, but the man page for it is a good place to start.
Read the rest of this entry »

Apple posted documentation about the Application Firewall today which explains a lot of what many folks have been seeing.

I haven’t had much time to analyze it yet, but here’s the kicker:

Anything running as UID 0 will not be blocked, even when the Application Firewall is set to Block All Incoming Connections.     This explains why the netcat tests were working.   I’m not sure how I feel about that — should “Block all incoming connections” have an asterisk?

Mac side, from a Terminal:

• sudo su
• nc -l <port number>  (I used 1000)
• Ensure that your Leopard firewall settings are set to “Block all incoming connections” and “Enable Stealth Mode” (in the advanced settings)

From a remote machine:

•  nc <leopard ip> <port from above>

Connected!   If you don’t have netcat on a remote machine, you can simply telnet to the port as well.    I suspect that we’re probably taking the wording “Block all incoming connections” too literally.     More thoughts tomorrow.
The idea for this came from Jurgen’s comment on Securosis.

I spent quite a bit of time tonight testing the Leopard firewall from my local host as well as from a Linux host on my local LAN while running various configurations of Nmap and tweaking the various Leopard firewall configuration options. 

As I started to write it up, I found that I’ve been beaten to the punch.  I did quite a few of the same tests that Rich Mogull did, but based on comments posted by Jurgen Schmidt, the author of the original Heise article, I have done some further testing this evening. 

Jurgen is absolutely right.   Despite having the Leopard firewall configured for “Block all incoming connections” and having ’stealth mode’ enabled in the Advanced Configuration options - I was able to run other servers locally on the Mac (I used netcat as he suggested)  and they showed up locally in both netstat and Nmap scans, and they also showed up as open ports when attempting to contact the Mac from a remote system.   The remote side (Linux) Nmap showed the ports as open, not even filtered.I understand that there is some confusion / concern about how the ‘Application Specific’ access control works — but I would expect that when you say “Block all incoming connections” and “Enable Stealth Mode” that at the very least it wouldn’t leave some ports wide open.  

  PORT STATE SERVICE VERSION

1000/tcp open cadlock?

Ouch!

The Tipping Point / 3com funded Zero Day Initiative posted a whole batch of Quicktime vulnerabilities yesterday:

• ZDI-07-065
• ZDI-07-066
• ZDI-07-067
• ZDI-07-068

While all of them are interesting, the 65 and 68 items stand out to me as the less important ones, as exploitation of the issue requires that a user open a specific file. The more nefarious items in 66 and 67 can be exploited by simply visiting a malicious website that has specially crafted images.

These vulnerabilities are part of what prompted the upgrade to the new Quicktime 7.3 that was released on Monday, and Apple has an updated page with notes about each vulnerability as well as a number of other CVE’s that were outstanding. As of today, Apple doesn’t have any outstanding issues on the ZDI Upcoming Advisories list.

This fall has largely been about image rendering flaws — from iPhone jailbreaks to this, it’s been almost non-stop. ‘Tis the season!

Since it’s a common question, I figured I’d link some of the more common Configuration Guides for OS X hardening. These are some of the more ‘official’ ones — I’ll post a collection of personal and Blog-related ones some other time. Just a note: None of these are updated for Leopard, and some aren’t even current for Tiger, but a lot of the same ideas and procedures apply.

• NSA Security Configuration Guide - For 10.3
• Corsaire: Securing OSX - For 10.4
  
• Apple - Common Criteria Security Tools
  
• CIS Mac OS X Benchmark