blog advertising is good for you


blog advertising is good for you
User login

Basic Mac OS X Security

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:

  • 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

secure-sysprefs-security

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. Smiling

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)

security-firewall
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.

security-myssh
It also makes our SSH hack above useless by blocking 2200 by default. Smiling 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)

security-keychain
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.

secure-password
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.

cover of Maximum Mac OS X SecurityMaximum Mac OS X Security
author: John Ray,William C. Ray
asin: 0672323818
Average rating
(1 vote)
About Adam Knight
Adam Knight's picture

Author Biography

Adam Knight is one of the founders of Mac Geekery and is a geek at heart. Programmer by day, hacker by night, his daily life revolves around the Macintosh platform, which he has been a user and programmer for since the early days of System 7 when his LCII replaced his Apple //c.

In-between tech jobs, he’s managed to learn the basics of any web hacker: PHP, MySQL, Perl, Apache, Linux, *BSD, and the intricacies of ./configure —prefix=~/bombshelter/. Today, codepoet is concentrating on blogging again, writing some software for the Mac by himself (including Notae) and for his company (such as Switchblade) and has a few other toys coming out soon.

Bug him over AIM or email [link fixed].

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. Smiling

Thanks.

There are several vulnerabliities in SSH Protocol version 1. You can look at http://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.

JC's picture

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!

JC's picture

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

Adam Knight's picture

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

Adam Knight's picture

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).
  4. 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.

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?

JC's picture

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.

JC's picture

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. Smiling

Oh, and what codepoet said…

JC's picture

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

.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.

Adam Knight's picture

For a freebie, ClamXav is a good idea (I still wish Disinfectant was updated these days Sad). 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 ?

Adam Knight's picture

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 ssh config, ignore the TCPwrappers section unless you want to roll your own OpenSSH.

Adam Knight's picture

The idea is to get past a lot of the worm-like rootkits that do not do portscans, and that’s a good number of them. Moving the port makes perfect sense in those cases.

Remember, the idea of moving the port is to be used in conjunction with rule #3: Only run services you need. Turn off SSH unless you need it. When you do use it, it will be on a non-default port so a majority of users and worms will believe you are not running it unless they have cause to believe you are.

It helps to step back from a solution a little to see why it is useful, sometimes.

I apologize, as this is going to make me sound like a really big idiot, but I can’t seem to take admin priveledges away from my original user, even after logging into my newly made administrator account. The “Allow user to administer this computer” checkbox is grayed out and inaccessible. Any suggestions would be appreciated. Thanks!

Adam Knight's picture
  • Make sure the new account really is an administrator
  • Try logging out the other account
  • If you’re sure the new account is an admin, an admin can usually self-demote.
  • Make sure you’re authenticated in System Preferences (the lock at the bottom)

Just a quick one… Which file gets the AllowUsers field? I tried to put that into ssh_config for the hell’ve it and got this upon testing:
/etc/ssh_config: line 38: Bad configuration option: AllowUsers

Also heads up everybody… When you change your SSH port it also changes the default port that terminals SSH client uses to connect – so when you’re connecting to those other SSH servers out there remember to -p it.

Sequoia
Only slightly ‘tarded.
(yes, the math questions have gotten me)

Why, oh why did I list all the OSes I’ve ran?

Adam Knight's picture

ssh_config is for your SSH client. Put it in sshd_config to alter the server daemon’s behavior.

jcjones's picture

EDIT: Oops, I was replying to jdb8167’s suggestion to use: “chown -R root:admin /Applications”.

Can anybody else vouch for this method? It made sense to me, so I gave it a whirl. Now I’m blocked out from certain folders in my /Applications/ directory. It seems Microsoft apps are afflicted, but I don’t think there is any correlation.

Adam Knight's picture

It’s a good idea to keep the mean fingers off the programs, sure, but a non-admin user isn’t a member of the admin group, nor is it root, so you have to ensure the permissions for everybody/world are set to at least read and execute for the folders and programs, and read for all other files.

Personally, I don’t use /Applications for my programs, I leave that for Apple’s programs. I made an Applications folder in my home and I keep my programs there. That also means I only need to backup my home directory when I need to make a backup and I get all my custom software as well.

jcjones's picture

Okay, I think this in sequence cleans everything up for me.

mac:/ admin$ sudo chown -R root Applications/

mac:/ admin$ sudo chmod -R o+rx Applications/

Sure, I could write a script to filter out everything that shouldn’t be an executable, but knowing that only an admin can write anything within the folder makes it unlikely that such a privileged user would ever write anything malicious.

In fact, I’ll look into writing a folder action for this so that any new applications copied to this folder will retain the same privilege structure.

Jared

Adam Knight's picture

Using a capital X only flips it on for folders and binaries.

chown -R o+rX foo

Hey,

Thanks for the great tip on saving time when backing up!
One question though, If I create the new App folder in my
user directory and move my previously installed third-party apps
to that location, will that break anything in regards to preferences,
libraries, etc. that applications access? (Would they still be in the
locations tied to the original admin folders? If so, would that affect
anything?) Thanks!

Shelley Revtai

saw the bit about virus software… i have been running Intego’s stuff for a while now and like it. Doesn’t seem to bog things down much at all except during scan and not too terribly bad then.

okay so what unix string should we do for the chown stuff? I just switched up my admin privs – what do i need to do now in the command line? Seen a couple comments on it.

Has anyone else besides the one user had problems?

Hi all,

I’ve followed these excellent instructions, and now have one unexpected side-effect of, I think, my day-to-day user not being an admin.

I was used to the idea that previously, in Terminal, sudo would ask for a password and I would supply my users’s login password (never been sure why it did so if I was already admin, but sobeit).

Now I am no longer an admin, if I assume I am to supply the new admin user’s password at the sudo prompt. When I do so however I am told “Sorry, try again” and after three goes I am thrown out??

I have confirmed that sudo in Terminal when logged in as an admin takes that password no problem.

Anyone got an idea what I might be doing wrong?

Thanks in advance,

yan

Your “user” was never the administrator. Sudo allows certain users or groups of users to elevate privleges. It was designed to allow normal users to become pseudo-superusers (read “sudo”) allowing them to perform specific jobs that required root access without giving them complete root access. Most home users use sudo as a replacement for “su”. “su” allows you to become a different user on the unix system, and most of the time home users decide to become root. It requires either knowing the password of the user you want to become or first being root, to become that user.

Now that you’re not in the “admin” group, sudo won’t allow you to elevate privleges.

That was the point of removing admin access… Having said that:

“man sudoers” is your friend.

Determine the amount of power you want to give yourself and after reading the manpage for sudoers, use “visudo -f /etc/sudoers” and edit the sudoers file to give yourself as many or as few adminsitrative abilities as you want.

You could always use “su – your_new_root_user -c command_to_execute” to achieve the same ultimate effect of “sudo command_to_execute” … You’ll need to specify root’s password and not your own. su will not log the operation, nor will you be able to limit what can be done in that command_to_execute.

HTH

Thanks for the reply,

Yes, in the meantime I have been digging around (its been driving me nuts!), discovered sudoers along the way, but I literally only just understood how sudo works. I thought it allowed an account to elevate its privileges by running the required command as another account, a la su, so once I had added an entry to sudoers, I was still trying to supply the password of an admin group account at the sudo prompt! I realise now that (via sudoers) I specify what elevation I wish to allow my account if I sudo and supply my own password.

Blinding flash of understanding, sigh of relief etc…

I found an annoying drawback to modifying /etc/services: on the one hand, this does the desired thing by forcing launchd to open sshd when the new port is accessed.

On the other hand, it also changes the default ssh port. So, from that point on, an ssh command to any machine will try to connect by default to the new port rather than to port 22. Clearly this is not the desired behavior and is likely to break existing scripts that use ssh (of which I have some).

If anyone can figure out to change the port in which sshd runs without changing the default ssh port for outgoing connections, I’d like to hear.

Adam Knight's picture

Add a “myssh” service and then edit the port name in /System/Library/LaunchDaemons/ssh.plist to use that port name instead.

I looked in there. Very scary. Saw “ssh” in a couple of places and wasn’t sure which to change. Can you give a “defaults write” command I could use so I don’t muck things up? Or be a bit more detailed as to what to change (and what to leave alone) in the ssh.plist file?

as i am doing backups every night anyway (i.e. for the case my powerbook might get stolen/head crashed) I am using FV without problems.
Should there once be a problem – i’ve got my backups just on my raid-server in a secure place.

I think I’m compromised. Even after a Archive install and new account. http://smg.photobucket.com/albums/v660/spoolingturbo6/stuff

Adam,

I’ve taking you advise in the past regarding not running as administrator (Rule #1). What are you thoughts about doing the same thing in Leopard? It has been somewhat of a hassle not to run as Admin, like upgrading apps with Versiontracker Pro has been a pain. The request for password can reach 30 times a day. Do you think Leopard will have addition security so rule #1 might not be necessary?

Thanks for posting this security guide.

As far as I can tell from tinkering around with Leopard for the last two days, there are some noticable changes.

  • The Firewall has been moved in System Preferences from the “Sharing” panel to the “Security” panel. Reading comments on forums a lot of people are angry about this, but to me it makes perfect sense!
  • The downside to the new Firewall screen is that they’ve really dumbed it down. Aside from a crude menu that lets you add generic “.app” programs, there is no way now to create your own custom rules, port number assignments, UDP/TCP or anything whatsoever. I guess it’s back to the command line to configure these things.
  • sshd_config uses level 2 security for SSH without the option of falling back to 1 BY DEFAULT which is nice.
  • But therein lies the problem! If you change your SSH listening port to “8800” as was suggested above, in the Leopard Firewall System Preferences pane there is no way whatsoever to open that SSH port because you’re limited to only creating generic rules based on .app’s and the Services you start in the “Sharing” panel; which will turn on port 22!

It’s a real pickle.

hey there, i’m really new to this mac stuff – would it be possible to find the app that SSHd or whatever is being executed and add that to the firewall permission list in leopard? :S

Someone know something more about rule #1 for Leopard?

Adam Knight's picture

Same as it always was.

http://www.nsa.gov/snac/downloads_macOSX10_4Server.cfm?MenuID=scg10.3.1.1

Hi everyone,

Since I am really new in using a Mac i’ve come across a problem i don’t know how to fix. In Adam’s rule #2 despite the fact that i have already checked the box ‘Require password to wake this computer from sleep or screen saver’ my mac simply refuses to do so in practice the same way it refuses to enable the screen saver after the specified period of time! It wakes up just fine without asking for any kind of password! Does anyone know why that happens? Maybe something to do with the keychain access?

Thanks a lot!

my university admin fucks with me on campus when i attempt to do homework. He/she will disbale functions of the applications i need use inorder to complete the assigments, change the way the applications function when there not in use, change the way search enegines work, change the root of the programs. i have attempted to do things to get around this such as use my own comp., but i am unable to access the internet without installing a program the server makes me install. What can I do? I have lots of general information about the server/domain here at uwsp that i accessed in my attempts to make the corrupt functioning of the admins yet i am not knowledgable in the subject there for i need someone who is. in detail is there a way i can make this stop for good such as making myself the admin? i think the server is windows and domain is uwspdom. what do you suggest? additionally my system is 10.4.

One simpler way to change the ssh port is to edit /System/Library/LaunchDaemons/ssh.plist. That file contains these lines:

<key>SockServiceName</key>

<string>ssh</string>

Which is what refers to the “ssh” line in /etc/services. You can change that to any other name from /etc/services, or you can change it to a number, like 2200. As far as I can tell, this also takes care of opening the correct port(s) on the firewall.

I learned this while I was reading the manpage for launchd.plist. I was actually trying to find out where launchd.plist is located on the system, so I was looking the directories mentioned in that document.

I also learned from a comment on macosxhints.com that it’s not difficult to open more than one port for the same service:

http://www.macosxhints.com/comment.php?mode=view&cid=96607

Which is how I tested my new ssh port without disabling the existing one.

One simpler way to change the ssh port is to edit /System/Library/LaunchDaemons/ssh.plist. That file contains these lines:

<key>SockServiceName</key>

<string>ssh</string>

Which is what refers to the “ssh” line in /etc/services. You can change that to any other name from /etc/services, or you can change it to a number, like 2200. As far as I can tell, this also takes care of opening the correct port(s) on the firewall.

I learned this while I was reading the manpage for launchd.plist. I was actually trying to find out where launchd.plist is located on the system, so I was looking the directories mentioned in that document.

I also learned from a comment on macosxhints.com that it’s not difficult to open more than one port for the same service:

http://www.macosxhints.com/comment.php?mode=view&cid=96607

Which is how I tested my new ssh port without disabling the existing one.

I am going to be very new to Macs. Essentially I am working on introducing Macs into our environment and eventually create Mac images, if there’s such a thing. This will also include application of security templates either standalone or through the AD. Could someone please point me to the right direction in terms of where to get this kind of resource. I am planning on getting a Mac one of these days to check it out about the OS.

Any help or right direction would be very appreciated

Thanks

Abed

I just may have screwed myself. Ok, I reset my password on the only account for my MacBook Pro. I must have clicked or unchecked “allow this user to administer this computer.” I can’t remember the admin name because from my understanding it is the name of the only account I have on here. Do I have to wipe out my entire computer just to get my rights back? There is no hint for the admin name. Everything I could have named it I tried. A new update for Safari came out today and I couldn’t even install it as will be the case with future updates of any kind. Please help if you can.

Post new comment
The content of this field is kept private and will not be shown publicly.
7 + 1 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.