Лучшие практики файрвола pfSense - правила и миграция

Грамотно спроектированная политика межсетевого экрана определяет уровень защищённости всей сети. pfSense предоставляет гибкие инструменты фильтрации на основе pf, однако сама по себе платформа не гарантирует безопасность - результат зависит от того, как администратор организует правила, контролирует их актуальность и адаптирует политику к изменяющимся требованиям. В этом руководстве рассмотрены принципы построения надёжной политики файрвола, типичные ошибки, процедура аудита правил и детальные инструкции по миграции с Cisco ASA, FortiGate и MikroTik RouterOS.

Организация правил

Порядок правил в pfSense определяет результат фильтрации: действует принцип first match wins - первое совпавшее правило завершает обработку пакета. Неправильная организация правил приводит к тому, что трафик блокируется или пропускается вопреки намерениям администратора. Подробное описание механизма обработки приведено в разделе правила файрвола pfSense .

Рекомендуемый порядок правил на интерфейсе

Для каждого интерфейса (LAN, DMZ, OPT и т.д.) следует придерживаться единой структуры:

1. Anti-lockout - pfSense создаёт это правило автоматически на LAN-интерфейсе. Если правило отключено вручную, необходимо создать явное разрешение для административного доступа (HTTPS/SSH к IP-адресу интерфейса) и разместить его первым.

2. Явные запреты для известных угроз - блокировка трафика от источников из чёрных списков (bogon-сети, GeoIP-списки, списки известных вредоносных адресов). Для этих правил рекомендуется использовать алиасы типа URL Table , которые обновляются автоматически.

3. Разрешающие правила для легитимного трафика - конкретные правила, разрешающие необходимые протоколы и направления. Каждое правило должно быть максимально специфичным: указан протокол, порт назначения, адрес источника и назначения.

4. Неявный запрет (default deny) - pfSense автоматически отбрасывает весь трафик, не совпавший ни с одним правилом. Создавать явное правило блокировки в конце списка не обязательно, но рекомендуется для двух целей: ведение журнала отклонённого трафика и визуальное подтверждение того, что политика default deny действует.

Использование разделителей

pfSense позволяет создавать цветные разделители (separators) между правилами в веб-интерфейсе. Разделители не влияют на обработку трафика, но существенно упрощают навигацию при большом количестве правил.

Рекомендуемая схема именования разделителей:

Описания правил

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

[TICKET/CR] Назначение - срок действия (если временное)

Примеры:

• CR-2024-031 VPN access for partner ExampleCorp - until 2024-12-31
• Allow DNS to internal resolvers
• Block outbound SMTP from workstations (relay prevention)

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

Минимизация количества правил через алиасы

Большое количество правил усложняет аудит и повышает вероятность ошибок. Вместо создания отдельного правила для каждого сервера или порта следует использовать алиасы :

Неоптимально - три отдельных правила:

Оптимально - одно правило с алиасами:

Алиас WebServers содержит IP-адреса серверов, алиас WebPorts - порты 80, 443, 8443. При добавлении нового сервера или порта достаточно обновить алиас, а не создавать новое правило.

Типичные ошибки

Избыточно разрешающие правила (any/any)

Правило Pass * * * * * (разрешить всё со всех адресов на все адреса по всем протоколам) - наиболее распространённая и опасная ошибка. Такие правила создаются для быстрой отладки и забываются в рабочей конфигурации. pfSense создаёт правило default allow на LAN по умолчанию - после первоначальной настройки его необходимо заменить набором специфичных разрешений.

Внимание:

Правило any/any на LAN-интерфейсе позволяет любому устройству в сети обращаться к произвольным адресам по любым протоколам, включая прямой доступ в интернет в обход прокси-серверов и средств контроля.

Отсутствие фильтрации исходящего трафика

Администраторы часто сосредоточены на входящем трафике и полностью игнорируют исходящий. Отсутствие egress-фильтрации позволяет скомпрометированным хостам свободно устанавливать обратные соединения (reverse shell), эксфильтровать данные и взаимодействовать с командными серверами (C2). Минимальный набор ограничений для исходящего трафика:

• Разрешить DNS только к внутренним серверам или конкретным публичным резолверам
• Разрешить HTTP/HTTPS через прокси-сервер (при наличии)
• Разрешить SMTP только с почтового сервера
• Заблокировать прямой выход на нестандартные порты (IRC, Tor, P2P)

Отсутствие журналирования запрещённого трафика

pfSense по умолчанию журналирует трафик, совпавший с неявным правилом deny. Однако при добавлении явных правил блокировки (например, для чёрных списков) журналирование необходимо включать вручную - по умолчанию оно отключено для явных правил. Без логов администратор не видит заблокированных атак и не может оценить эффективность политики.

Затенённые правила (shadowed rules)

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

Правило 2 никогда не сработает, потому что правило 1 разрешает весь трафик из LAN, включая SSH к 10.0.0.5. Для исправления необходимо переместить правило блокировки выше разрешающего:

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

Указание IP-адресов и портов непосредственно в правилах (hardcoded values) приводит к дублированию данных: при изменении адреса сервера приходится обновлять каждое правило, в котором он упоминается. Алиасы решают эту проблему - подробное описание их возможностей приведено в разделе алиасы pfSense .

Забытые временные правила

Временные правила, созданные для диагностики или краткосрочных задач, остаются в конфигурации на неопределённый срок. Рекомендации:

• Указывать срок действия в описании правила (например, until 2024-06-30)
• Включать журналирование для временных правил для контроля их использования
• Проводить ежемесячную проверку наличия временных правил

Миграция с Cisco ASA

Миграция с Cisco ASA на pfSense требует понимания фундаментальных различий в архитектуре и терминологии. Оба межсетевых экрана работают по принципу stateful inspection и first match wins, однако подходы к организации правил, объектов и NAT существенно отличаются.

Соответствие терминологии

Преобразование ACL в правила pfSense

ACL на Cisco ASA представляют собой упорядоченные списки ACE (Access Control Entries), которые привязываются к интерфейсу командой access-group. В pfSense каждое правило уже привязано к интерфейсу - промежуточный шаг привязки отсутствует.

Cisco ASA:

object-group network WEBSERVERS
 network-object host 10.0.1.10
 network-object host 10.0.1.11

object-group service WEBPORTS tcp
 port-object eq www
 port-object eq https

access-list INSIDE_IN extended permit tcp any object-group WEBSERVERS object-group WEBPORTS
access-group INSIDE_IN in interface inside

pfSense - эквивалентная конфигурация:

1. Создать алиас WEBSERVERS (тип Host): 10.0.1.10, 10.0.1.11
2. Создать алиас WEBPORTS (тип Port): 80, 443
3. Создать правило на вкладке LAN:

Различия в обработке NAT

На Cisco ASA NAT и правила фильтрации (ACL) обрабатываются как связанные, но отдельные конструкции. Порядок обработки зависит от версии ASA и типа NAT (auto NAT, manual NAT, twice NAT). В pfSense NAT и правила файрвола обрабатываются последовательно:

1. Входящий пакет проходит через правила NAT (Destination NAT / Port Forward)
2. После трансляции адресов пакет оценивается правилами файрвола с уже транслированными адресами

Это означает, что в правилах файрвола pfSense необходимо указывать транслированные (внутренние) адреса назначения, а не публичные. Это отличие часто вызывает ошибки при миграции.

Пример - port forward с фильтрацией:

NAT:   WAN:443 -> 10.0.1.10:443
Rule:  Pass TCP * -> 10.0.1.10:443 (on WAN interface)

На Cisco ASA правило ACL ссылается на публичный адрес (если не используется nat control), в pfSense - на внутренний адрес сервера.

Security Levels vs. правила интерфейсов

Cisco ASA присваивает каждому интерфейсу уровень безопасности (security level, 0–100). Трафик от интерфейса с более высоким уровнем безопасности к интерфейсу с более низким уровнем разрешён по умолчанию. Трафик в обратном направлении запрещён без явного ACL.

pfSense не поддерживает концепцию security levels. Каждый интерфейс обрабатывается независимо: разрешён только тот трафик, который явно указан в правилах (за исключением правила default allow на LAN, которое следует заменить после первоначальной настройки). Это упрощает модель безопасности, но требует создания явных правил для каждого направления трафика.

Пошаговый план миграции с Cisco ASA

1. Инвентаризация объектов - выгрузить все object-groups командой show running-config object-group и создать соответствующие алиасы в pfSense
2. Экспорт ACL - выгрузить ACL командой show access-list и преобразовать каждый ACE в правило pfSense на соответствующем интерфейсе
3. Проверка порядка - убедиться, что порядок правил сохранён (first match wins на обеих платформах)
4. NAT - преобразовать конфигурацию NAT, учитывая различия в порядке обработки
5. Тестирование - проверить критичные потоки трафика, используя Diagnostics > Packet Capture и журналы файрвола
6. Удаление правила default allow на LAN - заменить его набором специфичных разрешений

Миграция с FortiGate

FortiGate использует zone-based firewall с политиками безопасности (security policies), которые связывают зоны источника и назначения. pfSense применяет per-interface модель без зон. Миграция требует перепроектирования структуры правил с учётом этого различия.

Соответствие терминологии

Преобразование политик в правила

FortiGate политика определяет: зону источника, зону назначения, адреса, сервисы, действие, UTM-профили и расписание. В pfSense эквивалент - правило на вкладке интерфейса с указанием протокола, адресов и портов.

FortiGate:

config firewall policy
    edit 10
        set name "LAN to WAN Web"
        set srcintf "lan"
        set dstintf "wan1"
        set srcaddr "LAN_SUBNET"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "HTTP" "HTTPS" "DNS"
        set utm-status enable
        set av-profile "default"
        set ips-sensor "default"
        set ssl-ssh-profile "certificate-inspection"
        set logtraffic all
    next
end

pfSense - эквивалентная конфигурация:

1. Создать алиас WebAndDNS_Ports (тип Port): 80, 443, 53
2. Создать правило на вкладке LAN:

3. Установить пакеты Suricata или Snort для замены UTM-профилей (AV, IPS)
4. Установить SquidGuard или pfBlockerNG для веб-фильтрации

Зоны FortiGate vs. интерфейсы pfSense

FortiGate позволяет объединять несколько интерфейсов в зону и создавать политики между зонами. В pfSense такая абстракция отсутствует. Варианты решения:

• Interface Groups - pfSense позволяет группировать интерфейсы и создавать общие правила для группы. Это наиболее близкий аналог зон, но с ограничениями: правила группы обрабатываются до правил отдельных интерфейсов и не могут быть переопределены на уровне интерфейса.
• Floating Rules - позволяют применять одно правило к нескольким интерфейсам. Подходят для глобальных политик (например, блокировка определённых протоколов на всех интерфейсах).

VDOM и мультитенантность

FortiGate поддерживает Virtual Domains (VDOM) - виртуальные экземпляры файрвола в рамках одного устройства. Каждый VDOM имеет собственные интерфейсы, таблицу маршрутизации, политики и административный доступ.

pfSense не поддерживает аналог VDOM. Для мультитенантных сценариев необходимо использовать:

• Отдельные экземпляры pfSense (физические или виртуальные)
• Разделение через VLAN и отдельные наборы правил для каждого VLAN-интерфейса (ограниченная изоляция, единая таблица маршрутизации)

Security Profiles и их аналоги в pfSense

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

Внимание:

UTM-функции FortiGate глубоко интегрированы в обработку политик и работают на аппаратном уровне (ASIC). Пакеты pfSense выполняются программно и требуют дополнительных ресурсов CPU/RAM. При миграции высоконагруженных инсталляций необходимо проводить нагрузочное тестирование.

Пошаговый план миграции с FortiGate

1. Экспорт конфигурации - выгрузить полную конфигурацию через execute backup full-config
2. Маппинг зон на интерфейсы - определить, какие интерфейсы pfSense соответствуют зонам FortiGate; при необходимости использовать Interface Groups
3. Создание алиасов - преобразовать Address Objects и Address Groups в алиасы pfSense
4. Создание правил - преобразовать каждую Security Policy в правило pfSense на соответствующем интерфейсе
5. Установка пакетов безопасности - установить Suricata/Snort, pfBlockerNG и другие пакеты для замены UTM-профилей
6. Миграция NAT - преобразовать VIP и Central NAT в Port Forward и Outbound NAT
7. Тестирование - проверить все потоки трафика, особенно межзонные, которые в pfSense реализованы через правила на нескольких интерфейсах

Миграция с MikroTik RouterOS

MikroTik RouterOS использует цепочки (chains) для организации правил фильтрации, NAT и манипуляции пакетами. Модель существенно отличается от pfSense: в RouterOS администратор работает с таблицами filter, NAT и mangle, каждая из которых содержит цепочки (input, forward, output). В pfSense все правила привязаны к интерфейсам и обрабатываются на входе.

Соответствие терминологии

Критическое различие: default policy

Внимание:

MikroTik RouterOS по умолчанию разрешает весь трафик (default accept). pfSense по умолчанию запрещает весь трафик (default deny) на всех интерфейсах, кроме LAN (где создаётся начальное правило allow all). При миграции необходимо убедиться, что все необходимые разрешения созданы явно, иначе трафик будет заблокирован.

Преобразование цепочек в правила интерфейсов

В MikroTik правила распределены по цепочкам (input, forward, output). В pfSense все правила находятся на вкладках интерфейсов. Принцип маппинга:

MikroTik - filter/forward:

/ip firewall filter
add chain=forward src-address=192.168.1.0/24 dst-address=10.0.0.0/24 \
    dst-port=80,443 protocol=tcp action=accept comment="LAN to DMZ web"
add chain=forward src-address=192.168.1.0/24 dst-address=0.0.0.0/0 \
    dst-port=53 protocol=udp action=accept comment="LAN DNS"
add chain=forward src-address=192.168.1.0/24 action=drop \
    comment="Block all other LAN forward"

pfSense - правила на вкладке LAN:

Address Lists vs. алиасы

MikroTik Address Lists и pfSense алиасы выполняют одну и ту же функцию - группировку адресов для использования в правилах. Основные различия:

Динамическое добавление адресов через action=add-src-to-address-list (например, для автоматической блокировки сканеров) не имеет прямого аналога в pfSense. Аналогичная функциональность реализуется через пакеты:

• pfBlockerNG - автоматическая блокировка по IP-спискам и GeoIP
• Suricata/Snort - автоматическая блокировка при обнаружении атак

NAT: RouterOS vs. pfSense

MikroTik объединяет все типы NAT в одной таблице /ip firewall nat с разделением по цепочкам srcnat и dstnat. pfSense разделяет NAT на три раздела:

В MikroTik правила NAT и filter - отдельные таблицы, обрабатываемые независимо. В pfSense при создании Port Forward автоматически создаётся связанное правило файрвола (если не отключено). При миграции следует проверить, что для каждого dstnat-правила существует соответствующее разрешающее правило в pfSense.

Mangle и расширенная обработка пакетов

Таблица mangle в MikroTik используется для маркировки пакетов, соединений и маршрутов, а также для изменения полей заголовков (TTL, DSCP, TOS). pfSense не имеет прямого аналога mangle. Частичная замена:

Connection Tracking

MikroTik RouterOS использует модуль connection tracking (conntrack) с явными matcher’ами состояний:

/ip firewall filter
add chain=forward connection-state=established,related action=accept
add chain=forward connection-state=invalid action=drop

В pfSense state table управляется автоматически: каждое разрешающее правило создаёт запись в таблице состояний, и ответный трафик пропускается без явных правил. Явное правило для established/related не требуется. Однако рекомендуется включить опцию Scrub (System > Advanced > Firewall/NAT) для отбрасывания фрагментированных и некорректных пакетов.

Пошаговый план миграции с MikroTik

1. Экспорт конфигурации - выполнить /export для получения текстовой конфигурации
2. Инвентаризация Address Lists - преобразовать в алиасы pfSense
3. Маппинг цепочек:
   • chain=input - правила на интерфейсах для доступа к pfSense (WebGUI, SSH, DNS)
   • chain=forward - правила на интерфейсах для транзитного трафика
   • chain=output - floating rules (при необходимости)
4. Удаление правил conntrack - в pfSense established/related обрабатывается автоматически
5. Преобразование NAT - разделить srcnat и dstnat на Outbound NAT и Port Forward
6. Замена mangle - определить, какие функции mangle необходимы, и реализовать через floating rules, traffic shaper или system settings
7. Проверка default policy - убедиться, что все разрешения созданы явно (pfSense = default deny)
8. Тестирование - проверить все потоки трафика; особое внимание - правилам, которые в MikroTik работали через custom chains (jump), так как pfSense не поддерживает эту конструкцию

Аудит правил

Регулярный аудит правил файрвола - обязательная практика для поддержания безопасности и соответствия нормативным требованиям. Без аудита набор правил деградирует: накапливаются устаревшие разрешения, теряется логика организации, растёт поверхность атаки.

Счётчики срабатываний

pfSense отображает количество срабатываний (hit counters) для каждого правила в списке правил интерфейса. Счётчики позволяют:

• Выявить правила с нулевым счётчиком - потенциальные кандидаты на удаление
• Определить наиболее нагруженные правила для оптимизации их позиции (перемещение выше для ускорения обработки)
• Обнаружить аномалии - резкое увеличение срабатываний может указывать на атаку или изменение в сетевой инфраструктуре

Внимание:

Счётчики сбрасываются при перезагрузке pfSense и при применении изменений в правилах файрвола. Для долгосрочного анализа необходимо использовать внешние системы сбора логов.

Выявление неиспользуемых правил

Процедура выявления неиспользуемых правил:

1. Сбросить счётчики всех правил: Diagnostics > pfTop > Reset States
2. Дождаться полного бизнес-цикла (минимум 30 дней для типичной организации, чтобы учесть ежемесячные процессы)
3. Проверить счётчики: правила с нулевым значением - кандидаты на удаление
4. Перед удалением изменить действие правила на Block с журналированием и выждать дополнительный период
5. Если блокировка не вызвала инцидентов - удалить правило

Регулярность аудита

Соответствие нормативным требованиям

PCI DSS

PCI DSS Requirement 1 требует:

• Документирования всех разрешённых сервисов, протоколов и портов с обоснованием (1.1.6)
• Пересмотра правил файрвола и маршрутизатора не реже чем раз в шесть месяцев (1.1.7)
• Запрета прямого публичного доступа к среде данных держателей карт (1.3)
• Установки персональных файрволов на всех мобильных и принадлежащих сотрудникам устройствах (1.4)

Для выполнения Requirement 1.1.7 необходимо:

• Вести реестр правил с описанием назначения каждого правила
• Фиксировать дату последнего пересмотра
• Хранить результаты аудита в виде документированного отчёта

CIS Benchmarks

CIS Critical Security Controls (v8) включают:

• Control 4.4: Implement and Manage a Firewall on Servers - обязательна фильтрация на уровне серверов
• Control 4.5: Implement and Manage a Firewall on End-User Devices - фильтрация на конечных устройствах
• Control 13.4: Perform Traffic Filtering Between Network Segments - сегментация с контролем трафика

pfSense обеспечивает реализацию этих контролей через VLAN-сегментацию и правила файрвола на каждом интерфейсе.

Чеклист аудита

[ ] Все правила имеют описание
[ ] Нет правил any/any (кроме обоснованных исключений)
[ ] Нет правил с нулевым счётчиком старше 90 дней
[ ] Временные правила удалены или продлены с обоснованием
[ ] Алиасы актуальны (не содержат адреса удалённых серверов)
[ ] Журналирование включено для правил блокировки
[ ] Egress-фильтрация настроена
[ ] Правило default deny присутствует явно (с логированием)
[ ] Разделители актуализированы
[ ] Результаты аудита задокументированы

Интеграция с IDS/IPS

pfSense поддерживает установку систем обнаружения и предотвращения вторжений (IDS/IPS) через дополнительные пакеты - Suricata и Snort. Эти системы анализируют содержимое трафика на уровне приложений и дополняют правила файрвола, которые работают на сетевом и транспортном уровнях.

Взаимодействие IDS/IPS и файрвола

Правила файрвола и IDS/IPS работают на разных этапах обработки пакета:

1. Файрвол (pf) - принимает решение Pass/Block на основании заголовков пакета (IP, порт, протокол)
2. IDS/IPS (Suricata/Snort) - анализирует содержимое (payload) трафика, прошедшего через файрвол

Если файрвол заблокировал пакет, IDS/IPS его не видит. Это означает, что IDS/IPS защищает только от угроз в разрешённом трафике - например, эксплойты в HTTP-запросах, SQL-инъекции, вредоносные DNS-запросы.

Автоматическая блокировка

Suricata и Snort в режиме IPS могут автоматически блокировать трафик при обнаружении угрозы. Механизм блокировки:

• Suricata/Snort добавляет IP-адрес атакующего в таблицу snort2c
• pf проверяет таблицу snort2c до обработки правил файрвола
• Все пакеты от заблокированного IP отбрасываются до истечения timeout

Администратор управляет параметрами блокировки: длительность бана, белые списки (pass lists), категории правил.

Интеграция с Wazuh

Для централизованного мониторинга событий файрвола и IDS/IPS рекомендуется интеграция pfSense с Wazuh. Wazuh собирает журналы pfSense (filterlog, Suricata/Snort alerts), коррелирует события и генерирует оповещения. Подробная инструкция по настройке приведена в разделе интеграция pfSense с Wazuh .

Связанные разделы

• Правила файрвола pfSense - создание и управление правилами, иерархия обработки, floating rules
• Алиасы pfSense - группировка адресов, сетей и портов для упрощения правил
• Интеграция pfSense с Wazuh - мониторинг событий безопасности pfSense в SIEM