Page 5
<<Back | Index | Next >>

Macintosh Security Basics - Presentation Notes

Personal Web Sharing

Do you really need to do this?

• Anyone at Dartmouth can have a homepage on the main Dartmouth webserver
• Real web servers typically work better for the purpose

If you still want to do it, Apple’s default setup is recommended (read-only access to the web folder).
Ask yourself: Do you really need to do this?

Anyone at Dartmouth can have a homepage on the main Dartmouth webserver. Then, security is THEIR problem, not yours. :)

There are many free homepage sites (Angelfire etc.)

Real web servers typically work better for the purpose (more bandwidth, more reliable uptime, usage statistics, CGI access, static IP, etc.)

Eggs in one basket issue again.

If you still want to do it, the default setup is recommended (read-only access to the web folder).


PWS Features

PWS can be configured to inherit access privileges from Sharing Setup.

You can make web folders writeable to allow HTTP upload, if the client browser supports it. Yikes…

You can configure PWS such that aliases can be followed. Confusion risk though.
Instead of the default privs, PWS can be configured to make use of the users and privileges in Sharing Setup.

You can make web folders writeable to allow HTTP upload, if the client browser supports it. But I don’t think this is used much, if at all, and it sure sounds like a security hole, no?

You can configure PWS such that aliases can be followed (i.e., put an alias in the web folder, users can get to the real item even if it’s outside of the web folder). Scary. If you forget the alias is there, and you put sensitive data into the original folder, now anyone can see it...


PWS Caveats and Wrap-up

Be careful not to share your whole disk. PWS claims to have support for CGI scripts. Careful… Again, do you really need to serve webpages off your Mac?
Be careful not to share your whole disk. The webserver software is not magical enough to “know” which files are webpages and which files are, say, your thesis. It will happily allow users to “view” (i.e., download) anything on your disk -- including documents, applications, and system files.

PWS claims to have support for CGI scripts. I assume they mean scripts written in AppleScript (as opposed to Perl or PHP). If you venture into that realm, know what you’re doing with your scripts -- AppleScript can be misused. (Remember the LoJack story and the “suicide scripts.”)

Again, do you really need to serve webpages off your Mac?


Remote Access

Remote Access Server. Allows another Mac with Remote Access Client to dial into your Mac.

• Do not configure Remote Access Server to allow guests to dial in. • If your users won’t need TCP/IP services, don’t choose PPP as the protocol. The default is ARAP, which is safer.
It used to be that you had to buy the full-blown Server package to answer calls, but I think nowadays a light version is included with the OS. Perhaps only on OS X though. If you have a modem, it allows another Mac with Remote Access Client to dial into your Mac.

Do not configure Remote Access Server to allow guests to dial in. Wardialing is still popular. (Each User in the Users and Groups tab of Sharing Setup will have a box you can check to “allow this user to dial in.”)

If your users won’t need TCP/IP services, don’t choose PPP as the protocol. The default is ARAP (AppleTalk for Remote Access), which is safer because again, you’re taking advantage of the relative uniqueness of AppleTalk to help obscure what’s going on.

Again, do you really need to serve webpages off your Mac?


Moving on: “Safer Surfing”

Most of the suggestions here apply to any operating system. We’ll point out some Mac-specific details.

• Web browsing tips
• FTP and Fetch
• Email
 


Web browsing

You’ve probably heard this before.

In Netscape, go to Edit menu -> Preferences. Scroll the left pane and select Advanced. Disable Java, disable JavaScript, disable cookies.


It might also be a good idea to turn off Flash, since Flash has its own Javascript stuff built in…depends on how paranoid you feel vs. how much you care about flashy webpages functioning properly.


Ok, now I can’t use the web at all.

Trouble is, a lot of sites simply won’t work anymore.

Compromises:

• Only accept cookies that go back to originating server
• Delete the cookies file over and over. - Tiny freeware program called NoCookie did this automatically…
• Or, try Anonymizer!

Trouble is, a lot of sites simply won’t work if you do this. Compromises:

Only accept cookies that go back to originating server, and you might even want to check the “warn me” box (but I’ve found that this gets REALLY annoying when you visit a site that wants to set half a dozen cookies for every page). Or, delete the stupid cookies file over and over. For Netscape Communicator on MacOS, go into System Folder -> Preferences -> Netscape Users -> Your-User-Name and delete (or delete the contents of) the file named “MagicCookie.”

If you never want the cookies set or the scripts executed in the first place, but there’s a site you really want to visit that requires those things, there is another way:


http://www.anonymizer.com

You put in the URL you want to visit, then Anonymizer makes the connection for you, and it dev-nulls all the cookies and other crud so the server never talks directly to your machine. Nice for when you’re visiting certain nefarious websites (like 3L33T hAX0r homepages) and you don’t even want your IP recorded.

The basic service is free, but for a fee, they offer some kind of service that anonymizes all of your surfing automatically (I think you install a plugin and it invisibly does its thing.) Maybe they are logging every keystroke… ;)


FTP...

...is bad.

• Anonymous FTP is ok
• The whole session is clear text
• Easy to pick out login info
• Two ports = hard to tunnel
TFTP (File Transfer Protocol) with a username and password is just Bad.

The username and password are preceded by “USER” and “PASS” respectively, so it’s utterly trivial for an attacker to watch for and flag that data as it is transmitted (e.g., ngrep).


What you can do

If you HAVE to use FTP with login/pass, use a password that you
don’t use for anything else

Don’t transfer sensitive files over FTP

Keep backups

Work under the assumption that someone is going to be able to log in as you

Try to use a more secure alternative
TA better solution: Tunnel the USER/PASS portion of your session over MacSSH.

http://www.bio.upenn.edu/computing/instructions/security/portforwarding/

See if the server supports any of Fetch’s built-in security support (Kerberos authentication, one-time passwords, challenge-response system). Use them if possible. See if the server supports SFTP (Secure FTP) as part of SSH (Secure SHell, and its counterpart, SCP or Secure CoPy). Try connecting with MacSFTP, an easy-to-use shareware SFTP client with a very Fetch-like interface. Also, the next release of Fetch is supposed to include built-in SFTP support.

Fetch v. 4.0.x already has some security options, but they require you to install additional software, and the server(s) you connect to must support those features as well. To take advantage of some of them, you have to install and properly configure M.I.T.’s KClient package for your OS (there are versions for both OS 9 and OS X). But from what I can tell, the Kerberos server version in use at Dartmouth is not compatible with the current M.I.T. release, and Fetch is too new to use the old KClient. And configuring the client properly can be a non-trivial task anyway. So watch out.

Just for fun, we’ll talk about these features a little bit. The following assumes that you have installed and configured the right version of the KClient software.

<<Back | Index | Next >>