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