Xinetd — это альтернатива традиционному супер-серверу inetd, процессу, управляющему запуском и остановом сетевых серверов, не нуждающихся находиться в постоянно запущенном состоянии. Xinetd является не просто заменой, он умеет выполнять гораздо больше, нежели простой запуск и останов демонов в ответ на входящие TCP и UDP соединения. Наиболее значимым преимуществом xientd является его отличная конфигурируемость, включая списки контроля доступа (ACL), ограничение скорости, ограничение доступа по времени и перенаправление потоков.

Пакеты с xinetd присутствуют практически во всех популярных дистрибутивах Linux, в Freebsd находится порт (/usr/ports/security/xinetd) так что вы без труда должны установить его в вашей системе, используя менеджер пакетов. Если такой способ вам по каким-то причинам не подходит, вы можете скачать исходники с xinetd.org и собрать супер-сервер традиционным способом. Xinetd при сборке не требует каких-то экзотических зависимостей. Естественно, обратите внимание, чтобы в вашей системе уже не был установлен из пакетов xinetd, если будете собирать его из исходных кодов. И не забудьте сохранить /etc/inetd.conf перед тем, как начинать.

Файл конфигурации inetd состоит из строк, каждая из которых описывает одну службу. Строка состоит из:

Для примера, фрагмент файла конфигурации inetd:

Первая строка запускает IMAP-сервер всякий раз при входящем подключении на TCP-порт 220. Во второй строке описан запуск сервера Sane, предоставляющего разделение доступа к сканеру.

Формат конфигурационных файлов xinetd имеет другую структуру. Здесь каждый сервис описывается группой опций, помещённых в фигурные скобки. Каждое описание сервиса начинается со слова service, за которым следует имя сервиса, а затем описание параметров, заключённое в фигурных скобки. Например:

Первые несколько строк приведённого примера описывают то же, что и пример конфигурации inetd, представленный выше: TCP, stream, nowait, root. А вот оставшиеся строки — это уже возможности, предоставляемые только  xinetd. Параметр only_from позволяет определить список хостов, разделённых пробелами, с которых разрешены входящие подключения. В значении параметра banner_fail указывается путь к текстовому файлу, содержащему сообщение, передаваемое клиенту в случае, если подключение запрещено. Вы также можете воспользоваться атрибутом banner_success, чтобы отправлять сообщение в случае успешных подключений, и banner, если хотите отправлять сообщение независимо от того, успешным или неудачным было подключение.

Значение параметра log_on_failure определяет, какая информация будет заноситься в лог, в случае неудачных подключений. Обратите внимание на используемый оператор «+=» вместо «=» — при его использовании USERID будет добавлен к существующей информации, которая отправляется в лог по умолчанию. Как вы, наверное, догадались, параметр log_on_success тоже доступен. Существуют различные варианты информации, которую xinetd может протоколировать, как, например, имя удалённого хоста и количество трафика.

Вы можете затолкать всю конфигурацию xinetd в один-единственный файл /etc/xinetd.conf, а можете разбить её  на несколько мелких файлов, например, по одному сервису в каждый файл. Чтобы сделать это, воспользуйтесь директивой includedir, размещённой в конце файла основной конфигурации. В качестве аргумента директиве необходимо передать путь к каталогу, содержащему файлы конфигурации сервисов. Все файлы, имена которых не начинаются с точки или тильды, буду обработаны xinetd, как файлы конфигурации. В некоторых дистрибутивах подобная схема реализована по умолчанию, а каталогом для хранения файлов конфигурации является /etc/xinetd.d.

В случае, если вы используете такую разделённую конфигурацию, у вас, вероятней всего, имеется запись «default» в файле /etc/xinetd.conf. Это специальная запись, в которой описываются атрибуты, которые буду применены ко всем остальным записям, в которых они не буду обнаружены. Конечно, такие атрибуты, как server и socket_type не имеют смысла в «глобальном» их применении, однако есть ряд атрибутов, которые могут быть одинаковыми для всех или почти всех записей. Вы можете сэкономить себе немного времени, определив такие атрибуты в defaults. Например:

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

Базовым атрибутом, отвечающим за управление доступом, является only_from. В отличие от /etc/hosts_allow, при помощи only_from вы можете управлять доступом к каждому сервису отдельно. Или же, можно определить «умолчания» в записи default, а затем в отдельных записях конфигурации корректировать нужное при помощи операторов «+=» и «-=».  Зеркальным отражением атрибута only_from является атрибут no_access, который может отключать доступ к сервису на основании IP-адресов или имён хостов. Оба атрибута также принимают диапазоны IP-адресов в формате IP-адрес/маска.

Директива access_times позволяет управлять доступом к сервису на основании системного времени. Определяя эту директиву, вы задаёте промежуток времени, в течение которого будет разрешён доступ к сервису, в формате «чч:мм-чч:мм». Например

Оставляет сервис доступным с 5 до 11 утра, затем закрывает его «на обед» до часу дня, затем опять открывает до 16:30. Как видите, можно указывать последовательности временных интервалов. Если же вам необходимо управлять не разрешением, а запретом доступа по времени, используйте опцию deny_time.

Приведённые выше параметры контроля доступа можно комбинировать с «адаптивными» настройками, настроив которые, можно сделать так, чтобы сервис становился недоступным после наступления определённых обстоятельств. Например, атрибут per_source, принимающий в качестве аргумента целое число, позволяет ограничивать количество одновременных подключений к сервису. Такая возможно может быть использована, например, чтобы ограничить количество одновременных соединений к SMTP -серверу в случае, если в вашей сети где-то завёлся спам-бот.

Атрибут cps позволяет вам ограничивать частоту входящих соединений в течение одной секунды, при превышении этой частоты сервис будет недоступен в течение определённого времени, которое вы укажете. Использование подобной функции может помочь предотвращать DoS-атаки. Например, если вы определите:

то при достижении 81 подключения за секунду, сервис будет отключён на 60 секунд, после чего продолжит принимать входящие подключения.

Также, вы можете определить порог отключения сервиса для таких параметров, как:

Атрибут redirect позволяет перенаправлять весь TCP-трафик (но не UDP!) к другому хосту. Синтаксис атрибута очень прост:

Когда xinetd принимает входящее подключение к сервису, в описании которого присутствует этот атрибут, супер-сервер открывает TCP-соединение к хосту, указанному в параметре атрибута, и «пробрасывает» к нему входящее TCP-соединение на указанный порт.

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

Xinetd, кроме всего прочего, позволяет привязывать каждый сервис к определённому сетевому интерфейсу. Это может оказаться полезным, например, в ситуациях, когда какой-то сервис генерирует большое количество трафика и вы хотите сделать так, чтобы обмен данными с таким сервисом был возможен только через высокоскоростное проводное соединение, а не Wi-Fi. Если у вас есть потребность в подобном функционале, пользуйтесь атрибутами interface или bind, передав ему IP-адрес нужного интерфейса в качестве параметра.

Большую часть функционала, предлагаемого xinetd, можно реализовать и при помощи других программ, таких как inetd, TCP Wrapper, iptables и т. п. Однако в этом случае вы лишаетесь единого инструмента управления всем этим «хозяйством».