|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
ncsa |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
User Information Home
 NCSA's Help Desk is available 24 hours a day, seven days a week, 365 days a year: Kerberos and SSH through Firewalls and NATsThis document is meant as a guide to a firewall administrators or site administrators who use Network Address Translation (NAT) trying to allow users behind their firewall or NAT to use SSH (secure shell) or Kerberos clients to access servers outside. Much of the information on this page, while believed accurate, has not been tested, because we don't have a firewall.
Table of Contents
What traffic must I allow through my firewall in order to use SSH?A SSH connection looks very much like a telnet connection, except that the SSH daemons runs on tcp port 22 and not port 23. So from the client to the daemon you need to allow tcp traffic on port 22. In the return direction you will need to allow tcp traffic on an ephemeral port number (>1024).
What if I want to access NCSA's internal server through a firewall?Connecting to NCSA's internal server is very similar to connecting to a standard web server, however, the secure server runs on port 443. So you need to allow tcp traffic on port 443. In the return direction you will need to allow tcp traffic on an ephemeral port number (>1024).
What traffic must I allow through my firewall in order to use Kerberos?There are three components in the Kerberos world: the kerberos client applications (e.g. kinit, telnet, pop), the server applications (e.g. telnetd, popper), and the Kerberos KDC. Each pair has different types of traffic that go between them. Depending on the pair of components your firewall is between, you will need to allow different types of traffic through your firewall.The notation 'xxxx/udp' or 'xxxx/tcp' below refers to an ephemeral port number (>1024). This refers to a return port that is assigned by the system. The only assumption you can make about the port number is that it will be greater than 1024. Between a client program and the KDC, your firewall may need to allow traffic on the folowing ports/protocols:
Between an application server and the KDC, your firewall may need to allow traffic on the folowing ports/protocols:
Between an client program and an application server, your firewall may need to allow traffic on the folowing ports/protocols:
An ExampleA common example is that you are on one side of a firewall (call it the inside) and you want to make a Kerberos telnet connection to a box on the outside of the firewall. First you would need to run kinit, which means the firewall would need to allow your udp traffic to port 88 to pass out and the return traffic to some ephemeral udp port (>1024) to pass back in. This allows you to get your Kerberos ticket.Now you run telnet to connect to the tar host outside the firewall. First telnet gets a Kerberos service ticket. It does this using the same UDP ports as kinit does, so assuming kinit works this poses no additional requirements. Then telnet would make a connection to the telnet deamon running on the target machine. Note that this uses the same ports for here on out as a non-kerberized telnet connection. So you would need to allow traffic to TCP port 23 out of the firewall and return traffic to some ephemeral tcp port (>1024) to pass back in. If you wanted to make a Kerberos rlogin connection (un-encrypted) instead. The example would be the same as the above, except instead of allowing traffic on TCP port 24 out, you would need to allow traffic on TCP port 543 out.
What if I have a proxy firewall that does network address translation?With ssh this is not believed to be a problem, as it does no checking of IP addresses in the application.With kerberos this is a known problem. Kerberos application servers generally look at the user's ticket when the user authentications and check an IP address embedded in the ticket against the IP address the connection is coming from. This is done as a security measure to help prevent a stolen ticket from being used. What needs to be done is that extra IP addresses must be added to the Kerberos ticket when it is acquired initially. A patch to the Kerberos sources, written by Ken Hornstein, to allow this can be found at ftp://ftp.ncsa.uiuc.edu/aces/kerberos/misc_patches/patch.app-proxy. This patch is included in all NCSA Kerberos binary distributions for Windows since September 29, 1998 and all distributions for Unix. Assuming you have the above patch installed you need to edit your Kerberos configuration file (usually /usr/local/krb5/etc/krb5.conf or /etc/krb5.conf on Unix machines, and krb5.ini in your Windows or WinNT directory). In the configuration file you will find a section labeled [libdefault], in this section you need to add a line for your proxy gateway (you may add more than one if you have multiple gateways). The line should look like:
proxy_gateway = ip address
Where ip address is the ip address of the outgoing side of the
proxy gateway. This is the ip address that the target system should see
as the source address in the ip packets.
For example, let's say you are at system doing a telnet to a target system through a gateway that translates addresses so that they appear to be coming from the ip address 10.11.12.13. Your krb5.conf would need a libdefaults section that looked like:
[libdefaults]
...some other lines here...
proxy_gateway = 10.11.12.13
Questions or comments about this page may be sent to kerberos@ncsa.uiuc.edu
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
