Table of Contents Implementations
TCP/IP Tutorial and Technical Overview
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.
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:
For further information please refer to IBM NetSP Secured Network Gateway
Installation, Configuration, and Administration Guide, SC31-8113-00.
- 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:
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
- 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.
- The proxy server relays an authorized TELNET or FTP request to the intended
- 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:
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.
- rtelnet in place of telnet
- rftp in place of ftp
- rfinger in place of finger
- rwhois in place of whois
A TELNET connection for example works like this:
To the user, this is only a one-step process.
- You start the rtelnet application to log into a remote host outside
the secure network.
- The rtelnet sends that TELNET request to the SOCKS server
(sockd) in the firewall host.
- sockd checks the user's identity and, if correct, connects the user
to the requested remote host.
- After establishing the connection, the SOCKS server acts as a secure
pipeline to the remote host. The TELNET user is unaware of its existence.
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.
- Provide ways to limit user access into or out of a secure network based on:
By default the firewall denies all access between the secure and non-secure
- Source IP address
- Destination IP address
- IP protocol (UDP, ICMP, TCP and TCP-with-acknowledgment)
- Network adapter (secure or non-secure)
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.
- 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