Basic Mac OS X Security

  • Security
  • Moderately Involved
February 16, 2006 - 4:44am

Well, now that we have a possible candidate for another Mac trojan (not a virus, not a worm, not an exploit, and not good code) I think now’s as good a time as any to cover some basic Mac OS X Security so that people not familiar with such things have more than an ice cube’s chance in Phoenix at keeping secure.

Mac OS X is a secure operating system in that it’s multi-user and has limits on what some user accounts can do. If an account is setup as a basic user, that user can only hurt himself, not the whole system or other users. However, in the interest of being “friendly” to new users, Apple leaves of a lot of the secure bits off for the first user created and this means that trojans like this week’s can cause some pretty nasty problems on your system.

Yet, all of this is easy to correct. Just run over the following and you should be well on your way to a protected computer.

Rule #1: The Administrator is Not for Daily Use

spacer

Contrary to what Apple does with the setup program, the administrator account is not viable for daily use. There are too many things this account can do that you don’t want a script to be able to, such as cleaning out /Applications or various folders within /Library.

Instead:

  • Go make another account in System Preferences
  • Make it an administrator
  • Login with the new account and remove administrator rights from your original account
  • Log back in with the original account

Now when you’re prompted to enter a password to do something stupid creative, use the admin account name. This has the added benefit that people that walk up to your computer can’t do bad things to the system, either (just your account, so keep reading).

Rule #2: System Preferences is Not for Daily Use

spacer

You can do some crazy stuff in System Preferences. Happily, Apple realized this and added some settings to protect the system from random idiots (driver or passengers). You’ll want to use these to lock System Preferences out to roaming users that happen to get a hold of your computer. Open System Preferences and go to the Security pane. Review the following as you make the changes.

  • Require password to wake this computer from sleep or screen saver: This does exactly what it says. If you put the computer to sleep or have a screen saver setup then you’ll be asked for your user account information to unlock the computer. Use this, especially on portables. Of course, a restart will make this go away, so …
  • Disable automatic login: This completely disables automatic login. Your system will startup to a login panel with a list of names. This is the most secure option because it doesn’t make the computer usable from a cold boot. If you know the system will log you in as a user with a restart, any security measure meant to prevent someone from having user-level access can be defeated with a reboot. Turn this on to prevent that.
  • Require password to unlock each secure system preference: Notice how a lot of preferences have that lock at the bottom (like Network, Security, and Accounts)? Turning this on locks all of those by default, requiring an admin password (even for the admin user) to unlock. If you don’t do this, anyone can come right back to this preference pane and turn all of these settings off. Check it.
  • Log out after __ minutes of inactivity: More annoying than useful to me, but if you tend to walk away from your computer and don’t mind losing your place in your work, turn this on. Locking the screensaver works well for me, instead.
  • Use secure virtual memory: Turn this on. If this is off, then any time you enter a password it’s possible the system will write that password out in a block of memory it’s dumped to a file in /var/vm and, thus, makes the password recoverable. Using secure VM means those files are encrypted and it’s near-impossible to discover a user’s password from the swap files.

Rule #3: Turn off Services You Do Not Use

Go to System Preferences, then Sharing. Uncheck everything you’re not using, even if you think you will. Turn it on when you need it and turn it off when you’re done.

Rule #4: Secure Secure Shell

By default, SSH allows SSH v1, listens on the default port, and allows anyone with an account remote access. Secure, my ass. Change the port and limit the users allowed to users that need it. In /etc/sshd_config change:

 – #Port 22
+ Port 2200

- #Protocol 2,1
+ Protocol 2

- #PermitRootLogin yes
+ PermitRootLogin no

That moves ssh to port 2200, prevents root from logging in remotely (presuming you set a password for root, which you should not), and forces the more secure v2 protocol without a fallback. The only change you’ll need to remember is to connect to your machine as follows, instead:

$ ssh -p 2200 myuser@myhost.local

Now, we need to restrict the users that can login (your other users will unlikely ever need to ssh in, including that admin you made previously).

AllowUsers codepoet

Now only I can login to my machines. Replace the username as appropriate, or make me an account and tell me your IP address. spacer

Update: As mentioned on CIPB the port change happens in /etc/services, not in /etc/sshd_config because launchd is starting sshd rather than it running as a daemon. Change /etc/services as follows:

- ssh 22/tcp
+ ssh 2200/tcp

Rule #5: Outbound Calls Only, Please (Firewall)

spacer
Some look at Apple’s firewall as useless because it automatically pinholes running services and doesn’t allow some users in while locking some users or or whatnot. It’s not a commercial-level firewall (GUI) but it does do something very well: it prevents ports opened by rootkits or trojans from being accessible. Turn on the firewall and unauthorized listeners will be blocked.

spacer
It also makes our SSH hack above useless by blocking 2200 by default. spacer Click on New and pick Other from the menu and add 2200 as an option and check it and any other services you want to offer.

Rule #6: Freeze the Credit Card (Keychain)

spacer
The Keychain is the most dangerous moment of brilliance I’ve ever seen. On one side, it knows your passwords to everything and lets you get away with being human while still being secure. On the other, it lets you get away with being human while being insecure. If you walk away, I can connect to just about any password-protected service you have access to and the computer will fill in the password for me.

Yet, it has controls (again, turned off by default) that let you get around this. In Keychain Access, go to Edit and then to Change Settings for Keychain. You can do two things here: set an idle timeout, or tell it to lock on sleep. I prefer just locking on sleep, myself, because I rather depend on the screensaver to do the idle locking for my systems. Sleep, however, especially for portable users, means that the person waking the computer may or may not be the owner, and that’s prime time to start asking for passwords. Until a password is entered you won’t be on IM, or checking mail, or whatever else. Programs that use passwords will be locked from getting new data.

If your keychain password is different from your account password then you have an even greater level of security as the screensaver password won’t work for the keychain, and vice-versa.

Rule #7: Make a Good Password

The best password I’ve ever seen was someone that memorized a Windows license key and moved the sections around. Almost pure randomness, but ordered enough to remember. There are easier ways, and things you already know. For instance, do you know your car’s license plate? Know the plates of previous cars? Combine them in a memorable fashion, such as breaking them in half and merging two plates together.

Another popular method is to take two longish words and misspell them. That would result in something like “twinkel%unihorn” or “rut]row” or the like. Easy to remember, and hard to guess.

spacer
If that’s too simple for you, Keychain Access has a tool that helps make passwords, but since there’s no emotional investment in them they can be hard to remember (though, there is a phonetic method that makes near-English words as passwords). To get there pick New Password Item from the File menu and click on the lock icon (just one way; there are other ways to get to the assistant).

Rule #0: Never Lose Physical Control

This is at the end so you can remember it, but it’s the top concern for security. Do not lose physical control of your computer. Do not leave it somewhere unattended. Do not walk away without locking it down. Do not let someone you don’t know use your account to do something like browse the web. Use Fast User Switching and get to a dummy account for things like that. Your account is yours, and that’s how you keep your stuff yours.

Another Resource

Apple has a very good guide on hardening Mac OS X in their Common Criteria tools. Download them, do not install them, but read the PDF. There are a ton of tips on how to lock the system down in there.

  • Adam Knight's blog
  • flagged
February 16, 2006 - 5:31pm
jdb8167 said

If someone switches their admin account to a non-admin (presumably after creating a new admin account) they will have a lot of folders and files that are still owned by them in places like /Library and /Applications. This could still compromise security. Unfortunately, I haven’t found a good GUI mechanism to fix this problem. It is easy from the command line

sudo chown -R root:root /Applications

With all the applications out there it is hard to be sure that this won’t cause some issues. But I’ve done this before and never had trouble.

  • flagged
February 16, 2006 - 5:32pm
jdb8167 said

Oops, should have been chown -R root:admin /Applications

  • flagged
February 16, 2006 - 5:39pm
Jarod said

Why is SSHv1 not secure? What’s different about SSH2?

I checked out the file you mention; everything seems commented out. Clearly I’m not a Unix expert. Would it be possible to outline step by step where to go and what to do. I’m sure others would benefit from this as well. spacer

Thanks.

  • flagged
February 20, 2006 - 1:18pm
smitty said

There are several vulnerabliities in SSH Protocol version 1. You can look at www.openssh.org/security.html for more detailed information on the vulnerabilities.

The sshd_config file basically documents the default values for the options. If you want to change the options, remove the “#” at the begining of the line and change the option to the desired value.

You will also need to stop and then restart the ssh daemon so it will reload the new configuration. You can do that by using the Sharing preferences for Remote Login in System Prerferences or by rebooting the machine.

HTH,
/s

  • flagged
February 19, 2006 - 8:39am
vladak said

ad #0: although Kensington locks are penetrable, for protection against quick steal it is quite handy to have one always attached to your Mac.

  • flagged
February 19, 2006 - 8:51am
JC said
spacer

we’re not just worried about theft of a machine, we’re even more worried about someone just sitting down at your machine and using it while you’re up getting coffee.

  • flagged
February 19, 2006 - 3:12pm
JeffLass said

It was a surprise to read in Rule#4 your statement “...prevents root from logging in remotely (presuming you set a password for root, which you should not)...”

Did’t you really mean: “(presuming you’ve activated the root account using NetInfo Manager, which you should not)”?

The NeXT computer system on which OS 10 is built, did not have the new admin account category (that is kind of a quasi-root); just superuser and user were available. Apple wisely took the serious system-affecting power away from the new admin to prevent inadvertent system destruction. But that awesome power still remains with the root account which, fortunately, is dormant by default in OS 10. [There are many horror stories concerning what some NeXT and other UNIX sysadmins have inadvertently done with the power of root.]

Now what would happen if some very clever hacker could somehow surrepticiously access the NetInfo Manager to activate the root account? It would then be without a password by default, which would give total control to the hacker to destroy the entire computer [recursive remove with wildcard comes to mind]. Wouldn’t it be safer overall to have the root account activated, but then encumbered with a long and complicated password (using UC and lc letters, numbers, and other characters)? The password could then be kept on a card in a sealed envelope on which is written FOR EMERGENCIES ONLY, and stored in a very safe place known only to the admin.

All UNIX systems that I’ve ever worked on — including NeXT — not only had a hyper-secure password for the root (aka superuser) account, but also had that password kept in a sealed envelope in the VPs safe in case the sysadmin died. This is what I’ve done.

  • flagged
February 19, 2006 - 5:45pm
Notageek said

RE: Rule #1:
For security, I understand the advice to create a second user account. What I’ve never understood was where one downloads all your programs: I’ve assumed into the second user account (to which I’ve also given admin rights, which seems counter-intuitive), using the second user acct password.

Which brings me to rule #1: I refer to this advice: “Login with the new account and remove administrator rights from your original account. Log back in with the original account. Now when you’re prompted to enter a password to do something stupid creative, use the admin account name.”

What?

So, if I “disallow user to admin this computer” on my first account, which account do I use for daily use, and more importantly, into which account do I download all my programs? If I’ve disabled admin rights in the first account, how do I use admin account password — it’s been disabled?

I know this is basic, but thanks to anyone for any Help!

  • flag this
February 19, 2006 - 8:57pm
JC said
spacer

you’re getting ahead of yourself a bit here.

it helps to know this: when you are presented with a request for an admin password, you can put in the account credentials of ANY admin of the computer – it needn’t necessarily be the account that you’re logged into.

0) Your account is “Joe”.
1) Create a new Account. let’s call him “Admin”.
2) Give “Admin” admin privileges.
3) Log out of Joe, log in to Admin
4) Remove Joe’s admin privs
5) Log out of Admin, log in as Joe
6) Use Joe.

Make a folder in Joe’s home directory called “Applications” and install stuff in there. If ever asked for an admin password, think twice about what you’re doing, erase “Joe” from the “Account:” field and fill in “Admin” and the Admin password.

  • flagged
February 20, 2006 - 12:40am
sockettrousers said

Good advice thanks.

I have one problem, I need sudo access (to tunnel port 80 through SSH most frequently) but when I remove admin rights from my used, I’m removed from sudoers.

any way to have sudo access without admin privilidges? DO I have to edit /private/etc/sudoers by hand?

r

  • flag this
February 20, 2006 - 1:05pm
smitty said

The easiest way to do is to su to your admin account and then use sudo as you have been doing.

If you have to create the tunnel frequently, then the best thing to do is edit the suders file and give your non-priviledged user permission to run the exact command you use to create the tunnel. BTW, you have to use visudo since you can’t do it with another editor. Don’t give your normal user account, full sudo priviledges since that would make it an administrator account (almost).

/s

  • flag this
February 20, 2006 - 2:38pm
Adam Knight said
spacer

Either su to the admin user and sudo from there or su to the admin user and run visudo and add your main user in manually as you suggest (use visudo rather than editing the file directly).

  • flag this
February 20, 2006 - 12:32pm
smileproductions said

I know that Mac has a FileVault and I was wondering a) what does this do? and b) should I turn it on and will it help with my security?
I was also wondering if I should get antivirus software and which one is the best because .Mac stopped offering Virex

  • flag this
February 20, 2006 - 3:18pm
Adam Knight said
spacer

Early versions of Panther did very nasty things to FileVault homes so I’ve not been brave enough to try them since.

In short:

  1. It offers good encryption.
  2. It slows things down on slower machines.
  3. It does not lend easily to incremental backups (unless using rsync).
  1. It can potentially lose your entire home in one swoop if the catalog entry for the image is damaged on the system disk.

I strongly prefer the creation of a single encrypted image I keep in my Documents folder that holds sensitive items and keeping a good backup of that data in a physically secure location at home just incase the image bites it.

  • flag this
February 20, 2006 - 7:09pm
mrDoc said

I agree with CP’s use of single encrypted images saved in multiple safe locations. These work quite well and may easily be transported for use elsewhere. The main problem with FileVault is the lack of a recovery procedure incase of a hardware/software failure.

  • flag this
March 26, 2006 - 7:16am
falofolio said

Although I understand and somewhat agree with all of your concerns you all (CP, mrDoc and JC) stated in your comments, I cannot see why FV is highly risky or even evil.

I have not had any single problem with FileVault under Panther and Tiger what-so-ever since the very first moment I have started using it. That means I have had it activated since the last 2 years and never ever have had the intention to de-activate it again due to a problem. It works perfectly and very smooth. Just activate it and you don’t need to look after it anylonger, except for the dialog you get by logging out.

However, I have to agree that letting your sensitive data rely on one single encrypted image-file is kinda risky. So, in my opinion, there are two options to choose from:

1.) The first has already been mentioned by you all;
2.) Just backup your data more often.

Beside the fact that the last option is always a very clever thing to do, for the moment, I will keep on working according to this option with FV activated. But in the future, I might switch to your way. Hopefully, not due to a case of data corruption.

  • flag this
September 13, 2006 - 8:40pm
jay3 said

My HD failed, I could not boot up so that I could get any of my data off, or turn off Filevault… so I had My entire Honors thesis for my degree on filevault, and now I have nothing… what, if anything can I do, is it possible at all to get it back/ unencript it?

  • flag this
September 15, 2006 - 10:38am
JC said
spacer

i’ve met with some success attempting to mount the FileVault image in Disk Utility. DU, specifically, will attach the virtual device in /dev even if checksum fails or another error occurs, and will the FileVault decryption will do its best to interpret any block copy attempts.

so, with it attached (but not mounted) via Disk Utility, try a tool like dd_rescue (google around) or Data Rescue II.

  • flag this
February 20, 2006 - 6:53pm
JC said
spacer

My experience troubleshooting FileVault is that, while really cool, it really sucks. I can’t tell you have many customers I’ve dealt with whose FileVault disk image has corrupted, causing them to lose all of their data. It introduces an unnecessary and infuriating single point-of-failure.

There’s nothing I hate more than Single Points of Failure. Ok, I hate Paris Hilton something fierce, but SPoFs come in a very close second.

If you use FV (and I suggest you don’t; listen to me, I’m the guy who talks to customers about data loss for a living), ... just … for the love of Pete, please don’t. spacer

Oh, and what codepoet said…

  • flag this
February 20, 2006 - 6:59pm
JC said
spacer

i guess neither one of us answered your query about virex… spacer

.Mac stopped offering Virex, sure, but I still think it’s the best of the bunch, and McAfee still offers it (and even updated it for Tiger).

You can find it here.

  • flag this
February 20, 2006 - 7:39pm
Adam Knight said
spacer

For a freebie, ClamXav is a good idea (I still wish Disinfectant was updated these days spacer ). The real problem with viruses on Mac OS X isn’t the virus itself it’s that you can be a carrier and wind up blowing away some poor Windows user’s machine with a file you simply passed along. Well, that and some macro viruses do some damage on the Mac (Microsoft products are an equal opportunity security risk) but many may not quite understand their environment so strange things could happen.

Either way, if you deal in files with Windows users, I’d get at least ClamAV going and get Virex later on if you start to see some infected files that can justify it.

  • flag this
February 21, 2006 - 8:14am
MacPeter said

I tried to move my ssh server off port 22 without success. I’ve posted a question in the macgeekery forums about this.

In addition to changing the line #Port 22
in /etc/sshd_config
is it also necessary to modify the lines
ssh 22/udp # SSH Remote Login Protocol
ssh 22/tcp # SSH Remote Login Protocol
in /etc/services ?

  • flag this
February 21, 2006 - 8:48am
Adam Knight said
spacer

Yes.

  • flag this
February 21, 2006 - 8:25am
david allen said

Many of us have of course not been using an ‘anti-virus’ for a long time – there was nothing to stop, except perhaps the Office macros. I appreciate the comments on Virex and ClamXav above, particularly re Virex.

Earlier experience with Virex was sometimes disastrous – deleted Inbox’s for instance. The same with Symantec/Norton. Have those, particularly Virex, become bulletproof reliable?

Many seem to feel that Sophos is an industrial grade solution (unfortunately, costing at least five seats minimum …) Seasoned experience with Sophos, compared against the others, would be a great help. We all are going to have to get back to some tool, now.

Intego also has an offering.

I guess some of the main criteria are ‘bulletproof’ vs ‘performance’ (ie not excessively to suck up cycles).

Very much thanks for those who can shed experienced light on the subject. Most especially, it seems important to understand whether Sophos is industrial grade. —David Allen

  • flag this
February 22, 2006 - 11:10am
mrDoc said

Other than the default of not allowing root logins on non-priv ports (> 1024). There is no other advantage with this move. Simple tools such as nmap can easily find the new location of ssh and identify the protocol. Since in CP’s suggestions for configuring SSH prevent root logins, allows only user logins, and leaving root password not set (*), you do not have a problem with ssh being vulnerable. If one happens to sit behind an institutional firewall, it is a good chance by moving your access port you cannot access you mac directly from outside the firewall.

If you are worried about a brute-force firewall attack then a move from port 22 might provide some relief until the attacker port scans your computer. Security through obsecurity gives the bliss of false assurance. A pre-digested guide to ssh configuration is available at the following link

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.