Главная » 2013 » Декабрь » 12 » 8.1. Суперсерверы inetd и xinetd
01:52
8.1. Суперсерверы inetd и xinetd

В данной главе пойдет речь об общей настройке Интернет‑суперсерверов inetd и xinetd, а также о настройке сервера xinetd для работы с протоколом IPv6.

Для начала все же определимся, почему inetd(xinetd) называется суперсервером? Да потому, что он отвечает за установление TCP‑соединения, то есть он прослушивает пакеты и запускает необходимые программы для обработки информации. Таким образом, получается, что сервер inetd (xinetd) управляет другими серверами и потому называется суперсервером. Например, если в запросе клиента будет требование установить соединение с двадцать первым портом, то суперсервер вызовет сервер ftp, конечно, при условии, что соединение с 21‑м портом разрешено (в противном случае клиент получит сообщение Connection refused).

По правде говоря, все не так просто как я описал – на практике все намного сложнее: за установление TCP‑соединений отвечает демон tcpd (в более ранних версиях Linux его не было), программы‑сервисы (httpd, ftpd) могут постоянно находиться в памяти (режим standalone), в этом случае они сами обрабатывают пакеты, и, соответственно, суперсервер их уже не вызывает.

8.1.1. Настройка сервера inetd

Для начала разберемся с настройкой inetd. Этот сервер использовался в дистрибутиве RedHat до версии 7, в более новых версиях он заменен на xinetd (описание этого суперсервера приведено далее в п. 8.1.4…8.1.7). При конфигурирования inetd вам потребуется отредактировать два файла /etc/inetd. conf и /etc/services. Первый, собственно, и есть файл конфигурации суперсервера, а во втором перечислены все сетевые службы, которые доступны в вашей системе. Формат файла /etc/services следующий:

Листинг 8.1. Фрагмент файла /etc/services

Postoffice в данном случае является псевдонимом. Для некоторых служб могут потребоваться использование нескольких протоколов (как в листинге 8.1 для POP3 используется два протокола – TCP и UDP) и/или нескольких портов (см. листинг 8.2).

Листинг 8.2. Несколько портов для сервиса ftp (RedHat)

В других версиях ftp может потребоваться только одна запись – ftp 21/tcp. Из соображений безопасности лучше закомментировать символом # сервисы, которые вы не планируете использовать, например, если у вас роутер, то зачем вам sendmail (port 25)?

Теперь переходим к файлу /etc/inetd. conf. Каждая запись в этом файле имеет следующий формат:

Где:

Имя – имя сетевой службы, которое должно быть указано в файле /etc/services.

Тип_сокета – в этом поле указывается тип сокета, то есть тип технологии доставки данных для указанной службы. Наиболее часто используются значения: stream (поток) – для протокола TCP, dgram (дейтаграмма) – для протокола UDP и raw –непосредственно для протокола IP.

Протокол – имя протокола.

Флаги – с помощью флагов указывается статус ожидания. В качестве значения этого поля указывается ключевое слово wait или nowait. Если указано wait, то суперсервер inetd будет ожидать завершения работы данной сетевой службы на данном сокете, прежде чем перейти в состояние ожидания других запросов других служб на подключение к этому сокету. То есть в данной ситуации суперсервер перестает «слушать» порт до тех пор, пока на нем не завершит работу уже запущенная сетевая служба. Значение nowait приводит к обратной ситуации: после запуска описываемой сетевой службы суперсервер продолжает прослушивать сокет в ожидании других подключений. Обычно для служб с типом сокета stream устанавливается статус ожидания nowait, а для служб с типом сокета dgram – статус ожидания wait.

Пользователь – в этом поле указывается имя пользователя, с правами которого запускается описываемая сетевая служба (соответствующий ей сервер).

Путь – в этом поле указывается полное имя сервера (включая путь к нему), который должен быть запущен для обслуживания данного соединения.

Аргументы – все оставшиеся поля воспринимаются как аргументы для запускаемого сервера.

Ниже (см. листинг 8.3) приведен пример записи в файле /etc/inetd. conf.

Листинг 8.3. Фрагмент файла/etc/inetd. conf

Где:

Ftp – имя сетевой службы;

Stream – задает тип сокета stream (потоковый сокет);

Tcp – протокол (указан протокол tcp, так как именно этот протокол использует служба FTP в качестве протокола транспортного уровня);

Nowait – суперсервер продолжает «слушать» порт после выполнения одного сервера для определенного порта;

Root – сервер FTP будет запущен с правами root;

/usr/sbin/tcpd – сервер, который будет вызван для обработки соединения;

In. ftpd – аргумент, то есть программа, которую должен выполнить tcpd после проверки некоторой информации (о ней немного позже).

Еще вы можете написать и так, для прямого вызова службы ftp (ProFTP):

В данном случае сразу будет вызван демон ProFTP. Запись in. proftpd является ссылкой на proftpd. Если будете использовать такой вызов ProFTP, позаботьтесь о том, чтобы proftpd имел тип inetd, а не standalone.

8.1.2. Настройка tcpd

Демон inetd является довольно удобным в использовании средством для организации работы Интернет‑сервера. И все было бы замечательно, если бы не одно «но». А это «но» заключается в том, что разработчики inetd очень мало уделили внимания защите, что является недопустимым в нашей суровой Интернет‑действительности. Восполнить этот недочет призван демон tcpd (система TCP‑Wrappers). Так что давайте теперь разберемся, что же представляет из себя демон tcpd, который является еще одним барьером в системе безопасности.

Демон tcpd аутентифицирует удаленных пользователей и проверяет корректность их запросов. С помощью этого демона можно ограничить запросы с удаленных компьютеров.

Файл hosts. allow содержит список хостов, которым разрешено подключаться к вашей системе, a hosts. deny – запрещено. Записи имеют формат служба:хост. домен. Если вы хотите разрешить или запретить доступ всем, используйте ALL. Запись ALL:ALL открывает или закрывает доступ к вашему компьютеру для всех остальных компьютеров и для всех видов сервисов (см. листинг 8.4).

Листинг 8.4. Файл /etc/hosts. allow

В листинге 8.4 доступ к http и ftp разрешен всем, но доступ ко ВСЕМ сервисам разрешен только компьютеру server. dhsilabs. com.

8.1.3. Протокол IPv6

Думаю, что основной момент настройки понятен, и теперь переходим к протоколу IPv6. Схема 32‑разрядной адресации протокола IPv4 привела к дефициту IP‑адресов. В новой версии протокола IP (IPv6, ранее именовавшегося IPng – IP next generation) адрес состоит из 16‑ти октетов и изображается в виде восьми пар октетов, разделенных двоеточиями. В версии 6 используется 128‑разрядные адреса получателей и отправителей (это в 4 раза больше, чем в 4‑ой версии). Адрес в формате IPv6 может выглядеть так:

Заголовок 1Ру6‑пакета разработан таким образом, чтобы минимизировать содержащуюся в нем информацию. Поля параметров и поля, которые не являются необходимыми, вынесены за пределы заголовка.

Протокол IPv6 подробно описан в RFC 1883, а IPv4 – в RFC 791.

8.1.4. Установкаx inetd

Суперсервер xinetd является достойной заменой inetd. Этот суперсервер, помимо всего прочего, обладает встроенными механизмами защиты, которые для inetd выполняет специальный демон tcpd. К тому же xinetd, в отличии от inetd, поддерживает IPv6. Даже если вы пока не планируете переходить на IPv6, установка xinetd будет очень полезной из‑за расширенных функций суперсервера. Сам xinetd появился в Red Hat начиная с 7‑ой версии и обычно устанавливается во время установки системы. Если у вас он еще не установлен, сейчас самое время это сделать.

При этом рекомендую пойти по пути наименьшего сопротивления и установить xinetd из RPM‑пакета, а можно и выкачать из Интернет последнюю версию xinetd по адресу http://www. svnack. net/xinetd и установить его из исходных кодов.

После того, как вы распакуете исходники, введите ./configure, перейдя предварительно в каталог с исходниками (при этом желательно иметь права root). Для сценария configure вы можете использовать параметры, представленные в табл. 8.1.

Параметры сценария configure Таблица 8.1

Параметр

Описание

‑‑with‑libwrap

Демон будет использовать tcp wrappers. При этом у вас уже должен быть установлен libwrap. С этой опцией xinetd будет сперва проверять ваши /etc/hosts. allow и /etc/hosts. deny файлы, и только после этого запускает свой механизм контроля доступа

‑‑with‑loadavg

Компилирует xinetd с опцией max_load. Этот параметр остановит сервис, когда нагрузка достигнет определенного уровня

‑‑wilh‑inet6

Включает поддержку IPv6

Внимание! При включении IPv6 все IPv4‑сокеты становятся IPv6‑сокетами и соответственно ядро (это прежде всего) и все программы должны поддерживать IPv6. Поэтому будьте готовы к тому, что вам понадобится перекомпилировать свое ядро с поддержкой IPv6. Если ваше ядро не поддерживает IPv6, выкачайте последнюю версию ядра по адресу http://www. kernel. org. Тем не менее, и после включения IPv6 запросы IPv4 также будут обрабатываться. Так что никакой аварийной ситуации не будет.

Возвращаясь к настройке: теперь введите make, а затем – make install.

Файл конфигурации xinetd – /etc/xinetd. conf отличается по синтаксису от файла конфигурации inetd. Но если inetd у вас уже настроен и вам лень настраивать все заново, воспользуйтесь программой itox: itox < /etc/inetd. conf > /etc/xinetd. conf

Такое использование команды itox верно при условии, что файлом конфигурации inetd является файл /etc/inetd. conf, a xinetd –/etc/xinetd. conf. Но в любом случае, вам не помешает разобраться с форматом xinetd. conf.

Рис. 8.1. Автозапуск суперсервера

После установки суперсервера из RPM‑пакета или его сборки из исходных текстов, xinetd (или inetd) добавляется в сценарий автозагрузки системы. Напомню, что включить или отключить запуск xinetd (inetd) или любого другого сервиса всегда можно с помощью конфигуратора drakxservices в Linux Mandrake или setup в Linux Red Hat (см. рис. 8.1).

8.1.5. Настройка xinetd

Синтаксис файла xinetd. conf такой:

Service_name – это имя сервиса (login, shell, telnet, ftp, pop3 и т. д). Оператор присваивания может быть одним из следующих: «=», «+=», «‑=». Большинство атрибутов может работать только с оператором «=» (равно). Назначение операторов следующее:

«=» – присвоить значение атрибуту;

«+=» – добавить еще одно значение;

«‑=» – удалить значение.

Атрибут может иметь несколько значений, указанных через пробел. Некоторые параметры очень похожи на параметры inetd. Список всех атрибутов приведен в табл. 8.2.

Атрибуты сервиса для сервера xinetd Таблица 8.2

Атрибут

Описание

Id

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

Туре

Может быть использована любая комбинация из следующих значений: RPC – если это сервис RPC (Remote Procedure Call). UNLISTED – если сервис не описан в файле /etc/rpc для rpc‑сервисов или в /etc/services для не rpc. INTERNAL – если xinetd представляет этот сервис (для echo, time, daytime, chargen, и discard). Если RPC‑сервисы у вас работают некорректно после установки xinetd, вы можете использовать для них старый inetd – inetd и его новая версия xinetd прекрасно уживаются вместе. В файле /etc/inetd. confоставьте только rpc‑сервисы, а остальное закомментируйте, а в /etc/xinetd. conf – наоборот

Flags

В качестве значения может быть использована любая комбинация из следующих значений: NODELAY – для tcp‑сервиса будет установлен флаг сокета – TCP_NODELAY. Только для TCP‑сервисов! DISABLE – отключить сервис. KEEPALIVE – установка флага сокета SO_KEEPALIVE. Только для TCP‑сервисов! REUSE – установить флаг SO_REUSEADDR на сокет сервера. INTERCEPT – перехватывать пакеты или принимать соединения по порядку, проверяя, что они приходят из нужных мест. NORETRY – избегать повторных попыток в случае неудачи. IDONLY – соединение будет приниматься только от идентифицированных пользователей. На удаленной машине должен работать identification‑сервер

Disabled

Может принимать 2 значения, «yes» и «no». Если указать «yes», сервис запускаться не будет

Socket_type

Тип сокета. Может принимать следующие значения: stream – сокет stream, обычно используется службами, работающими на основе протокола TCP dgram – сокет dgram, обычно используется службами, работающими на основе протокола UDP raw – сокет raw для сервисов, требующих прямого доступа к IP seqpacket – сокет seqpacket для сервисов, требующих надежную последовательную пересылку дейтаграмм

Protocol

Задает протокол, по которому будет работать сервер (top, udp, …)

Wait

Задает статус ожидания и может принимать два значения: yes и no, которые соответствуют значениям wait и nowait для сервера inetd (см. выше). Значение yes обычно устанавливается на сокетах dgram, а значение no на сокетах stream

User

Задает пользователя, от имени которого будет запущен сервер. Пользователь должен быть определен в файле /etc/passwd. По умолчанию сервер запускается от имени пользователя root

Server

Указывает абсолютный путь к запускаемому серверу

Server args

Определяет аргументы, которые будут переданы серверу

Log_on_failure

Определяет, какая информация будет писаться в файл отчета (протокол), если сервис по каким‑либо причинам не запустился: HOST – записывать адрес удаленного хоста. USERID – если возможно, записывать идентификатор удаленного пользователя (используется протокол идентификации RFC 1413). ATTEMPT – записывать факт неудачной попытки. RECORD – записывать информацию с удаленного хоста, в случае невозможности запуска сервера

Log_on_success

Определяет, какая информация будет писаться в файл отчета (протокол) в случае удачного запуска сервиса. Можно комбинировать любые из следующих значений: PID – записывать идентификатор запущенного серверного процесса. HOST – записывать адрес удаленного хоста. USERID – если возможно, идентификатор удаленного пользователя (используется протокол идентификации RFC 1413). EXIT – записывать, каким образом был произведен выход. DURATION – записывать продолжительность сессии

Rpc_number

Определяет номер сервиса RPC

Rpc_version

Определяет версию сервиса RPC

Env

Задает значение атрибута. Атрибут представляет собой список строк типа: «name=value». Эти переменные будут добавлены в окружение перед тем, как сервер будет запущен

Passenv

Это список переменных окружения из окружения xinetd, которые могут быть переданы серверу

Port

Определяет порт сервиса. Если порт указан в файле /etc/services, то значение данного параметра должно совпадать с ним

Redirect

Позволяет tcp‑сервису делать перенаправление на другой хост. Значение задается в виде host:port

Interface

Устанавливает интерфейс, на котором будет работать сервис. Синтаксис: interface=IP‑адрес

Bind

Это синоним параметра interface

Banner

Определяет имя файла, который будет показываться при соединении с сервисом

Banner_success

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

Banner_fail

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

Cps

Атрибут имеет два аргумента. Первый устанавливает количество соединений в секунду. Если это число будет превышено, сервис будет временно недоступен. Второй – число секунд, после которых сервис снова будет доступен

Max_load

Определяет максимальную загрузку. При достижении максимума, сервер перестает принимать запросы на соединение. Значение параметра – число типа float

Instances

Устанавливает число серверов, которые могут быть активны одновременно для сервиса (по умолчанию лимита нет). Значением этого атрибута может быть число, либо – UNLIMITED

Nice

Устанавливает приоритет сервиса

Примечание. RPC (Remote Procedure Call) – вызов удаленной процедуры. Используется в серверной части приложения. Механизм RPC скрывает от программиста детали сетевых протоколов нижележащих уровней.

Вам необязательно указывать все эти атрибуты для каждого сервиса. Можно указать только необходимые:

1. socket_type

2. user

3. server

4. wait

Параметр protocol указывается только для RFC‑сервисов, а также для всех сервисов, которые не описаны в /etc/services. Параметр rpc_version – только для rpc‑сервисов. Параметр rpc_nuinber указывается только для RFC‑сервисов, которые не указаны в файле /etc/rpc. Параметр port задается только для He‑RPC‑сервисов, которые не описаны в /etc/services. Следующие атрибуты поддерживают все операторы присваивания:

1. only_from

2. no_access

3. log_on_success

4. log_on_failure

5. passenv

6. env (не поддерживает оператор «‑=»)

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

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

1. log_type

2. log_on_success

3. log_on_failure

4. only_from

5. no_access

6. passenv

7. instances

8. disabled

9. enabled

8.1.6. Параметры запуска xinetd

Я надеюсь, что с настройкой более‑менее все понятно. Если же мои надежды не оправдались, то в разделе 8.1.7 вы найдете пример файла /etc/xinetd. conf. Сейчас же займемся запуском только что откомпилированного и настроенного суперсервера. А запускать его можно с параметрами, указанными в табл. 8.3.

Параметры запуска xinetd Таблица 8.3

Параметр

Описание

‑f файл

Устанавливает альтернативный файл конфигурации, который должен использоваться вместо стандартного файла /etc/xinetd. conf

‑pidfile рid_файл

Файл с ID‑процесса

‑stayalive

Даже если ни один сервис не прописан, демон должен выполняться («остаться в живых»)

‑loop число

Задает количество коннектов в секунду

‑d

Режим отладки (debug mode)

‑reuse

Перед тем как связать сокет сервиса с IP‑адресом, суперсервер установит опцию сокета SO_REUSEADDR

‑limit число

Ограничение на количество одновременно запущенных процессов

В табл. 8.3 я привел описание не всех параметров запуска, выбрав лишь самые нужные. Более подробную информацию вы сможете получить в документации по xinetd. Так Же как и inetd, xinetd можно контролировать с помощью сигналов (см. табл. 8.4).

Сигналы суперсервера Таблица 8.4

Сигнал

Описание

SIGUSR1

Суперсервер перечитает файл конфигурации

SIGQUIT

Остановит xinetd

SIGTERM

Перед остановкой xinetd все процессы будут остановлены

8.1.7. Пример файла конфигурации /etc/xinetd

Теперь, как и обещал, привожу пример файла конфигурации (см. листинг 8.5). В этом листинге перечислены наиболее часто используемые сервисы с оптимальными параметрами (атрибутами). Конечно же, вам предстоит решить: какие сервисы вы будете использовать, а какие нет. Возможно, вы также измените и их атрибуты, например, время работы сервиса.

Листинг 8.5. Фрагмент файла конфигурации /etc/xinetd

Как видно из примера, я описал лишь те сервисы, которые больше всего необходимы. Доступ к сервисам в рассматриваемом примере могут получать только из сети 111.111.111.0, 111.111.112.0 и 192.168.1.0. Можно также указывать адрес и маску подсети, например 192.168.1.0/32. Вместо sendmail я использовал qmail. Можно было бы запускать qmail в режиме standalone, но так как я не очень часто пользуюсь услугами 25‑го порта, то мне удобнее запускать сервис smtp через xinetd. Из соображений безопасности я отключил некоторые сервисы: finger, telnet.

Категория: Конфигурирование сервера | Просмотров: 595 | Добавил: spb_serge | Рейтинг: 0.0/0
Всего комментариев: 0
Имя *:
Email *:
Код *: