next up previous contents
Next: 8.3 A Joint Solution Up: 8. Case Studies - Previous: 8.1 Packet Filters

Subsections

8.2 Application Proxies

8.2.1 Our Feature Application Proxy

The TIS FWTK is a suite consisting of the following components:

8.2.1.1 Proxy Servers

The suite includes proxy servers for telnet, ftp, SMTP, rlogin and http. A plug-board connection server is also provided. The plug-board server is included primarily for use in proxying Network News. It can be used as a proxy for other services for which custom proxy servers do not exist. The proxy servers generally replace the normal service daemons. However, the normal service daemons can be configured for use together with the gateways. We will see an example of how to achieve this in the example section. For an in-depth look at proxy server setup together with their perfomance issues, the reader is referred to [16].

All the proxy servers are configurable and indeed are configured from a central file, called ``netperm-table''. This file contains information on the configuration of each service, including any restricted access information.

8.2.1.2 Network Access Control List

Access lists to services are provided by a program called ``netacl''. Through this program, are run all the services that require restricted access. As mentioned above, all the proxies are configured in a central file. It is this same file that is used by the ``netacl'' program in its evaluation of who is allowed to use which service. Network access control is based on the source IP address. In this sense, it plays a similar purpose to a packet filter, but at a higher level.

8.2.1.3 Authentication Server

The authentication server provides a second level of restriction for services. This is the layer of the application gateway that discriminates by username and password pairs. The authentication server allows new users and groups to be created in the authentication server database. User and group administrators can add new users and give privileges to other users. The authentication server is provided mainly for the rlogin and telnet services. Although it can be used with other services, it is designed for, and works for, the aforementioned services.

8.2.1.4 Client Programs

The only client programs supplied with the version of the firewall that we obtained are ftp and telnet clients. Both these clients allow the user to be completely unaware of the firewall. When users use the above-mentioned clients, they only have to worry about their destination host. Connections to the firewall, and the connections from the firewall to the destination host, are handled by the clients. If authentication is required for the service on the firewall, the user is prompted for the relevant information.

8.2.1.5 Reporting scripts

As mentioned in our initial discussion of application proxies, they log more, and better than packet filters. Since they work at the service level and not only with source and destination addresses and ports, they log all the relevant information about a connection to a service. The reporting scripts allow for easy reporting on the information that has been logged. They parse the log files and report on the service whose statistics are required, the day's statistics or the week's statistics.

8.2.1.6 Documentation

The toolkit comes with extensive documentation. The documentation can be separated into four categories:

1.
An overview of the toolkit, its influence and impact on the organization.
2.
Documentation for the system administrator on how to set the firewall up.
3.
Documentation for the user on the workings of the firewall and the how the firewall impacts on the user.
4.
Manual pages for all components of the toolkit.

8.2.1.7 Sample Configurations

The toolkit is distributed with a version of the syslog daemon. A sample configuration of this new daemon is included as part of the kit. A local configuration file on how to start the services when the host ``boots up'' is also included. Examples of how to run the services from the inetd daemon are also included. Finally, a sample ``netperm-table'' is included to show how to provide and restrict access to the proxies.

8.2.2 The 'netperm-table' file and configuration issues

An entry in the ``/etc/inetd.conf'' file for telnet looks may follows :

telnet  stream  tcp  nowait  root  /usr/local/etc/netacl in.telnetd
The above entry looks similar to the normal entry for the telnet service in the ``inetd'' configuration file. The only part that has been modified is the sixth field which is the ``server program''. In this case our server program is the network access list program. Let us now have a look at how an entry in ``netperm-table'' would look.

netacl-in.telnetd: permit-hosts 146.231.128.* -exec /usr/sbin/in.telnetd

netacl-in.telnetd: permit-hosts * -exec /usr/local/etc/tn-gw

The ``netacl-`` part of the above rules shows that the rules are for the network access control program. It is followed by the name of the actual server name or program to be run. If the daemon being executed in ``/etc/inetd.conf'' is called ``telnetd'', its entry in the netperm-table should be ``netacl-telnetd''. This is an important point, as it can lead to a lot of confusion if the convention is not followed properly.

The next keyword of interest in the above rules is ``permit-''. Entries beginning with ``permit-'' or ``deny-'' are flagged internally as either granting or revoking permission to the service. The next keyword is ``hosts''. This keyword gives us the ability to list the names and/or IP addresses of hosts we wish to allow to use the service. Wildcards are allowed as arguments for this keyword. The next keyword to note is ``-exec''. This allows us to execute different programs depending on where the request to the service originated. The keyword is followed by the complete path of the program to be executed.

The above rules allow hosts on the network 146.231.128.x to telnet into the firewall machine and be able to login into the firewall itself. All other hosts that telnet into the firewall machine are presented with the telnet gateway. Rules for the telnet gateway would have to be specified in the netperm-table file if it is being executed.

8.2.2.1 Configuration Issues

8.2.2.1.1 The netacl program

The netacl program provides access control for programs that have been invoked by inetd. Instead of inetd calling the service itself, it calls netacl. Netacl then searches through the rules in the netperm-table file for ones that matches the requested service. If the host that initiated the connection is found to have authorization to access the service, the real server is run. If the host is found not to have authorization, the request is logged and netacl exits.

Netacl comes with a few options but we shall only consider a few. The first option is the ``hosts'' option. This option is the same keyword that we identified above when looking at an example of a service configuration. It allows us to list the hosts which are allowed or denied (flagged by permit- or deny-) to use a certain service. The list of hosts allowed or denied access to a service is optionally followed by a options flags. ``-exec'', we have already shown above, is one of these options. The other option we will consider is the ``-user'' option. It allows us to specify who the server is run as. An example of a command including all the options follows:

netacl-telnetd: permit-hosts 146.231.128.* -exec /usr/sbin/telnetd -user siviwe

8.2.2.1.2 The Telnet Gateway (tn-gw)

The telnet gateway also comes with a variety options. As with the netacl program, we shall consider only the few which are of particular interest to us. Configuration lines for the telnet gateway and for all the other proxies appear in the netperm-table file as follows:

proxy-name: configuration options
The telnet gateway also has a ``hosts'' option followed by a pattern. More than one host patterns may be used by separating them with spaces. Here too the pattern is followed by some extra optional options. The first of these options that we shall consider is the ``-auth'' option. This option specifies that before the user connected to the gateway can use it, he has to be authenticated with the authentication server. The next option we shall consider is the ``-dest'' option. The ``-dest'' option is either followed by one pattern in the form ``-dest pattern'' or by a group of patterns in the form ``-dest {pattern1 pattern2 ...}''. The ``-dest'' option allows us to specify which are suitable or allowed destinations for a particular rule of our configuration. The default configuration allows all destinations. The ``-dest'' option also allows us to specify destinations we think are unsuitable or not allowed. The form of that configuration option is ``-dest !pattern''. Let us put this together into a rule

tn-gw: permit-hosts 146.231.128.* 146.231.24.* -dest !*.hack.com -dest *.com 
Other options of the telnet gateway that we shall consider are informational. The first of these options is ``denial-msg''. It has the form ``denial-msg filename''. When an unauthorized host connects to the gateway, the message contained in filename will be displayed. The next option for consideration is ``welcome-msg'' which has the same form as ``denial-msg''. The filename specified with the ``welcome-msg'' option is displayed as a welcome banner after successful connection. The last of the options we shall consider is the ``denydest-msg'' option. It has the same as the previous two options we discussed. The contents of its filename parameter are when the gateway is instructed to connect to a destination which is not permitted. Let us see examples of these options.

tn-gw: denial-msg /usr/local/etc/telnet-deny.txt

tn-gw: welcome-msg /usr/local/etc/telnet-welcome.txt

tn-gw: denydest-msg /usr/local/etc/telnet-denydest.txt

8.2.2.1.3 The FTP Gateway (ftp-gw)

The FTP gateway provides in the same manner as discussed for the telnet gateway, the rules ``denial-msg'', ``welcome-msg'' and ``denydest-msg''. The gateway also provides a ``hosts'' rule. The options that may be applied to this rule differ from the telnet gateway's and will be discussed. The first option to note is the ``-log''. The option specifies the operations to log. It takes either the form ``-log operation'' or ``-log {operation1 operation2 ...}''. The next option to note is the ``-auth'' option. This option specifies commands which may not be executed except when authenticated. It takes either the form ``-auth operation'' or ``-auth {operation1 operation2 ...}''. The last option for our consideration is the ``-dest'' option. This functions in the same way as in the telnet gateway. A sample follows:

ftp-gw: hosts 192.82.142.* 196.21.104.* -auth { list retr stor } 

                                        -log { retr stor } -dest !*.com

8.2.2.1.4 The SMTP Gateway (smap, smapd)

8.2.2.1.4.1 smapd

smapd has five configuration rules that we will consider. The first of the configuration rules is mandatory and is the ``executable''. The parameter to this rule is the path to the smapd executable. The next rule we shall consider is ``sendmail''. Its parameter specifies the path to the sendmail or other mail transfer agent (MTA). The ``userid'' rule's parameter specifies the userid under which smapd is to be run, for security reasons. The ``directory'' rule has its parameter specifying the spool directory. It should be noted that this spool directory has to be readable and writable by the userid given with the ``userid'' option. The last of the smapd rules is ``wakeup''. This specifies the amount of time (in seconds) after which smapd should check the spool directory for new mail.

8.2.2.1.4.2 smap

smap also has ``userid'' and ``directory'' rules. These rules can be shared with the smapd rules. The next rule to consider is the ``maxbytes'' rule. It specifies the maximum amount of bytes that a mail message is allowed to be. The last of our smap rules for consideration is the ``timeout'' rule which specifies the amount of time (in seconds) smap should wait when collecting a message before giving up on it.

Example rules for smapd and smap follow:

smap: timeout 3600

smap: maxbytes 4000

smapd: wakeup 60

smapd: executable /usr/local/etc/smapd

smapd: sendmail /usr/local/exim/bin/exim

smap, smapd: userid 511

smap, smapd: directory /var/spool/smap

8.2.2.1.5 The Plug-Board (plug-gw)

The plug-board has two primary options. The ``timeout'' option works in the same way as the one described for SMTP gateway above. The second primary option is the ``port'' option. The ``port'' option is followed by the port-ID which may either be a port number or the name of a service associated with a port, from /etc/services. The port-ID represents the port to bind to. The port-ID is followed by a host-pattern which indicates hosts allowed to connect to that service. There are secondary options to the ``port'' option. The first is the ``-plug-to'' option. Its form is ``-plug-to hostname'' where hostname represents the host to connect requests on the port-ID to. The last secondary option we will discuss is the ``-port'' option. It's form is ``-port port-ID''. The port-ID in this case represents the host to connect to on the host specified by the ``-plug-to'' option. An example rule follows.

plug-gw: port nntp 146.231.27.* -plug-to news.cnn.com -port 119

8.2.2.1.6 The Authentication Server

We will consider four of the five configuration rules the authentication server provides. The first rule under consideration is the ``database'' rule. This specifies the location of the authentication database. The database is stored in dbm(3) format. The second rule for consideration is the ``nobogus true'' rule. The rule specifies that the authentication server should be as unfriendly to the user as possible, returning ``Permission Denied'' instead of a useful error message. The third rule for noting is the ``badsleep'' rule. The rule specifies the number of seconds for which a user should be locked out after repeated bad logins. After more than five attempts when the ``badsleep'' value is not set, the user is locked out of the account. If the value is set however, the user may attempt to login after the number of seconds specified by the ``badsleep'' rule has expired. The last rule for our consideration is the ``hosts'' rule. The syntax and semantics of this rule are the same as for the previously discussed proxy servers. The difference with the ``hosts'' rule here is that if an optional DES key is supplied, communication will be encrypted and decrypted using the key. Sample authentication server configuration rules follow.

authsrv: database /usr/local/etc/authdb

authsrv: permit-hosts 146.231.128.*

authsrv: nobogus true

authsrv: badsleep 1200

New users can be added with the ``adduser'' command either from the authentication manager or connecting to the authentication server. For more details, see the manual pages on the authentication server, client and manager. An example of how a new user can be added to the authentication server's database follows:

% Create a username "siviwe" with the fullname "Siviwe Kwatsha"

adduser siviwe 'Siviwe Kwatsha'

8.2.3 An Example


  
Figure 8.2: Representation of our network
\resizebox*{6cm}{7cm}{\includegraphics{applicationprox.ps}}


Figure 8.2 is a diagram representing our network. The network is simply an adaptation of the packet filtering diagram. Instead of the packet filter between the internal networks and the outside network, we use an application proxy. There is also the introduction of a second network separated from the ``backbone'' by a router. Here too, as with the packet filtering example, we have some policies for the network. The difference is that here the policies focus on services provided rather than which packets go through and in which direction.

Our policy has the following requirements:

8.2.3.1 Inetd setup

Our inetd(8) will start the required services using the ``netacl'' program. As we run both proxied and normal versions of the telnet and ftp services, we have a choice on how to run them. We can either decide to start the normal version of the services on a different port from the proxied one or run them both on the same port and use ``netacl''. We illustrate how to run both versions of the telnet service on the same port using ``netacl''. The proxied and normal FTP services will be run on different ports. Our ``/etc/inetd.conf'' file looks as follows:

% <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>

1: ftp     stream  tcp     nowait  root    /usr/local/etc/netacl   in.ftpd

2: ftp2    stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -l -a

3: telnet  stream  tcp     nowait  root    /usr/local/etc/netacl   in.telnetd

4: authsrv stream  tcp     nowait  root    /usr/local/etc/authsrv  authsrv

% End of inetd.conf

To add a service called ``ftp2'', we have to modify our ``/etc/services'' file and add a similar entry to the following :

ftp2          300/tcp
Line 1 of the inetd configuration file is for ftp access from outside networks. Line 2 allows us to configure an anonymous ftp service for the internal networks. The argument in line 2 corresponding ``<server_path>'' on the comment line is ``/usr/sbin/tcpd''. This program is part of Wietse Venema's tcp wrappers package discussed later. Like ``netacl'', it provides restricted access to a service and could be used instead of netacl for some services. The configuration of anonymous ftp or tcp wrappers is outside the scope of this discussion. Line 3 is the proxied telnet access. Line 4 is the authentication server which we use to authenticate users on the firewall. The service name is ``authsrv'' and is not included in the services (/etc/services) file by default. For this service too, we have to define a port number and add an entry in the services file similar to the following:

authsrv       5544/tcp

8.2.3.2 rc.local setup

The services we do not want to start from the inetd, can be started from this file. The only services which we require that have not been started from the inetd file are the SMTP services. From the example configuration of the ``rc.local'' file, we extract the following

echo 'starting FWTK daemons:'

 

% Start the SMTP queuer (smapd)

(cd /var/spool/mqueue; rm -f nf* lf*)

echo "    smtp queuer"

/usr/local/etc/smapd &

 

% Script to deliver undelivered mail

/usr/local/etc/mqueue &

 

% Start the SMTP listener (actual mail daemon that binds to port 25)

echo "    smtp listener"

/usr/local/etc/smap -daemon &

The ``mqueue'' script mentioned that is started along with the listener and queuer performs an important function. Mailer daemons such as ``sendmail'' and ``exim'' can be started with flags to tell them how often to check the queue and deliver undelivered messages. The ``smap'' program does not have the functionality built into it to do that. The ``mqueue'' script then bridges the gap by performing the queue checking and delivery function every fifteen seconds.

It should be noted that all the services could be started from the rc.local file. The inetd handles the starting and termination of services for us and is therefore the preferred method of starting some services. Starting them ourselves from the rc.local file, while they will work the same way, means that if the process we start (the parent) dies, we no longer provide that service. With inetd, connections to the port always succeed if the daemon can be found and inetd itself is running. An example how to start the services from the rc.local file through netacl follows

/usr/local/etc/netacl -daemon telnet in.telnetd &
The ``telnet'' argument in the above example specifies to which port the service is bound. The last argument (in.telnetd) specifies the server that is to be run for that service. It also specifies the string, in netperm-table, appended to ``netacl-`` referring to rules for the service.

8.2.3.3 netperm-table setup

% Telnet access

netacl-in.telnetd: permit-hosts 20.20.20.* -exec /usr/sbin/in.telnetd

netacl-in.telnetd: permit-hosts * -exec /usr/local/etc/tn-gw

 

% FTP access

netacl-in.ftpd: permit-hosts * -exec /usr/local/etc/ftp-gw

 

% Telnet gateway

tn-gw: denial-msg /usr/local/etc/telnet-deny.txt

tn-gw: welcome-msg /usr/local/etc/telnet-welcome.txt

tn-gw: denydest-msg /usr/local/etc/telnet-denydest.txt

tn-gw: hosts 20.20.30.* -dest !*.hack.com -dest !firewall -auth

tn-gw: hosts * -dest !firewall -auth

 

% Ftp Gateway

ftp-gw: denial-msg /usr/local/etc/ftp-deny.txt

ftp-gw: welcome-msg /usr/local/etc/ftp-welcome.txt

ftp-gw: denydest-msg /usr/local/etc/ftp-denydest.txt

ftp-gw: deny-hosts 20.20.30.*

ftp-gw: permit-hosts * -auth { nlist } -dest !firewall -log { retr stor }

 

% Smap and Smapd

smap, smapd: userid 511

smap, smapd: directory /var/spool/smap

smapd: executable /usr/local/etc/smapd

smapd: sendmail /usr/local/exim/bin/exim

smap: maxbytes 4000

smap: timeout 3600

 

% Authentication server

authsrv: database /usr/local/etc/database

authsrv: nobogus true

authsrv: badsleep 300

authsrv: hosts 20.20.*

 

% Clients that can use authentication server

*: authserver 127.0.0.1 5544

next up previous contents
Next: 8.3 A Joint Solution Up: 8. Case Studies - Previous: 8.1 Packet Filters
Shaun Bangay
1998-11-19