Controlling Access to Your Services with xinetd - page 5
Creatures of the Linux Underworld
When it comes to configuring your own superdaemon, you might be much more fussy than just accepting the defaults. The first thing you need to do is determine which services you want to configure, because what the service is and does will tell you what statements you must include, and what statements won't work at all.
Once you've got a list of what you want to custom configure, decide if you want to alter xinetd.conf itself, or to create a separate file in the xinetd.d directory. I typically recommend that if it's not global, to use the separate files. It just keeps things neater.
Now you have to choose what you want to set for this particular service. There are forty-four available parameters, but only two that must be set for any service. These two are:
socket_typeThis entry is determined by whether the underlying protocol used is TCP (which yields a socket type of
stream) or UDP (which yields a socket type of "dgram").
waitThis entry is also determined by whether you're using TCP (
not) or UDP (
The other required parameters depend on the type of service you're setting up. For the services that xinetd does not handle for you, such as incoming FTP and web requests, you must also have:
serverThe path to the program that xinetd needs to start.
server_argsOnly required if you need to pass flags, options, or values to the server when it's started.
userThe user that this program should run as. More often than not, this user is root, but never just blindly use root if you can help it.
Another pair of services are referred to as RPC services, and unlisted services. An RPC (Remote Procedure Call) service is a C programming library that supports client/server architecture, allowing a machine to send a command to another machine, which executes the command and then sends back the results. An unlisted service is one that isn't included in /etc/services or /etc/rpcthe file that contains the list of all RPC services.
Keeping the RPC and unlisted services in mind, the remaining required statements (if appropriate for the service you're setting up) are:
portThe port to accept communications for this service on. Only required for unlisted services that don't use RPC.
protocolThe protocol from /etc/protocols that this service requires. Only absolutely necessary for RPC and unlisted services.
rpc_numberThe number from /etc/rpc for this services. Only absolutely necessary for RPC and unlisted services.
rpc_versionThe version number of RPC that this service requires, either a single number or a range separated by dashes. Only required for RPC services.
From here, everything is optional. Rather than putting you to sleep covering all of the items in the xinetd.conf man page, here are the ones you are most likely to want to use or to run into when editing existing filessee the xinetd.conf man page for in depth specifics on exact syntax and options:
banner_failA banner to print for the user who tries to access this service but isn't allowed.
banner_successA banner to print for the user who successfully accesses this service.
bindOnly accept accesses for this service through a particular network device.
cpsThe threshold of connections per second that push xinetd to temporarily disable the service.
noif you want xinetd to pick up the phone when someone tries to access this service, and a
yesif you don't. Often distributions that utilize xinetd will install software such as FTP servers with
disable = yesso that they will not be available until you've fully configured the server and then enable it.
envEnsures that the specified environment variables are in this service's environment.
groupThe group that this program should run as.
instancesThe number of simultaneous accesses xinetd should allow for this service.
UNLIMITEDis the default.
log_on_successWhat information to log when the service starts and when it stops.
log_on_failureWhat information to log when a service can't start due to an error or someone trying to get in who shouldn't.
log_typeWhether to use the syslog daemon or log to a file.
max_loadThe threshold of the one minute load average that causes xinetd to refuse connections for this service.
niceThe priority this particular service should have in taking up CPU cycles. See the nice man page for details.
no_accessExpressly forbids access from the specified location to this service. Uses the same formats as
only_fromWhich hosts outside of this server are allowed to access this service.
per_sourceLimits how many times someone can access this service from the same location at the same time.
redirectWhenever someone tries to access this service, point the request to another location and forward it along.
Most of these entries are used in the format:
statement = item1 item2 ...
So, once you know what service you want to configure, where you want to configure it (what file), and what portions you want to configure, you create an entry that looks like this whether you're doing it in the main file or in one of the separate files:
servicename statement1 = item1 item2 ... statement2 = item1 item2 ... ... }
Once you're finished making these configuration changes, be sure to restart xinetd so it can load the new setup. It's typically a good idea to use the control scripts if your distribution supports them. For example, in Red Hat Linux you would type:
Hopefully you've found here that xinetd deserves further investigation. If you're used to inetd then this more secure superdaemon can give you a few headaches at first, but the better control over who's accessing your system, and when, makes up for it.
Sites of interest:
Dee-Ann LeBlanc has written over 10 computer books, over sixty articles, taught classes, and more, mostly involving the Linux operating system and its programs. You can follow her work and share your input through her new mailing list at http://www.dee-annleblanc.com/mailman/listinfo/general, or find out more in general at http://www.Dee-AnnLeBlanc.com/.
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.
- 1Linux Top 3: CoreOS, Oracle Enterprise Linux 7 and Ubuntu 14.10
- 2Linux Top 3: Debian Dumps SPARC, Ubuntu Takes Over Linux 3.13 and the Core Infrastructure Initiative
- 3Linux Top 3: Fedora, Ubuntu and Gluster Lose Community Leaders
- 4Red Hat Enterprise Linux 7 Finally Hits the Big Time
- 5Linux Top 3: Tails 1.0, OpenMandriva Lx 2014.0 and Debian 7.5