Wrap a Security Blanket Around Your Computer
TCP_wrappers write a message into your system logs every time a connection is requested, whether it is granted access or not. These entries in the logs above are reason enough to have TCP_wrappers installed on your system. The messages are written through the standard syslog facility and by default go to the same place as mail transactions. On my Linux distribution, Caldera Network Desktop based on Red Hat Linux, the default has been changed so that the messages are written to the same log file as other daemons (LOG_DAEMON facility).
In any event, when someone accesses my machine via telnet, a message like this is placed in the /var/log/messages:
Apr 9 17:24:58 ads in.telnetd: connect from somewhere.else.com
If the connection was refused, the message would read:
Apr 9 17:25:15 ads in.telnetd: refused connect from someother.place.comIf I want to see all the telnet attempts in my log, I can simply type the command:
grep telnetd /var/log/messagesTCP_wrappers can give me even more information through the use of “booby traps”. TCP_wrappers can be configured to run shell commands when certain services are requested. Let's assume I have reason to suspect someone at nasty.badguy.com is trying to use the Trivial FTP program (TFTP) to steal my password file. In my /etc/hosts.deny file, I can put the following line (this example is straight from the hosts_access(5) man page that comes with TCP_wrappers):
in.tftpd : nasty.bad-guy.com : ( /usr/sbin/safe_finger -l @%h |\ /bin/mail -s %d->%h root) &Access to TFTP is denied to all users from nasty.badguy.com. In addition, the command:
safe_finger @nasty.badguy.comis run, and the results are piped into a mail message sent to the root user with the subject line:
in.tftpd->nasty.bad-guy.comsafe_finger is a command provided along with the TCP_wrappers that strips out any “bad” characters, like control sequences and data overruns. Running safe_finger @hostname generates a list of everyone currently logged into that system. The strings %h and %d are called expansions, and tcpd replaces them with the corresponding text for the host name and daemon process, respectively. Other expansions include %a for the client Internet address and %u for the client user name.
Now, this isn't a perfect solution, since our cracker friend may have disabled his finger service or altered it to give false information; however, this example does show us the power of the TCP_wrappers program.
The access control language in the /etc/hosts.allow and /etc/hosts.deny files is quite simple, yet powerful, but TCP_wrappers can be compiled to include even more powerful extensions to the normal access controls. Instead of having the line:
service : host
in the configuration files, you can have the line:
service : host : option : option ...Where option can be allow, deny or many other advanced options.
To enable the advanced options, compile the wrapper programs with the -DPROCESS_OPTIONS. The wrappers are compiled in this way by my Caldera/Red Hat distribution. To check your distribution for the advanced options, run tcpdchk<\!s>-a. On my system, I see the following output:
warning: /etc/hosts.allow, line 6: implicit "allow" at end of rule warning: /etc/hosts.allow, line 7: my.isp.net: host not found warning: /etc/hosts.allow, line 7: implicit "allow" at end of rule warning: /etc/hosts.allow, line 8: implicit "allow" at end of rule
The message implicit<\!s>"allow" indicates my version of the wrappers is looking for additional options in the /etc/hosts.allow file. If your distribution does not have PROCESS_OPTIONS compiled in, you will not see this message.
Using the advanced options, we can do away with the /etc/hosts.deny file entirely, since the options for "allow" and "deny" can be added to any rule. We can change the logging level, control the priority (“niceness”) of the network service, look up user names with the RFC 931 “ident” protocol and display customized “banners” for each service.
More information on these advanced features can be found in the hosts_options(5) man page included with TCP_wrappers, or in the Garfinkel & Spafford book cited above (a must-read for anyone concerned with network security). For now, let's convert our /etc/hosts.allow and /etc/hosts.deny files to use the advanced options. The etc/hosts.deny file is no longer needed. In /etc/hosts.allow we rewrite the rules as follows:
ALL : localhost : allow in.telnetd : my.isp.net : allow in.fingerd : ALL EXCEPT .cracker.org : allow in.tftpd : nasty.bad-guy.com : spawn \ (/usr/sbin/safe_finger -l @%h |\ /bin/mail -s %d-%h root) & : deny ALL : ALL : deny
In English, this says the following:
All services from our own machine are allowed.
telnet is allowed from my.isp.net.
finger is allowed from everywhere except hosts in the cracker.org domain.
tftp is not allowed from nasty.badguy.com, and if they try, we will spring a “booby trap” to find the guilty party.
All other services from everywhere else are denied.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Concerning Containers' Connections: on Docker Networking
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Where's That Pesky Hidden Word?
- A Project to Guarantee Better Security for Open-Source Projects
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- Three More Lessons
- Calling All Linux Nerds!