|
|
| Previous | Table of Contents | Next |
When netacl is configured for the service that you want to provide, you should test it to ensure that it is working. Testing requires verifying rules configured for that service to ensure that they are in fact operating as they should. Consider the following rules:
netacl-ftpd: permit-hosts 204.191.3.147 -exec /usr/libexec/ftpd -A -l
This rule says that FTP connections will be accepted only from the host 204.191.3.147. When this connection is received, the ftpd server with the appropriate arguments will be started. This can be evaluated by connecting to the FTP server from the authorized host, as illustrated here:
C:\ >ftp pc Connected to pc.unilabs.org. 220 pc.unilabs.org FTP server (Version wu-2.4(1) Fri Feb 3 11:30:22 MST 1995) ready. User (pc.unilabs.org:(none)): chrish 331 Password required for chrish. Password: 230 User chrish logged in. ftp>
As you can see from this output, the connection from the authorized machine to the target system did in fact work. This could further be validated by examining the syslog records for the target system where any transfers may in fact be logged. The availability of this feature depends on the implementation of the ftpd that is in use at your site.
Another security breach you want to avoid is granting a non-authorized system a connection. To illustrate, consider the exchange:
pc# ftp pc Connected to pc.unilabs.org. 421 Service not available, remote server has closed connection ftp>
The connection is initially established, but after netacl has performed verification of the rules, it finds that the host is not permitted access, and the connection is closed. On the target system, a deny informational message is written to the syslog and to the console:
Oct 4 02:53:12 pc netacl[1775]: deny host=pc.unilabs.org/204.191.3.150 service=ftpd
In this case, the remote system received no information other than the connection has been closed. Meanwhile, the system administrator knows that the remote has been attempting to gain access. If this occurs enough, some other action may be required against the remote user.
Such a blunt response to an unauthorized attempt to gain access might not be the most appreciated. For this reason, you might be wise to consider a rule like the one shown here:
netacl-ftpd: permit-hosts 204.191.3.147 -exec /bin/cat /usr/local/etc/noftp.txt
In this case, a user who attempts to connect from the site 204.191.3.147 will not be refused a connection; he or she will just not get what they want. With this configuration, you can log the connection, and tell the user that he or she is not permitted access to the requested service. For example, when you attempt to connect to your server, the /usr/local/etc/noftp.txt file displays this response:
C:\ >ftp pc Connected to pc.unilabs.org. **** ATTENTION **** Your attempt to use this server’s FTP facility is not permitted due to organizational security policies. Your connection attempt has been logged and recorded. Use of the FTP Services on this machine is restricted to specific sites. If you believe that you are an authorized site, please contact Jon Smith at 555-1212 ext 502, or e-mail to ftpadmin@org.com. Connection closed by remote host. C:\ >
Any type of message can be displayed here instead of allowing access to the requested service. This “denial” can be for system administration purposes, for example, or because of maintenance.
Remember that after each reconfiguration of the inetd.conf file, inetd must be restarted. To do this, you must find the Process ID or PID number for inetd and send a SIGHUP to it. The following commands are used in this process:
Signaling inetd pc# ps -aux | grep inetd root 1898 0.0 0.2 120 28 p3 R+ 10:46AM 0:00.02 grep inetd root 75 0.0 1.5 140 220 ?? Is 11:19AM 0:00.25 inetd pc# kill -1 75 pc#
When inetd has been signaled with the -1, or SIGHUP, it rereads the /etc/inetd.conf file and applies the new configuration immediately.
Note: You might have to send a second SIGHUP signal to inetd to make the changes permanent. Specific systems are IRIX and some versions of SunOS.
This is the most common problem that system administrators have when changing the configuration file. They make the change, but forget to restart inetd.
The telnet proxy, tn-gw, provides pass-through telnet services. In many circumstances, a system administrator may not want to allow telnet access through the firewall and either into or out of the private network. The telnet proxy does not provide the same type of access to the firewall host as the netacl program. The intent behind using Telnet with netacl is to allow access to the firewall host. With the proxy, the intent is to provide pass-through telnet with logging control.
Because of the dilemma of allowing remote administrative access and establishing a proxy telnet, it is common for the firewall administrator to run the real telnetd on a TCP port other than the default, and to place the proxy on the standard TCP port. This is accomplished by editing the /etc/services file and changing it to be something similar to the following:
telnet 23/tcp telnet-a 2023/tcp
These changes are only effective after /etc/inetd.conf has been changed to reflect the configuration shown here:
telnet stream tcp nowait root /usr/local/etc/tn-gw tn-gw telnet-a stream tcp nowait root /usr/local/etc/netacl telnetd
| Previous | Table of Contents | Next |