Enforcing firewall in OS X

May 24, 2013 12:24 PM

How can I enforce a firewall -- built-in or 3rd-party -- in OS X, such that even someone with an admin account can't disable it?

We're currently doing PCI compliance, and one of the requirements is that mobile devices that have access to systems involved in processing card data have personal firewall software installed which can't be disabled by the person using the computer.

The only mobile computers we have which that requirement applies to belong to our system administrators, and they're all MBPs running ML. Since they're sysadmins, they've got admin access to their Mac.

I've had a couple of endpoint protection vendors promise me a solution only to fall through when we tried it out (in particular, Symantec), and now I'm stuck.

Does anyone know of something that will meet this requirement in OS X?

posted by mendel to Computers & Internet (16 answers total)

Have them log on with non-Admin credentials while using the computers for the bulk of their work, only logging into the Admin accounts when necessary?
posted by deezil at 12:34 PM on May 24, 2013

Best answer: The problem is that no such software exists for Mac OS X, Windows, or any other COTS platform. Absent very exotic hardware, it is not possible to install software on a computer which can't be disabled by someone who has both unlimited administrative access as well as physical control of the hardware.

I've seen PCI compliant shops deal with this issue in a number of different ways — it's hard to suggest a solution that would work for your organization with knowing a lot more about your setup. One solution I've seen is simply forbidding bringing portable devices in or out of the secure server room. Instead, a small pool of debugging laptops are permanently assigned to the secure server room. System administrators only have user access to these laptops. These laptops are themselves administered by someone who does not have administrative access to the PCI compliant systems.
posted by RichardP at 12:49 PM on May 24, 2013 [3 favorites]

Best answer: Agreed. If the user shouldn't be able to modify the firewall settings, then they need to be a non-admin user. That's essentially what admin users are for: being able to mess with possibly-dangerous system settings. (They aren't root in the Unix sense but they are root-equivalent in a security sense.)
posted by hattifattener at 12:50 PM on May 24, 2013

Yeah, none that I can think of. As the maxim goes: Physical access is root access. On any Mac, with the OS disk or just a bootable thumb drive, they can do literally whatever they want (other than reading other users' encrypted files, like Keychain): format the whole damn thing, change anyone's password.
posted by supercres at 1:01 PM on May 24, 2013

Best answer: Talk to your QSA about acceptable compensating controls -- those folks need to approve it anyway, and they've seen it before. That said, your goal in life should be to reduce the scope of what is touching PCI data as much as possible. This lowers your compliance costs.

Personally, I'd tell the sysadmins that when they're working on PCI, they're working from a windows laptop. Macs, quite frankly, are not suitable for enterprise environments that have compliance concerns.
posted by bfranklin at 1:05 PM on May 24, 2013

supercres: "Yeah, none that I can think of. As the maxim goes: Physical access is root access. On any Mac, with the OS disk or just a bootable thumb drive, they can do literally whatever they want (other than reading other users' encrypted files, like Keychain): format the whole damn thing, change anyone's password."

Don't intend to derail, just need a quick clarification: I thought an EFI firmware password prevented OS install disk/ USB boot thumb drive hacks? Especially since post-2010 Macs are no longer susceptible to the pulled RAM/ reset the PRAM hack?
posted by bluecore at 1:20 PM on May 24, 2013

Oh, you're right. I always forget about the EFI password. Good thing I don't need to handle securing these things.
posted by supercres at 1:39 PM on May 24, 2013

I'm just brainstorming here but I wonder if there isn't some way to log on with root access (different from admin access - google it up) and then put the firewall application(s) in a folder that is only changable from the root account??? ( or accessible from root and system??)

Again - just a brainstorm but perhaps someone better versed in UNix permissions can chime in n the feasibility.
posted by Podkayne of Pasadena at 1:53 PM on May 24, 2013

Response by poster: I've been heading towards the same conclusion. Rats.

Unfortunately, I can't avoid having remote workers -- we're a 24/7 operation, online, and so whoever's on-call needs to be able to administer systems in the card data environment from home. Luckily it's just a handful of people.

(Plan B, at this point, is to provide locked-down Windows laptops which then connect to an OS X terminal server.)

It even seems like GPO is not going to be enough to enforce this even on Windows. But since the personal firewall requirement only replies to employee-owned (no thanks!) and mobile systems, a locked-down laptop outside our perimeter and a chewy center less-restricted "terminal server" inside will at least be a solution.
posted by mendel at 2:15 PM on May 24, 2013

That solution might work, although there is no particular requirement that your remote access client devices (i.e. locked-down mobile laptops running a personal firewall) have to be Windows laptops (particularly if you already own Mac laptops that your sysadmins prefer). Of course, whoever is auditing your security setup may be more familiar with the steps required to lock-down Windows, so it may be easier to win their approval if you use Windows laptops.
posted by RichardP at 2:45 PM on May 24, 2013

Best answer: Since they're sysadmins, they've got admin access to their Mac.

Does this actually have to be the case? Can't they have non-admin accounts that have a lot of access? The idea of saying "They have root but they're denied access to something" is basically gibberish, from a traditional unix account-permissions perspective.
posted by Tomorrowful at 3:08 PM on May 24, 2013

Is your QSA the one telling you to hunt this snipe?

If your sysadmin users are logging in to in-scope systems to do their daily work with an administrative account, that's a problem anyway. Tell them not to do that, and give them separate administrative accounts, and have them elevate privileges as necessary to perform administrative tasks.

Once you've squashed that, if your QSA keeps insisting, push back hard. You cannot prevent an administrator from doing an administrative thing.

It sounds, too, like your scoping has gone poorly, but that's another bucket of hurt.
posted by TheNewWazoo at 3:49 PM on May 24, 2013

Yes, I agree that having regular access to sensitive data is not a good security plan. There should be, at a minimum, some kind of privilege escalation, or better yet, some kind of remote console or kvm-over-ip solution for getting into secured systems while on the LAN. And some kind of air gap for remote access.

There *should* be a way to roll your own admin privileges without simply saying Joe User = root. What access do the admins need on their workstation laptops that a regular user doesn't have? Once the machines are set up, there should be no reason for them to sudo anything. Give them the specific rights they need without giving them full root. You can do something like making them a member of a certain group, and then change the machine's root password to something they don't know.

Also, and god help you if you can figure it out, there is SELinux. I don't know if it is ported to OS X or not, but it should give you the necessary tools. I believe there is a way to configure it to only be configurable by root itself, not via sudo.
posted by gjc at 4:53 PM on May 24, 2013

Response by poster: The scoping situation for systems on our LAN is actually pretty good. It's mildly complicated because a sizeable portion of our entire product does credit card processing (I probably didn't mention we're a level 1 service provider, did I? Well, we're a level 1 service provider) but we've got all of our desktops and mobile devices, with the exception of production sysadmins' workstations, out of scope.

Since we're a service provider and so much of our product is directly in-scope, it's not uncommon for my sysadmins to spend entire days working on nothing but in-scope systems, so their comfort is a priority!

And the sysadmin workstations in the office are straightforward. The only complication I have now is that my sysadmins occasionally have to reach systems in the CDE while on-call so I had to figure out what to do about requirement 1.4, but realizing that "admin access on everyday-work workstation" and "admin access on on-call laptop" are not the same thing and that I can solve this by sending people home with a computer that our desktop support people, but not sysadmins, maintain.
posted by mendel at 6:43 PM on May 24, 2013

There's still a difference between admin access to the local machine and admin access to the remote machine. Admin access to the local machine is not required, usually. You log in as jdoe, and then you ssh into the in-scope server as jdoe, and then you sudo everything, or su into jdoe-admin on the remote server. In all cases, transmitting logs to a remote system can be a mitigating control.
posted by TheNewWazoo at 8:27 PM on May 24, 2013

One thing I used to do in my old sysadmin days and was recommended to me by a old school wizard is use Tripwire with change logs written to a printer that was not physically accessible to all staff (including some admins and other IT staff). The paper trail the printer leaves is a hard copy of server changes that Tripwire logs. Someone malicious would have to have physical access to both the server and the printer's output — and even finding the printed record destroyed is quick evidence of a security problem. It isn't foolproof — nothing is — but when designed properly, this kind of procedure (separating administration from reporting) can make auditing and security requirements easier to meet.
posted by Blazecock Pileon at 11:49 PM on May 24, 2013