Table of Contents Implementations

6.3 Firewalls

In essence, a firewall is a barrier between a secure, internal private network and another (non-secure) network or the Internet. The purpose of a firewall is to prevent unwanted or unauthorized communication into or out of the secure network. The firewall has two jobs:

• To keep users in your own network from freely exchanging information with users outside your network
• To keep users who are outside your network from coming in to compromise or attack your network

Normally, hosts in a secure network cannot access the outside network. This reduces the risk of being intruded upon by unauthorized users from the Internet but denies Internet accessibility to users within the secure network. Without Internet accessibility, users in the secure network cannot access important tools, such as TELNET, FTP, Gopher, and World Wide Web, to access the resources available in the Internet.

There are several ways a firewall can protect your network. A firewall can provide screening services that deny or grant access based on such things as user name, host name, and TCP/IP protocol. A firewall can also provide a variety of services that let authorized users through while keeping unauthorized users out. At the same time, it ensures that all communications between your network and the Internet appear to end at the firewall, allowing the outside world no glimpse of the structure of your network.

6.3.1 IBM NetSP Secured Network Gateway

The IBM NetSP Secured Network Gateway (NetSP) is a network security firewall program for AIX/6000. NetSP offers a secure internal network and is very selective about who it lets in. In order to control access between your network and the Internet and facilitate authorized transactions, the NetSP Secured Network Gateway provides these services and barriers:

Proxy Servers

A proxy server is, in essence, an application gateway. A gateway from one network to another for a specific network application like TELNET or FTP for example. To get to a TELNET or FTP server outside the secured network the user has to go through a two step process:

1. The workstation user starts his TELNET or FTP client to connect to the proxy server at the firewall. The proxy server then asks the user for the name of the remote host to be accessed.
2. The proxy server relays an authorized TELNET or FTP request to the intended remote host.

For example a user inside a secure network would use TELNET to log into the firewall's proxy TELNET server, telnetd. Once telnetd checks the user's credentials, and the user's permission to cross the firewall with TELNET, telnetd, in turn, logs into the remote host specified by the user. It appears that data and commands then flow through the proxy TELNET server as if it were not there. The disadvantage of this concept is that the real TCP/IP function is performed in the firewall and not in the client workstation. This causes more processing load in the firewall than using SOCKS Services.

SOCKS Servers

SOCKS servers (SOCKets Secure) intercept and redirect all TCP/IP requests at the firewall. It handles data to and from many types of applications such as TELNET, FTP, Mosaic, WebExplorer and Gopher. The sockd daemon is a secure Internet socket server that provides users in a secure network access to resources outside that network by directing data through the firewall. To cross the firewall users must use client programs that are designed especially to work with the sockd server. These "SOCKS-ified" clients replace their normal TCP/IP counterparts. The Secured Network Gateway provides the following AIX servers:

• rtelnet in place of telnet
• rftp in place of ftp
• rfinger in place of finger
• rwhois in place of whois

The only difference between a normal and a "SOCKS-ified" client are the socket calls used by the client application. The normal C library socket calls are replaced by SOCKS library calls. The SOCKS routine names are the C sockets names preceded by an "R", for example connect() becomes Rconnect(). The parameters accepted are the same. The client application uses remote sockets residing on the firewall.

A TELNET connection for example works like this:

1. You start the rtelnet application to log into a remote host outside the secure network.
2. The rtelnet sends that TELNET request to the SOCKS server (sockd) in the firewall host.
3. sockd checks the user's identity and, if correct, connects the user to the requested remote host.
4. After establishing the connection, the SOCKS server acts as a secure pipeline to the remote host. The TELNET user is unaware of its existence.

To the user, this is only a one-step process.

The advantage of this concept is that the real TCP/IP application (TELNET for example) runs on the client workstation, not in the firewall. This saves processing in the firewall.

In summary, you need only the SOCKS version of the client at the workstations in your network. You can remove, or save and rename, standard versions and rename the SOCKS versions to replace them. For example save the standard telnet and rename rtelnet to telnet. The users will not see the difference.

The IBM WebExplorer shipped with OS/2 Warp supports SOCKS. You only have to name your SOCKS server at the Configure - Servers menu.

Filters

Provide ways to limit user access into or out of a secure network based on:

• Source IP address
• Destination IP address
• IP protocol (UDP, ICMP, TCP and TCP-with-acknowledgment)
• Port
• Network adapter (secure or non-secure)
• Direction

By default the firewall denies all access between the secure and non-secure network.

Domain Name Service

If you want to isolate the domain name services that are accessible from the secure network from those outside your network so that your internal network structure is not visible outside, you need two domain name servers:

• One domain name server, on the firewall host, responds to requests from outside your network, and resolves outside host names in response to requests from inside the secure network. The response to external requests includes the IP address only to hide the internal network structure.
• Another domain server, inside the secure network, resolves secure addresses in response to requests from inside the secure network. The internal nameserver knows all the internal hosts and consults the domain name server on the firewall if it cannot satisfy a request.

Mail Handler

NetSP provides mail handling at the firewall host. You provide a secure mail handler in the secure network. When mail arrives at the firewall, the firewall domain name server and the firewall mail handler forward the incoming mail to your internal mail server which, in turn, forwards it to the target host. For mail going out to the non-secure network, your secure hosts send their mail to the secure mail server which, in turn, sends it via the mail handler in the firewall to the non-secure network. Users outside see only the host name and the address of the firewall and not any secure host.

Table of Contents Bibliography