« OS X Networking | Main | X for X »

created 25 July 2000

OS X Security Concerns

Last column, we took a quick look at some of the advantages that OSX gives the network administrator, particularly in the security area. This time, we are going to deal with the dark side of security, namely the new, fun ways that OSX can potentially hurt you if you aren't aware of security, and security issues.

The first danger has much to do with OSX's increased feature set, and how a Unix box can be manipulated on a network. Although Mac users have been networking heavily since 1985, Unix takes network operations to another level.
For one, in the world of Unix, the only difference between a networked hard drive and a local hard drive is the name. Functionally, you use applications on a mounted network drive the same way as you would use applications on a local drive. In some cases, the directory that you run most of your applications from may not even be local, and in larger Unix installations, your home directory is on the network as well. The local hard drives are used for swap space and the operating system.

So far this is not too terribly different than the way Mac users do things, especially with things like NetBoot, Macintosh Manager, etc. The next part of the network equation is very different, and is where the Unix layer of OSX has a real ability to severely hurt a network.

It's the Remote Procedure Call, (RPC)

RPC is a way for Unix, and other operating systems to 'farm out' jobs to other computers on a network, so that large jobs can be handled by multiple machines at once. RPC was started by Sun Microsystems, and is now a standard way for computers to programmatically communicate with each other.
Essentially, there are two parts to an RPC program. The local part is the part you start, and contains the code that does what needs to be done locally, as well as the locations of the remote machines that are going to assist in running the program. The local RPC application passes data to the remote programs, and waits for the returned data. (NOTE: This is a drastic oversimplification of what really goes on with RPC.) The advantage of this is that you can have a relatively small RPC local stub program passing information to much larger remote programs on tens, or even hundreds of machines, and let them work on the data for you. Very efficient, and a nice way to make use of spare CPU cycles.

Especially for crackers.

If a hacker gets root access, (root being the 'superuser' or owner of a machine in Unix-speak), then they can set up RPC programs that can do, well, anything they want them to, from sniffing passwords, to copying data, to being used as launch pads for other activities. RPC programs aren't scripts, or applets, they are compiled code, and can have the capabilities that any other compiled application can have.

So how do you prevent this from happening to you?

First of all, don't turn anything on that doesn't need to be on. If you have an OSX Mac that doesn't have a specific need to use RPC, don't turn it on. The same goes for FTP, Web services, File Sharing, etc. If there is no door, the lock can't get picked. Yes, this will mean you aren't exercising the absolute full capabilities of your network. This is due to one simple principle:

Security and inconvenience are directly proportional to each other.

The most secure computer in the world is one that's turned off. But it's also rather useless. Now, in a lot of cases, you will need to have certain services, such as RPC, or FTP available for use, so the next level is how to make sure that the only people using those services are the ones who are supposed to.

The answer: Password policy

First of all, root password should *only* be given to those with an absolute clear need for it. 'Need to know' should be the only reason here, not position, not friendship, not anything else. Secondly, all passwords, not just root should be changed regularly. I recommend a minimum of every thirty days, but you may want to change critical ones, like root more often. In some heavily classified facilities, it is not unheard of for certain passwords to change daily. Other times to change root is when anyone who had root leaves the company, or transfers to a position where root is no longer needed, or when a remote site is added or dropped on or off of the network.

Third, enforce good passwords. This means a minimum of eight characters, with at least one number and one non-alphanumeric character, no names, no common words. Something like 'Hyrg8*_Z' is a decent enough one. Make sure that when passwords are changed, they can't be 'changed' to the exact same thing they currently are, and in some cases, keeping track of the last year's worth of changes is not a bad idea.

Finally, get the message across that writing down, or giving out passwords is A BAD THING. If you read about crackers like Kevin Mitnick, you realize that he did a lot of his best cracking by calling up an employee of a company and saying "This is the IS department, we're running a check of the system, and need to verify your password. Could you tell me what that is so that I can make sure it's correct?" No long, sweaty hours over a CRT, just five minutes, and a believable story, and he had an access to a network. Janitorial staffs have been also been a great way to gain access. A cracker will hire on with a company that cleans for a company they want to crack, and a little astute observation of sticky notes on monitors, and boom! Instant access.

There's still more to talk about on this subject, such as command - line issues, and shell scripts, etc. But this is a good start. I highly recommend that any Mac administrator familiarize themselves with Unix security issues now, before you are doing it at 3am while dealing with a break-in. A lot of security measures will not win you points with your users, and they are very inconvenient. But it beats having a hundred G4s become the local cracker supercomputer cluster.

Comments