domain.com. When a client connects, xinetd will reverse lookup the
•
connecting address, and see if it is in the specified domain.
To optimize things, obviously IP addresses are obviously better, that way you avoid name lookup(s) on incoming connections to that service. If you must do access control by the hostname, you can significantly speed things up if you run a local (at least a caching) name server. It's even better if you are using domain sockets to perform your address lookup (don't put a nameserver entry in /etc/resolv.conf).
Service defaults
The defaults section 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.
Configuring a service
To configure a service, we need ...nothing :) In fact, everything works like it does with defaults values: you just have to precise the attributes and their value(s) to manage the service. This implies either a change in the defaults values or another attribute for this service.
Some attributes must be present according to the type of service (INTERNAL, UNLISTED ou RPC) :
Tab. 2: required attributes
Attribute
Comment
socket−type Every service.
user
Only for non INTERNAL services
server
Only for non INTERNAL services
wait
Every service.
Every RPC service and the ones not contained
protocol
in /etc/services.
rpc_version Every RPC service.
Every RPC service, not contained in
rpc_number
/etc/rpc.
Every non RPC service, not contained in
port
/etc/services.
This example shows how to define services:
service ntalk
{
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.ntalkd
only_from = 192.168.1.0/24
}
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = −l
instances = 4
access_times = 7:00−12:30 13:30−21:00
nice = 10
only_from = 192.168.1.0/24
}
Let's note that these services are only allowed on the local network (192.168.1.0/24). Concerning FTP, some more restrictions are expected: only four instances are allowed and the service will be available only during certain segments of time.
Port binding: the bind attribute
This attribute allows the binding of a service to a specific IP address. This is only useful when a machine has at least two network interfaces, for example a computer beeing part of a local network and connected to Internet through a separate interface.
For instance, a company wishes to install an FTP server for its employees (to access and read internal documentation). This company wants to provide its clients with an FTP access towards its products: bind has been made for this company :) The solution is to define two separate FTP services, one for public access, and a second one for internal company access only. However, xinetd must be able to differentiate them: the solution is to use the id attribute. It defines a service in a unique way (when not defined within a service, its value defaults to the name of the service).
service ftp
{
id = ftp−public
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = −l
instances = 4
nice = 10
only_from = 0.0.0.0/0 #allows every client
bind = 212.198.253.142 #public IP address for this server
}
service ftp
{
id = ftp−internal
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = −l
only_from = 192.168.1.0/24 #only for internal use
bind = 192.168.1.1 #local IP address for this
server (charly)
}
The use of bind will allow to call the corresponding daemon, according to the destination of the packets.
Thus, with this configuration, a client on the local network must give the local address (or the associated name) to access internal data. In the log file, you can read: 00/9/17@16:47:46: START: ftp−public pid=26861
from=212.198.253.142