iSeries™ uses
SOCKS version 4 to enable programs that use the AF_INET address family with
SOCK_STREAM socket type to communicate with server programs that run on systems
outside a firewall.
A firewall is a very secure host that a network administrator places between
a secure internal network and a less secure external network. Typically such
a network configuration does not allow communications that originate from
the secure host to be routed on the less secure network, and vice versa. Proxy
servers that exist on the firewall help manage required access between secure
hosts and less secure networks.
Applications that run on hosts in a secure internal network must send their
requests to firewall proxy servers to navigate the firewall. The proxy servers
can then forward these requests to the real server on the less secure network
and relay the reply back to the applications on the originating host. A common
example of a proxy server is an HTTP proxy server. Proxy servers perform a
number of tasks for HTTP clients:
- They hide your internal network from outside systems.
- They protect the host from direct access by outside systems.
- They can filter data that comes in from outside if they are properly designed
and configured.
HTTP proxy servers handle only HTTP clients.
A common alternative to running multiple proxy servers on a firewall is
to run a more robust proxy server known as a SOCKS server. A SOCKS server
can act as a proxy for any TCP client connection that is established using
the sockets API. The key advantage to iSeries Client SOCKS support is that
it enables client applications to access a SOCKS server transparently without
changing any client code.
The following figure shows a common firewall arrangement with an HTTP proxy,
a telnet proxy, and a SOCKS proxy on the firewall. Notice that the two separate
TCP connections used for the secure client that is accessing a server on the
internet. One connection leads from the secure host to the SOCKS server, and
the other leads from the less secure network to the SOCKS server.
Two actions are required on the secure client host to use a SOCKS server:
- Configuration of a SOCKS server. On February 15, 2000, IBM® announced
that the IBM Firewall
for iSeries product
(5769-FW1), which provides SOCKS server support, is not enhanced beyond its
current V4R4 capability.
- On the secure client system, define all outbound Client TCP connections
that are to be directed to the SOCKS server on the Client system. You can
define the secure client SOCKS configuration entries by using the SOCKS tab
found under the iSeries Navigator
function of iSeries Access
95 or Microsoft® Windows
NT®. The SOCKS tab has substantial help on configuring the secure client
system for Client SOCKS support.
To configure client SOCKS
support, follow these steps:
- In iSeries Navigator,
expand your .
- Right-click TCP/IP Configuration.
- Click Properties.
- Click the SOCKS tab.
- Enter your connection information about the SOCKS page.
Note: The secure client SOCKS configuration data is saved in the file
QASOSCFG in library QUSRSYS on the secure client host system.
When configured, the system automatically directs certain outbound connections
to the SOCKS server you specified on the SOCKS page. You do not need to make
any changes to the secure client application. When it receives the request,
the SOCKS server establishes a separate external TCP/IP connection to the
server in the less secure network. The SOCKS server then relays data between
the internal and external TCP/IP connections.
Note: The remote host on the less secure network connects directly to the
SOCKS server. It does not have direct access to the secure client.
Up to this point, outbound TCP connections that
originate from the secure client have been addressed. Client SOCKS support
also lets you tell the SOCKS server to allow an inbound connection request
across a firewall. An Rbind() call from the secure client
system allows this communication. For Rbind() to operate,
the secure client must have previously issued a connect() call
and the call must have resulted in an outbound connection over the SOCKS server.
The Rbind() inbound connection must be from the same IP
address that was addressed by the outbound connection that the connect() established.
The following figure shows a detailed overview of how sockets
functions interact with a SOCKS server transparent to the application. In
the example, the FTP client calls the Rbind() function
instead of a bind() function, because the FTP protocol
allows the FTP server to establish a data connection when there is a request
from the FTP client to send files or data. It makes this call by recompiling
the FTP client code with the __Rbind preprocessor #define, which defines bind() to
be Rbind(). Alternatively, an application can explicitly
code Rbind() in the pertinent source code. If an application
does not require inbound connections across a SOCKS server, Rbind() should
not be used.
Notes: - FTP client initiates an outbound TCP connection to a less secure network
through a SOCKS server. The destination address that the FTP client specifies
on the connect() is the IP address and port of the FTP
server located on the less secure network. The secure host system is configured
through the SOCKS page to direct this connection through the SOCKS server.
When configured, the system automatically directs the connection to the SOCKS
server that was specified through the SOCKS page.
- A socket is opened and Rbind() is called to establish
an inbound TCP connection. When established, this inbound connection is from
the same destination-outbound IP address that was specified above. You must
pair outbound and inbound connections over the SOCKS server for a particular
thread. In other words, all Rbind() inbound connections
should immediately follow the outbound connection over the SOCKS server. You
cannot attempt to intervene non-SOCKS connections relating to this thread
before the Rbind() runs.
- getsockname() returns the SOCKS server address. The
socket logically binds to the SOCKS server IP address coupled with a port
that is selected through the SOCKS server. In this example, the address is
sent through the "control connection" Socket CTLed to the FTP server that
is located on the less secure network. This is the address to which the FTP
server connects. The FTP server connects to the SOCKS server and not directly
to the secure host.
- The SOCKS server establishes a data connection with the FTP client and
relays data between the FTP client and the FTP server. Many SOCKS servers
allow a fixed length of time for the server to connect to the Secure client.
If the server does not connect within this time, errno ECONNABORTED is encountered
on the accept().