Institut für Astronomie und Astrophysik Abteilung Astronomie Sand 1, D-72076 Tübingen, Germany
Hinweis: Einige Seiten auf astro.uni-tuebingen.de können veraltet sein und werden nicht mehr aktualisiert. Note: Some webpages at astro.uni-tuebingen.de may be outdated and will no longer be updated.

Firewalls: The Gory Technical Details

Frequent hacker attacks, especially on our Linux machines, have forced us to protect the machines at IAAT with a firewall. A firewall is a computer that looks at incoming and outgoing internet traffic ("IP Packets"). Depending on the type of IP Packet and on the type of connection requested the firewall grants access to the IAAT machines or denies the connection by dropping the IP-packet. When the packet gets dropped, the machine requesting the connection never gets an answer, trys again, and after a few minutes the connecting program gives up and returns a time-out error message to the user trying to connect.

Apart from the data they transport, each IP-Packet contains two adresses. First, an IP-Packet is adressed to a machine by using the IP-adress. For astro.uni-tuebingen.de, e.g., the IP-address is 134.2.76.76. Apart from this well known type of address, the packet is also adressed to a certain service. This service is identified by adressing the IP-Packet to a certain port on the server machine. For example, when making an email connection with astro.uni-tuebingen.de, an IP packet gets send to IP-adress 134.2.76.76 port 25. On Unix machines a list of services and their corresponding port-numbers can be found in the file /etc/services.

For each IP service, e.g., telnet, smtp (email), http (WWW connections) and so on, a server process is running on the server machine, which listens to connections to ``its'' port. For example, the sendmail process, which is responsible for accepting email, listens at port 25. Whenever somebody sends email to the machine, the IP-packets are adressed to port 25 to initiate the connection. sendmail responds to this request by sending another IP packet back to the initiating machine, telling the initiating machine to send all its data to some (arbitrary) data port, which we will call x for the moment. After this initial handshake, sendmail listens at port x to receive the email message. The cause for this rather complicated process is that each port can only be used by one machine at a time. Therefore, to allow the reception of further email messages, the data dialogue between the two computers, which might take a long time, has to be done on port x to leave port 25 free for other incoming email.

In order to avoid chaos with different machines using different ports for the same services, the port numbers for Unix processes are standardized. Port numbers below 1024 (i.e., ports 0 to 1023) are reserved for root processes, while port numbers above 1023 (1024 to 65535) are free for data connections and user processes.

Since data connections need to be allowed by a firewall, firewalls typically allow established connections to ports above 1023 (with the exception of a few notorious ports, like those of the X-window system), but only allow initiating connections to a few selected ports below 1023. For example, at IAAT, incoming http requests are only allowed to astro.uni-tuebingen.de, and only to port 80. The result of this selection is that incoming requests to ports below 1023 are generally dropped by the firewall, with the exception of those few services that are allowed to pass through.

For the purposes of understanding why we cannot allow the use the standard FTP PORT mode at IAAT, we need to look at how the FTP server and the FTP client talk to each other. First of all, the FTP dialogue is more complicated than the process outlined above. FTP uses two connections, one to transport the FTP commands, and one to transport the FTP data. Thus, commands like mget *, dir, and so on are transported using the ``command channel'', while the data is transported via the data channel. The latter transport requires the initiation of another connection, and unfortunately for us, standard old PORT mode of FTP requires the initiation of a connection to a random port below1023. Obviously, allowing such connections to pass through the firewall would negate its purpose. Therefore: PORT mode is not possible to servers behind a firewall.

A solution to this problem was the invention of the ``passive FTP mode'', where the connection for the data channel follows the procedure outlined above for normal TCPIP connections. Since only ports above 1023 participate in this process, it is safer than normal PORT mode. For an academic research environment like IAAT, therefore, PASV mode through the firewall seems acceptable.

[Home Page] [Software, Documentation] [Quick Reference] [Feedback]