Книга: Сетевые средства Linux

Формат файла /etc/xinetd.conf

Формат файла /etc/xinetd.conf

Поскольку возможности нового суперсервера расширены по сравнению с inetd, формат конфигурационного файла также отличается от inetd. Настройка xinetd производится с помощью файла /etc/xinetd.conf. Следует заметить, что файл xinetd.conf, поставляемый в составе дистрибутивных пакетов Red Hat и Mandrake, содержит лишь минимальный набор установок. В нем задана конфигурация серверов, а также содержится строка, которая указывает суперсерверу прочитать все файлы в каталоге /etc/xinetd.d и интерпретировать их как дополнительные конфигурационные файлы. Конфигурация xinetd напоминает конфигурацию SysV; каждому серверу соответствует собственный управляющий файл, названный по имени сервера. Например, для сервера Telnet используется файл /etc/xinetd.d/telnet. При необходимости xinetd можно настроить так, что этот суперсервер будет использовать лишь основной файл xinetd.conf, но в дистрибутивных пакетах Red Hat и Mandrake некоторые файлы запуска уже содержатся в каталоге /etc/xinetd.d.

Независимо от того, содержится ли описание сервера в /etc/xinetd.conf или в файле, находящемся в каталоге /etc/xinetd.d, оно может занимать несколько строк. Базовое определение включает те же данные, что и запись в файле inetd.conf. Например, приведенное ниже описание почти эквивалентно рассмотренной ранее записи для Telnet-сервера, находящейся в файле inetd.conf.

service telnet
{
 socket_type = stream
 protocol = tcp
 wait = no
 user = root
 server = /usr/sbin/in.telnetd
}

В конфигурационном файле xinetd каждое поле именуется. Несмотря на то что в данном примере поля расположены в том же порядке, что и в рассмотренной ранее записи inetd, порядок их следования может быть произвольным. Как нетрудно заметить, в данном примере не вызывается TCP Wrappers, однако при необходимости этот инструмент можно использовать (для того, чтобы Telnet-сервер запускался через TCP Wrappers, надо задать значение /usr/bin/tcpd поля server и добавить поле server_args, присвоив ему значение /usr/sbin/in.telnetd).

В дополнение к стандартным средствам inetd xinetd предоставляет новые опции, расширяющие возможности суперсервера. Большинство из этих опций включаются в описание сервера и помещаются в фигурные скобки. Наиболее важные опции описаны ниже.

• Средства защиты. Как упоминалось ранее, xinetd поддерживает большое количество опций, предназначенных для повышения безопасности системы. Средства, соответствующие многим из этих опций, эквивалентны средствам, предоставляемым TCP Wrappers. Опции защиты подробно будут рассматриваться в следующем разделе.

• Запрет вызова сервера. Для того чтобы запретить вызов сервера, управляемого суперсервером inetd, надо закомментировать соответствующую строку в конфигурационном файле. В программе xinetd для этой цели используется опция disable = yes, которая помещается в описание требуемого сервера. Тот же результат можно получить, включив в раздел defaults основного файла /etc/xinetd.conf опцию disables = список_серверов, где список серверов состоит из имен серверов, разделенных пробелами. Различные инструментальные средства настройки используют оба способа. Если в описании сервера присутствует опция disable = no, это значит, что сервер активен.

• Перенаправление. Если вам необходимо передать запрос на другой компьютер, вы можете сделать это с помощью опции redirect = целевой_компьютер, где целевой компьютер (т.е, компьютер, которому должен быть передан запрос) задается с помощью доменного имени или IP-адреса. Например, если вы включите в описание сервера, содержащееся в файле /etc/xinetd.d/telnet на узле dummy.threeroomco.com, опцию redirect = 192.168.3.78, то при попытке обращения к Telnet-серверу на компьютере dummy.threeroomco.com запрос будет перенаправлен на 192.168.3.78. Эту возможность использует NAT-маршрутизатор для того, чтобы организовать обслуживание внешних запросов компьютером, принадлежащим внутренней сети. Тот же результат достигается с помощью iptables, но применяя для этой цели xinetd, вы можете использовать средства управления доступом суперсервера.

• Протоколирование. Используя опции log_on_success и log_on_failure суперсервера xinetd, вы можете определять, какая информация должна записываться в файл протокола в случае успешного или неудачного обращения к серверу. Значениями этих опций могут быть PID (идентификатор процесса сервера), HOST (адрес клиента), USERID (идентификатор пользователя клиентской системы, которая передала запрос), EXIT (время получения запроса и статус завершения его обработки) и DURATION (длительность сеанса). При необходимости вы можете добавлять к набору, принятому по умолчанию, или исключать из него отдельные значения, используя вместо символа = пары символов += и -=.

• Ограничения на установление соединений. Ограничить число соединений, поддерживаемых xinetd, можно несколькими способами. Опция per_source определяет, сколько запросов от одного источника xinetd может обработать в единицу времени. (Значение UNLIMITED этой опции позволяет обрабатывать неограниченное число запросов.) Опция instances задает максимальное количество процессов, которые xinetd может породить (это значение должно быть больше, чем значение опции per_source). При использовании опции cps ей передаются два значения, разделенные пробелом: число соединений, которые xinetd может установить в течение одной секунды, и длительность паузы (в секундах), которая должна быть выдержана, если число соединений превысит максимально допустимое. Приоритет серверов, управляемых xinetd, задается с помощью опции nice; эта опция действует подобно программе nice. И наконец, опция max_load, значением которой является число с плавающей точкой, указывает максимальную загрузку системы, при достижении которой xinetd должен отвергать последующие запросы. При использовании этих опций снижается вероятность того, что сервер пострадает от атаки, предпринятой с целью вывода его из строя, или в результате обилия запросов, вызванных высокой популярностью сервера.

Большинство из приведенных выше опций можно использовать либо в описании сервера, либо в разделе defaults файла /etc/xinetd.conf. Помещенная в раздел defaults опция воздействует на все серверы, управляемые xinetd. Если опция присутствует и в разделе defaults, и в описании, принимается значение опции, заданное в описании сервера.

Если вы внесли изменения в файл /etc/xinetd.conf или в один из файлов, содержащихся в каталоге /etc/xinetd.d, необходимо перезапустить программу xinetd. Поскольку суперсервер xinetd чаще всего запускается посредством сценария SysV, проще всего перезапустить его с помощью команды типа /etc/rc.d/init.d/xinetd restart (в некоторых системах сценарий запуска может находиться в другом каталоге). Можно поступить и по-другому — передать xinetd сигнал SIGUSR1 или SIGUSR2, используя для этого команду kill. При получении сигнала SIGUSR1 xinetd читает содержимое нового конфигурационного файла и продолжает работу. В ответ на сигнал SIGUSR2 суперсервер делает то же самое, но при этом завершает работу тех серверов, которые согласно новому конфигурационному файлу должны быть неактивны.

Оглавление книги