Accessing CSE Network Resources from non-CSE IP Addresses (via an ISP)

CSE Home

About Us

Search

Contact Info

This note is intended for people accessing the CSE network from their home machines, via an ISP. The big difference is that you'll be using a "foreign" IP address -- that is, one that is outside the set of addresses used within the Department. This document will give you pointers to software you can install on your home machine to make such access more convenient and secure. It also offers some advice for making decisions on the type of IP addressing you might want to establish with your ISP.

The types of access that are discussed in this document are:

The Basics		Services		Misc
	Login/Shell		Web		Access To Your Home Computer from Campus
	X-Windows		Mail		Keep Security in Mind!
	File Systems		News
			Printing

A Short Explanation of the Problem

Access to many network resources -- established through some process of authentication and authorization, hereafter A/A -- is often based on the IP address of the requesting machine: if your computer has a CSE IP address, you are allowed to use the resource. Examples include printing, file service, certain non-public areas of our WWW space and being able to login to machines without being prompted for your password. This IP-based A/A scheme works well enough in our local network environment. Unfortunately it will not work if you are using a home computer with network access provided by an ISP. This is because the ISP assigns your machine an IP address, and it won't (now matter how much you plead) be a CSE address.

The extent to which having the "wrong" type of IP address impacts you depends upon what operating system you are running at home. Win9? and WinNT are somewhat less affected since file system and printer access are for the most part based on credentials other than IP address. If you are using a Unix variant at home, the impact will be larger but is hardly unmanageable.

Additionally, access via an ISP presents increased security problems. We treat our local network as "trusted", i.e., that it is not accessible to hackers, sniffers, impersonators and the like. This trust is based on the local security procedures we implement and on the fact that we trust the people who use the network. With the growing use of ISPs for network access (rather than password- authenticated dialup connections made directly into the department), the latter basis of trust is eroded. Your home machine looks like any other random host on the Internet; the bits you send and receive are subject to eavesdropping, modification and replay from any number of locations outside the department. This means that it is possible for your password to be stolen, your data recorded, and your home machine impersonated.

The software packages described below not only allow you to access services transparently, but make it much less likely that you (or the department) will be hacked.

1. Static Address. The IP address assignment is permanent. You can write the address on a piece of paper and send it to your friends. They will always be able to ping you at that address. Static addresses are very convenient, and hence ISPs charge extra for them. (They are also not sharable among a pool of users, so their dedicated nature also tends to affect the price.)

2. Dynamic IP Address (aka DHCP). The address is temporary and lasts only as long as a single session, where the precise semantics of "session" are defined by the ISP. You can write the address on a piece of paper and send it to your friends. They will be able to ping you for as long as the session lasts. After that, they will probably be pinging some other machine.

3. Network Address Translation (NAT). The address your machine uses is both temporary and completely useless outside your ISP. You can write the address on a piece of paper and give it to friends and enemies alike. Neither will ever be able to ping you using that address. This obviously provides significant advantages, in terms of being safely hidden behind a firewall. But life behind such a firewall cal also be very isolating.

   NAT can cause problems with some of the A/A mechanisms described below. In particular, the standard Kerberos software (including those associated with the Reflection package) will not work when your home machine is NAT'ed. Additionally there can be problems with NT domain authentication.

You should be sure to have a clear idea of what address assignment choices your ISP offers and pick the one that is right for you. A discussion about choosing an ISP can be found here.

On our local network you would probably use telnet or rlogin to login to another machine via the network. Unfortunately standard telnet sends your plaintext password over the network. Rlogin either sends a plaintext password or relies on the name of your remote machine being in your .rhosts file. Neither of these options is desireable when connecting through an ISP. Your plaintext password is easily captured using a network sniffer. The name/IP address of your remote machine may change on every dialup session, invalidating the contents of your .rhosts file. Worse, the address may be re-assigned to or hjacked by another machine, effectively allowing anyone on that machine to impersonate you. For these reasons that we do not allow non-CSE machines to appear in local .rhosts files.

Secure login and shell access are provided by Kerberos clients or ssh, the Secure Shell.

Kerberos

General information regarding Kerberos and its use in the department is available here. Kerberized client software includes telnet, rlogin, rsh and rcp. Each of these programs provides encryption of all data and never sends your cleartext password over the wire. Kerberos applications are included in most PC Unix distributions (e.g., RedHat Linux, FreeBSD). Send mail to support@cs for advice on configuring your home Unix installation.

So what's a person to do? Well, you could ask your ISP to switch you to something other than NAT (see discussion above). Or, if you'd prefer to enjoy the security benefits of hiding behind a NAT "firewall", there's another solution: ssh.

Ssh

Ssh uses a different authentication and encryption mechanisms than Kerberos but provides the same basic set of services. Additionally, ssh is capable of encrypting X-windows connections via a ``proxy'' mechanism. For home use you will want to use the RSA public-key authentication protocol. See the man(1) pages on the Unix machines for details about ssh or visit the ssh home page.

There is also an SSH package for Windows provided by UW Computing & Communications. Included is an extremly good terminal emulator program. This software is not susceptible to NAT problems.

Remote NT Login

If most of your computing is NT-based within the department, you can use the ultimate in remote login software: the Windows Terminal Server. Essentially, the terminal server allows you to open a complete Windows login session running on a CSE server with the display going to your home machine. Authentication is done via your normal Windows password. Terminal Server clients exist for Windows and Unix.

You can access CSE resources from home using the X Window System in a secure fashion, although you will not be able to establish an XDM session. The reason is that the XDM protocol is not Kerberized, has no provision for handling encrypted passwords, and thus would send your password in cleartext. You can, however, run X clients on an on-campus CSE machine that will display on your home machine. You'll just need to run an X server on your home machine (e.g., Reflection X for NT, or standard X-11 packages on Unix systems), and properly configure it to allow display from your CSE machine.

More about X can be found here.

The department supports two types of network file system on our internal network: NFS and SMB (Windows).

For security reasons, access to NFS file systems from your home machine is not possible at the present time nor is it likely to be in near future. Some consideration has been given to using a Kerberized version of NFS, but this is not on anyone's critical path.

Transparent access to Windows shares is possible from your home machine. However, it requires some special configuration. See here for details. Data transferred via SMB cannot be encrypted and there are known methods of attack on the Microsoft authentication protocol.

Many people use cvs in client-server mode to maintain large file collections on lab machines that are backed while keeping a working copy on their local disk. Cvs by default uses .rhosts based A/A. You can easily switch to Kerberos-based authentication by setting the environment variable CVS_RSH to the path for a Kerberized version of rsh. We have also experimented with cvs servers configured to use peer-to-peer Kerberos, passing commands over a single connection established at startup, rather than using rsh-style commands. This appears to work nicely and is more efficient, but no decision has been made on installing such servers everywhere.

Two cautionary notes:

1. Many ISPs charge by the number of bytes you transfer over the network. For some applications (e.g., compiling programs or searching through large files), you may be money ahead to login to a department machine rather than access files through your ISP connection.
   
   
2. There are persistent rumors (and much evidence) that certain broadband service providers actively block SMB traffic to reduce share bandwidth consumption. You should specifically ask a potential ISP what their policy is regarding handling SMB traffic.

Some of the resources in our local Web are accessible only by authenticated CSE users. Examples include the room reservation page, some course content, and internal policy documents.

We have implemented a "CSENetID" A/A scheme that allows secure authentication of both remote and local users for web page access. The only difference that remote users should notice is that authentication is required for some pages that do not explicitly require it when viewed locally. This is because those pages use a combination of address-based and CSENetID-based authentication.

Please remember that there are good reasons for access protections on Web pages. Don't leave something less protected than it needs to be.

If you are an Outlook user, you should not have any problems reading your mail from home. Look here for details.

Since Unix provides a much wider variety of mail handling programs it is difficult to give any advice without giving too much of it. Suffice it to say that your best bet may be to read your mail from a host within the department, either by using a secure, encrypted login (as described above), or by using an X-Windows interface (also described above). If you do want to read mail directly from your home computer, use an IMAP-based mail client that is capable of Kerberos A/A, such as Pine. You should not use a POP2-based client (which will transfer your mail to your local disk, a place that is not as likely to be backed up as the mail server), and you should not use any client that sends your password in the clear.

Information on choosing and configuring an email client for remote access can be found here.

It's a very rare ISP that does not have a news feed. And that feed almost certainly has a wider variety of news groups than our local news server. You should read news directly from your ISP. One exception is CSE newsgroups, which -- due to privacy concerns -- are NOT fed outside the deparment.

Remote access to CSE newsgroups can be accomplished in two ways: by logging into a CSE machine to run a news client within the department (using either a secure login, or X-Windows), or from a remote news client that authenticates to the CSE news server.

More information about remote news reading can be found here.

Printing from your home Windows machine to department printers should be completely transparent once you have file access to our local domain as described above.

It you use Unix, printing becomes slightly more baroque since the print daemons currently use IP-based A/A. Absolutely the easiest thing to do is to use remote shell access to do your printing. E.g.

      cat file | rsh csehost whatever-print-command-you-use

Our Unix print spoolers have the capability to use Kerberos A/A, but it is not currently being used. We will wait to see whether such capability is actually required.

Accessing you home computer from Sieg Hall can range from impossible to very easy. The key to the difference is whether you home machine has a permanent IP address and/or hostname. The permanence of the address/name is something that you have to work out with your ISP. Some ISPs will refuse to give you a permanent name. Others will charge extra for it. Always get a permanent name if you possibly can. Otherwise your home machine will become an Internet will-o-the-wisp and you will have difficulty remembering how to get from wherever you are to wherever it is.

Naturally, you want the same degree of security in going from the department to your home machine as when coming from home to the department. For Unix machines this means you will need the Kerberized servers for telnet, rlogin, etc. and/or the ssh daemon. Setting up the server side is slightly trickier than than just having clients. Particularly for Kerberos since some material has to be transferred in a secure manner. Send mail to support@cs for help in this area.

Unix folks can use the normal network programs to access their home machine. Windows folks have less choice. One good place to start is the VNC. Much like PC-Anywhere, this program lets you take over take over a Windows desktop remotely. Unlike PC-Anywhere, VNC is free software and can also be used to display your X desktop on your Windows screen. VNC is used locally and has a number of satisfied users.

Keep Security In Mind

Even though the previous section gave you information about how to get at your home PC, you should seriously consider whether you really need to have that capability. DSL, cable modems, etc., make it easier for you to leave your machine on all the time. But remember: it's just another machine on the Internet. Which means that while you're watching TV or playing cards on the 4th floor, hackers from Lower Slobovia are trying to invade the machine in your den. For some sobering scenarios of what can happen when the hackers succeed, see this message from Dave Dittrick, one of the UW network security people.

Falling victim to such hackery can be expensive, time consuming and embarrassing. Preventing it is mostly just time consuming. Some folks simply can't be bothered with keeping up with security bulletins and patches. These are the same people who gave rise to the expression: "You can pay me now or pay me later."

One of the cheapest preventatives is making sure that your initial software configuration is kept to a minimum. Many installation procedures will load every network service under the sun, most of which you don't need and some of which are downright unhealthy. The people in the Lab can offer advice on how to set things up.

Finally, you don't really need the space-heater effect or the distracting fan noise, so:

If you aren't using it, turn it off

	Computer Science & Engineering University of Washington Box 352350 Seattle, WA  98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [comments to oystr@cs.washington.edu]