xinetd.linuxfocus, wisisz, wydzial informatyki, studia zaoczne inzynierskie, administrowanie systemem linux
[ Pobierz całość w formacie PDF ]
//-->byFrédéric RaynalAbout the author:Frédéric Raynal is preparing athesis about watermarking ofdigital images at the INRIA(Institut National de Rechercheen Informatique etAutomatique).Content:•What's that, xinetd ?•Compilation &Installation•Configuration•Access Control•Service defaults•Configuring a service•Port binding: the bindattribute•Service redirectiontowards an othermachine: the redirectattribute•Special services•Let's play a bit...•Starting with a riddle•chroot a service•Conclusion•pop3 server•Bad configuration withRH7.0, Mandrake 7.2and maybe some others...•Talkback form for thisarticlexinetdAbstract:xinetd − eXtended InterNET services daemon − provides a good security against intrusion and reduces therisks ofDenial of Services(DoS) attacks. Like the well known couple (inetd+tcpd), it enables theconfiguration of the access rights for a given machine, but it can do much more. In this article we willdiscover its many features.What's that, xinetd ?The classicalinetdhelps controlling network connections to a computer. When a request comes to a portmanaged byinetd,then inetd forwards it to a program called tcpd. Tcpd decides, in accordance with therules contained in thehosts.{allow, deny}files whether or not to grant the request. If the request isallowed, then the the corresponding server process (e.g ftp) can be started. This mechanism is also referred toastcp_wrapper.xinetd provides access control capabilities similar to the ones provided bytcp_wrapper.However, itscapabilities extend much further :•access control for TCP, UDP and RPC services (the latter ones aren't well supported yet).•access control based on time segments•full logging, either for connection success or failure•efficient containment againstDenial of Services(DoS) attacks (attacks which attempt to freeze amachine by saturating its resources) :♦limitation on the number of servers of the same type to run at a time♦limitation on the total number of servers♦limitation on the size of the log files.•binding of a service to a specific interface: this allows you, for instance, to make services available toyour private network but not to the outside world.•can be used as a proxy to other systems. Quite useful in combination with ip_masquerading (orNetwork Address Translation − NAT) in order to reach the internal network.The main drawback, as already mentioned, concerns poorly supported RPC calls. However,portmapcancoexist with xinetd to solve this.The first part of this article explains how xinetd works. We'll spend some time on a service configuration, onsome specific options (binding to an interface, redirection) and demonstrate this with a few examples. Thesecond part shows xinetd at work, the logs it generates and finishes with a useful tip.Compilation & InstallationYou can get xinetd fromwww.xinetd.org.For this article we will use version 2.1.8.9pre10.Compilation and installation are done in the classical way: the usual commands./configure; make;make installdo it all :)configuresupports the usual options. Three specific options are available atcompile time:1.−−with−libwrap: with this option, xinetd checks thetcpdconfiguration files(/etc/hosts.{allow,deny})and if access is accepted, it then uses its own control routines.For this option to work, tcp_wrapper and its libraries have to be installed on the machine (Author'snote: what can be done with the wrapper can also be done with xinetd. Allowing this compatibilityleads to multiplying the config files, and makes the administration heavier... in short, I don'trecommend it);2.−−with−loadavg: this option allows xinetd to handle the max_load configuration option. Thisallows the deactivation of some services when the machine is overloaded. An options essential toprevent some DoS attacks (check the attributemax_loadintable 1);3.−−with−inet6: if you feel like using IPv6, this option allows to support it. The IPv4andIPv6connections are managed, but IPv4 addresses are changed into IPv6 format.Before starting xinetd, you don't have to stop inetd. Nevertheless, not doing so may lead to an unpredictablebehavior of both daemons!Some signals can be used to modify xinetd behavior:•SIGUSR1 : software re−configuration : the configuration file is re−read and the services parametersare changed accordingly•SIGUSR2 : hardware re−configuration: as above, but furthermore, the outdated daemons are killed•SIGTERM : ends xinetd and the daemons it generatedThere are a few others (let's mention a mistake in the documentation and the man pages: SIGHUP writes itsdump in the file/var/run/xinetd.dumpand not in/tmp/xinetd.dump),but the three mentionedabove can be easily managed with a small script containing the start, stop, restart, soft, hard options (the lattertwo respectively corresponding to SIGUSR1 and SIGUSR2).ConfigurationThe/etc/xinetd.conffile is the default configuration file for the xinetd daemon (a command lineoption allows to provide another one). The xinetd configuration is not very complex, but it may be a longwork and the syntax is unfortunately quite different from that of its predecessorinetd.Two utilities (itox andxconv.pl)are provided with xinetd and allow to convert the/etc/inetd.conffile into a configuration file for xinetd. Obviously, that's not enough since the rulesspecified in the wrapper configuration are ignored. Theitoxprogram, still maintained, is no longerdeveloped. Thexconv.plprogram is a better solution, even if the result has to be modified because offeatures that xinetd has in addition toinetd:>>/usr/local/sbin/xconv.pl < /etc/inetd.conf >/etc/xinetd.confThe configuration file begins with a default section. The attributes in this section will be used by every servicexinetd manages. After that, you will find as many sections as there are services, each of them being able tore−define specific options in relation to the default ones.The default values section looks like:defaults{attribute operator value(s)...}Each attribute defined in this section keeps the provided value(s) for all services described thereafter. Thus,theonly_fromattribute, allows to give a list of authorized addresses that should be able to connect toservers:only_from = 192.168.1.0/24 192.168.5.0/24 192.168.10.17Every service declared thereafter will allow access from machines having an address contained in the list.However, these default values can be modified for each service (check the operators, explained a bit furtherdown). Nevertheless, this process is a bit risky. As a matter of fact, to keep things simple and secure, it's muchbetter not to define default values and change them later on within a service. For instance, talking about accessrights, the simplest policy consists in denying access to everyone and next allowing access to each service tothose who really need it (with tcp_wrapper, this is done from anhosts.denyfile containingALL:ALL@ALL,and anhosts.allowfile only providing authorized services and addresses).Each section describing a service in the config file looks like:serviceservice_name{attribute operator value(s)...}Three operators are available: '=', '+=' and '−='. Most of the attributes only support the '=' operator, used toassign a fix value to an attribute. The '+=' operator adds an item to a list of values, while the '−=' operatorremoves this item.Thetable 1briefly describes some of these attributes. We'll see how to use them with a few examples.Reading thexinetd.confman pageprovides more information.Tab. 1: a few attributes for xinetdAttributeValues and descriptionOnly the most current values are mentioned here, check the documentation to find newones:•IDONLY : only accepts connexions from clients having an identificationserver;•NORETRY : avoids a new process to be forked again in case of failure;•NAMEINARGS : the first argument of theserver_argsattribute is used asargv[0]for theserver.This allows to usetcpdby putting it in theserverattribute, next writing the server name and its arguments such asserver_args,as you would do withinetd.xinetd usessyslogdand thedaemon.infoselector by default.•SYSLOG selector [level] : allows to choose amongdaemon, auth, userorlocal0−7fromsyslogd;•FILE [max_size [absolute_max_size]] : the specified file receives information.The two options set the file size limit. When the size is reached, the first onesends a message to syslogd, the second one stops the logging for this service (ifit's a common file − or fixed by default − then various services can beconcerned).Different information can be logged when a server starts:flagslog_type•PID : the server's PID (if it's an internal xinetd service, the PID has then a valueof 0) ;log_on_success•HOST : the client address ;•USERID : the identity of the remote user, according toRFC1413definingidentification protocol;•EXIT : the process exit status;•DURATION : the session duration.log_on_failureHere again, xinetd can log a lot of information when a server can't start, either by lackof resources or because of access rules:•HOST, USERID : like above mentioned ;niceno_accessonly_fromportprotocolserverserver_argssocket_type•ATTEMPT : logs an access attempt. This an automatic option as soon asanother value is provided;•RECORD : logs every information available on the client.Changes the server priority like thenicecommand does.List of clients not having access to this service.List of authorized clients. If this attribute has no value, the access to the service isdenied.The port associated to the service. If it's also defined in the/etc/servicesfile, the2 port numbers must match.The specified protocol must exist in the/etc/protocolsfile. If no protocol isgiven, the service's default one is used instead.The path to the server.Arguments to be given to the server.stream (TCP), dgram (UDP), raw (IP direct access) or seqpacket ().xinetd can manage 3 types of services :1. RPC : for those defined in the/etc/rpcfile... but doesn't work very well;2. INTERNAL : for services directly managed by xinetd (echo,time,daytime, chargenanddiscard);3. UNLISTED : for services not defined either in the/etc/rpcfile, or in the/etc/servicesfile ;Let's note it's possible to combine various values, as we'll see withservers,servicesandxadmininternal services.Defines the service behavior towards threads. Two values are acceptable:typewaitcpsinstancesmax_loadper_source•yes : the service is mono−thread, only one connexion of this type can bemanaged by the service;•no : a new server is started by xinetd for each new service request according tothe defined maximum limit (Warning, by default this limit is infinite).Limits the number of incoming connexions. The first argument is this number itself.When the threshold is exceeded, the service is deactivated for a given time, expressed inseconds, provided with the second argument.Defines the maximum number of servers of a same type able to work at the same time.This gives really the maximum load for a server (for example, 2 or 2.5). Beyond thislimit, requests on this server are rejected.Either an integer, or UNLIMITED, to restrict the number of connexion from a sameorigin to a serverThe four last attributes shown intable1allow to control the resources depending on a server. This is efficientto protect fromDenial of Service(DoS) attacks (freezing a machine by using all of its resources)This section presented a few xinetd features. The next sections show how to use it and give some rules tomake it work properly.Access ControlAs we have seen previously, you can grant (or forbid) access to your box by using IP addresses. However,xinetd allows more features :
[ Pobierz całość w formacie PDF ]