Security

Anti-Virus Options for OS X

I'll give you the executive summary ("TL;DR") version right up front: the world of anti-malware products for OS X is pretty awful.

Most products are re-cycled from their Windows counterparts and don't feel like something made for OS X. Many products destabilize the OS or have a heavy impact on CPU. Worst, many have vulnerabilities themselves, making you feel secure for having installed them, but in reality making you less secure.

Then, there's just plain foolishness. While evaluating the state of current A/V for OS X, I tried to get a trial of Symantec Endpoint Protection for Mac. After spending time on the website, and figuring I was just missing how to download it, I chatted with a sales rep. No, he assured me, I wasn't just missing it: there is no trial for the Mac. "Can't be," I thought.

The good news: there is a Mac client.

The bad news: you need to download the Windows version of the product, which weighs in at 1GB. It's a Windows .exe executable file. Or is it?

The Windows app is really a 7zip executable, so you can unpack it with The Unarchiver on your mac. This reveals a "Symantec_Endpoint_Protection_12.1.2_Part1_Trialware_EN" folder. Inside that archive at the path SEPM/Packages/, you'll find SEP_Mac.dat. Rename it to SEC_Mac.zip and again use The Unarchiver to unpack this and you'll get a new folder with the installer.

Why the obscurity?

Possibly the worst part of the whole experience? Symantec recommends that you use their Java-based download manager to download the file. Yeah, Symantec is truly concerned about security.

Updated[2]: For Security's Sake: Remove Diginotar CA Certificate

*
Apple has released a security update for Snow Leopard and Lion that addresses this issue:

Snow Leopard: http://support.apple.com/kb/DL1446
Lion: http://support.apple.com/kb/DL1447

There is no update for Leopard, so, in that case, you should still follow the instructions below.

Apple's update simply drops these files into place (on Lion):

/System/Library/Keychains/EVRoots.plist
/System/Library/Keychains/SystemRootCertificates.keychain
/System/Library/Keychains/SystemTrustSettings.plist

So, no matter which updates you made to the Diginotar cert -- delete or untrust -- the Apple update will just plow over all of that with the right setting and updated certs.
*

While ignoring how broken the entire Certificate Authority (CA) model is, here's what you should do right now: Delete the CA cert for Diginotar from your system. Why?

http://www.computerweekly.com/Articles/2011/08/30/247730/Microsoft-warns...

Now, if you're an individual, this is simple: just remove it from your system. Since I largely focus on Macs here, that would be in the keychain. Open Keychain Access.app, search for "Diginotar" and delete the resulting certificate.

...and don't forget Firefox, which keeps its own list of CAs:

http://support.mozilla.com/en-US/kb/deleting-diginotar-ca-cert

But, what if you're a Sys Admin responsible for protecting a fleet of machines and you don't expect end-users to do this themselves? (Or, that you're going to personally visit each machine.) Automate it, of course! The security binary will help you do that:

sudo /usr/bin/security delete-certificate -Z C060ED44CBD881BD0EF86C0BA287DDCF8167478C /System/Library/Keychains/SystemRootCertificates.keychain

(You can first check for the existence of the certificate using security's find-certificate instruction.)

Of course, you're using a system management framework that will allow you to run this command on all the machines in your fleet, right?

Update: This turns out to be a little more complex than simply removing the certificate. While removing the Diginotar cert is still recommended, DigiNotar is cross signed by other CAs. Removing the Diginotar root only removes one of them (and there are 5 paths). Also, it seems that there are some bugs in Apple's certificate handling in some cases. So, what can we do?

Certainly, remove the Diginotar cert from your machines, as that does help the most egregious cases. From there, we have two options: Use FireFox 6.0.1, which uses its own root certificate store and is now protected against this. Secondly, we need to wait for a patch from Apple--the only one in a position to really address this. Only a patch from Apple can completely fix browsers and apps that rely on the system store, Safari, of course, being the biggest use case, with Chrome and Mail.app as two other Webkit-based apps that may rely on the system root store for certificate handling.

(Big thanks to Harald Wagener for review on this, and reminding me about using find-certificate.)

Help Barracuda Defend Good Sense!

Thank goodness for good sense! The US Patent system is unfortunately broken, handing out patents in this digital age that make little sense, and show little understanding modern technology. Barracuda, as a company, is trying to stop Trend Micro, a patent troll.

Trend was granted a patent that covers scanning files that pass through a proxy. Huh?

Help Barracuda show prior art. Story here:

Linux World

The "Air Gap"

In the security and networking field, an "air gap" means that two systems are totally separated - no network connection runs between them. So, no pun intended, how could the new Boeing Dreamliner 787 not have an air gap between the flight system and the passenger "browse-the-web" system? That's insane. Literally, if you define "insane" as being out of touch with reality. Who came up with this, and who approved it?

The sad thing is that there are more good ways to handle this than bad ways, and someone chose a bad way.

More About OS X 10.5 Leopard Kerberos

A little more about Kerberos in 10.5: Interestingly, now in Leopard, each and every 10.5 machine is a Kerberos server. In some ways, very cool. Kerberos on its own is a pretty big topic. My fear is that while it's operating as expected, it's going to catch some people by surprise.

OS X and Kerberos

OS X Server has used Kerberos as a single sign-on technology for some time now.  It's rare, though, to find a Kerberos server on a workstation, but that's precisely what you'll find on each and every OS X v10.5 workstation.  Single sign-on with no infrastructure.  Very, very cool.  However, it's not really documented very well.  Apple just put this kb article on-line, though:

http://docs.info.apple.com/article.html?artnum=306723

Here's hoping to further implementation details!

Ugh...Another Mac "Security Issue"

C'mon.....really!  After talking about sensationalism recently, Intego comes up with this winner today:

http://www.intego.com/news/ism0705.asp

Leopard Security Sensationalism

So, out of the gate, there have been a number of people talking and blogging about security in Leopard from a number of perspectives.  Some, though, are just looking for attention.  Take the two posts at "Internet Security for Your Mac" warning that people stay away from the new "Back to My Mac" feature:

SonicWall OpenDirectory User Authentication

I answered a message on the OS X Server Administrator's list regarding how to set up a SonicWall Pro Series appliance to authenticate users against OpenDirectory. I promptly started receiving more questions directly from people trying to accomplish the same thing. Since not all lists are attachment-friendly, here are snapshots of the settings I'm using in one case. Please note that a) this could be more secure, and b) I've redacted where necessary.

Learning From Your Mistakes

Data theft should bother everyone.  It has happened way too much recently, and for all of the wrong reasons: employee takes data on laptop and leaves it in car, missing unencrypted backup tapes, lax policy on verification, etc.  One of the biggest cases was Choicepoint, after which, I had serious doubts about their future.  Well, it's always nice to see people learn from their mistakes:

Choicepoint's Lessons Learned

Syndicate content