Secure Network Services using TCP Wrapper
Updated: Apr 21, 2019
If you are running a Linux box and connect to the net through it, then there is every chance of someone else using or misusing the services running on your system. If someone gets to know your IP, then it does give the attacker an opportunity to be able to use the services or daemons running on various ports of your system for malicious purposes. Thus it has become very important to ensure that you define a access list which controls who all can have access to what services on your system and who all should be blocked or denied access to any of the services on your system. This is where TCP Wrappers are so efficient but easy to us .
While performing a network scan on a machine i found nmap showing services on ports as "tcpwrapped".
nmap -sV --script=banner IP Address
So now the Question arises is :
When i scan a ip with nmap some ports are return as "tcpwrapped". What is it? How can i bypass it?
So What Exactly are TCP Wrappers?
Well, TCP Wrappers basically act as efficient tools which allow us to define a set of rules called the Access Control Rules. These access control rules control or define which hosts or machines are allowed to access and use the services running on the local machine (where the TCP Wrappers are installed and configured) and which hosts or machines are denied access to these services. So they in fact are somewhat (well, quite remotely) something like Firewalls. They check to see who has requested the connection and if the connection requestor in amongst the deny list, and then he is not allowed to open a connection.
Besides controlling the access to various services on your system, TCP wrappers also allow you to log and know who is using what service at what time and even for what purpose. The best thing about TCP Wrappers is that they can also be used to set boobey traps to catch lamers.
"Tcpwrapped" refers to tcpwrapper, a host-based network access control program on Unix and Linux. When nmap labels something tcpwrapped, it means that the behaviour of the port is consistent with one that is protected by tcpwrapper. Specifically, it means that a full TCP handshake was completed, but the remote host closed the connection without receiving any data.
It is important to note that tcpwrapper protects programs, not ports. This means that a valid (not false-positive) tcpwrapped response indicates a real network service is available, but you are not on the list of hosts allowed to talk with it. When such a large number of ports are shown as tcpwrapped, it is unlikely that they represent real services, so the behavior probably means something else.
What you are probably seeing is a network security device like a firewall or IPS. Many of these are configured to respond to TCP port scans, even for IP addresses which are not assigned to them. This behaviour can slow down a port scan and cloud the results with false positives.
How it works on Linux?
Anyway, before we go on, we need to have basic understanding of how exactly, Linux responds to a connection request. Now, the thing to remember here is that all requests for connections received by a Linux box, are transferred to the Internet Daemon or the 'inetd'. The 'inetd' is the main daemon on a Linux Machine, which receives all connection requests on behalf of all services or daemons running on all the Port Numbers. Now, once the 'inetd' receives a connection request, it uses 2 configuration files two determine what to do next. These two files are:
1. /etc/services 2. /etc/inetd.conf
The first one, the /etc/services file contains the names of the various Services and the corresponding port numbers on which they run. It is basically used by the 'inetd' to figure out what service runs on a particular Port Number.
The Second File, the /etc/inetd.conf contains the names of various services and the names of the corresponding daemons or programs providing those services. It is used by 'inetd' to figure out which program or daemon to call on when there is a request for a connection to a particular service.
Both these files work together and are interlinked.
Let us assume that the server is Y and the client(connection requestor) is X. Now, X send Y a packet containing the Port Number to which it wants to connect (In this case 23 or the Telnet Port) and other such information required for a TCP connection to start. At Y, the 'inetd' daemon responds to the connection request and looks up the /etc/services file for the service name running on Port 23 (This Port number is mentioned in the packet sent by X). The /etc/services/ responds to 'inetd' saying that the service name running on Port 23 is Telnet. Then, 'inetd' contacts '/etc/inetd.conf' and asks for the name of the daemon or program which runs the telnet service. The '/etc/inetd.conf' file replies saying that a daemon called in.telnetd. Then 'inetd' runs in.telnetd and that is when its job is over and it starts listening for other connection requests.
So, basically a remote system doesn't start out by directly communicating with the various daemons, but instead communicates only with the 'inetd' in the beginning.
Now, if we want to restrict some particular hosts from accessing our system and allow only a predefined set of hosts to access our system, they what do we do? This is when, TCP Wrappers come to the rescue.
A TCP Wrapper acts as a daemon which resides between the main daemon of the linux system i.e. the 'inetd' and other programs or daemons like in.ftpd, in.telnetd etc. As all connections to the linux box will pass through the inetd, they will also definitely pass through the TCP Wrapper. Right? Thus, if there are certain rules which are defined by TCP Wrappers, then they indeed can be used to manipulate access control.
NOTE: Normally, the inetd is configured to call the concerned programs or daemons like telnetd etc. However, once TCP wrappers are installed, then the inetd is configured to call on the Wrapper instead of the concerned daemon.
Anyway, once the inetd daemon calls on the TCP Wrapper or sends the packet received to the wrapper, the wrapper collects the source IP from the packet and accordingly allows or denies a connection. Irrespective of whether the connection is allowed or denied, the wrapper enters a log into the system log file.
Anyway, now, how does the TCP Wrapper daemon i.e. /usr/sbin/tcpd decide whether to allow access to a particular host or not? Well, the Wrapper is helped in this aspect by two files:
1. The /etc/hosts.allow 2. The /etc/hosts.deny
As soon as the inetd sends the connection request to the Wrapper, tcpd scans the /etc/hosts.allow for a match for the hostname of the connection requestor. If a match is found, then the connection is opened. However, if no matches are found, then it searches the /etc/hosts.deny file for a match. Well, if even then no match is found or even if both the files are empty, then the connection is allowed to be opened.
NOTE: By Default both of them are empty, allowing everyone to open connections.
How do I know if a program will work with TCP wrappers?
Not all services will support TCP wrappers. Services must be compiled with the libwrap library. Common services like sshd, ftpd and telnet support TCP wrappers by default. We can check whether TCP wrappers are supported by a service:
ldd /path-to-daemon | grep libwrap.so
The command ldd prints a list of an executable’s shared dependencies. By piping the output of lld to grep, we’re searching the returned list for libwrap.so. If there is any output from this command we can assume that TCP wrappers are supported.
For example, if we want to test the ssh daemon on a server, we must first locate its binary file:
You will most likely get multiple results:
sshd: /usr/sbin/sshd /usr/share/man/man8/sshd.8.gz
Files located in /usr/bin and /usr/sbin are most likely the executables you are looking for. Now we know which file to check for the libwrap dependency:
ldd /usr/sbin/sshd | grep libwrap.so libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007ff363c01000)
How do I use TCP wrappers?
TCP wrappers rely on two files in order to work: /etc/hosts.allow and /etc/hosts.deny. If these files don’t yet exist, create them:
Editing hosts.allow and hosts.deny
You can edit hosts.allow and hosts.deny with any text editor you like. Open the hosts.deny file in your preferred text editor. If you’ve never opened hosts.deny before it will look something like this:
Rules can be added to this file. hosts.deny rules have to be inserted in a certain order, rules lower down in the file will be ignored if a rule higher up applies. Rules also have a specific syntax that you must adhere to. A rule looks like this:
daemons : hostnames/IPs
On the left-hand side of the colon you enter a space-separated list of daemons (A daemon is just a process that runs in the background. For example, sshd is the daemon for SSH). On the right-hand side of the colon you place a space-separated list of the hostnames, IP addresses and wildcards the rule applies to.
This example hosts.deny file will block all client from all processes.
ALL : ALL
We could express this rule in a sentence like this, “Deny access to all daemons from all clients”. This rule will deny all traffic to the server regardless of the source.
Rules in the hosts.allow file have a higher priority than rules in the hosts.deny file. This allows us to use the hosts.allow file to create exceptions to our deny rules.
Open hosts.allow in your preferred text editor.
Inside of your hosts.allow file you can add your exceptions. Find the IP you want to allow, be that your own IP address or the IP address of another server.
Choose the service to allow the IP address access to. The example below will permit SSH traffic.
Here’s how the rule should appear, replacing 220.127.116.11 with the IP you wish to allow:
sshd : 18.104.22.168
When you save the file the rules will automatically take effect.
TCP wrappers have wildcards, allowing you to create broad rules not limited to certain IP addresses or hostnames. The wildcards you can use are, ALL, LOCAL, UNKNOWN, KNOWN and PARANOID.
Here’s what each wildcard means:
ALL - Matches everything.LOCAL - Matches hostnames that don’t contain a dot (.).UNKNOWN - Matches any user/hostname whose name is not known.KNOWN - Matches any user/hostname whose name is known.PARANOID - Matches any host whose name doesn’t match its address.
TCP wrappers will log connections per the settings in your /etc/syslog.conf file. The default location for these log files is the /var/log/messages log file
Is it possible to bypass TCP Wrapper?.
Yes, if it is truly tcp wrappers (and not just a service that refuses to answer because you haven't given a proper protocol message) then the only way to bypass it is to send traffic from an authorized IP address. Often you can compromise a trusted host and attack from there (pivot).