Родерик Смит - Сетевые средства 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.
