Client access (from behind a corporate firewall) of campus services

The chart below lists the networking ports required to Stanford University network services access from another network address range (non-Stanford University) network on which some blocking networking ports is done e.g. using a corporate firewall. This list is informational and does not imply that Stanford University recommends that these ports be opened for client access unless doing so is consistent with the corporate security policy of the organization from which the Stanford user is connecting. Attempting to circumvent the local security policy or infrastructure design by a client is strongly discouraged by ITSS.

Example Scenario

A Stanford University user is trying to connect from inside a trusted corporate network, the perimeter of which is controlled by a corporate firewall. The user’s client (the Stanford user’s computer which in this case is a Microsoft Windows 2000 workstation) attempts to connect to one of Stanford University’s email servers using each of the available methods:

1) For PC Eudora or Mac Eudora require 1109/TCP to communicate with the POP server in Kerberos mode. Additionally, this application requires authentication via PC Leland and Mac Leland uses ports 88/UDP and 751/TCP. Use of these applications require the user have the authorization to install software on the workstation which is used.

2) To use a terminal session email client (e.g. pine or elm), typically a user would connect over a secure terminal session using either Samson over 23/TCP or an SSH over port 22/TCP client program. After securely logging in, the user runs the mail program from a command line. The support of a specific SSH client program for all Stanford University users is still being reviewed. Several free clients exist and some require virtually no setup.

3) Webmail is a web browser based service that uses both ports 80/TCP and 443/TCP during a session. In the case of web browsing, corporations often use a web proxy which may specify ports to use instead of these.

Also, the user in this example has installed the WS-FTP program for file transfers and Norton Anti-Virus program from the Stanford University central distribution server. As with most FTP clients, WS-FTP requires port 21/TCP be available outgoing from the client to an FTP server. However, this port is only used for a setup of the connection. The data is exchanged across a different port. In passive mode, the second port will be agreed on above 1023 and as such, is less worrisome as a method of exchange. However, FTP is not a secure file transfer mechanism and should only be used for anonymous connections where possible. Norton Anti-Virus will connect to the internet on demand for virus definition updates. It defaults to connecting via port 80/TCP as though it were a browser. As with a browser, it may need to be set to point to a web proxy if one is used in the corporate intranet.

Requesting Access from the Corporate Security Administrator

Access to the above services may be blocked by the “rules” on the corporate firewall. The Stanford University user can then approach the security officer or firewall administrator of that company to request permissioning of the specific network ports needed corresponding to the services required. Also, it is important to be aware that the network ports that are permissioned (opened) in one direction generally have an return traffic associated with them. These return traffic ports are generally in the non-privileged range above 1023. The local administrator will likely be aware of this requirement and most commercial firewall products automatically account for this fact.

NAT will break Kerberos ticketing when lookups are done of

Service	Port/Transport	Description of Communication	To Client	From Client
SSH	22/TCP	Secure shell terminal connection over encrypted point to point tunnel
Telnet	23/TCP	Insecure terminal connection. Secure version called Samson telnet client uses same port but requires PC or Mac Leland.
Kerberos	88/UDP	Kerberos authentication
IDENT or AUTH	113/TCP	Used for authentication by browsers to some web servers which are restricted to Stanford users.
HTTP	80/TCP or local web proxy properties	Web/browser protocol
HTTPS	443/TCP or local web proxy properties	Secure Sockets Layer over HTTP
Kerberos	751/TCP	Kerberos client password change
Kerberos POP3	1109/TCP	Post Office Protocol v3 with Kerberos authentication
PC Leland DNS lookup ¹	53/UDP	Direct DNS lookup from client to external name servers.
PC Leland syslog call ²	514/UDP	Login information send to security for user tracking
IMAP ³	143/TCP	IMAP email protocol
AFS	7000-7008/TCP	AFS distributed file system
WS-FTP	21/TCP	Passive mode file transfer protocol
Norton Antivirus Live Updater	80/TCP or local web proxy properties	Web access of Norton virus definition site

1 This is a bug which will be corrected in future releases. Currently in version 2.1.1 build 2, this port is required for PC-Leland to function.

2 This is optional in the sense that the client will work without this port being permissioned.

3 This port is only needed if IMAP is being used for email by the Stanford University client.

4 Of the above listed ports, 113/TCP will likely cause the greatest concern to a local security administrator since it requires a privileged port to listen for external connections.