How to install and setup an example service with xinetd on RHEL 8 / CentOS 8 Linux

Xinetd, or the Extended Internet Services Daemon, is a so-called super-server. You can configure it to listen in the place of many services, and start the service that should handle an incoming request only when there it actually arrives to the system – thus saving resources. While this may not seem to be a big deal on a system where traffic is relatively permanent, this service in the front of another approach does have some neat advantages, like logging or access control.

In this article we will install xinetd on a RHEL 8 / CentOS 8, and we’ll put the sshd daemon under it’s care. After verifying the setup, we’ll tweak the configuration a bit to see the access control in action.

In this tutorial you will learn:

• How to install xinetd
• How to setup sshd on RHEL 8 / CentOS 8 as an xinetd service
• How to allow access only from a specific network to the sshd service from xinetd
• How to audit traffic from xinetd log entries

Allowing access from a certain network segment to sshd.

Software Requirements and Conventions Used

How to install xinetd service in Red Hat 8 step by step instructions

Xinetd can be found in the base repositories after setting up the official Subscription Management repositories. The sshd server is installed to any Red Hat (and pretty much any Linux distribution) by default.

1. Fist we need to install the xinetd daemon. We’ll use dnf:

   # dnf install xinetd

2. If for some reason your system does not contain OpenSSH installation, you can install packages like in this case the openssh package the same way as above:

   # dnf install openssh

---

---

3. Xinetd comes with a default configuration file /etc/xinetd.conf, as well as some neat examples in the /etc/xinetd.d/ directory, all disabled by default. With a text editor like vi or nano, let’s create a new text file /etc/xinetd.d/ssh with the following content (note that the new line after the service name is mandatory):

   service ssh 
   {
    disable     = no
    socket_type = stream
    protocol    = tcp
    port        = 22
    wait        = no
    user        = root
    server      = /usr/sbin/sshd
    server_args = -i
   }

4. If the sshd server is running on the system, we need to stop it, otherwise xinetd can’t bind to TCP port 22. This is the step where you will be disconnected if you are logged in via ssh.

   # systemctl stop sshd

   If we plan to use sshd over xinetd in the long term, we can also disable the systemd service for it, to prevent it from starting at boot time:

   systemctl disable sshd

5. Now we can start xinetd:

   # systemctl start xinetd

   And optionaly enable startup at boot time:

   # systemctl enable xinetd

6. After xinetd starts, we can login trough ssh, as our basic setup does not contain any additional restriction. To test the service, we ask for login on localhost:

   # ssh localhost
   root@localhost's password: 
   Last login: Sun Mar 31 17:30:07 2019 from 192.168.1.7
   #

7. Let’s add another line to /etc/xinetd.d/ssh, just before the closing bracelet:

   [...]
    server      = /usr/sbin/sshd
    server_args = -i
    only_from   = 192.168.0.0
   }

   With this setting, we restrinct access only from the network segment 192.168.*.*. We need to restart xinetd for this configuration change to take effect:

   # systemctl restart xinetd

8. Our lab machine has more than one interfaces. To test the above restriction, we’ll try to connect to connect to one interface that isn’t allowed by xinetd configuration, and one that is indeed allowed:

   # hostname -i
   fe80::6301:609f:4a45:1591%enp0s3 fe80::6f06:dfde:b513:1a0e%enp0s8 10.0.2.15 192.168.1.14 192.168.122.1

   We’ll try to open connection from the system itself, so our source IP address will be the same as the destination we are trying to connect to. Therefore, when we try to connect to 10.0.2.15, we are not allowed to connect:

   # ssh 10.0.2.15
   ssh_exchange_identification: read: Connection reset by peer

   While the address 192.168.1.14 is within the allowed address range. We’ll get the password prompt, and can login:

   # ssh 192.168.1.14
   root@192.168.1.14's password:

---

---

9. As we haven’t changed the default logging configuration, our login attempts (or with other words, our attempts to access the xinetd service) will be logged to /var/log/messages. The log entries can be found with a simple grep:

   cat /var/log/messages | grep xinetd
   Mar 31 18:30:13 rhel8lab xinetd[4044]: START: ssh pid=4048 from=::ffff:10.0.2.15
   Mar 31 18:30:13 rhel8lab xinetd[4048]: FAIL: ssh address from=::ffff:10.0.2.15
   Mar 31 18:30:13 rhel8lab xinetd[4044]: EXIT: ssh status=0 pid=4048 duration=0(sec)
   Mar 31 18:30:18 rhel8lab xinetd[4044]: START: ssh pid=4050 from=::ffff:192.168.1.14

   These messages make it easy to know how our services accessed. While there are many other options (including limiting concurring connections, or set timeouts after failed connections to prevent DOS attacks), this simple setup hopefully shows the power of this super-server that can make the sysadmin’s life easier – especially crowded, Internet-facing systems.