Праймер Xinetd

Xinetd – это хранитель, который управляет доступом к вашему компьютеру из Интернета. Это демон, который работает все время и прослушивает на всех портах запросы на подключение или обслуживание. Если вы не запускаете сервер, вам не понадобится xinetd. Однако даже если ваш компьютер предназначен только для домашнего использования, вам может потребоваться разрешить другим пользователям доступ к службам на вашем компьютере в будущем. Когда вы делаете, вам нужно будет установить xinetd для защиты вашего компьютера от вредоносной активности.

Операционная система

Утилита xinetd была написана для Unix и Unix-подобных систем. Таким образом, он будет установлен на Linux и Mac OS, но не на Windows. Программа бесплатна для использования и доступна из GitHub.

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

Назначение xinetd

Система Xinet предназначена для функционирования в качестве сервер. Вы, вероятно, знаете, что при обычном подключении к Интернету один компьютер связывается с другим. Компьютер, который инициирует контакт, называется «клиентИ программа, с которой связываютсясервер.«Обычная причина подключения заключается в том, что клиент может получить услугу с сервера. Однако на подключенном компьютере должна быть запущена программа, ожидающая запросов. Это функция xinetd.

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

Альтернативы: Xinetd против INETD

Разработчики xinetd были не первыми, кто придумал идею программы, которая прослушивает в сети входящие запросы. Фактически, xinetd предназначен для улучшения исходной программы, которая выполняла эту задачу, которая называется inetd..

Название «xinetd» является аббревиатурой от «расширенный интернет-сервис». «Демон интернет-сервисов» описывает оригинал Inetd. С помощью inetd вы получаете тот же мониторинг запросов к серверу, что и xinetd. Тем не менее, этот демон не имеет защитных механизмов и поэтому считается небезопасным.

Старый inetd работал не один. Он передал запросы на TCPD, который проверил на разрешениях файлов (hosts.allow и hosts.deny). Как следует из названия, tcpd обрабатывает запросы TCP-соединений. Тем не менее, он также проверяет порты UDP, так что это реализация интерфейса транспортного уровня. Вы также можете увидеть упоминание оболочки TCP – это просто другое название tcpd. Включение tcpd добавило некоторое улучшение контроля доступа. Тем не менее, процесс разрешения был вызван двумя заполненными вручную файлами, и поэтому это не было всеобъемлющим решением для обеспечения безопасности..

Особенности Xinetd

Режим работы xinetd аналогичен режиму inetd в сочетании с tcpd. Однако решение xinetd обладает гораздо лучшими функциями безопасности, чем комбинация inetd / tcpd. Особенности демона включают в себя:

• контроль доступа по TCP и UDP
• регистрация событий, которая регистрирует успешное и неудачное соединение
• контроль доступа на основе временных сегментов
• ограничение количества одновременных серверов – защита от отказа в обслуживании (DoS)
• ограничение размера файла журнала
• распределение услуг по разным интерфейсам, что позволяет ограничивать определенные услуги частной сетью
• функция прокси, включая трансляцию сетевых адресов

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

Методы контроля доступа

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

Выбор, будете ли вы идентифицировать запросчиков по IP-адресу, имени хоста или имени домена, остается за вами. тем не мение, придерживаться IP-адреса создает соединения быстрее потому что это устраняет необходимость в фазе поиска.

Конфигурация системы

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

Демон будет продолжать проверять файл конфигурации всякий раз, когда он получает запрос от внешнего мира. Он не загружает конфигурацию в память при запуске. Это значит вы можете настроить производительность демона во время его работы изменив инструкции в файле конфигурации.

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

Настройка файла конфигурации

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

Вы можете создать файл xinetd.conf из существующего inetd.conf файл с xconv.pl программа, которая является частью пакета, который вы можете скачать из репозитория GitHub для xinetd. Запустите программу преобразования с помощью следующей команды:

/usr/local/sbin/xconv.pl < /etc/inetd.conf > /etc/xinetd.conf

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

Раздел настроек по умолчанию для файла конфигурации

Когда вы просматриваете только что созданный файл xinetd.conf, вам необходимо сосредоточиться на двух ключевых разделах конфигурации. Первым из них является по умолчанию раздел и второй является Сервисы раздел.

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

Некоторые ключевые параметры, которые вы можете установить в разделе по умолчанию:

• only_from
• нет доступа
• log_type
• log_on_success
• log_on_failure
• экземпляры
• per_source

Следующие разделы объясняют эти опции более подробно.

Условия доступа

only_from и нет доступа эффективно выполнять ту же задачу, которая заключается в блокировании (без доступа) или разрешении (только_от) определенного адреса или диапазонов адресов. Рекомендуется использовать один из этих параметров, чтобы заблокировать все по умолчанию, а затем создать список служб ниже в файле конфигурации. С помощью этой стратегии вы покрываете себя, если происходит событие, которое вы не учли.

Эти две опции также являются действительными командами для включения в раздел служб. Так что вы можете начните с запрета всего по умолчанию, а затем добавьте в сервисы. Если есть раздел службы, относящийся к типу запроса на подключение, который получает xinetd, он не будет рассматривать раздел настроек по умолчанию в конфигурации.

Инструкции only_from и no_access в описании службы переопределяют операторы only_from и no_access в разделе по умолчанию.

Формат для этих двух вариантов

знак равно

Помните, что адреса могут быть выражены в виде IP-адресов, имен хостов или доменных имен. Однако лучше придерживаться IP-адресов. Вы можете использовать нотацию CIDR для указания диапазона. Вот два примера того, как вы можете использовать эти параметры:

no_access = 0.0.0.0/0

Это, вероятно, самая распространенная строка в разделе по умолчанию, потому что она блокирует всех. Раздел по умолчанию есть только в файле конфигурации, чтобы сообщить xinetd, что делать в случае запроса на обслуживание, который не описан в разделе служб. Вам следует исходить из того, что вы сможете предоставить конкретные инструкции для каждого типа сервиса, который может предоставить ваш компьютер, поэтому разумно утверждать, что все остальные запросы заблокированы. Как сказал бы швейцар на эксклюзивной VIP-вечеринке: «Если вас нет в списке, вы не входите».

Альтернатива этой стратегии – впустить всех. Вы могли бы реализовать это с помощью:

only_from = 0.0.0.0/0

Эта политика не имеет смысла в разделе по умолчанию. На раздел по умолчанию ссылаются только в том случае, если вы не указали инструкции для службы, поэтому, когда xinetd прибегает к настройкам по умолчанию, возникает случай, в котором для него не предусмотрено никаких инструкций. Таким образом, разрешение доступа при таких обстоятельствах приведет к ошибке, потому что вы не сказали xinetd, что делать с запросом. Логично использовать эту опцию catch-all only_from в описании службы, поэтому в этом сообщении xinetd будет разрешено использовать запросы из всех возможных источников для использования этой службы..

К сожалению, в параметрах only_from и no_access есть функция, которая может создать конфликт, если вы реализуете политику, как описано выше. То есть, и no_access, и only_from являются глобальными и xinetd проверяет их каждый раз, когда у него есть задача. Поэтому, если вы оба установили, демон будет проверять входящий запрос на соответствие этому оператору no_access в разделе по умолчанию, даже если настроена правильная конфигурация службы.

Эту причуду no_access и only_from быть глобальным можно преодолеть, выбрав политику только когда-либо используя один или другой в вашем файле xinetd.conf. Обычная практика – придерживаться only_from и игнорировать опцию no_access. Вы можете создать только универсальную инструкцию, оставив список адресов пустым в разделе значений по умолчанию, т. Е. «only_from = ”И это позволит программе xinetd использовать настройку only_from в описаниях сервисов. Это произойдет без возникновения конфликта, поскольку значение параметра only_from в разделе по умолчанию перезаписывается параметром only_from службы.

Досадно, если вы не поместите оператор only_from или no_access в раздел настроек по умолчанию, xinetd разрешит все подключения что вы не охвачены в разделе услуг, что, вероятно, приведет к ошибке.

Формат для перечисления нескольких адресов в качестве параметров обеих этих опций – оставить пробел между каждым адресом (без запятых). Вы также можете включить диапазоны CIDR в список.

Команды файла журнала

log_type, log_on_success, и log_on_failure варианты все работают вместе. Каждый из них имеет ряд констант, которые необходимо указать в параметре в качестве параметров..

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

Например, вы могли бы написать адрес файла журнала с:

log_type = FILE / usr / log / internetlog

Другая опция, доступная с атрибутом log_type, – это SYSLOG, которая устанавливает уровень сообщений для этих событий, о которых будет сообщать syslogd. Возможные значения:

• демон
• авт
• пользователь
• local0-7

Примером может быть:

log_type = SYSLOG local1

SYLOG атрибут не является существенным, и это гораздо менее важно, чем ФАЙЛ вариант. Вам действительно нужно дать вашему xinetd имя файла журнала для записи; вам не нужно указывать уровень системного журнала для сообщений о событиях.

Доступные варианты отчетов для log_on_success:

• PID – 0, если это внутренний сервис xinetd
• ХОСТ – адрес клиента
• USERID – личность удаленного пользователя
• EXIT – выход из процесса
• DURATION – продолжительность сеанса

Варианты отчетов для log_on_failure:

• ХОСТ – адрес клиента
• USERID – личность удаленного пользователя
• ATTEMPT – регистрирует неудачную попытку доступа
• ЗАПИСЬ – вся доступная информация о клиенте

Вы можете включить несколько параметров в каждой строке log_on_success и log_on_failure, и они должны быть разделены пробелами без знаков препинания. Например:

log_type = FILE / usr / log / internetlog
log_on_success = HOST PID USERID DURATION EXIT
log_on_failure = HOST USERID ЗАПИСЬ ПОПЫТКИ

Обычной практикой является сохранение операторов log_type, log_in_success и log_on_failure в последовательных строках файла..

Контроль мощности

Еще две опции, которые вам нужно добавить в xinetd.conf, ограничивают количество одновременных соединений, которые должен принимать ваш сервер. Это важный фактор, и это простой, но мощный способ предотвратить атаки типа «отказ в обслуживании» (DoS). Два варианта, которые реализуют эту стратегию: экземпляры и per_source.

Параметр экземпляров в разделе значений по умолчанию указывает количество соединений, которые xinetd будет разрешать запускать одновременно, а параметр per_source указывает количество запросов на соединение, на которые демон будет отвечать с того же адреса источника.. Распределенные атаки типа «отказ в обслуживании» (DDoS) будет обходить ограничение per_source, но не параметр instance. К сожалению, реализация этого лимита сервиса заблокирует подлинных пользователей на время атаки.

Формат этих двух вариантов очень прост:

= число.

Значение per_source должно быть ниже значения экземпляров.

Пример раздела по умолчанию

Собрав все детали, описанные в этом разделе, ваш оператор по умолчанию xinetd.conf должен выглядеть так:

по умолчанию
{
случаи = 20
per_source = 5
log_type = FILE / usr / log / internetlog
log_on_success = HOST PID USERID DURATION EXIT
log_on_failure = HOST USERID ЗАПИСЬ ПОПЫТКИ
only_from =
}

Каждый файл xinetd.conf должен иметь оператор по умолчанию. Вам не нужно иметь никаких отчетов об услугах.

Разделы настройки сервиса

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

Типы услуг

Атрибуты, доступные для раздела услуг, различны для каждой из трех категорий услуг. Эти:

• ВНУТРЕННИЙ
• UNLISTED
• RPC

Категория обслуживания (INTERNAL / UNLISTED / RPC) может быть указана с помощью атрибута тип. Тем не менее, этот атрибут не является обязательным и часто не учитывается.

Определения атрибутов службы

При написании спецификации атрибута все поля разделяются пробелами или символами возврата каретки – вы не используете в определении разделитель или пунктуацию.

Макет оператора службы такой же, как и для раздела по умолчанию:

служба
{
  значение атрибута оператора
}

Оператор, используемый для операторов атрибута, обычно равен («знак равно«). Очень мало атрибутов позволяют добавлять значения в существующий список с помощью «+знак равно»Или исключен из списка с помощью«-знак равно«- в обоих случаях вы пишете оператор без кавычек, показанных здесь.

Вот атрибуты, которые доступны для ВНУТРЕННИЙ Тип Обслуживания:

• socket_type
• флаги
• красивый
• Подождите
• протокол (если не указан в / etc / services)
• порт (если не указан в / etc / services)
• герц
• access_times

Атрибуты, доступные для RPC услуги являются:

• socket_type
• флаги
• пользователь
• сервер
• server_args
• красивый
• Подождите
• протокол
• rpc_version
• rpc_number
• герц
• access_times

UNLISTED Типы услуг могут иметь любой из следующих атрибутов:

• socket_type
• флаги
• пользователь
• сервер
• server_args
• Максимальная нагрузка
• красивый
• Подождите
• протокол (если не указан в / etc / services)
• порт (если не указан в / etc / services)
• access_times
• герц

Атрибуты сервиса

Значения этих атрибутов приведены в таблице ниже:

AttributeDescription

тип	ВНУТРЕННИЙ, RPC, НЕДОСТУПЕН или
socket_type	stream (TCP), dgram (UDP), raw (прямой доступ по IP) или seqpacket ().
Я бы	создать уникальное имя для этого сервиса
флаги	объяснил ниже таблицу
пользователь	указывает приоритет сервера
сервер	Путь и программа сервиса
серверные аргументы	аргументы для передачи с вызовом службы
Максимальная нагрузка	количество одновременных процессов для службы
красивый	увеличивает приоритет для службы
Подождите	да | no – блокирует или разрешает параллельную обработку новых запросов
протокол	можно не указывать, если протокол указан в / etc / protocol
порт	номер порта также должен существовать в / etc / services и быть тем же номером
rpc_version	версия RPC
rpc_number	Номер RPC
герц	ограничение соединения, второй аргумент является необязательным и дает количество секунд ожидания при достижении лимита
access_times	часы дня, когда служба может быть запущена
привязывать	отвечать на подключения к определенному IP-адресу
редирект	перенаправляет запросы на услугу на другой компьютер

флаги Атрибут может иметь следующие значения:

IDONLY: принимать соединения только от клиентов, имеющих сервер идентификации

NORETRY: предотвращает создание нового процесса при сбое подключения

NAMEINARGS: первый аргумент в server_args это сервер значение. Используется при вызове tcpd

В дополнение к вышеуказанным атрибутам параметры, доступные в разделе значений по умолчанию, также могут быть записаны в определение службы. Эти:

• only_from
• нет доступа
• log_type
• log_on_success
• log_on_failure
• экземпляры
• per_source

Повторное использование этих атрибутов перезапишет любые значения, установленные для них в разделе по умолчанию. Однако помните, что only_from и нет доступа атрибуты являются глобальными, поэтому вы должны организовать использование этих параметров, чтобы избежать конфликтующих параметров.

Примеры декларации сервиса

Вот два примера определения сервиса.

сервис ntalk
{
socket_type = dgram
подожди = да
пользователь = никто
server = /usr/sbin/in.ntalkd
access_times = 7: 00-12: 30 13: 30-21: 00
only_from = 192.168.1.0/24
}

сервис ftp
{
socket_type = stream
ждать = нет
пользователь = root
server = /usr/sbin/in.ftpd
server_args = -l
случаи = 4
хороший = 10
}

Обратите внимание на использование access_times в Ntalk определение. При этом используются два диапазона времени с временами от и до, разделенных тире («-») без пробелов. Два временных диапазона разделены пробелом. В определениях времени используется 24-часовой формат часов.

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

Ntalk сервис имеет socket_type из dgram, Это означает, что это служба UDP. socket_type в FTP определение ручей, Это означает, что это служба TCP.

Создать несколько экземпляров службы

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

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

В этом случае вы должны определить «Service ftp» дважды. Затем вы бы дали один экземпляр атрибута id = ftp-internal и другие id = ftp-external. С тех пор xinetd может различать два. Чтобы сделать каждый экземпляр доступным для разных аудиторий, вы должны использовать only_from атрибут для ограничения доступа к службе ftp-internal только адресами в сети и доступом к службе ftp-external всем не сетевым адресам.

Привязать адрес к услуге

Сценарий создания разных сервисов для внутренних и внешних пользователей может сильно помочь с помощью атрибута bind. Срок “привязывать”Часто используется в программировании TCP. Обычно это означает связать соединение с портом, создавая таким образом идентификатор для сеанса. В этом случае, однако, «связать» означает что-то другое. На примере внутреннего и внешнего доступа к FTP-серверу, Вы можете привязать сетевой адрес компьютера к экземпляру ftp-internal и общедоступный IP-адрес этого компьютера к экземпляру ftp-external.

В этом примере можно было бы пропустить атрибут only_from в определении сервиса. Тем не менее, безопаснее оставить эти ограничения. Итак, полное определение вашего внутреннего и внешнего FTP-серверов будет следующим:

сервис ftp
{
id = ftp-external
server = /usr/sbin/in.ftpd
server_args = -l
случаи = 4
only_from = 0.0.0.0/0
bind = 202.19.244.130
}

сервис ftp
{
id = ftp-internal
socket_type = stream
server = /usr/sbin/in.ftpd
server_args = -l
only_from = 192.168.1.0/24
bind = 192.168.1.5
}

Эта стратегия требует, чтобы вашему FTP-серверу был присвоен статический IP-адрес для публичного доступа. Кроме того, вам необходимо настроить DHCP-сервер на резервирование того же адреса для вашего внутреннего FTP-сервера. Хотя приведенный выше сценарий работает, когда для внутреннего и внешнего доступа используется один компьютер, вы также можете выделить адреса отдельных компьютеров для каждого экземпляра FTP.

Отключить службы, специфичные для inetd

Есть три услуги xinetd которые дают информацию о системе.

• серверы: отчет об используемых серверах
• сервисы: отчет о доступных сервисах, их протоколах и портах
• xadmin: объединяет две вышеупомянутые команды

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

отключено = серверы службы xadmin

С изменениями в файле конфигурации, описанными выше, теперь вы можете начать использовать xinetd.

Запуск xinetd

Вы запускаете xinetd в командной строке. Команду также можно запустить из командного файла, чтобы вы могли добавить ее к процедурам запуска вашего компьютера. Программа может быть запущена со следующими параметрами:

SwitchOptionDescription

-d		Режим отладки
-системный журнал	syslog_facility	То же, что log_type SYSLOG в настройках по умолчанию для файла conf
-FileLog	лог-файл	Аналогично log_type FILE в файле настроек по умолчанию
-е	config_file	Указывает файл конфигурации – по умолчанию это /etc/xinetd.conf
-PidFile	PID_FILE	Записать идентификатор процесса в pid_file
-остаться в живых		Никогда не прекращайте
-предел	proc_limit	Максимальное количество процессов, которые могут быть запущены одновременно
-logprocs	предел	Максимальное количество серверов, которые могут работать одновременно
-версия		Распечатать версию xinetd
-inetd_compat		Прочитайте /etc/inetd.conf, а также файл конфигурации xinetd
-куб.см	интервал	Выполнять проверки согласованности каждые интервалы секунд

Также можно запустить xinetd без каких-либо опций.

Используйте xinetd

Если у вас есть компьютер с Linux, возможно, у вас уже установлен xinetd. Вы можете проверить, запустив xinetd-версия. Если на вашем компьютере работает inetd, скорее всего, вы не используете Linux. Замените программу на xinetd и преобразуйте файл конфигурации из совместимости с inetd в использование xinetd, как описано выше..

Вы используете xinetd в данный момент? Оставьте сообщение в Комментарии раздел ниже, чтобы поделиться своим опытом с сообществом.

Смотрите также: 15 лучших бесплатных серверов Syslog

Изображение: Сетевое интернет-соединение от Pixabay. Лицензировано под CC0 Creative Commons