Tcp wrappers что это

14.6. TCP Wrappers

рПУЛПМШЛХ ТБУУНБФТЙЧБЕФУС ТБУЫЙТЕОЙЕ Л ОБУФТПКЛБН inetd, РТЕДРПМБЗБЕФУС, ЮФП ЮЙФБФЕМШ ПЪОБЛПНЙМУС У ТБЪДЕМПН П ОБУФТПКЛЕ inetd.

14.6.1. оБЮБМШОБС ОБУФТПКЛБ

ч РТПУФЕКЫЕК ЛПОЖЙЗХТБГЙЙ, РПМЙФЙЛБ РПДЛМАЮЕОЙС УЧПДЙФУС Л ТБЪТЕЫЕОЙА ЙМЙ ВМПЛЙТПЧБОЙА Ч ЪБЧЙУЙНПУФЙ ПФ РБТБНЕФТПЧ Ч /etc/hosts.allow. оБУФТПКЛБ Ч FreeBSD РП ХНПМЮБОЙА ЪБЛМАЮБЕФУС Ч ТБЪТЕЫЕОЙЙ РПДЛМАЮЕОЙС Л МАВПНХ ДБЕНПОХ, ЪБРХЭЕООПНХ ЙЪ inetd. йЪНЕОЕОЙЕ ЬФПЗП РПЧЕДЕОЙС ВХДЕФ ПВУХЦДБФШУС ФПМШЛП РПУМЕ ТБУУНПФТЕОЙС ВБЪПЧПК ОБУФТПКЛЙ.

уХЭЕУФЧХАФ Й ДТХЗЙЕ РБТБНЕФТЩ, ОП ПОЙ ВХДХФ ПРЙУБОЩ Ч УМЕДХАЭЙИ ТБЪДЕМБИ. рТПУФБС ЛПОЖЙЗХТБГЙС НПЦЕФ ВЩФШ, ОБРТЙНЕТ, ФБЛПК: ДМС ТБЪТЕЫЕОЙС УПЕДЙОЕОЙК РП РТПФПЛПМХ POP 3 Л ДБЕНПОХ mail/qpopper, Ч hosts.allow ОЕПВИПДЙНП ДПВБЧЙФШ УМЕДХАЭЙЕ УФТПЛЙ:

14.6.2. тБУЫЙТЕООБС ЛПОЖЙЗХТБГЙС

14.6.2.1. чОЕЫОЙЕ ЛПНБОДЩ

ч ЬФПН РТЙНЕТЕ УППВЭЕОЙЕ, »You are not allowed to use daemon from hostname.» ВХДЕФ ЧПЪЧТБЭЕОП ПФ ЧУЕИ ДБЕНПОПЧ, ЛПФПТЩЕ ОЕ ВЩМЙ РТЕДЧБТЙФЕМШОП ОБУФТПЕОЩ Ч ЖБКМЕ ДПУФХРБ. пВТБФЙФЕ ЧОЙНБОЙЕ, ЮФП ЧПЪЧТБЭБЕНПЕ УППВЭЕОЙЕ ДПМЦОП ВЩФШ ЪБЛМАЮЕОП Ч ЛБЧЩЮЛЙ; ЙЪ ЬФПЗП РТБЧЙМБ ОЕФ ЙУЛМАЮЕОЙК.

чОЙНБОЙЕ: чПЪНПЦОБ ТЕБМЙЪБГЙС DoS БФБЛЙ, ЛПЗДБ ЗТХРРБ БФБЛХАЭЙИ РТПЙЪЧПДЙФ НОПЦЕУФЧП ЪБРТПУПЧ ОБ РПДЛМАЮЕОЙЕ.

рПНЙНП РТЙЧЕДЕООЩИ ЧЩЫЕ УЙНЧПМПЧ РПДУФБОПЧЛЙ, ОБРТЙНЕТ %a, УХЭЕУФЧХЕФ ЕЭЕ ОЕУЛПМШЛП УЙНЧПМПЧ. пВТБФЙФЕУШ Л УФТБОЙГЕ hosts_access (5) УРТБЧПЮОПК УЙУФЕНЩ ЪБ РПМОЩН УРЙУЛПН.

ч ЬФПН РТЙНЕТЕ ЧУЕ ЪБРТПУЩ ОБ РПДЛМАЮЕОЙС Л sendmail ПФ ИПУФПЧ, IP БДТЕУ ЛПФПТЩИ ОЕ УППФЧЕФУФЧХЕФ ЙНЕОЙ ИПУФБ, ВХДХФ ПФЛМПОЕОЩ.

вПМЕЕ РПДТПВОБС ЙОЖПТНБГЙС П ЫБВМПОБИ Й ЙИ ЧПЪНПЦОПУФСИ ДБОБ ОБ УФТБОЙГЕ hosts_access (5) УРТБЧПЮОПК УЙУФЕНЩ.

дМС ФПЗП, ЮФПВЩ МАВБС ЧЩВТБООБС ЛПОЖЙЗХТБГЙС ЪБТБВПФБМБ, Ч hosts.allow ОЕПВИПДЙНП ЪБЛПННЕОФЙТПЧБФШ РЕТЧХА УФТПЛХ ОБУФТПКЛЙ. ч ОБЮБМЕ ТБЪДЕМБ ПВ ЬФПН ОЕ ХРПНЙОБМПУШ.

Источник

Русские Блоги

TCP_Wrappers Контроль безопасности на основе TCP

Введение в TCP_Wrappers

Полное имя TCP_Wrappers: Оболочки протокола управления передачей (TCP)

Это система списков управления доступом к сети на основе хоста, используемая для фильтрации сетевого доступа к Unix-подобным системам (таким как Linux или BSD).

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

Основные возможности Tcp_Wrappers

 Протокол TCP, работающий на четвертом уровне (транспортный уровень)

 Выполнять проверки безопасности и реализовывать контроль доступа для определенных служб с подключениями с отслеживанием состояния

 Реализован в виде файлов библиотеки

 Принимает ли процесс управление libwrap, зависит от того, была ли программа, инициировавшая процесс, была скомпилирована для libwrap во время компиляции.

Определите, поддерживает ли программа tcp_wrapper

Если программа вызывает библиотеку libwrap.so, она ее поддерживает.

Использование TCP_Wrappers

TCP Wrappers реализует механизм, подобный брандмауэру, через два файла конфигурации /etc/hosts.allow и /etc/hosts.deny.

Файл конфигурации

Справочная информация: man 5 hosts_access, man 5 hosts_options

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

грамматика

пример

Сетевая IP-конфигурация двух используемых тестовых хостов выглядит следующим образом:

Файлы конфигурации по умолчанию hosts.allow и hosts.deny пусты, то есть все разрешены.

Запретить доступ к определенному IP:

Что делать, если client_list существует в 2 файлах одновременно

Как видите, доступ разрешен, в нем задействован механизм обработки выполнения.

Таким образом, приведенный выше результат разрешает доступ. Потому что он уже указан в hosts.allow.

Разрешить только IP-доступ к интрасети

Записывать каждый журнал входа ssh в файл

Приложения

Напишите сценарий /root/bin/checkip.sh и проверяйте его каждые 5. Если вы обнаружите, что количество неудачных попыток входа в систему через ssh превышает 10 раз, удаленный IP-адрес будет автоматически помещен в черный список Tcp_Wrapper, чтобы предотвратить его запрос.

Источник

Функция hosts_access использует два конфигурационных файла /etc/hosts.allow и /etc/hosts.deny (в FreeBSD только /etc/hosts.allow ), которые могут иметь классический или расширенный синтаксис.

Классический вариант

Классический синтаксис описан в man странице HOSTS_ACCESS(5). Файлы состоят из строк вида

Современный вариант

Синтаксис правил описан в man странице HOSTS_OPTIONS(5). Файлы состоят из строк вида

daemon_list, client_list полностью совместимы с классическим синтаксисом, а опции позволяют понизить привилегии, запустить дополнительную программу параллельно с сервисом или вместо него, и, наконец, принять решение allow или deny. Опции выполняются слева направо. Опция allow / deny должна стоять последней, поскольку после неё произойдёт запуск сервиса или прекращение работы.

Для запуска дополнительных программ используются две опции: spawn shell_command – запуск программы в параллельном процессе одновременно с сетевым сервисом, и twist shell_command – запуск программы в текущем процессе вместо сервиса. Командам в качестве параметров можно передать некоторую информацию о соединении. spawn не влияет на запуск основного сервиса, поэтому за ней должна следовать опция allow или deny. twist затирает текущий процесс и, соответственно, дальнейшие проверки опций. Однако, через параметры в twist можно передать имя исполняемого файла сервиса, чтобы выполнить его после дополнительных проверок.

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

Формат списка client_list

Список состоит из полей, разделённых пробелами и/или запятыми. Список может состоять из основной части и исключений, следующих за ключевым словом EXCEPT. Возможна группировка списков и исключений с помощью круглых скобок. В списке могут присутствовать IP адреса, имена хостов, ключевые слова и шаблоны.

Ключевые слова (часть опущена):

Источник

Использование TCP Wrappers

Использование TCP Wrappers

Как было сказано ранее, инструмент TCP Wrappers играет роль посредника между inetd и целевым сервером. Средства TCP Wrappers применяются для повышения безопасности системы; они позволяют задавать правила установления соединений, защищая тем самым сервер от нежелательного взаимодействия. Предположим, что вы хотите, чтобы доступ к серверу Telnet имели только пользователи, работающие в вашей локальной сети. Программу, обеспечивающую работу сервера Telnet, можно настроить так, чтобы она отвергала попытки обращения с узлов, для обслуживания которых сервер не предназначен. Однако не все серверы предоставляют такие возможности. Передача TCP Wrappers полномочий по управлению соединением повышает гибкость системы, не требуя при этом внесения изменений в программы.

TCP Wrappers можно сравнить с локальным брандмауэром, работа которого будет рассматриваться в главе 25. При этом TCP Wrappers реализует дополнительную защиту, которая может оказаться полезной, если брандмауэр настроен неправильно, кроме того, этот инструмент предоставляет новые возможности, например, фильтрацию на основе имени группы NIS.

Подобно другим конфигурационным файлам, символ # в начале строки означает, что в данной строке содержатся комментарии. Запись в файле hosts.allow или hosts.deny имеет следующий формат:

В списке демонов указывается один или несколько серверов, к которым применяется данное правило. Если в списке указано несколько серверов, их имена разделяются запятыми или пробелами. Имена серверов должны совпадать с именами, содержащимися в файле /etc/services. Кроме имен серверов в этом поле можно также указывать ключевое слово ALL, определяющее групповую операцию. Оно означает, что правило применяется ко всем серверам, управляемым TCP Wrappers.

Не забывайте, что не все серверы запускаются с помощью TCP Wrappers. Поэтому групповая операция ALL может не включать все серверы, выполняющиеся в системе. Аналогично, указав сервер в списке демонов, вы не защитите его, если для управления им не применяются inetd и TCP Wrappers, либо если он не использует TCP Wrappers непосредственно.

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

• IP-адрес. В списке клиентов можно указать конкретный IP-адрес, например 10.102.201.23. Такое описание определяет только этот адрес.

• Диапазон IP-адресов. Задать диапазон IP-адресов можно несколькими способами. Проще всего сделать это, указав в составе адреса меньше четырех десятичных чисел; в этом случае адрес должен заканчиваться точкой. Например, значение 10.102.201. соответствует сети 10.102.201.0/24. Кроме того, можно использовать запись типа IP-адрес/маска. В файлах hosts.allow и hosts.deny также поддерживаются адреса IPv6. Они задаются в виде [n:n:n:n:n:n:n:n]/длина, где n — значения компонентов адреса, а длина — это число битов, используемых для представления диапазона.

• Имя узла. Узел можно описывать с помощью его доменного имени, например badcracker.threeroomco.com. Этим способом определяется только один узел. В этом случае при получении запроса система выполняет преобразование имен, а, следовательно, если сервер DNS работает некорректно, при идентификации компьютера могут быть допущены ошибки.

• Имя группы NIS. Если последовательность символов начинается со знака @, оно интерпретируется как имя группы NIS (Network Information Services — сетевая информационная служба). Этот метод предполагает, что в сети функционирует сервер NIS.

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

• ALL. Идентифицирует все компьютеры.

• LOCAL. Определяет все локальные компьютеры на основании анализа имени узла. Если в имени отсутствует точка, соответствующий узел считается локальным.

• UNKNOWN. Данное ключевое слово задает все компьютеры, чьи доменные имена не могут быть получены средствами преобразования имен.

• KNOWN. Идентифицирует компьютеры, доменные имена и IP-адреса которых известны системе.

• PARANOID. Определяет компьютеры, имена которых не соответствуют IP-адресам.

При использовании последних трех ключевых слов надо соблюдать осторожность, поскольку, если они присутствуют в списке клиентов, компьютер обращается к серверу DNS. Неисправность сетевого оборудования может привести к ненадежной работе сервера DNS. Если сервер DNS недоступен, получить доменное имя компьютера не удастся. Пример файла /etc/hosts.allow, содержащего две строки, приведен ниже.

telnet,ftp : 192.168.34. dino.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 goodguy@exception.badcracker.org

В данном случае доступ к Web-серверу запрещается для всех компьютеров, принадлежащих домену badcracker.org. Исключением являются лишь запросы, полученные от пользователя goodguy@badcracker.org. Аналогичный результат можно получить, включив правило для goodguy@exception.badcracker.org в файл /etc/hosts.allow.

Если перед вами стоит задача максимально повысить безопасность системы, вы можете начать настройку с создания файла /etc/hosts.deny, содержащего следующую информацию:

Эта запись блокирует доступ ко всем серверам, поддерживаемым TCP Wrappers, с любого компьютера, независимо от его адреса. Затем можно постепенно разрешать доступ к серверам, составляя соответствующие правила и записывая их в файл /etc/hosts.allow. Возможности доступа должны ограничиваться необходимым минимумом. В частности, к серверам, чувствительным к попыткам взлома извне, например к Telnet, следует разрешить доступ только для определенных компьютеров. (Дело в том, что в процессе Telnet-взаимодействия данные, в том числе пароль, передаются в незашифрованном виде. Строго говоря, если компьютер содержит важные данные, на нем не следует вовсе устанавливать Telnet-сервер. Подробно эти вопросы будут обсуждаться в главе 13.)

Читайте также

Использование

Использование Во-первых, мы сперва должны подключить библиотеку cssexpr.js (о ней речь чуть ниже) и только потом вызывать нашу функцию constExpression. После этого можно использовать constExpression в любом задаваемом блоке стилей ( ), или любом

14.7.1. Использование ftw()

14.7.1. Использование ftw() #include int ftw(const char *dir, ftwFunctionPointer callback, int depth);Функция ftw() начинает с каталога dir и вызывает указанную в callback функцию для каждого файла в этом каталоге и его подкаталогах. Функция вызывается для всех типов файлов, включая символические ссылки и

Использование tar

Использование tar Утилита tar — одна из самых популярных программ, используемых для резервного копирования в системах Linux и UNIX. Она объединяет несколько файлов в один файл архива, что упрощает передачу информации по сети и сохранение ее на резервном носителе. Название

Использование ip

Использование ip Программа ip предназначена для управления таблицами маршрутизации, в частности, правилами, определенными в них. Выполнение данной программы зависит от значений некоторых подопций опции IP: Advanced Router. Программа ip вызывается следующим образом:ip команда [list |

Использование tc

Использование tc Утилита tc использует средства ядра, которые активизируются посредством опций меню QoS and/or Fair Queueing. Данная программа управляет исходящим трафиком, в частности, не позволяет одному типу трафика монополизировать пропускную способность линии связи. В

Использование VPN

Использование VPN VPN позволяет расширить локальную сеть за счет взаимодействия с внешними компьютерами. Очевидно, что если локальная сеть подключена к Internet, внешние пользователи могут обращаться к ней без VPN. Однако VPN имеет ряд преимуществ перед обычными типами сетевого

Использование

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

Использование

Использование

Использование По сути дела, Xalan Java и Xalan C++ — это библиотеки, позволяющие использовать XSLT-преобразования в собственных проектах. Xalan Java поддерживает набор интерфейсов TrAX (от англ. transformation API for XML — программный интерфейс преобразований для XML), определяющий стандартные

Использование

Использование

Использование Главной областью применения Oracle XSLT Processor является его использование совместно с технологиями XSQL и XSU для обеспечения Web-доступа к реляционным данным. Кроме этого, Oracle XSLT Processor легко интегрируется в другие приложения и также может выполняться из командной

Использование

Использование Как и любой другой XSLT-процессор, написанный на Java, xt можно без труда использовать в Java-проектах. Помимо этого, xt можно использовать в качестве сервлета и из командной строки.Сервлет-версия xt реализована в классе com.jclark.xsl.sax.XSLservlet и может выполняться на

Использование

Использование Прежде всего, как C-библиотеку, libxslt можно подключать к собственным модулям посредством документированного API, а также при помощи разработанных врапперов использовать в Perl и Python-программах. Поскольку по степени совместимости и разработанности libxslt явно

29.4.3. Использование SSI

29.4.3. Использование SSI Использование сценариев cgi, открывающих Web–страницы с целью отображения небольшого количества сведений, не всегда является оправданным. Например, была отображена дата, но также был создан сценарий cgi, который тоже отображает дату. Не лучше ли было бы

Источник

Archived | Using TCP Wrappers to control access

Easily protect and secure your machines

By David Tansley
Published July 12, 2011

Archive date: 2019-08-14

This content is no longer being updated or maintained. The content is provided “as is.” Given the rapid evolution of technology, some content, steps, or illustrations may have changed.

Introduction

TCP wrappers, often called just wrappers, is written by Wieste Venema and has been around for quite a few years. The idea behind it is simple, but the effect is that popular TCP inbound clients can be locked down on your AIX (UNIX® /Linux® ) box quickly and easily.

Wrappers allow system administrators to control access of TCP-based services or daemons that are wrappers aware. Tcpd controls TCP daemons that are run from /etc/inetd.conf. However, many TCP-based applications have been compiled with wrappers support (usually using the libwrap library) and are wrapper aware; it does not matter that they are not controlled from /etc/inetd.conf. Some common candidates that are used under wrappers for access control are telnet, ssh, sendmail, ftp packages, pop3, and stunnel.

Wrappers do offer limited support for UDP-based connections, but I suggest using your built-in or third party firewall for UDP based access

To see if your application has wrapper support, use the strings command and grep for hosts_access or host:

Or, you can use the ldd command:

The wrappers daemon is called tcpd. It is called instead of the real daemon in the /etc/inetd.conf file. Tcpd reads two files, hosts.allow and hosts.deny, based on the rules in these files. When the first rule match is found, the calling client is either denied or allowed access. All actions are logged to the messages file or to a specified log file that can be determined via syslog. Traditionally, hosts.allow contains the allowed access rules and hosts.deny contains the denied rules.

Looking at a typical telnet client scenario, this is how it works. The client tries to connect via a telnet session to a host that has wrappers configured. The client unknown to them connects to the wrapper daemon instead of the real telnetd daemon. This client is either allowed or denied access based on the rules contained in the hosts.allow or hosts.deny file. If denied, the telnet connection is terminated. If the client is allowed access based on the allowed rules, then tcpd hands over control to the real daemon that was called (in this case, telnetd). In either case, a grant or denied connection is logged via syslog.

In this article, I will demonstrate how to configure wrappers from source and discuss and review rules on blocking or allowing different remote service connections.

Building wrappers

Wrappers can be downloaded for either IPv4 or IPv6 support. The version to download is 7.6. In my experience of administering over 50 AIX boxes, the IPv6 version runs quite happily on a IPv4 only connection, so use this version. To build wrappers, you need a C compiler; I am using gcc from the AIX toolbox. Details of all downloads can be found in the Related topics section.

Once downloaded, unzip and untar the wrappers. The files are extracted into the tcp_wrappers_7_6-ipv6.4 directory:

The next task is to customise wrappers to allow rule checking, lookups and lookup verification (if required), logging, spawning programs and the use of banners.

In the makefile, the following entries are enabled by uncommenting the lines, as shown below:

The real_daemon informs wrappers where the real daemons live like ftpd, telnetd, and sshd.

Always attempt a hostname lookup:

Enable host control access is the whole point of wrappers, so make sure it is uncommented.

Enable language extensions, for banner messages, and using shell commands with spawn and twist.

Make sure wrappers knows about the syslog mechanism:

If you prefer, you can send messages from wrappers to a specific log file instead using LOCAL:

If you are running IPv4 on your hosts, still uncomment the following or the client’s IP address may not be resolvable under wrappers. Typically it could log an IP as 0.0.0.0. instead of the real IP.

The logging level via syslog:

Wrappers do a forward and reverse lookup thus checking the IP against the host-name. Action is taken if this condition is not met, as denoted in the access rules. This can cause issues with connecting clients if the DNS is not correctly set-up. If this could be an issue with your security policy, then do not uncomment this line.

In the actual AIX build segment, we have:

Save and exit the changes; then build it.

Once completed, the following binaries are compiled:

The next task is to copy those binaries and library into your local bin and sbin directory. In this demonstration, I will copy the files into the following directories:

And finally the libwrap:

Be sure to check that the permissions are executable for the tcpd binaries.

Configuring wrappers

The next task is to invoke tcpd instead of the real daemon or service from /etc/inetd.conf. First, create a backup of /etc/inetd.conf. In this demonstration, I am only going to replace daemons I wish to control access. I am going to replace ftpd and telnetd with tcpd as the calling daemon from /etc/inetd.conf. Feel free to protect other daemons in this file. The /etc/inetd.conf lines we are interested in are:

We simply replace the daemons that we wish to protect, in this case ftpd and telnetd with tcpd. So, after editing we would have the following configuration change:

Next, refresh inetd for the changes to take effect.

As discussed earlier, for other wrapper aware built third party applications, the hosts.allow and hosts.deny files are consulted. It is that application’s responsibility to honor the rules in the files, thus deny or allow access to its own clients. Let’s now configure the hosts files.

Logging of wrappers log by default to /var/adm/messages, using the facility level of authority:

If you have specified the LOCAL facility in the makefile, then you must tell syslog what file to use in syslog.conf. In the following example, all messages using LOCAL from wrappers is logged to the /var/adm/wrappers.log file.

Be sure to create the file wrappers.log before restarting syslog:

The rules

To turn wrappers off, simply mv the hosts.allow and hosts.deny file to different file-names. If there are no allow or deny files present, wrappers will not use access control, effectively turning wrappers off. Alternately emptying or zeroing your hosts files will have the same effect.

Wrappers first check the hosts.allow file for a rule match. If a match is found, then tcpd stops, depending on the rule, and access is either granted or denied. If no match is found in the hosts.allow file, then tcpd reads the hosts.deny file until a match is found. If a match is found, access is denied, otherwise access is granted.

I have mentioned both the hosts.allow and deny, but due to the flexibility of the rules, you can use just one file, generally hosts.allow, for all of the wrappers rules.

Wrappers will consult the rules in hosts.allow and hosts.deny to determine access. The basic format of the rules are:

Option can either be:

Where there are multiple daemons or clients on a line, separate each one with a comma. The ALL keyword can be used to mean ALL daemons or ALL clients.

The LOCAL keyword means to match any host that does not have a dot (“.”) in it; this means any local host not associated with a domain.

It is good practice and a good habit to append the allow or deny option at the end of each rule where the rule syntax allows (as this provides a clear picture on your access rules, especially when you have multiple allow and deny rules in your hosts.allow file).

There are a few other options as well that I will demonstrate later. For now, let’s put some access controls together.

Changes to the hosts.allow and hosts.deny are dynamic. The changes take effect once the file is saved.

A good starting point is to allow only the clients you want access to the host using the allowed daemons and then deny everything to everybody else.

So, the hosts.deny could deny all daemons to all clients using the following:

The examples in the rest of this section are related to the hosts.allow file only. To allow all daemons access only from local hosts (that is, hosts not associated with a domain name) I could use:

On a personal note, I prefer not to use the LOCAL pattern matching on any hosts, as all the hosts in the network should belong to your or some domain. If they are not, then they should be. However, there are occasions with small networks where this may not be the case, and LOCAL allows these hosts access.

Let’s now assume that we only wish to allow the hosts that belong to the domain mydomain.com using either telnet or ssh. The following hosts.allow entry accomplishes this:

Notice in this example the dot (“.”) before mydomain.com. This is a wild card and means all hosts ending with mydomain.com. We also specify at the end of the rule that this is an allow rule. Though not strictly required, as mentioned previously, it is good practice to do so.

Now, further assume that we wish to allow access for ssh and telnet using the following IP addresses: 192.168.4.10 and all IP address that start with 192.168.6. Again, notice the use of the dot after the partial IP address; this equates to 192.168.6.*., or more precisely, all IP addresses that start with 192.168.6. Another way of looking at the IP range 192.168.6. is that it equates to 192.168.6/24 or all IP addresses between 192.168.6.1 thru to 192.168.6.254

Additionally, we also want to allow the following domains access using telnet and ssh. Those domains are mydomain.com and mydomain2.com. The following accomplishes this:

Now, assume we wish to allow ftp access from all hosts in the domain mydomain.com, except the following two hosts in mydomain.com: uktrip1 and uktrip2. Using the except option, we can provide two lists where the hosts on the left hand side of the word “except” are granted access, but the hosts contained in the right hand list after the word “except” are denied, by using the allow rule.

Let’s now look at a deny rule. To refuse telnet to the following IP’s, 192.168.8. and 192.168.9., but allow telnet access from 192.168.6., I could use:

The previous example could also be written using the except option:

Wrappers log the messages to the /var/adm/messages file. A typical refused connection with telnet from a client called tardis in the messages file could be:

A typical ssh failed connection from a client called tardis could be:

If you decided to have PARANOID on, wrappers informs you of any IP to host discrepancies it cannot resolve:

Источник