Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   


Xinetd

Old News TCP Wrappers Recommended Links Reference Etc
 

XINETD has TCP Wrappers capabilities built-in.  Both RHEL and Suse uses Xinetd instead of classic inetd.  XINETD integrated TCP Wrappers. This allows XINETD to provide a slightly greater range of security options, but makes the software harder to deploy. 

Configuration is complexly different:

service smtp
{
     socket_type = stream
     protocol = tcp
     wait = no
     user = qmaild
     id = smtp
     server = /var/qmail/bin/tcp-env
     server_args = /var/qmail/bin/qmail-smtpd
     log_on_success -= DURATION USERID PID HOST EXIT
     log_on_failure -= USERID HOST ATTEMPT RECORD
}

XINETD also allows the same per service based access controls that TCP Wrappers recently supports.

XINETD can also protect UDP services (imitating firewall) and detect a some Denial of Service attacks

To restart xinetd, one must send the -USR1 signal instead of SIGHUP.  If xinetd receives a SIGHUP, it will exit prematurely hopefully killing whatever network connection was used to compromise the system security.

Service defaults

The defaults section in /etc/xinetd.conf allows setting values for an number of attributes (check the documentation for the whole list). Some of these attributes (only_from, no_access, log_on_success, log_on_failure, ...) hold simultaneously the values allocated in this section and the ones provided in the services.

By default, denying access to a machine,  is the first step of a reliable security policy. Next, allowing access will be configured on a per-service basis. We've seen two attributes allowing to control access to a machine, based on IP addresses: only_from and no_access. Selecting the second one we write:

no_access = 0.0.0.0/0
which fully blocks services access. However, if you wish to allow everyone to access echo (ping) for instance, you then should write in the echo service:
only_from = 0.0.0.0/0
Here is the logging message you get with this configuration:
Sep 17 15:11:12 charly xinetd[26686]: Service=echo-stream: only_from list and no_access list match equally the address 192.168.1.1
Specifically, the access control is done comparing the lists of addresses contained in both attributes. When the client address matches the both lists, the least general one is preferred. In case of equality, like in our example, xinetd is unable to choose and refuses the connexion.  To get rid of this ambiguity, you should have written:
only_from = 192.0.0.0/8
An easier solution is to only control the access with the attribute:
only_from =
Not giving a value makes every connexion fail :) Then, every service allows access by means of this same attribute.

Important, not to say essential: in case of no access rules at all (i.e. neither only_from, nor no_access) for a given service (allocated either directly or with the default) section, the access to the service is allowed!

Here is an example of defaults :

defaults
{
  instances       = 15
  log_type        = FILE /var/log/servicelog
  log_on_success  = HOST PID USERID DURATION EXIT
  log_on_failure  = HOST USERID RECORD
  only_from       =
  per_source      = 5

  disabled = shell login exec comsat
  disabled = telnet ftp
  disabled = name uucp tftp
  disabled = finger systat netstat

  #INTERNAL
  disabled = time daytime chargen servers services xadmin

  #RPC
  disabled = rstatd rquotad rusersd sprayd walld
}

among internal services, servers, services, and  xadmin allow to manage xinetd. More on this later.

 

Old News ;-)

 

[Nov. 19, 2000] System Administration xinetd

xinetd - extended Internet services daemon - provides a good security against intrusion and reduces the risks of Deny of Services (DoS) attacks. Like the well known couple (inetd+tcpd), it allows to fix the access rights for a given machine, but it can do much more. In this article we will discover its many features.

You could now ask which daemon should I choose xinetd or inetd. As a matter of fact, xinetd requires a bit more administration, especially as long as it won't be included into distributions (it is in Red Hat 7.0). The most secure solution is to use xinetd on machines with public access (like Internet) since it offers a better defense. For machines within a local network inetd should be enough.

 

Recommended Links


In case of broken links please try to use Google search. If you find the page please notify us about new location
Google     

http://synack.net/xinetd/ XINETD Home Page:

 


Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: June 02, 2008