Фильтрующие мосты

Всё чаще, благодаря снижению стоимости широкополосных подключений к Интернету (xDSL), а также из-за сокращения доступных IPv4-адресов, многие компании подключены к Интернету 24 часа в сутки и имеют мало (иногда даже не степень двойки) IP-адресов. В таких ситуациях часто возникает желание иметь межсетевой экран, который фильтрует входящий и исходящий трафик из Интернета и в него, но решение для фильтрации пакетов на основе маршрутизатора может быть неприменимо — из-за проблем с подсетями, потому что маршрутизатор принадлежит поставщику услуг (ISP) или потому что он не поддерживает такие функции. В таких сценариях настоятельно рекомендуется использовать фильтрующий мост.

Межсетевой экран на основе моста может быть настроен и установлен между xDSL-маршрутизатором и вашим Ethernet-концентратором/коммутатором без каких-либо проблем с IP-адресацией.

Добавление функциональности моста в систему FreeBSD не является сложной задачей. Начиная с версии 4.5, появилась возможность загружать такие функции как модули, вместо необходимости пересборки ядра, что значительно упрощает процедуру. В следующих подразделах я объясню оба способа установки.

Прежде чем продолжить, убедитесь, что у вас есть как минимум две Ethernet-карты, поддерживающие режим promiscuous как для приёма, так и для передачи, поскольку они должны уметь отправлять Ethernet-пакеты с любым адресом, а не только с собственным. Кроме того, для обеспечения хорошей пропускной способности карты должны поддерживать управление шиной PCI. Наилучшим выбором по-прежнему остаются Intel EtherExpress™ Pro, за которыми следуют карты серии 3Com® 3c9xx. Для упрощения настройки межсетевого экрана может быть полезно иметь две карты от разных производителей (использующие разные драйверы), чтобы чётко различать, какой интерфейс подключён к маршрутизатору, а какой — к внутренней сети.

Прежде чем перезагрузиться для загрузки нового ядра или необходимых модулей (в соответствии с выбранным ранее методом установки), необходимо внести некоторые изменения в конфигурационный файл /etc/rc.conf. Правило по умолчанию для межсетевого экрана — отклонять все IP-пакеты. Изначально мы настроим открытый межсетевой экран, чтобы проверить его работу без каких-либо проблем, связанных с фильтрацией пакетов (если вы выполняете эту процедуру удалённо, такая конфигурация позволит избежать изоляции от сети). Добавьте следующие строки в /etc/rc.conf:

Первая строка включит межсетевой экран (и загрузит модуль ipfw.ko, если он не встроен в ядро), вторая настроит его в режиме open (как описано в /etc/rc.firewall), третья отключит отображение загрузки правил, а четвёртая включит поддержку логирования.

О конфигурации сетевых интерфейсов: наиболее распространённый способ — назначить IP только одной из сетевых карт, но мост будет работать одинаково, даже если оба интерфейса или ни один из них не имеют настроенного IP. В последнем случае (без IP) машина с мостом останется более скрытой, так как будет недоступна из сети: для её настройки потребуется войти с консоли или через третий сетевой интерфейс, отделённый от моста. Иногда во время запуска системы некоторым программам требуется доступ к сети, например, для разрешения доменных имён: в этом случае необходимо назначить IP внешнему интерфейсу (тому, который подключён к интернету, где находится DNS-сервер), так как мост будет активирован в конце процедуры запуска. Это означает, что интерфейс fxp0 (в нашем случае) должен быть указан в разделе ifconfig файла /etc/rc.conf, тогда как xl0 — нет. Назначение IP обеим сетевым картам не имеет особого смысла, за исключением случаев, когда во время запуска приложения должны получать доступ к сервисам на обоих сегментах Ethernet.

Есть ещё один важный момент. При работе IP поверх Ethernet фактически используются два протокола Ethernet: один — это IP, другой — ARP. ARP выполняет преобразование IP-адреса хоста в его Ethernet-адрес (уровень MAC). Чтобы обеспечить связь между двумя хостами, разделёнными мостом, необходимо, чтобы мост передавал ARP-пакеты. Этот протокол не включён в уровень IP, так как он существует только при работе IP поверх Ethernet. Межсетевой экран FreeBSD фильтрует исключительно на уровне IP, поэтому все не-IP пакеты (включая ARP) будут передаваться без фильтрации, даже если межсетевой экран настроен на запрет всего.

Вот теперь пришло время перезагрузить систему и использовать её как прежде: будут появляться некоторые новые сообщения о мосте и межсетевом экране, но мост не будет активирован, а межсетевой экран, находясь в режиме open, не будет препятствовать никаким операциям.

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

На этом этапе, чтобы включить мост, необходимо выполнить следующие команды (с учётом замены имён двух сетевых интерфейсов fxp0 и xl0 на ваши собственные):

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

На этом этапе вы должны быть способны разместить машину между двумя группами хостов, не нарушая их способности к взаимодействию. Если это так, следующим шагом будет добавление строк net.link.ether.bridge.[blah]=[blah] в файл /etc/sysctl.conf, чтобы они выполнялись при запуске системы.

Время создать собственный файл с правилами межсетевого экрана для защиты внутренней сети. Это будет несколько сложно, так как не все функции межсетевого экрана доступны для мостовых пакетов. Кроме того, есть разница между пакетами, которые перенаправляются, и пакетами, которые принимаются локальной машиной. В целом, входящие пакеты проходят через межсетевой экран только один раз, а не два, как обычно; фактически они фильтруются только при получении, поэтому правила с out или xmit никогда не сработают. Лично я использую in via — это более старый синтаксис, но он интуитивно понятен при чтении. Ещё одно ограничение заключается в том, что для пакетов, фильтруемых мостом, можно использовать только команды pass или drop. Более сложные действия, такие как divert, forward или reject, недоступны. Такие опции всё ещё можно использовать, но только для трафика, направленного на саму машину моста или исходящего от неё (если у неё есть IP-адрес).

В FreeBSD 4.0 появилась концепция фильтрации с сохранением состояния. Это значительное улучшение для UDP-трафика, который обычно представляет собой запрос, отправляемый наружу, за которым вскоре следует ответ с тем же набором IP-адресов и номеров портов (но, конечно, с поменянными местами источником и назначением). Для межсетевых экранов без сохранения состояния практически нет возможности обрабатывать такой трафик как единую сессию. Однако, если межсетевой экран может «запоминать» исходящий UDP-пакет и в течение нескольких минут разрешать ответ, обработка UDP-сервисов становится тривиальной. В следующем примере показано, как это сделать. То же самое можно проделать и с TCP-пакетами. Это позволяет избежать некоторых атак типа «отказ в обслуживании» и других неприятных трюков, но также обычно приводит к быстрому росту таблицы состояний.

Рассмотрим пример настройки. Обратите внимание, что в начале файла /etc/rc.firewall уже есть стандартные правила для loopback-интерфейса (интерфейса обратной петли) lo0, поэтому нам не нужно о них заботиться. Пользовательские правила следует поместить в отдельный файл (например, /etc/rc.firewall.local) и загружать его при старте системы, изменив строку в /etc/rc.conf, где мы определили open для межсетевого экрана:

Для нашего примера представим, что интерфейс fxp0 подключён к внешней сети (Интернет), а xl0 — к внутренней (ЛВС). У машины с мостом IP-адрес 1.2.3.4 (ваш провайдер вряд ли выдаст вам такой адрес, но для нашего примера он подходит).

Те из вас, кто ранее настраивал межсетевые экраны, могут заметить некоторые отсутствующие элементы. В частности, здесь нет правил защиты от спуфинга, и фактически мы не добавили:

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

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

Существует два правила для пропуска SMTP и DNS-трафика к почтовому серверу и серверу имен, если они у вас есть. Очевидно, весь набор правил должен быть адаптирован под личные предпочтения — это лишь конкретный пример (формат правил подробно описан на ipfw(8)). Обратите внимание, что для работы "relay" и "ns" разрешение имен должно работать до включения моста. Это пример того, как убедиться, что IP-адрес установлен на правильной сетевой карте. Альтернативно можно указать IP-адрес вместо имени хоста (это требуется, если у машины нет IP-адреса).

Люди, привыкшие настраивать межсетевые экраны, вероятно, также привыкли использовать правило reset или forward для идентификационных пакетов (TCP-порт 113). К сожалению, это не применимо при использовании моста, поэтому лучше всего просто передавать их целевому устройству. Пока на этом устройстве не запущен идентификационный демон, это относительно безопасно. Альтернативой является сброс соединений на порту 113, что создает проблемы с такими сервисами, как IRC (запрос идентификации будет ожидать таймаута).

Единственное, что может показаться немного странным — это наличие правила, разрешающего общение для мостовой машины, и другого правила для внутренних хостов. Помните, что это связано с тем, что два типа трафика проходят разные пути через ядро и попадают в пакетный фильтр. Трафик внутренней сети проходит через мост, в то время как локальная машина использует обычный IP-стек для общения. Поэтому и нужны два правила для обработки разных случаев. Правила in via fxp0 работают для обоих путей. В общем случае, если вы используете правила in via во всём фильтре, вам потребуется сделать исключение для локально сгенерированных пакетов, так как они не поступают через какие-либо из наших интерфейсов.

Многие части этой статьи были взяты, обновлены и адаптированы из старого текста о мостах, отредактированного Ником Сайером. Пара вдохновений обязана введению в мосты от Стива Петерсона.

Огромная благодарность Луиджи Риццо за реализацию кода моста в FreeBSD и за время, которое он уделил мне, отвечая на все мои вопросы по этой теме.

Благодарность также выражается Тому Родсу, который проверил мою работу по переводу с итальянского (оригинального языка этой статьи) на английский.