Демон inetd: управление демонами
Категория: Процессы-демоны | Автор: admin | 2-07-2010, 09:54 | Просмотров: 5446

Демон inetd управляет другими демонами. Он запускает демоны-клиенты, когда для них есть работа, а после выполнения задачи позволяет им тихо завершиться.

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

Работа некоторых демонов (например, тех, что связаны с NIS и NFS) основана на протоколе RPC, который был разработан и реализован компанией Sun в качестве механизма совместного использования информации в распределенной сетевой среде. Назначениями портов для RPC-демонов управляет демон portmap (иногда называется rpcbind).

Многие демоны могут использоваться либо традиционным способом (т.е. они запускаются однократно и работают до выключения системы), либо под контролем демона inetd.

 

Конфигурирование демона inetd

 

Для того чтобы определить, какие сетевые порты нужно контролировать, демон inetd читает файл конфигурации (обычно /etc/inetd.conf, а иногда /usr/etc/inetd.conf или /etc/servers). Его формат одинаков для всех платформ.

Приведем пример:

 

ftp        stream tcp      nowait root   /usr/sbin/ftpd ftpd

telnet     stream tcp      nowait root   /usr/sbin/telnetd telnetd

shell      stream tcp      nowait root   /usr/sbin/rshd rshd

finger     stream tcp      nowait guest  /usr/sbin/fingerd fingerd

bootp      dgram  udp      wait   root   /usr/sbin/bootpd bootp -f

pop-2      stream tcp      nowait root   /usr/sbin/рорреr popper

pop-3      stream tcp      nowait root   /usr/sbin/рорреr popper

mountd/1   stream rpc/tcp  wait   root   /usr/sbin/mountd mountd

mountd/1   dgram  rpc/udp  wait   root   /usr/sbin/mountd mountd

 

 

Первая колонка содержит имя сервиса. Эти имена преобразуются в номера портов на основе данных, содержащихся в файле /etc/services (для UDP- и TCP-сервисов) или демоном portmap (для RPC-сервисов). RPC-cepвисы можно отличить по формату имени имя/номер и обозначению rpc в третьей колонке. В приведенном выше примере RPC-сервисы указаны в двух последних строках.

Во второй колонке определяется тип сокета, которым будет пользоваться сервис: stream или dgram. Сокеты типа stream используются с ТСР-сер-висами (ориентированными на установление соединения), а сокеты типа dgram — с UDP-сервисами.

В третьей колонке указывается протокол обмена, которым пользуется данный сервис. Допустимые типы перечислены в файле protocols (обычно он находится в том же каталоге, что и файл конфигурации демона inetd). Почти всегда в этой колонке указывается тип tcp или udp. RPC-сервисы предваряют тип протокола обозначением rpc/ (см. в примере rpc/tcp и rpc/udp).

Если описываемый сервис может обрабатывать одновременно несколько запросов (а не завершает выполнение после обработки одного запроса), в четвертой колонке нужно ставить ключевое слово wait, которое не даст демону inetd постоянно порождать новые экземпляры демона этого сервиса. Данное средство применяется для сервисов, которые обрабатывают множество мелких запросов. Если опция wait не подходит, то в этом поле нужно поставить ключевое слово nowait.

В пятой колонке указан пользователь, от имени которого должен выполняться данный демон. Если вы не доверяете той или иной программе либо знаете, что она порождает проблемы, связанные с безопасностью системы, можете выполнить ее от имени непривилегированного пользователя. Естественно, это годится только для демонов, которые не требуют привилегий пользователя root. В нашем примере демон ingerd выполняется с правами пользователя guest.

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

 

Файл services

 

После добавления нового сервиса в файл inetd.conf, возможно, понадобится ввести его и в файл services. Этот файл обычно находится в том же каталоге, что и файл inetd.conf, и используется несколькими стандартными библиотечными функциями, которые преобразуют имена сервисов в номера портов. Например, если ввести команду

% telnet anchor smtp

 

то в файле services будет произведен поиск номера порта, соответствующего SMTP-сервису. В большинстве систем все самые распространенные сервисы на момент поставки уже сконфигурированы. Если потребуется добавить еще несколько сервисов, нужно будет просто отредактировать файл services.

Файл services используется только для сервисов TCP/IP. Аналогичная информация для RPC-сервисов хранится в отдельном файле конфигурации (обычно это /etc/rpc).

Ниже приведено несколько строк из файла services (размер которого около 70 строк):

 

tcp       1/tcp                 # TCP port multiplexer

echo      7/tcp

echo      7/udp

...

smtp     25/tcp   mail

time     37/tcp   timserver

time     37/udp   timserver

rip      39/udp   resource      # resource location

name     42/tcp                 # IEN 116

whois    43/tcp   nicname

 

 

Формат строки таков:

имя       порт/тип     псевдонимы       # комментарий

 

Сервисы в файле обычно упорядочены по номерам, но это не обязательно. В поле имя указывается имя сервиса (которое используется в файле inetd.conf). В поле порт значится номер порта, контролируемого сервисом. Если сервис работает под управлением демона inetd, то это тот порт, который контролируется демоном inetd.

Поле тип обозначает протокол, которым пользуется данный сервис (на практике это всегда tcp или udp). Если программа может работать и по протоколу TCP, и по протоколу UDP, необходимо включить строку для каждого из этих протоколов (как в записи для сервиса time; см. пример). Поле псевдонимы содержит дополнительные имена сервиса (например, сервис whois можно искать по имени nicname).

 

Перезапуск демона inetd

 

Изменения, внесенные в файл конфигурации, вступят в силу лишь после того, как демону inetd будет дано указание перечитать файл. Это делается путем передачи этому демону сигнала отбоя. Послав сигнал, подождите минуту и проверьте, нет ли в журнальных файлах сообщений об ошибках, связанных с внесенными изменениями (демон inetd регистрирует ошибки в системе Syslog). Можно попробовать связаться с новыми сервисами и проверить, как они работают.

 

Защита демона inetd

 

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

Но даже после этого рекомендуется дополнить демон inetd пакетом TCP-оболочек, написанным Витсом Венема. Этот пакет регистрирует все попытки установления соединений и ограничивает доступ к демонам в зависимости от того, кто именно к ним обращается.

В HP-UX демон inetd имеет встроенные средства, напоминающие TCP-оболочки. Демон проверяет файл /var/adm/inetd.sec и определяет, кому разрешено подключаться к данному конкретному сервису. Если демон запускается с флагом -l, он также регистрирует все запросы на установление соединений.

 

Демон portmap/rpcbind: преобразование номеров RPC-сервисов в номера портов TCP и UDP

 

Демон portmap (в настоящее время называется rpcbind во многих системах — спасибо компании Sun!) преобразует номера RPC-сервисов в номера портов TCP/IP, которые контролируются их серверами. Когда запускается PRC-сервер, он регистрирует себя с помощью демона portmap/rpcbind, указывая поддерживаемые сервисы, а также используемый порт. Клиенты запрашивают демон portmap/rpcbind и выясняют, как связаться с соответствующим сервером.

Такая схема позволяет устанавливать соответствие между номером порта и символьным именем сервиса. Это уже принципиально иной уровень абстракции, более высокий, чем используемый в файле services, но вместе с ним появляются дополнительные сложности (и проблемы безопасности), тогда как реальных проблем он не решает. Многие RPC-сервисы фактически запускаются демоном inetd. Таким образом, создается не один, а два уровня косвенного вызова программ.

Если демон portmap/rpcbind зависает, все связанные с ним службы (включая inetd и NFS) должны перезапускаться. На практике это означает перезагрузку системы. Для того чтобы демон inetd обрабатывал RPC-запросы правильно, демон portmap должен быть запущен раньше, чем inetd.

  


 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page