Freeware-Based Security
Syed Ali Press coverage of security measures such as advanced firewalls, tunneling, and so forth diverts our attention from less sophisticated measures that may provide adequate security. In this article, I explore various freeware security measures and provide rudimentary information about obtaining and installing them. Security can be classified into host-based, network-based, remote access, and physical. Host-based security tools would prevent Trojan horse attacks. Network-based security tools would assist in port monitoring, detection of port scanning, and access control. Remote access security would enable a secure channel for remote communication. Physical security would ensure that servers are not damaged physically. Any of the mentioned attacks can be detected using event detection. In general, protecting against Trojan horses, controlling access, actively monitoring your system, and using a secure shell will lead to a system that is sufficiently secure for most needs. There are many freeware security tools available on the Internet, and I will give a brief description of a few. Keep in mind, though, the first step toward a more secure environment is installing the vendor-recommended security patches. Tripwire for Trojans Once a cracker manages to break into your system, most often he or she will install a Trojan horse so that access in the future will be easier. The most common Trojan horses include a tainted /bin/login that will allow a specified user root access. Other Trojan horses include tainted /bin/su that will grant root access without a password when invoked with a particular option. Tripwire is one way to make sure these binaries and other important files are not tainted. Installation of Tripwire is relatively complex. It involves checking the makefile to ensure that the C compiler settings are okay, then checking the configs directory to match a config file with your OS. This config file name will need to be entered in the include/config.h file. Then, look in the configs directory to match a tw.conf file for the OS on which Tripwire will be compiled. Run make at the top level of your tripwire source directory. This will produce the needed binaries, but will not install them. Run make test to test the configuration file. Then, copy the Tripwire binary to /usr/local/bin and the configuration file to a read-only filesystem if possible. The heart of Tripwire is the tw.conf file. In this file, you specify which files Tripwire needs to track. Besides the common files, such as /etc/passwd, different UNIX flavors have different configuration files in different locations. When you choose the tw.conf file for your flavor of UNIX, it includes a default set of files. You should look at these defaults and add or delete target files as appropriate for your site. Tripwire can be run in four modes: database generation, integrity checking mode, interactive mode, and database update mode. The database generation mode will generate a database file based on tw.conf. The database file will be used in the future to compare any changes, additions, and deletions to tw.conf and the file specified in tw.conf. This mode is invoked by using the -initialize option to Tripwire. In the integrity checking mode, Tripwire will check all files specified in the tw.conf file. It will notify the user of any discrepancies between the original file and the changed file. No options are needed, and this mode can be invoked by simply typing in tripwire. Running Tripwire in interactive mode is similar to the integrity checking mode with the difference that whenever a deleted, added, or changed file or directory is encountered, Tripwire asks the user whether the database entry should be updated. This mode is invoked by using the -interactive option. In the database update mode, Tripwire will note the changes, additions, and deletions of files and will update the current database without asking for confirmation. This mode is invoked by using the -update option. Tripwire comes with eight different signature routines: MD5, Snefru, MD4, MD2, SHA, Haval, CRC-32, and CRC-16. The CRC signature routines use simple polynomial division to generate the checksums, whereas the other six routines are all examples of message-digest algorithms, otherwise known as one-way hash functions. Tripwire can be obtained at:
ftp://coast.cs.purdue.edu/pub/Purdue/Tripwire Access Control with tcp_wrapper Unrestricted access to a host often leads to unwanted access. If you have a server on the Internet, and you know which hosts connect to it and what protocol they use, then tcp_wrapper will enable you to restrict or grant access based on network number, domain name, or protocol. For example, say you have a Web server on the Internet. You want the Internet community to be able to access the httpd daemon, but not necessarily ftp or telnet. tcp_wrapper gives you the ability to restrict access to your telnet and ftp port, but allow free access to your http port. This reduces the risk of unauthorized access to your Web server. Installation of tcp_wrapper is simple. After obtaining the distribution and untarring it, simply run make to compile and produce the binary tcpd. tcp_wrapper works well with most TCP- and rpc-based applications but not with UDP, because UDP is stateless. For instance, tcp_wrapper can be used for services such as systat, finger, ftp, telnet, rlogin, rsh, exec, tftp, and talk. tcp_wrapper provides small daemon wrappers that can be installed without changing the way the existing services and applications run. There are two ways tcp_wrapper can be used. The first and easiest way is to move the programs that you plan to replace with tcp_wrapper to a different directory (e.g., /etc/tcp_wrapper) and fill in the resulting holes with the wrapper programs generated during compilation. There is no other change to the system configuration, so this method involves minimum risk. The second method is to leave the network daemons alone and modify their respective entries in /etc/inetd.conf. The inetd.conf file has syntax of:
<service_name> <socket_type> <proto> <flags> <user> <server_pathname> <args> for socket-based internet services, or:
<service_name> tli <proto> <flags> <user> <server_pathname> <args> for TLI-based internet services. Because tcp_wrapper supports both socket- and TLI-based services, we are able to replace the <server_pathname> field in either case with the location of the tcpd binary. When an Internet request arrives, inetd will run the wrapper program with the name of the concerned server. tcpd will then log the request and call the respective server with the necessary arguments. For instance, a normal telnetd line appears in /etc/inetd.conf as:
telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd With tcpd installed, it would appear as:
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetdtcp_wrapper supports extensive logging and all log information goes to the syslog daemon. Messages are written to files, to the console, or are forwarded to @loghost. tcp_wrapper also supports access control by using the /etc/hosts.allow and /etc/host.deny files. Access is granted when a daemon/client pair matches an entry in the /etc/hosts.allow file; otherwise, access is denied. By default, tcpd allows access to all hosts. You can also enable client hostname lookup in the Makefile by uncommenting the line reading:
#AUTH = -DALWAYS_RFC931 This will tell tcpd to allow connections from hosts whose IP address can be resolved into a hostname and disallow connections otherwise. Banner messages can also be displayed by tcp_wrapper. To support banners, language extensions must be enabled in the Makefile. This can be done by uncommenting the line that reads:
#STYLE = -DPROCESS_OPTIONS # Enable language extensions Then, create a banners subdirectory and move the Banners.Makefile file to that subdirectory and rename it Makefile, then create a file called prototype in the same subdirectory and type make. This will produce three files, in.ftpd, in.rlogind, and in.telnetd, which can be then moved to your directory of choice (e.g., /etc/banners). Then, specify the location in the /etc/hosts.allow or /etc/hosts.deny file of the banner file, using the syntax:
daemons ... : clients ... : banners /some/directory ... The tcp_wrapper program can be obtained at:
ftp://coast.cs.purdue.edu/pub/mirrors/ftp.win.tue.nl/tcp_wrappers Port Monitoring with Satan From a security perspective, an offensive strategy sometimes proves better than a defensive strategy. Instead of letting a cracker discover holes in your system, why not attempt to discover the holes yourself? This is the main reason Security Administrator Tool for Analyzing Networks (Satan) was written. Satan scans a remote system for various security holes. These holes indicate possible avenues of attack into the system. As a responsible system administrator, running Satan may help detect security holes. Possible security holes, which are outlined on Satan's Web page (http://www.trouble.org/~zen/satan/satan.htm) are:
Satan requires Perl 5.000 or later and a Web browser. Satan's author, Dan Farmer, recommends a "SPARC 5, Indy, or better and memory 32MB or better" as the Satan host. To get started, run the reconfig script, which will set up a few preliminaries, such as finding your Web browser path, changing the source directories, and looking for commands. The next step is to run make with the system option (e.g., make sunos5 for SunOS 5.x systems). If all this works, then run the script satan, which will start up a Web browser and present the configuration menu. Satan can also be run from the command line. The attack level can be set at three different values: light, normal, and heavy. In light mode (using option -a 0), Satan collects information about RPC services and from DNS. In normal mode (-a 1), Satan collects information from telnet, smtp, ftp, and will usually specify the operating system type. In heavy mode, (-a 2), Satan does additional scanning. Satan stores results in results/satan-data/all-hosts. When using the Web browser to view results, Satan parses this file and displays the results by listing the vulnerabilities found. Once vulnerabilities have been identified, it is obviously prudent to fix them. For example, if Satan detects a writeable ftp directory, you should change the permissions on the ftp home directory to be read and execute only (chmod 755 ~ftp/pub). Out-of-the-box UNIX installations tend to run a lot of network services that may not be needed. Examples would be chargen (port 19) and echo (port 7). Satan will detect that these services are running and report them as vulnerabilities. It is best to turn these services off by commenting them out in /etc/inetd.conf and sending the HUP signal to inetd. Satan can be obtained at:
http://www.fish.com/satan/ Port Monitoring Detection with Courtney In addition to checking your systems yourself, it is prudent to know when your system is being scanned for weakness by crackers. Satan is a port scanner, and it quite popular in the cracker community. Although there are a number of Satan detection tools, some commercial, some freeware, I found Courtney to be the most convenient to use. Another popular Satan probe detection tool is Gabriel, but Gabriel runs only on SunOS. Courtney runs on multiple platforms, but requires Perl, libpcap, and tcpdump. Installation of Courtney is simple. After untarring the distribution, make sure that tcpdump is in your path environment variable, edit the courtney.pl executable, and modify the first line to point to your Perl executable. By default it points to /bin/perl. Courtney is fairly reliable, however, it may miss packets on a heavily loaded system or a very busy network. Courtney can be set to mail detection using the -m <user@host> option, or to output to the screen using the -s option. A specific interface on a multiple interface machine can be monitored with the -i <interface> option. libpcap and tcpdump can be obtained at ftp.ee.lbl.gov. Courtney can be obtained at:
ftp://ciac.llnl.gov/pub/ciac/sectools/unix/courtney/courtney-1.3.tar.Z Secure Shell Access with ssh Two reasons for creating a networked environment are to be able to access files on remote systems and to execute programs on such systems. A common method of remote execution is to use rsh (remote shell) for command execution. However, rsh assumes the network to be secure, and hence uses clear text to transmit passwords as well as data. The solution is to use ssh (secure shell), which uses encryption between endpoints. Other features of ssh include:
Installing ssh is relatively simple, but does require a C compiler. After unpacking the tar file, run configure, make, and then make install. make install will install the binaries and two configuration files, /etc/sshd_config and /etc/ssh_config. The former is for the server, and the latter for the client. In general, no editing of these files is required, but checking them does not hurt. Also, if you plan to connect to the server using ssh from another server, sshd will have to be entered in the run scripts.
ssh consists of the following programs:
ssh can be obtained from http://www.cs.hut.fi/ssh/. ssh has been discussed in a previous Sys Admin article, which can be found on the Sys Admin Web site at: http://www.samag.com/archive/0701 \ /feature.html. The article covers ssh as a secure way for remote access and gives detailed information on installation and configuration. Event Detection with swatch Now that you are using Tripwire to prevent Trojan horses, tcp_wrapper to control access, Satan for port monitoring, ssh for secure shell, you might want to consider getting swatch for triggering events based on entries in the messages file by syslog. Although the software mentioned has built-in notification, it is sometimes useful to add event triggering based on logs that are output using the syslog facility. swatch is one such tool, and can either email you, page you, or perform some other task based on a particular string it notices in any given log file (e.g., /var/adm/messages in Solaris or /var/log/messages in Linux). Installation of swatch is relatively easy. Keep in mind, though, that you need Perl on the system of installation. The swatch executable itself is written in Perl. swatch comes with a Bourne shell installation script that can be invoked by typing in sh install.sh, and it also comes with a Perl installation script that can be invoked using perl install.pl. The script asks for some basic information, like the location where you want the program to be installed and the permissions on the program. Choose the default values given in square brackets, if you have no preference. You will, however, need to know the location of your Perl libraries. These normally reside in /usr/local/lib/perl. Installation places a .swatchrc file in the home directory of the user installing swatch. The .swatchrc file controls the behavior of swatch. The .swatchrc file consists of four tab-separated fields where one can specify the following: the pattern to look for in regular expression form, the action to perform when such a pattern is noticed, a third (optional) field of time interval within which if another such pattern is received swatch will not perform the action, and a fourth field (which is also optional) that specifies the location of the time stamp in the log message as well as the length of the time stamp.
# sample .swatchrc file /file system full/ mail=root 10:00 0:15 In the above example, swatch will mail root when it notices that a file system is full. It will not mail again if the same message appears within ten minutes, thereby giving you at least ten minutes to clean up. The 0:15 specifies the location of the time stamp (i.e., 0 and the length of the time stamp, 15). Pattern is specified through regular expression using /pattern/; action can be of seven types: echo, bell, exec, ignore, mail, pipe, and write. Time is specified in the format of either SS, MM:SS, or HH:MM:SS, and the fourth field in the format of start:length. The man page that comes with the distribution for swatch gives detailed information on configuring the .swatchrc file. Creating a run script for swatch would help in starting it each time the system boots. swatch can be obtained via ftp from:
ftp://coast.cs.purdue.edu/pub/mirrors/ftp.stanford.edu/swatch Physical Security Software-based security measures can be defeated if the server is physically not protected from unauthorized access. Cabinet and rack-mountable servers can offer some protection, but a server room with restricted key access is usually a better solution. Don't forget to apply the same diligence to monitoring physical security that you apply to software security tools, however. For example, if you have a touch-pad combination lock on the door, change the combination as frequently as you would a password. Also, make sure individuals with server-room access do not keep the door combination on a card in their Rolodex (or in a world-readable file on the server). Conclusion Keep in mind that the tools mentioned here may not be a complete solution to your security needs. Each tool by itself offers functionality that when combined with other tools offers reasonable security, but not necessarily complete security. For example, none of the above mentioned tools does packet filtering, which quite often is a required part of security measures. These tools also do not offer certain other features that may be desired in a modern security tool. An example would be a WWW-based interface to configuration, scalability across multiple platforms, distributed computing support, or a graphical user interface to configuration. The security tools I mentioned are free, so your only cost is the time spent installing them. However, these tools might not be the ideal solution for you organization if you are looking for commercial support. For example, if you use S/Key for logins into a firewall, and S/Key breaks, then your only support is the user community, including newsgroups, mailing lists, and IRC channels pertaining to the particular software. On the other hand, buying a commercial product with support does entitle you to support, which at times is needed. Additionally, any security tool that you install should be consistent with the security requirements of your particular environment, and ideally those requirements should be reflected in a formal security plan or architecture document. You can see, however, that it is possible to achieve a reasonable level of security at a minimal cost.
About the AuthorSyed Ali started his system administration career in 1996 after graduating from Rutgers University. Currently he is working for a major financial firm and can be reached at: alii@paul.rutgers.edu.
|