Алексей Стахнов - Linux

Другой способ состоит в использовании второго брандмауэра, называемого заглушкой (choke). Компьютер, на котором реализован брандмауэр-заглушка, выполняет роль шлюза между демилитаризованной зоной и локальной сетью. Внутренний сетевой интерфейс бравдмауэра-заглушки подключен к локальной сети, а внешний -k демилитаризованной зоне. Данные, передаваемые компьютерами локальной сети, маскируются. Таким образом, с точки зрения брандмауэра-бастиона и машин, принадлежащих демилитаризованной зоне, вся внутренняя сеть представлена одним брандмауэром-заглушкой.

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

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

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

Отладка брандмауэра

Брандмауэр установлен, настроен и активизирован, но функционирует не так, как хотелось. Даже если брандмауэр работает, рекомендуется сразу после установки и настройки произвести проверку правильности функционирования брандмауэра.

Общие рекомендации по отладке брандмауэра

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

• Перед запуском сценария убедитесь, что в первой строке находится команда удаления существующих правил, а следующая команда устанавливает политику по умолчанию.

• Не рекомендуется производить изменения в правилах брандмауэра в X Window, поскольку неправильно заданное правило может «подвесить» X Window.

• Производите отладку с текстовой консоли. Не производите отладку брандмауэра с удаленной машины. В случае обрыва связи или неправильного конфигурирования вы рискуете остаться без доступа в Интернет.

• По возможности производите добавление правил по одному. В этом случае гораздо проще выявить причину неисправности. Сразу после добавления правил рекомендуется проверить их работоспособность.

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

• Помните, что существуют как минимум две не зависящие друг от друга цепочки: input и output. Если правила, содержащиеся в одной цепочке, обрабатывают пакет корректно, причина неисправности, очевидно, находится в другой цепочке.

• Если сценарий «зависает», возможно, что правило, в котором содержится доменное имя узла, вступает в действие раньше, чем правило, разрешающее доступ к DNS. Если какое-либо правило предшествует правилам, определяющим взаимодействие с DNS, в нем должны быть указаны IP-адреса. Использование доменных имен в таких правилах недопустимо, поскольку у вас еще нет доступа к серверу DNS.

• Проверяйте синтаксис команд программы ipchains. При составлении правил легко перепутать адрес или порт источника с адресом или портом назначения либо неверно задать регистр опции.

• При наличии синтаксической ошибки выполнение сценария брандмауэра завершается, и последующие правила не устанавливаются. Чтобы определить неверно составленное правило, запускайте сценарий с опциями -х или – v. Если указана опция – v, строки сценария выводятся в тот момент, когда они читаются интерпретатором команд. Опция -х задает вывод строк по мере выполнения команд оболочкой.

• Если какой-либо из серверов не работает, включите протоколирование удаляемых пакетов, указав опцию -l программы ipchains. Проанализируйте записи в файле /var/log/messages.