Управление сетевыми службами: описание демона xinetd

Довольно часто в постах я упоминал демоны inetd и xinetd, настало время про них поговорить. Не без участия последних были написаны следующие статьи:

Способы исследования сети или “ловля на живца”;

Безопасная настройка TFTP-сервера;

“Черви” под Linux: хроника;

В операционной системе Linux предусмотрена возможность поддержки многих интернет-служб, включая HTTP, SMTP, telnet и FTP. Управление и запуск большинства из них осу­ществляется с помощью демона inetd (Internet Daemon) или xinetd (Extended Internet Daemon). Демон inetd используется уже долгое время и добавлен в большинство версий UNIX для поддержки управления интернет-службами, но имеет ограниченные возможности. Бо­лее новая программа, демон xinetd, обладает широким набором различных возможностей. О нем и поговорим.

Уже по названию демона можно догадаться, что это расширенный или улучшенный вари­ант inetd. Он обладает несколькими полезными возможностями, недоступными для inetd.

Встроенный контроль доступа, подобный реализуемому с помощью TCP Wrappers, кото­рый осуществляется по IP-адресу, имени или домену удаленного хоста.

Предоставление доступа в определенные промежутки времени.

Полная регистрация всех соединений, включая успешные и неудачные попытки.

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

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

Конфигурация xinetd

Одним из недостатков xinetd является то, что синтаксис, используемый в файле конфи­гурации этого демона, полностью отличается от синтаксиса для inetd. Для каждой службы используется собственный файл в каталоге /etc/xinetd.d (или любом другом каталоге, ко­торый указан в директиве icludedir файла xinetd.conf). Например, файл /etc/xinetd.d/ftp может иметь следующий вид:

service ftp
{
flags	=  REUSE  NAMEINARGS
socket_type	=  stream
protocol	=  tcp
wait	= no
user	=  root
server	=  /usr/sbin/in.ftpd
server_args	= -l   -a
}

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

defaults
{
instances  = 25
log_type   = FILE /var/log/servicelog
log_on_success = HOST PID
log_on_failure = HOST RECORD
per_source = 5
}

Рассмотрим назначение полей в разделе defaults:

instances – значение, которое определяет максимальное количество запросов, одновременно обрабатываемых сервером;

log_type – запись зарегистрированных событий будет выполняться в файл (FILE Имя_файла) или а системный журнал (syslog);

log_on_suссеss / log_on_failure – можно выбирать, какая часть информации об успешных или неудачных со­единениях будет сохранена. Среди возможных значений: PID, HOST, USERID;

per_source – данное значение указывает максимальное количество соединений, разрешенных с одного IP-адреса для доступа к определенной службе.

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

Установка нежелательных соединений

Если на компьютере запущены какие-либо службы, и он подключен к сети, значит, рано или поздно хакер проверит защиту запущенных служб. Некоторые из служб требуют аутенти­фикации пользователей. Но существуют и уязвимые версии служб, успешная атака на которые возможна вообще без процедуры аутентификации.

В арсенале хакера есть и другие средства для получения действительных имен пользовате­лей и паролей, например, методы социальной инженерии. В этом случае при попытке установ­ки telnet-соединения с чужим компьютером, система защиты не сможет отличить легитим­ного пользователя от хакера и предотвратить подключение последнего.

Контроль доступа с помощью xinetd

Одним из наиболее важных улучшений в xinetd является отсутствие необходимости использования TCP Wrappers, так как контроль доступа уже встроен в сам демон xinetd. Для каж­дой службы контроль доступа может быть реализован следующими методами:

по параметрам, подобным возможностям, обеспечиваемым TCP Wrappers;

контроль доступа по IP-адресам компьютеров;

контроль доступа по именам компьютеров;

контроль доступа по имени домена;

по интервалам времени доступа (например, доступ к службе FTP может быть разрешен с 8.00 до 17.00).

При использовании xinetd для полного запрещения доступа необходимо использовать ат­рибут no_access в разделе defaults файла /etc/xinetd.conf:

no_access  =  0.0.0.0

Строка 0.0.0.0 означает все IP-адреса (подобно групповому символу ALL для TCP Wrappers).

Альтернативой является использование атрибута only_from без указания какого-либо значения этого атрибута:

only_from =

Атрибут only_from можно использовать в разделе defaults или в разделах service для каждой службы. Чтобы предоставить доступ ко всем службам нескольким отдельным компьюте­рам, достаточно добавить следующую строку в раздел defaults файла /etc/xinetd.conf:

only_from = 127.0.0.1  trusted.machine.example.com .example.org

Эта строка разрешит перечисленным хостам доступ ко всем службам. Настройки, заданные с помощью атрибута only_from, могут быть замещены настройками в конфигурационных файлах отдельных служб. Тем не менее, для более точной настройки доступен оператор «+=», с помощью которого можно предоставлять доступ к службам для отдельных компьютеров. На­пример, следующая запись в конфигурационном файле ipop3d позволяет предоставить доступ к POP-серверу другим компьютерам:

only_from  +=  my_work_machine.com  192.168.

Для более «тонкого» управления доступом можно совместно применять атрибуты no_access и only_from. При подключении удаленного компьютера используется правило, которое наиболее точно соответствует IP-адресу или имени этого компьютера. Например, если заданы правила:

no_access  =   192.168.10.29   .example.org
only_from  =  192.168.10.   my.machine.example.org

то запросы на соединение от хоста 192.168.10.29 будут отклоняться согласно атрибуту no_access, но те же запросы от my.machine.example.org будут разрешаться, согласно бо­лее конкретному атрибуту only_from.

2 комментария на «“Управление сетевыми службами: описание демона xinetd”»

1. Ника:

   5 Январь 2011 в 16:44

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

   Ответить
2. uhta:

   23 Январь 2011 в 15:14

   да статья мне тоже понравилась — на вела на несколько интересных идеек

   Ответить