Note:
To determine if a network service binary is linked to “libwrap.so”, type the following command as the root user:
ldd | grep libwrap
Example
[root@client1 Desktop]# ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f22184a9000)
[root@server1 Desktop]# ldd /usr/sbin/vsftpd | grep libwrap
libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f906a243000)
|
daemon_list : client_list : option : option …
daemon_list : client_list [ : shell_command ]
|
Note:
ALL : .example.com
ALL : *.example.com
ALL : 192.168.1.
ALL : 192.168.1.0/24
ALL : 192.168.1.100
ALL : 192168.1.0/255.255.255.0
ALL : *.example.com EXCEPT my.org
ALL : ALL EXCEPT *.example.com : deny
|
Deny requests for a particular service
[root@myvm1 ~]# cat /etc/hosts.allow sshd: .slashroot.in [root@myvm1 ~]#
In the above shown example sshd service is only allowed from “slashroot.in” domain.
[root@myvm1 ~]# cat /etc/hosts.allow vsftpd: .slashroot.in [root@myvm1 ~]#
In the above shown example, vsftpd service is only allowed from slashroot.in domain.
Again keep the fact in mind that a conflicting entry in hosts.deny will be ignored, because hosts.allow is processed first and if a request pattern is allowed, it will never process hosts.deny file at all.
Also you can deny these same requests as shown in the above examples, by making the same entry in hosts.deny, but in that case your hosts.allow must be empty or else must not contain similar rule for allowing.
Let’s see another pattern for allowing and denying hosts.
[root@myvm1 ~]# cat /etc/hosts.allow ALL: 172.16. [root@myvm1 ~]#
In the above example all hosts with the ip address 172.16.*.* is allowed to make connections to all TCP wrapper based services on the hosts.
In the above example if you add ALL: 172.16.104.54, in the file hosts.deny will not be of any use, because you have already allowed all requests from 172.16.*.* in hosts.allow file.
You can also make the same entry with IP and subnet mask based style, as shown below.
[root@myvm1 ~]# cat /etc/hosts.allow ALL: 172.16.0.0/255.255.0.0 [root@myvm1 ~]#
If you want to deny or allow a large number of hosts, then you can also do that by mentioning the list of ip/hostnames in another file and pointing to that file in /etc/hosts.allow.
[root@myvm1 ~]# cat /etc/hosts.allow sshd: /etc/sshd.hosts [root@myvm1 ~]#
In the above rule, an important point to note is that the rule starts with a “/”, mentioning the path for the file.
Previously we saw that you can allow/deny an entire domain, but what if you want to make exceptions to some hosts on that domain.
[root@myvm1 ~]# cat /etc/hosts.allow ALL: .slashroot.in EXCEPT example.slashroot.in [root@myvm1 ~]#
In the above example all hosts from slashroot.in domain will be allowed except example.slashroot.in.
In the exact similar manner, you can also deny one particular service, after allowing the rest to a group of hosts or domain, as shown below.
[root@myvm1 ~]# cat /etc/hosts.allow ALL EXCEPT sshd: 172.16.0.0/255.255.0.0 [root@myvm1 ~]#
In the above shown method all hosts from 172.16.0.0 network are allowed for all the services except ssh.
The <options> field in the tcp wrapper entry can also be used to make all entry in one files itself(Yeah that’s correct, you can use a single file for accept and deny rules. This is the best method to avoid confusion.), the syntax for such entry should be made, by taking an extra care.
[root@myvm1 ~]# cat /etc/hosts.deny vsftpd : example1.slashroot.in : allow sshd : example1.slashroot.in : deny sshd : example2.slahroot.in : allow [root@myvm1 ~]#
In the above example, i have made the entry of both allowing and denying connections to service in hosts.deny file(i have kept my hosts.allow file empty). “allow” and “deny” are part of the options filed in the entry.
Another important fact that must be kept in mind is the length of the access rule that you are making in tcp wrapper files.
One rule per line is the way it must be made. Otherwise rules might get skipped without applying them while processing. There is a workaround for this problem, by including “/”, for all those rules that are lengthy. An example is shown below.
[root@myvm1 ~]# cat /etc/hosts.allow vsftpd : 172.16.103.150 \ : spawn /bin/echo ftp access prohibited>>/var/log/ftp.log \ : deny [root@myvm1 ~]#
In the above example, we have used backslashes to denote that the rule is one line. Also we have spawned echo process to make a text redirect to ftp log file. This kind of actions can be taken with the help of options field as shown above.
Like we have used spawn to echo some text content in ftp log, this can be made very detailed log with the help of some options.
[root@myvm1 ~]# cat /etc/hosts.allow vsftpd : 172.16.103.150 \ : spawn /bin/echo %c %h %p %u ftp access prohibited>>/var/log/ftp.log \ : deny [root@myvm1 ~]#
In the above example, i have used
%c for complete client information like username and hostname
%h is used to determine client’s ip address
%p is used to log process id of the process
%u is used for username of the client who is requesting the service.
You can make much more interesting things to trigger on matching a rule, using the same spawn method and redirection.
A complete mannuel entry for TCP wrapper can be found by running the below command as shown below.
[root@myvm1 ~]# man hosts_options [root@myvm1 ~]#
Hope this article was helpful in understanding the concept of TCP wrappers in Linux.