In the process of hardening systems, you want to reduce the attack profile as much as possible, by whatever means possible. You can do this either by removing or disabling services or by denying access to them in the event they cannot be removed or disabled.
TCP Wrappers TCP Wrappers is a network access control measure that can grant or deny TCP, UDP, and some ICMP connections to particular services. It works by tying in with the services that are run by inetd or xinetd.
TCP Wrappers can be used to extend the functionality of inetd or xinetd to provide support and control for every server daemon under their respective purviews. This support could include logging, welcome messages, and spawning of other processes (among other things), in addition to the traditional firewall-like controls.
Essentially, TCP Wrappers operates like a rudimentary firewall but has a few extra enhancements, as it is attuned to respective service and the service control manager. It is important to mention, however, that this tool is not a replacement for a firewall, but just another cog in the wheel of defense-in-depth.
It operates through the use of two configuration files (hosts.allow and hosts.deny).
The hosts.allow file is used to grant access to a particular host and service, whereas the host.deny is used for the opposite. Take a look at the following example:
sshd : .hacker.com \
: twist /bin/echo "421 Bad hacker, go away!"
Chapter 5: Data Networks Security
105
If placed in the hosts.deny file, the above example can be used to deny access to sshd from the hacker.com domain and send the friendly message “Bad hacker, go away!”
sshd : .goodguy.com \
: twist /bin/echo "421 Welcome, Would you like some coffee?"
If placed in the host.allow file, the above example can be used to allow access from the goodguy.com website and display an even friendlier message.
Application Firewalls Fortunately, a number of different application firewalls are included with and available for modern Linux distributions. Some are designed to provide access controls between any remote host and any network-enabled application on the system.
IPTables (or NetFilter) is probably the most commonly used and one of the most configurable. It is included by default with most Linux distributions and provides a robust feature set. Not only does it provide stateful traffic inspection, but also it provides enhance protections through a host of extensions that can be customized, such as mentioned in “Fingerprint Scrambling,” earlier in this chapter.
Other firewalls are embedded in specific applications and provide access controls on the ports with which they communicate. ModSecurity is a perfect example of an embedded application firewall. It is a module in Apache that provides a wide variety of functions customized for web traffic, such as intrusion prevention, event correlation, anomaly detection, and so on.
Probably the best advice to give regarding any of the various application firewalls is to use them where they are appropriate as part of a defense-in-depth architecture. They should not be the entire basis for defense, but used as part of a comprehensive, secure design utilizing multiple layers of defense. They should be configured using the same methodology of least privilege as discussed thus far. Specifically, only provide exactly the ingress and egress access needed.
Don’t stop at allowing access only to those ports desired. Just as with TCP Wrappers, use application firewalls for limiting, if possible, access to open ports. For instance, if a server is sitting directly on the Internet, there is absolutely no reason for everyone on the Internet to have the ability to attempt to make SSH connections to it. This just invites brute-force attacks and potentially worse if a vulnerability is identified against the installed version of SSH.
Furthermore, critical internal servers should also be protected using an application firewall, and you should restrict access to only designated ports from intended sources.
This approach may be overkill in some environments and can lead to a lot more firewall configurations, setup, and maintenance overhead. However, the upside is that servers utilizing application firewalls are much less likely to suffer a compromise. Therefore, incident response and possible server redeployment time will be minimized.
Unfortunately, regardless of the type or configuration of the particular application firewall, they are still just another application. As with other kinds of applications, application firewalls are best protected behind a physical firewall. It is undoubtedly true that sooner rather than later a critical vulnerability will be found for an application firewall that will render it useless—or worse—allow privileged access to the host machine.
When choosing a firewall option, make sure it can help you react to the most various attack situations you have experience with and can think of, for instance, brute-force against services, port scanning, multiple connection attempts without valid data, or multiple valid connection attempts from a single source.
Port Knocking Port knocking is a term that refers to a particular application responding to a series of connection attempts to closed ports. This process triggers previously closed ports to accept communications from the sender following the port knocking sequence.
This is reminiscent of some kind of elfin technology but has very practical, real-world security uses.
This monitoring application could operate in a variety of ways. The two most likely are as follows:
• The fi rst methodology is for it to continually monitor the fi rewall logs looking for evidence of a particular port sequence to be knocked. Once the proper sequence in the specifi ed period of time is received, the application could either make a quick fi rewall rule confi guration change (to allow TCP communication) or sniff the network and collect data from a UDP transmission from the sender.
• The second methodology is for the monitoring application to just sniff all traffi c on the network looking for the particular knocking sequence. Once that sequence is detected, it would once again use either a fi rewall rule change or a UDP transmission for actually receiving the data.
Depending upon how it is used, port knocking can be either beneficial or detrimental.
If it is an intentional, covert authentication measure, it can be an important part of a defense-in-depth architecture. If it is part of some kind of backdoor and its existence is suspected, it can be very difficult to ferret out. This is mainly because a process is not always bound to a suspicious port. By understanding how port knocking applications work (monitoring log files or sniffing network traffic), identifying one on an infected system, if it is used maliciously, will be evident.
The website http:// www.portknocking.org is a great resource for more information on this particular topic. They have information as well as Perl scripts available for download.
Chapter 5: Data Networks Security