Controlling Access to Your Services with xinetd - page 4
Creatures of the Linux Underworld
The xinetd program has two major configuration setups. First, there's the default configuration, which is in the file /etc/xinetd.confthough your distribution might put this file in a different place. Then there's a group of files typically in the /etc/xinetd.d directory that each corresponds to a different service.
We'll start with xinetd.conf. A default setup for this file might look like:
# Simple configuration file for xinetd
defaults
{
only_from = localhost
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
If you've only seen the inetd configuration file before, it should
already be obvious just how different xinetd setup is. Contained in
xinetd.conf are your global defaultsthough you can do individual
configurations here as well. The globals are assigned in the defaults
statement, and its contents are marked off with the braces ({}). Let's
take a look at the options from top to bottom:
only_fromRestricts access to a service to only the specified external machines.instancesRestricts how many simultaneous accesses to this service will be accepted.log_typeSets logging rules for this particular service. The options here areSYSLOGandFILE.SYSLOGtells xinetd to utilize syslogd, the "standard" Linux system logging daemon, and the term that follows it tells syslogd which facility and level (seeman syslogd) to utilize.log_on_successSets logging rules for a successfully started server instance. The value(s) allowed areDURATION,EXIT,HOST,PID, andUSERID(seeman xinetd.conffor more details).log_on_failureSets logging rules for when a requested server instance cannot start, either due to bugs or the request not matching the set rules. Value(s) allowed areATTEMPT,HOST, andUSERID(again, seeman xinetd.conffor more information).cpsRestricts the rate of incoming connections that xinetd will bother with. The first argument is how many requests per second the server will put up with before it disables the requested service completely. The second argument tells xinetd how many seconds to wait before opening the port again.
If you see the following as the last line then your xinetd is set up to look in /etc/xinetd.d (or whatever directory is specified) for specific configurations:
includedir /etc/xinetd.d
You can add such a line as well, if needed.
When we turn our attention to the broader range of elements you might configure for specific services, we discover that there is a long list of options. Rather than spending the time and space covering every option in detail, I'll cover one specific example so that we can get on to more tutorial. You can get more information about any option, and of course the whole list of available options, in the xinetd.conf man page.
Let's use the vsftpd xinetd configuration file:
# default: off
# description: The vsftpd FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/sbin/vsftpd
nice = 10
}
Notice that this file, like all of its cousins in /etc/xinetd.conf,
starts with a line in the form
service . is one of the items in
/etc/services or one of the other files listed in this tutorial, and
refers to the basic functionality provided by this particular tool. In
the case of vsftpd, it's not hard to guess that the service is ftp.
Inside the braces are the options for this specific service. Here I'm only going to define what these particular settings mean. We'll get into the specifics of these options in the tutorial. The vsftpd setup is, from top to bottom:
- The port is open and the service is available.
- FTP uses TCP so that it can ensure that all of the data has arrived, and so is a streaming socket type.
- Streaming sockets are typically set to no wait.
- This FTP server runs as root.
- This FTP server is located at /usr/bin/vsftpd.
- This command runs at an average priority level.
All of these settings are in addition to what was set in xinetd.conf.
- Skip Ahead
- 1. Creatures of the Linux Underworld
- 2. Creatures of the Linux Underworld
- 3. Creatures of the Linux Underworld
- 4. Creatures of the Linux Underworld
- 5. Creatures of the Linux Underworld
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.