Access control for services using Tcp_wrapper or xinetd

Tcp_wrapper and xinetd Introduction

We know that access control for services can use iptables, because iptables is working in the kernel state, and it uses several control modules to control access policies (such as NetFilter, Nat, and so on). And Tcp_wrapper is an access control library, which works between the kernel and application services, that is, the system in the absence of iptables control, the user wants to access a load Tcp_wrapper Library application services, first through the TCP_ Wrapper to verify that this user is not compliant, Tcp_wrapper will actively prohibit access to this user if it is not legal.

A service to function, the first to run this service corresponding to the binary program, run successfully in the system to generate a process, and the process is divided into: 1, independent daemon 2, non-independent daemon. The non-independent daemon is also known as the Transient daemon, and the transient daemon is required to xinetd the Super Daemon management to turn it on or off.

Tcp_wrapper Combat

To see if an app service is subject to Tcp_wrapper to control user access, you can use the LDD command to view, for example, the SSHD service, to find out that it is a library file loaded with Tcp_wrapper libwrap.so, and is dynamically linked to load the library file. If an application service specifies to load the libwrap.so library file at compile time, it is not visible with LDD, but the compiled application service is in fact tcp_wrapper to control the user's access to it.

[Email protected] ~]# ldd  ' which  sshd '        libwrap.so.0 =/lib64/libwrap.so.0 (0x00007fd55061e000)

For example, say XINETD service is also loaded libwrap.so library files, on the CENTOS6 installed telnet-server is dependent on xinetd, so install telnet-server when installed xinetd, However, the installation of Telnet-server on the CENTOS7, the default is not to install XINETD, to install the XINETD service independently. The following is an example of CENTOS6 installation Telnet-server

[email protected] ~]# Yum  install  telnet-serverinstalled:  telnet-server.x86_64 1:0.17-48.el6                                           Dependency installed:  xinetd.x86_64 2:2.3.14-40.el6       [[email protected] ~]# ldd  ' which  xinetd '        libwrap.so.0 =/lib64/libwrap.so.0 (0x00007f0045a13000)

So Tcp_wrapper is how to control the loading of libwrap.so library file application services, mainly by the following two files control, one is/etc/hosts.allow, the other is/etc/hosts.deny

[Email protected] ~]# ll/etc/host*-rw-r--r--. 1 root root 370 Jan  2010/etc/hosts.allow-rw-r--r--. 1 root root 460 Jan  2010/etc/hosts.deny

The following combat tcp_wrapper to control the user access to the Telnet service. To start the Telnet service, start the XINETD service first, because the transient process of the Telnet service is managed by the Super Daemon xinetd

[Email protected] ~]#/etc/init.d/xinetd startstarting xinetd:                                           [  OK  ][[email protected] ~]# chkconfig  telnet  on[[email protected] ~]# netstat-lntup TCP        0      0:::                       :::*                        LISTEN      2825/xinetd  

To allow Tcp_wrapper to control telnet access, configure the Hosts.allow and Hosts.deny files in the format: Deamon_list:host_list For example, allow 192.168.0.0/ 16 network segment hosts can access Telnet, other host access denied

[Email protected] ~]# vim  /etc/hosts.allow   in.telnetd:192.168.[ [Email protected] ~]# Vim/etc/hosts.deny  In.telnetd:ALL

You can also exclude individual hosts by adding except parameters to the rule. For example, allow 192.168.0.0/16 network segment host access Telnet, in addition to this network segment of the 192.168.1.180 host access Telnet, and deny other network segment host access. Using Telnet on the 192.168.1.180 host to access the Telnet service on the 192.168.1.120 host will be denied.

[Email protected] ~]# vim  /etc/hosts.allow   in.telnetd:192.168.  Expect 192.168.1.180[[email protected] ~]# vim/etc/hosts.deny  In.telnetd:ALL

Of course, we can also use the spawn parameter in the rule, this parameter means to start, you can follow this parameter followed by a command, such as to let the user log on to Telnet success or failure after logging to a log file

[Email protected] ~]# vim  /etc/hosts.allow in.telnetd:192.168. Except 192.168.1.180:spawn echo "' Date ', login Attem PT from%c to%s ">>/var/log/tcpwrapper.log[[email protected] ~]# vim  /etc/hosts.deny in.telnetd:ALL:spawn EC Ho "' Date ', login attempt from%h" >>/var/log/tcpwrapper.log

When the client accesses the Telnet service, the resulting log is as follows:

[Email protected] ~]# tail/var/log/tcpwrapper.log Thu Mar 15:23:00 CST 2018,login attempt from 192.168.1.180Thu Mar 1 5 15:23:39 CST 2018,login attempt from 192.168.1.190 to [email protected]

The parameters in the access control file above%c%s%h This Tcp_wrapper macro definition uses the man 5 hosts_access to see what it means, and some tcp_wrapper can define hosts.allow hosts.deny file parameters

[email protected] ~]# man  5 hosts_access       %c     Client information: [email protected], [email protected], a host Name,              or  just an address, depending on how much information is              available.       %h (%h)              the client (server) host name or  address,  if  the  host              name is unavailable.       %s     Server information: [email protected], [email protected], or  just              a  daemon  name,  Depending on what  much information is              available.

　　

　

　　

　

Access control for services using Tcp_wrapper or xinetd