Сетевые средства Linux

Смит Родерик В.

• Запрет вызова сервера. Для того чтобы запретить вызов сервера, управляемого суперсервером

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

суперсервер делает то же самое, но при этом завершает работу тех серверов, которые согласно новому конфигурационному файлу должны быть неактивны.

Средства управления доступом

Одно из преимуществ

xinetd

состоит в том, что эта программа объединяет в себе функции суперсервера и средства управления доступом, характерные для TCP Wrappers. Кроме того, настройка

xinetd

выполняется достаточно просто. Средства управления доступом

xinetd

не дублируют соответствующие функции TCP Wrappers; некоторые задачи лучше решаются с помощью

xinetd

, для решения других приходится применять TCP Wrappers. Настраивая

xinetd

, можно определять доступ либо одновременно для всех серверов, либо для каждого сервера в отдельности. Основные опции, предназначенные для управления доступом, описаны ниже.

• Ограничения для различных узлов. Для

xinetd

предусмотрены опции

only_from

и

no-access

, которые выполняют те же функции, что и содержимое файлов

/etc/hosts.allow

и

/etc/hosts.deny

TCP Wrappers. Эти опции могут присутствовать либо в главном конфигурационном файле, либо в файле, предназначенном для конкретного сервера. В качестве значения опции

only_from

задается список компьютеров, которым разрешено обращаться к серверу (для всех остальных компьютеров доступ запрещен). Аналогично, значение опции no-access представляет собой "черный список"; компьютеры, указанные в списке, не имеют права устанавливать соединение с сервером, а для остальных компьютеров доступ разрешен. Если адрес присутствует в обоих списках, приоритет имеет адрес, заданный более конкретно. Для идентификации компьютеров используются разные способы. В опциях

only_from

и

no-access

может быть указан IP-адрес узла (например, 172.23.45.67), адрес сети, оканчивающийся нулем (например, 172.23.0.0 для сети 172.23.0.0/16) или заданный с помощью маски (172.23.0.0/16), имя сети, указанное в файле

/etc/networks

, или доменное имя узла (например,

badguy.threeroomco.com

). Если в качестве значения опции указано имя узла,

xinetd

выполняет преобразование имени в адрес один раз при загрузке суперсервера. Поскольку в течение работы

xinetd

доменное имя может измениться, данный способ установления ограничений неэффективен.

• Ограничения по времени. Для указания временного интервала, в течение которого сервер доступен для клиентов, используется опция

access_times

. Значение этой опции задается в формате

часы:минуты– часы:минуты

, например, 08:00-18:00 означает, что к серверу можно обращаться с 8 до часов. Значение опции

access_times

влияет только на установление соединения. Например, если для Telnet-сервера задан интервал 08:00-18:00, то соединение, установленное в 17:58, может использоваться как угодно долго.

• Ограничения на использование интерфейсов. При необходимости вы можете связать сервер с одним сетевым интерфейсом. Для этого используется опция

bind

(либо опция

interfасе

, которая является синонимом

bind

). В качестве значения опции задается IP-адрес, связанный с интерфейсом. Например, если интерфейсу

eth1

присвоен адрес 172.19.28.37 и для сервера задана опция

bind = 172.19.28.37

, это означает, что обращаться к этому серверу можно только через интерфейс

eth1

. Попытки установить соединение через

eth0

окончатся неудачей; результат будет такой же, как в случае, когда сервер не установлен в системе. Эту опцию удобно использовать на маршрутизаторах или на компьютерах, подключенных одновременно к нескольким сетям. Предположим, что на компьютере, обеспечивающем связь локальной сети с Internet и использующем для соединения с сервером провайдера PPP-соединение, установлены серверы Telnet и FTP. С помощью опции

bind

вы можете настроить

xinetd

так, чтобы доступ к серверам Telnet и FTP имели только компьютеры, подключенные к локальной сети.

В этом и предыдущем разделе были описаны лишь наиболее часто используемые опции

xinetd

. Для получения информации об остальных опциях обратитесь к справочным данным.

Использование локальных сценариев запуска

Как правило, в системе Linux большинство стандартных серверов запускается либо с помощью сценариев SysV, либо суперсервера. Исключением является сервер X, для запуска которого в файле

/etc/inittab

предусмотрена соответствующая запись. Сервер X запускается только на конкретном уровне выполнения. В системе Slackware для запуска основных серверов используется

/etc/rc.d/rc/inet2

. Большинство дистрибутивных пакетов включает локальные сценарии запуска, редактируя которые администратор имеет возможность обеспечить работу дополнительного сервера, запустить специальную утилиту или выполнить другие подобные действия. Локальные сценарии запуска для основных дистрибутивных пакетов Linux приведены в табл. 4.1.