- Layout for this exercise:
1 - Introduction
- TCP Wrapper is a host-based networking ACL system used to filter network access to Internet Protocol servers on Unix-like operating systems such as Linux or BSD.
- For access control and filtering purposes it allows host IP or subnetwork IP addresses, and also hostnames to be used as tokens.
- The tarball includes a library named libwrap that implements the actual functionality, and most common network service daemons can be compiled against libwrap directly.
- A wrapped service is compiled with libwrap support.
- Some benefits of using TCP wrappers:
a) connections are monitored and reported through the syslog facility.
b) simple form of access control based on pattern matching.
c) verifies the client host name is returned by the address.
d) spoofing protection.
e) works on the application layer so encrypted requests can be filtered.
2 - Configuration of TCP wrappers
- The command ldd can be used to see if the library libwrap.so is supported by services, meaning that those services are compiled with TCP wrappers. For instance:
- There are two main files for the configuration of TCP Wrappers: /etc/hosts.allow and /etc/hosts/deny, listing hosts allowed and not allowed to use the services.
- Locating hosts.allow and hosts.deny:
- /etc/hosts.allow is checked first. If a match is found access is granted. If not, then /etc/hosts.deny is checked next, and if a match is found access is denied.
- Access rules, one per line, are written inside those two files. The pattern of the rules is SERVICES : CLIENTS : ACTIONS
- ALL can be used as a wildcard for all services and for clients.
- Let's see some examples of how to apply TCP wrappers.
3 - Example 1: allowing and denying access
- Editing hosts.allow for allowing SSH access from the Windows system:
- Editing hosts.deny for denying SSH access from the Kali device:
- The result is that Windows can remotely access Debian with SSH, but Kali cannot:
- The reason for that result is that hosts.allow matches the Windows devices's IP when trying to use SSHD, running the connection. However, because hosts.allow does not match Kali's IP it moves to hosts.deny file where Kali's IP is actually present, therefore denying the access.
4 - Example 2: using the wildcard ALL
- Let's try another configuration. In this case hosts.allow holds both Windows and Kali's IPs:
- However, hosts.deny holds the wildcard ALL, meaning that any other host different from 192.168.17 or 192.168.1.19 is not allowed to access via SSH:
- Not even the localhost, whose SSH access is also denied because it is comprised under the wildcard ALL:
