• UNKNOWN. Данное ключевое слово задает все компьютеры, чьи доменные имена не могут быть получены средствами преобразования имен.
• KNOWN. Идентифицирует компьютеры, доменные имена и IP-адреса которых известны системе.
• PARANOID. Определяет компьютеры, имена которых не соответствуют IP- адресам.
При использовании последних трех ключевых слов надо соблюдать осторожность, поскольку, если они присутствуют в списке клиентов, компьютер обращается к серверу DNS. Неисправность сетевого оборудования может привести к ненадежной работе сервера DNS. Если сервер DNS недоступен, получить доменное имя компьютера не удастся. Пример файла /etc/hosts.allow, содержащего две строки, приведен ниже.
telnet,ftp : 192.168.34. dino.pangaea.edu
ssh : LOCAL .pangaea.edu
Первая строка задает правила установления соединений для серверов Telnet и FTP, разрешая доступ к ним только из сети 192.168.34.0/24 и с компьютера dino.pangaea.edu. Вторая строка сообщает о том, что доступ к серверу SSH разрешен только для машин локальной сети, а также для компьютеров, принадлежащих домену pangaea.edu. Поскольку другие серверы не указаны в списках демонов, TCP Wrappers не блокирует доступ к ним. Например, если вы запустите через inetd и TCP Wrappers Apache, обратиться к этому серверу сможет каждый желающий.
Используя в списке клиентов записи типа ident (в некоторых системах он называется auth), который возвращает имя пользователя, работающего с конкретным сетевым портом. Компьютер, использующий TCP Wrappers, передает запрос клиентской машине и получает имя пользователя. В этом случае соединение устанавливается с некоторой задержкой, а информация о пользователе, полученная из Internet, не всегда заслуживает доверия. Поэтому данную возможность лучше использовать в локальной сети, где вы имеете возможность контролировать конфигурацию всех компьютеров.
В составе правила может присутствовать дополнительное ключевое слово EXCEPT. Оно определяет исключения из этого правила. Рассмотрим следующую запись, содержащуюся в файле /etc/hosts.deny:
www : badcracker.org EXCEPT [email protected]
В данном случае доступ к Web-серверу запрещается для всех компьютеров, принадлежащих домену badcracker.org. Исключением являются лишь запросы, полученные от пользователя [email protected]. Аналогичный результат можно получить, включив правило для [email protected] в файл /etc/hosts.allow.
Если перед вами стоит задача максимально повысить безопасность системы, вы можете начать настройку с создания файла /etc/hosts.deny, содержащего следующую информацию:
ALL : ALL
Эта запись блокирует доступ ко всем серверам, поддерживаемым TCP Wrappers, с любого компьютера, независимо от его адреса. Затем можно постепенно разрешать доступ к серверам, составляя соответствующие правила и записывая их в файл /etc/hosts.allow. Возможности доступа должны ограничиваться необходимым минимумом. В частности, к серверам, чувствительным к попыткам взлома извне, например к Telnet, следует разрешить доступ только для определенных компьютеров. (Дело в том, что в процессе Telnet-взаимодействия данные, в том числе пароль, передаются в незашифрованном виде. Строго говоря, если компьютер содержит важные данные, на нем не следует вовсе устанавливать Telnet-сервер. Подробно эти вопросы будут обсуждаться в главе 13.)
Использование xinetd
Традиционно inetd был основным суперсервером, использовавшимся в системе Linux. Однако в 2000 г. наметилась тенденция перехода к альтернативному суперсерверу xinetd. Условно xinetd можно представить себе как сочетание inetd и TCP Wrappers. Но между этими программами существуют некоторые отличия. Не все возможности xinetd можно реализовать с помощью inetd и TCP Wrappers, но ряд действий, которые можно выполнить, используя inetd и TCP Wrappers, нельзя сделать посредством xinetd. При необходимости xinetd можно использовать совместно с TCP Wrappers, поэтому считается, что данный инструмент обеспечивает большую степень гибкости по сравнению с inetd. В начале 2002 г. xinetd был использован в Red Hat и Mandrake в качестве суперсервера по умолчанию; ожидается также переход других операционных систем на xinetd.
Формат файла /etc/xinetd.conf
Поскольку возможности нового суперсервера расширены по сравнению с inetd, формат конфигурационного файла также отличается от inetd. Настройка xinetd производится с помощью файла /etc/xinetd.conf. Следует заметить, что файл xinetd.conf, поставляемый в составе дистрибутивных пакетов Red Hat и Mandrake, содержит лишь минимальный набор установок. В нем задана конфигурация серверов, а также содержится строка, которая указывает суперсерверу прочитать все файлы в каталоге /etc/xinetd.d и интерпретировать их как дополнительные конфигурационные файлы. Конфигурация xinetd напоминает конфигурацию SysV; каждому серверу соответствует собственный управляющий файл, названный по имени сервера. Например, для сервера Telnet используется файл /etc/xinetd.d/telnet. При необходимости xinetd можно настроить так, что этот суперсервер будет использовать лишь основной файл xinetd.conf, но в дистрибутивных пакетах Red Hat и Mandrake некоторые файлы запуска уже содержатся в каталоге /etc/xinetd.d.
Независимо от того, содержится ли описание сервера в /etc/xinetd.conf или в файле, находящемся в каталоге /etc/xinetd.d, оно может занимать несколько строк. Базовое определение включает те же данные, что и запись в файле inetd.conf. Например, приведенное ниже описание почти эквивалентно рассмотренной ранее записи для Telnet-сервера, находящейся в файле inetd.conf.
service telnet
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/in.telnetd
}
В конфигурационном файле xinetd каждое поле именуется. Несмотря на то что в данном примере поля расположены в том же порядке, что и в рассмотренной ранее записи
