mac geekeryGet your geek on. |
Basic Mac OS X Security
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
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:
Now when you’re prompted to enter a password to do something Rule #2: System Preferences is Not for Daily Use
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.
Rule #3: Turn off Services You Do Not UseGo 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 ShellBy 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 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. 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) Rule #6: Freeze the Credit Card (Keychain) 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 PasswordThe 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. Rule #0: Never Lose Physical ControlThis 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 ResourceApple 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.
|
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.
Oops, should have been chown -R root:admin /Applications
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.
Thanks.
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
ad #0: although Kensington locks are penetrable, for protection against quick steal it is quite handy to have one always attached to your Mac.
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.
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.
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!
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.
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
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
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).
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
Early versions of Panther did very nasty things to FileVault homes so I’ve not been brave enough to try them since.
In short:
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.
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.
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.
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?
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.
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.
Oh, and what codepoet said…
i guess neither one of us answered your query about virex…
.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.
For a freebie, ClamXav is a good idea (I still wish Disinfectant was updated these days ). 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.
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 ?
Yes.
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
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