Prohomelab

Порядок настройки

Все DNS-запросы маршрутизируются в открытом виде. Ваш интернет-провайдер или хакер может перехватывать передачи запросов по протоколам UDP и TCP на порту 53 в открытом виде, чтобы скомпрометировать DNS-запросы и ответы сайта. По этой причине мы должны шифровать наши DNS-запросы в целях безопасности. DNS через TLS (DoT) — это протокол безопасности, который использует Transport Layer Security (TLS) для шифрования DNS-трафика и является одним из наиболее распространенных решений безопасности DNS. Основная задача — повысить вашу безопасность и конфиденциальность. Вот несколько преимуществ DNS over TLS:

• Предотвращение манипуляций с DNS со стороны злоумышленника.
• Исключение атаки типа «человек посередине». Это когда ваш запрос перехватывается и перенаправляется на какой-нибудь фишинговый сайт.
• Предотвратить шпионаж. Ну для дома это конечно фантасмагория.

Включение DoT в Opnsense

Чтобы настроить и включить DoT на брандмауэре OPNsense, выполните следующие действия:

1. Перейдите в раздел «Services» → «Unbound DNS» → «DNS over TLS» в веб-интерфейсе OPNsense.

2. Нажмите кнопку «Добавить» со значком + в правом нижнем углу панели.
3. Убедитесь, что отмечен параметр «Включено».
4. Вы можете оставить поле Домен пустым. По умолчанию, если оставить это поле пустым, все запросы будут направляться на указанный сервер. Ввод доменного имени в этом поле приведет к направлению запросов для этого конкретного домена на выбранный сервер.
5. Введите IP-адрес DNS-сервера для пересылки всех запросов, например 8.8.8.8.
6. Установите порт сервера для DoT 853.
7. Введите общее имя DNS-сервера (например, dns.google.com) в поле Verify CN, чтобы проверить его сертификат TLS. DNS-over-TLS уязвим для атак типа «человек посередине», если подлинность сертификатов не может быть подтверждена. Вы можете оставить поле пустым, чтобы принять самоподписанные сертификаты, но это полностью нивелирует смысл того, что мы с вами делаем в этой статье.

8. Нажмите «Сохранить» .
9. Вы можете добавить DNS-сервер IPv6 в качестве вторичного DNS-резолвера.
10. Нажмите «Применить», чтобы активировать настройки.

В итоге вы получите что-то вроде такого

Настройка DNS и DHCP серверов 

Чтобы заставить всех клиентов в вашей сети использовать серверы DoT, которые вы определили выше, вы должны правильно настроить свои серверы DNS и DHCP. Вы можете настроить службы DNS и DHCP в OPNsense, выполнив следующие шаги:

1. Перейдите в раздел System → Settings → General в меню слева.
2. Убедитесь, что все поля для DNS-серверов пустые. Это делается для того, чтобы гарантировать, что DNS-трафик будет перенаправлен обратно на маршрутизатор.
3. Снимите флажок Allow DNS server list to be overridden by DHCP/PPP on WAN для параметров DNS-сервера. Если этот параметр включен, DNS-серверы, предоставляемые DHCP/PPP-сервером в глобальной сети (WAN) (перевожу на русский, это днс сервера вашего провайдера), будут использоваться для своих предполагаемых функций, таких как предоставление DNS-сервисов. И соответственно они будут иметь приоритет.

Чтобы обеспечить безопасную и доверенную среду, рекомендуется использовать правило брандмауэра, которое запрещает любой исходящий трафик DNS на порту 53 при использовании DNS over TLS, который у нас использует порт 53. Если клиенты решат напрямую запрашивать другие серверы имен самостоятельно, можно использовать правило перенаправления NAT для отправки этих запросов на 127.0.0.1<53>, который является локальной службой Unbound. Это гарантирует, что эти запросы точно будут отправлены через TLS.

Список СN доменов, которые используются для DoT надо смотреть для соответствующего провайдера.

Для quad 9 это - dns.quad9.net.

Просмотр журналов Unbound DNS

Дополнительно можно проверить журналы Unbound DNS, чтобы убедиться, что DNS-запросы действительно передаются по протоколу DNS over TLS (DoT) через порт 853.

Для этого выполните следующие действия:

1. Перейдите в Services → Unbound DNS → Advanced.

2. Прокрутите страницу до раздела Logging Settings.

3. Включите параметр Log Queries.

   После этого Unbound будет записывать в журнал каждую обработанную DNS-запрос. Для каждой записи будут указаны время, IP-адрес клиента, запрашиваемое доменное имя, тип и класс запроса.

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

4. Для параметра Log Level Verbosity выберите значение Level 2. Этот уровень обеспечивает достаточно подробную информацию для диагностики работы DNS over TLS.

5. Нажмите Apply, чтобы сохранить изменения.

6. Затем откройте раздел Services → Unbound DNS → Log File.

7. В поле поиска введите 853.

Если DNS over TLS настроен корректно, в журнале появятся записи, подтверждающие, что Unbound обменивается данными с настроенным DNS-резолвером через порт 853. Это означает, что DNS-запросы передаются в зашифрованном виде, а не по обычному протоколу DNS через порт 53.

Dnsmasq DHCP

Для большинства домашних пользователей и небольших homelab я рекомендую использовать Dnsmasq. Именно поэтому он стал DHCP-сервером по умолчанию.

Dnsmasq подойдет вам, если:

• домашняя сеть или Homelab состоит из нескольких VLAN и не требует сложной DHCP-инфраструктуры;

• вы хотите использовать Dnsmasq не только как DHCP-сервер, но и как DNS Forwarder вместо Unbound DNS;

• необходимо, чтобы имена устройств, получивших адрес по DHCP, автоматически регистрировались в локальном DNS-сервере;

• вы планируете использовать специальные DNS-алиасы OPNsense для блокировки доступа к определенным доменам.

Kea DHCP

Kea DHCP — это современный преемник ISC DHCP, ориентированный на более сложные сценарии использования.

Его стоит выбрать, если:

• требуется обеспечить отказоустойчивость DHCP-сервера (High Availability);

• в сети используются сложные маршрутизаторы, которым необходимо делегировать IPv6-префиксы (Prefix Delegation).

Какой DNS-сервер выбрать?

Помимо выбора DHCP-сервера, необходимо определиться и с DNS-службой. В OPNsense доступны два варианта: Dnsmasq DNS и Unbound DNS.

Несмотря на появление Dnsmasq в качестве DHCP-сервера по умолчанию, основным DNS-сервером по-прежнему остается Unbound DNS. Каждый из вариантов имеет свои преимущества.

Unbound DNS

Unbound DNS — это DNS-сервер, который используется в OPNsense по умолчанию, и именно его я рекомендую большинству пользователей.

Его основные преимущества:

• является полноценным рекурсивным DNS-резолвером, который может выполнять запросы непосредственно к корневым DNS-серверам, не полагаясь на публичные DNS-провайдеры;

• поддерживает DNS Block Lists (DNSBL), позволяя блокировать рекламу, трекеры и вредоносные домены по аналогии с Pi-hole;

• поддерживает DNS over TLS (DoT), благодаря чему DNS-запросы могут передаваться в зашифрованном виде через доверенные DNS-серверы, например Cloudflare или Quad9;

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

Следует помнить, что при использовании DNS over TLS Unbound перестает работать как рекурсивный резолвер. В этом режиме он пересылает запросы выбранному внешнему DNS-серверу по защищенному TLS-соединению.

Использование Dnsmasq и Unbound одновременно

В некоторых случаях имеет смысл использовать оба DNS-сервиса одновременно.

Например, если в качестве DHCP-сервера используется Dnsmasq, а основным DNS-сервером остается Unbound, клиенты сети продолжают отправлять DNS-запросы в Unbound. При этом запросы к локальным именам хостов автоматически перенаправляются в Dnsmasq, который знает обо всех устройствах, получивших адрес по DHCP.

Такая схема позволяет объединить преимущества обоих решений: использовать расширенные возможности Unbound и одновременно сохранить автоматическое разрешение имен устройств внутри локальной сети.

Включение службы

Первый параметр — Enable.

Выбор интерфейсов

В поле Interface выберите все интерфейсы, на которых Dnsmasq будет обслуживать DHCP-клиентов.

Одним из преимуществ Dnsmasq является возможность выбрать сразу несколько интерфейсов в одном месте. .

Использование Dnsmasq в качестве DNS

Если вы планируете использовать Dnsmasq не только как DHCP-сервер, но и для разрешения имен устройств в локальной сети, необходимо включить его DNS-функциональность.

Для этого в разделе DNS измените значение параметра Listen port.

Настройка переадресации DNS-запросов

В разделе DNS Query Forwarding рекомендуется включить следующий параметр:

В этом случае Dnsmasq не будет использовать DNS-серверы, указанные в System → General, а будет отвечать только за разрешение локальных имен хостов. Это предотвращает отправку запросов к неизвестным локальным именам на внешние DNS-серверы.

Параметры DHCP

В разделе DHCP по умолчанию уже включены три рекомендуемые опции. Их можно оставить без изменений.

Локальный домен

Если поле DHCP default domain оставить пустым, Dnsmasq автоматически будет использовать доменное имя, указанное в разделе System → General. Такое поведение аналогично поведению ISC DHCP.

При необходимости здесь можно задать другой домен по умолчанию или указать отдельный домен для каждого DHCP-пула.

Note. Для локальной сети лучше использовать специальный внутренний домен, например .internal. Он официально зарезервирован ICANN для использования в частных сетях. Альтернативой является домен .home.arpa, однако .internal обычно проще воспринимается и запоминается.

Раздел ISC/KEA DHCP (Legacy)

В нижней части страницы находится раздел ISC/KEA DHCP (Legacy).

Если вы настраиваете Dnsmasq по схеме, описанной в этой статье, включать какие-либо параметры в этом разделе не требуется. Локальное разрешение имен будет работать без использования механизмов совместимости с ISC DHCP и Kea DHCP.

![[dnsmasq-general-settings.webp]]

Создание нового DHCP-пула

Нажмите кнопку + в правом нижнем углу страницы и заполните параметры.

Например, для сети 192.168.1.0/24 диапазон может выглядеть следующим образом:

Параметр Subnet mask заполнять не требуется. Поскольку диапазон создается для существующего интерфейса OPNsense, система автоматически определит маску подсети на основании его конфигурации.

После заполнения параметров нажмите Save.

Если в вашей инфраструктуре используется несколько сетей (например, LAN, WIFI, Guest или Management), аналогичным образом создайте DHCP-пулы для каждого соответствующего интерфейса.

Настройка Query Forwarding

Перейдите в раздел:

Services → Unbound DNS → Query Forwarding

В таблице Custom forwarding нажмите кнопку + и создайте новое правило.

Здесь используется адрес 127.0.0.1, поскольку Dnsmasq работает на том же устройстве, что и Unbound, а порт 53053 был указан при включении DNS-службы Dnsmasq.

Если для разных сегментов сети используются разные домены (например, .lan, .iot, .guest), аналогичное правило необходимо создать для каждого домена.

Настройка Reverse DNS

Кроме обычного разрешения имен рекомендуется настроить Reverse DNS (обратное разрешение имен).

Reverse DNS позволяет определить имя устройства по его IP-адресу. Это особенно удобно при анализе журналов OPNsense, когда известно только IP-адрес клиента.

Настройка выполняется аналогично предыдущему пункту.

Нажмите + и создайте еще одно правило.

Для параметра Domain используется специальная зона in-addr.arpa.

Например, если необходимо обслуживать всю адресацию диапазона 192.168.0.0/16, параметры будут следующими:

Такое правило позволит выполнять обратное разрешение имен для всех подсетей вида 192.168.x.x.

Если ваша инфраструктура использует другие диапазоны адресов или требуется более точная настройка, можно создать отдельные записи Reverse DNS для каждой локальной сети.

После сохранения изменений Unbound будет автоматически перенаправлять запросы к локальным доменам в Dnsmasq, сохраняя при этом все преимущества Unbound как основного DNS-резолвера.

Domain Override и Firewall Alias

Одной из интересных особенностей Dnsmasq в OPNsense является возможность связать Domain Override со специальным алиасом межсетевого экрана.

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

Это значительно упрощает создание правил Firewall, если необходимо разрешить или запретить доступ сразу ко всему домену.

Создание Firewall Alias

Перед созданием Domain Override необходимо создать специальный алиас.

Перейдите в:

Firewall → Aliases

Создайте новый алиас со следующими параметрами:

После сохранения нажмите Apply.

Теперь этот алиас можно будет выбрать при создании Domain Override.

Создание Domain Override

Перейдите в раздел:

Services → Dnsmasq DNS & DHCP → Domains

Создайте новое правило и в качестве DNS-сервера укажите локальный адрес Dnsmasq.

После этого OPNsense будет автоматически наполнять выбранный алиас IP-адресами домена и его поддоменов.

Важно

Эта функция очень удобна, но использовать ее следует с осторожностью. Если домен обслуживается большим количеством серверов или использует CDN, алиас может содержать сотни IP-адресов. Применение такого алиаса в правилах Firewall способно привести к неожиданным результатам — например, разрешить или заблокировать доступ к сторонним сервисам, которые используют те же IP-адреса. По этой причине разработчики OPNsense рекомендуют использовать подобные алиасы прежде всего для разрешаюших списков разрешения (Allow List), а не для блокировки.

Следует также учитывать, что OPNsense не отслеживает значение TTL DNS-записей для такого алиаса. Если IP-адреса домена изменятся, они не будут обновлены автоматически до очистки и повторного заполнения алиаса. В результате правила межсетевого экрана могут некоторое время использовать устаревшие адреса.

Создание нового статического резервирования

Чтобы добавить новое устройство, нажмите кнопку + и заполните необходимые поля.

Если поле Domain оставить пустым, будет использован домен, указанный в общих настройках системы (System → General).

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

Помимо статических DHCP-записей, Dnsmasq позволяет создавать дополнительные DNS-псевдонимы (Alias Record).

Это может быть полезно, например, при использовании обратного прокси (Reverse Proxy), когда несколько доменных имен должны указывать на одно устройство.

Кроме того, можно создавать записи CNAME, что особенно удобно для устройств с динамическими IPv4-адресами.

Правила (Rules)

OPNsense использует межсетевой экран с отслеживанием состояния соединений (Stateful Packet Filter). Он позволяет разрешать или запрещать прохождение сетевых пакетов между определенными сетями, а также управлять тем, каким образом пакеты пересылаются через устройство.

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

Ниже рассмотрены основные элементы правила.

Действия (Actions)

Каждому правилу можно назначить одно из трех действий.

Правило «Разрешить всё» (Allow All Rule)

После установки OPNsense и первоначальной настройки интерфейсов LAN и WAN система автоматически создает несколько правил:

• правило защиты от блокировки доступа (Web Administration Anti-Lockout Rule);
• правило Allow All для IPv4;
• правило Allow All для IPv6.

Эти правила выполняют две важные функции:

• предотвращают потерю доступа к веб-интерфейсу управления OPNsense;
• предоставляют устройствам локальной сети (LAN) полный доступ в Интернет и к другим сетям, расположенным за межсетевым экраном.

Поэтому любое устройство, подключенное непосредственно к маршрутизатору (или к коммутатору, подключенному к нему), сразу получает возможность работать в сети без дополнительной настройки правил.

Если правило Allow All удалить или отключить, весь исходящий трафик из локальной сети будет заблокирован. Исключением останется только доступ к веб-интерфейсу управления OPNsense.

Почему правило Anti-Lockout не рекомендуется использовать в корпоративной сети

Хотя правило Anti-Lockout очень удобно для домашнего использования, в корпоративной среде его применение считается небезопасным.

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

• Web GUI;
• SSH-консоль.

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

Поэтому в корпоративных сетях рекомендуется:

1. отключить правило Anti-Lockout;
2. создать собственное правило, разрешающее доступ к управлению только администраторам или доверенным устройствам.

Как посмотреть правила по умолчанию

Чтобы просмотреть автоматически созданные правила:

1. Перейдите в Firewall → Rules → LAN.
2. В верхней части списка правил нажмите значок раскрывающегося списка рядом с пунктом Automatically generated rules.

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

• Default Anti-Lockout Rule;
• Allow LAN to Any.

Порядок обработки правил в OPNsense

При поступлении сетевого пакета OPNsense проверяет правила в следующем порядке:

1. Floating Rules (плавающие правила);
2. Interface Groups (правила групп интерфейсов);
3. Interface Rules (правила отдельных интерфейсов).

Автоматически создаваемые внутренние правила системы обычно регистрируются первыми.

Параметр Quick и порядок срабатывания правил

По умолчанию большинство правил создаются с включенным параметром Quick.

Если Quick включен, используется принцип:

Note

Первое совпавшее правило побеждает (First Match Wins).

Как только пакет соответствует какому-либо правилу:

• дальнейшая проверка прекращается;
• последующие правила игнорируются.

Если параметр Quick отключен, применяется другой алгоритм:

Note

Побеждает последнее совпавшее правило (Last Match Wins).

Такой режим используется значительно реже и подходит для реализации специальных политик фильтрации.

Например, именно этот механизм применяется в стандартном правиле Default Deny: если пакет не подошел ни под одно правило, он будет отброшен.

Почему порядок правил имеет значение

Правила OPNsense проверяются сверху вниз.

Поэтому их расположение напрямую влияет на результат обработки трафика.

Как только пакет соответствует правилу:

• Pass;
• Block;
• Reject,

дальнейшая обработка прекращается.

Именно поэтому рекомендуется соблюдать следующий принцип:

• наиболее специфичные правила размещать в начале списка;
• более общие — ближе к концу.

Например:

1. разрешить пользователям LAN доступ только к HTTP и HTTPS;
2. затем разрешить DNS;
3. после этого добавить другие необходимые правила;
4. в самом конце оставить правило Deny All или Allow All, которое будет обрабатывать весь трафик, не попавший под предыдущие правила.

Такой подход делает конфигурацию более понятной и значительно повышает безопасность сети.

Пример

Предположим, необходимо разрешить подключения по HTTPS (порт 443) из Интернета к внутреннему веб-серверу. В этом случае правило следует создавать на интерфейсе WAN, поскольку именно через него пакеты поступают в OPNsense из внешней сети. После этого правило разрешит входящие подключения на TCP-порт 443 к указанному серверу.

Описание параметров

Основные параметры

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

Алиасы (Aliases)

Алиасы — один из самых полезных инструментов OPNsense. Они позволяют существенно сократить количество правил и сделать конфигурацию более понятной.

Алиас представляет собой именованный список:

• узлов;

• сетей;

• портов;

• MAC-адресов;

• стран;

• других объектов.

Вместо того чтобы перечислять множество IP-адресов или портов в каждом правиле, достаточно указать имя соответствующего алиаса.

В OPNsense уже имеются встроенные алиасы, например:

• SSH

• HTTP

• HTTPS

• LAN net

• LAN address

• LAN interface

• DNS

Использование встроенных алиасов делает правила значительно более читаемыми.

1
!172.16.0.10

1
youtube.com,
2
172.16.1.1,
3
192.168.10.1,
4
web_server

1
172.16.1.10

1
!172.16.1.10

1
172.16.1.10-172.16.1.15

1
dbserver

1
!dbserver

1
youtube.com

1
!youtube.com

1
!172.16.0.0/24

1
20:25

1
21,8000:8080

1
F4:90:EA

1
dmzservers

1. Разрешение использования только определённых DNS-серверов

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

Рекомендуется разрешить клиентам использовать только:

• встроенный DNS-сервер OPNsense;

• собственный локальный DNS-сервер;

• либо доверенный внешний DNS-сервис с функциями фильтрации.

Для этого необходимо создать два правила.

Шаг 2. Заблокировать все остальные DNS-серверы

После разрешения собственного DNS необходимо создать правило блокировки.

OPNsense проверяет правила сверху вниз.

Поэтому:

1. сначала пакет попадает под правило Allow Internal DNS;

2. если DNS-сервер не совпадает с разрешенным, пакет доходит до правила Block External DNS и блокируется.

Таким образом:

• внутренний DNS продолжает работать;

• обращения ко всем остальным DNS-серверам блокируются.

После создания правил рекомендуется переместить их в начало списка правил и нажать Apply Changes.

2. Разрешение доступа к локальным сервисам между VLAN

Одним из основных принципов информационной безопасности является сегментация сети.

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

Например, сервер базы данных отдела кадров должен быть доступен исключительно компьютерам сотрудников HR.

Пример: доступ к серверу базы данных Postgres

Создадим следующие алиасы.

Алиас типа Hosts, содержащий список айпи адресов с которых можно получить доступ до базы данных

Например:

1
10.10.10.11-10.10.10.20

Postgres

Алиас типа Hosts, содержащий IP-адрес сервера базы данных.

Например:

1
192.168.1.157

SQL

Алиас типа Ports, содержащий стандартный порт Postgres.

1
5432/TCP

Пример: доступ из LAN к веб-серверу в DMZ

Рекомендуется размещать публичные веб-серверы в отдельной сети DMZ (Demilitarized Zone).

Предположим, веб-сервер имеет адрес:

1
192.168.10.20

Создаем алиас:

1
Web_server

После этого создаем правило.

После применения изменений пользователи локальной сети смогут подключаться к веб-серверу по HTTPS.

3. Блокировка доступа между VLAN

По возможности следует запрещать любое ненужное взаимодействие между внутренними сегментами сети.

По умолчанию OPNsense не разрешает обмен трафиком между VLAN, если только внизу списка правил не находится правило Allow All.

Однако многие домашние пользователи предпочитают использовать правило Allow All, разрешающее весь трафик, кроме явно запрещенного.

В этом случае необходимо вручную запретить доступ к другим VLAN.

Иначе устройства различных сегментов смогут свободно взаимодействовать друг с другом, что полностью нивелирует преимущества сетевой сегментации.

4. Разрешение всего остального трафика

В конце списка правил OPNsense всегда существует неявное правило Deny All.

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

Однако домашним пользователям бывает сложно определить все необходимые порты для современных устройств:

• телевизоров;

• игровых приставок;

• смартфонов;

• ноутбуков;

• IoT-устройств.

Поэтому для домашних сетей нередко применяется следующая схема:

1. в начале списка размещаются правила блокировки;

2. после них — необходимые разрешающие правила;

3. в конце добавляется правило Allow All.

Такой подход значительно упрощает эксплуатацию домашней сети, хотя для корпоративной инфраструктуры он не рекомендуется.

5. Полный доступ для администратора

Во время устранения неисправностей системному администратору часто требуется быстро получить доступ к любому устройству сети.

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

1
admins

Перенаправление портов (Destination NAT)

Когда несколько устройств локальной сети используют один внешний IP-адрес, все входящие подключения из Интернета поступают на этот единственный адрес.

Без дополнительных настроек OPNsense не может определить, какому внутреннему устройству следует передать входящий трафик. В результате такие подключения будут отклоняться.

Эта проблема решается с помощью Destination NAT (DNAT), также известного как Port Forward (перенаправление портов).

Типичный пример использования — публикация веб-сервера, расположенного во внутренней сети. Чтобы сервер стал доступен из Интернета, необходимо перенаправить на него входящие подключения к портам:

• 80/TCP (HTTP);
• 443/TCP (HTTPS).

Где настраивается Destination NAT

Для создания правил перенаправления портов перейдите в веб-интерфейсе OPNsense:

Firewall → NAT → Destination NAT (Port Forward)

В данном разделе отображается список всех существующих правил Destination NAT, а также доступны функции их создания, редактирования и удаления.

Параметры правила Destination NAT

При создании нового правила доступны следующие основные параметры.

Параметры интерфейса (Interface)

При создании правила Destination NAT (Port Forward) необходимо указать, на каком интерфейсе и для какого типа трафика оно будет применяться.

Параметры источника (Source) в правилах OPNsense

При создании правил фильтрации и NAT в OPNsense важно правильно определить параметры, связанные с источником трафика.

Параметры назначения (Destination) в правилах OPNsense

При настройке правил фильтрации и NAT важно точно определить, куда направляется трафик. Для этого используются параметры назначения (Destination).

Параметры перенаправления (Redirect / Translation)

В правилах Destination NAT (Port Forward) параметры перенаправления определяют, куда именно будет отправлен входящий трафик после обработки.

Параметры перенаправления

Дополнительные параметры (Options) в Destination NAT

При настройке правил Destination NAT (Port Forward) в OPNsense доступны дополнительные опции, которые управляют поведением правила, синхронизацией и взаимодействием с firewall rules.

Установка плагина

Перейдите в:

System → Firmware → Plugins

Найдите и установите:

os-crowdsec

После установки автоматически будут развернуты следующие пакеты:

• crowdsec
• crowdsec-firewall-bouncer
• os-crowdsec

⚠️ Важно: не запускайте и не настраивайте сервисы вручную через shell. В OPNsense управление CrowdSec полностью выполняется через интерфейс плагина.

Проверка установки

После установки обновите страницу и перейдите в:

Services → CrowdSec → Overview

Здесь можно проверить:

• запущен ли Log Processor
• активен ли LAPI
• работает ли Remediation Component
• загружены ли collections и сценарии

Если все отображается корректно — базовая установка завершена.

Настройки CrowdSec

Далее перейдите в:

Services → CrowdSec → Settings

По умолчанию включены три основных компонента:

• Log Processor
• LAPI
• Remediation Component

Их можно отключить только для тестирования или при нестандартной архитектуре (например, если LAPI вынесен на отдельный сервер).

Поведение по умолчанию

Начиная с CrowdSec 1.6.3, частные IP-адреса (LAN диапазоны) автоматически исключаются из блокировок.

Это означает, что адреса вида:

• 192.168.x.x
• 10.x.x.x
• 172.16.x.x

не будут блокироваться даже при совпадении со сценариями атак.

Если необходимо изменить это поведение и разрешить блокировку внутренних адресов, можно удалить соответствующий whitelist-парсер:

1
cscli parsers remove crowdsecurity/whitelists

Тестирование работы Remediation (IPS)

Для проверки работы блокировки можно вручную добавить тестовое правило.

⚠️ Важно: при выполнении команды ваш SSH-сеанс может быть разорван.

1
cscli decisions add -t ban -d 2m -i <your_ip_address>

После выполнения:

• ваш текущий IP будет заблокирован на 2 минуты
• повторное подключение с этого IP будет невозможно

Как узнать свой внешний IP

Если вы подключены по SSH, IP можно получить так:

1
echo $SSH_CLIENT | awk '{print $1}'

или:

1
w -h | awk '{print $3}' | sort -u

Remote LAPI (опционально)

По умолчанию LAPI (локальный API CrowdSec) работает прямо на OPNsense. Однако в более сложных схемах его можно вынести на отдельный сервер.

Это имеет смысл, если:

• OPNsense работает на слабом железе
• уже есть центральный CrowdSec сервер
• требуется единая точка управления

⚠️ Важно: при использовании удаленного LAPI часть информации в интерфейсе OPNsense может отображаться некорректно (например, список машин и bouncers).

Настройка удаленного LAPI

Предположим, что у вас уже есть отдельный LAPI сервер, доступный по сети.

1
/usr/local/etc/crowdsec/config.yaml (FreeBSD)/etc/crowdsec/config.yaml (Linux)

1
api.server.listen_uri

1
192.168.122.214:8080

1
local_api_credentials.yaml

1
http://192.168.122.214:8080

1
cscli lapi register -u http://192.168.122.214:8080

1
cscli machines list

1
cscli machines validate <machine_id>

1
cscli bouncers add opnsense

1
a8605055a065fd06b86ecac84e9e9ae4

1
/usr/local/etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml

1
service oscrowdsec restart

Firewall rules для блокировки исходящих подключений

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

Например, это может быть:

• заражённый хост в локальной сети;
• вредоносный скрипт или контейнер;
• случайно запущенное подозрительное ПО.

В таких случаях соединение будет разрешено, если отдельно не запретить исходящий трафик к известным плохим IP.

Для этого в OPNsense рекомендуется использовать Floating Rules, которые позволяют применять правила сразу к нескольким интерфейсам (LAN/VLAN).

Создание алиаса FireHOL

Перейдите в Firewall → Aliases и нажмите Add.

Заполните поля следующим образом:

В поле Content добавьте ссылки на используемые блок-листы:

1
https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level1.netset
2
https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level2.netset
3
https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level3.netset
4
https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_abusers_1d.netset

После сохранения нажмите Apply, чтобы OPNsense загрузила содержимое списков.

Исключение локальных сетей

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

Warning

Какой уровень FireHOL выбрать?

FireHOL объединяет десятки различных источников информации об угрозах и предоставляет несколько уровней блокировки.

• firehol_level1 — наиболее консервативный список. В него попадают IP-адреса с высокой репутацией угроз, поэтому риск ложных срабатываний минимален. Именно этот уровень можно рекомендовать большинству пользователей.
• firehol_level2 — содержит больше адресов и обеспечивает более агрессивную фильтрацию, однако вероятность блокировки легитимных ресурсов становится выше.
• firehol_level3 — максимально строгий уровень. Он объединяет большое количество источников и может вызывать ложные срабатывания, поэтому использовать его стоит только в том случае, если вы понимаете возможные последствия.
• firehol_abusers_1d — список IP-адресов, замеченных в подозрительной активности за последние сутки. Он постоянно обновляется и помогает оперативно блокировать новые источники атак.
• Для домашней сети или небольшой инфраструктуры чаще всего достаточно использовать firehol_level1. Если вы регулярно наблюдаете большое количество сканирований или попыток подбора паролей, можно дополнительно подключить firehol_abusers_1d.
• Уровни level2 и level3 лучше включать только после оценки возможных последствий и контроля журналов межсетевого экрана.

Для этого создайте алиас со следующими параметрами:

В качестве содержимого укажите:

1
!10.0.0.0/8
2
!172.16.0.0/12
3
!192.168.0.0/16
4
!127.0.0.0/8

Затем создайте еще один алиас:

В него необходимо добавить алиасы External и Firehol.

Создание правила блокировки

Теперь остается создать правило межсетевого экрана.

Перейдите в Firewall → Rules → WAN и добавьте новое правило со следующими параметрами:

После сохранения нажмите Apply changes.

Теперь все входящие соединения с IP-адресов, присутствующих в списках FireHOL, будут автоматически блокироваться еще до обработки другими правилами межсетевого экрана.

Автоматическое обновление списков

IP-адреса, используемые злоумышленниками, постоянно меняются, поэтому блок-листы необходимо регулярно обновлять.

Перейдите в System → Settings → Cron и создайте новое задание со следующими параметрами:

После этого OPNsense будет ежедневно загружать актуальные версии списков FireHOL и автоматически применять изменения без вашего участия.

Географическая блокировка (GeoIP)

Если ваши сервисы предназначены только для пользователей из определенных стран, имеет смысл ограничить доступ по географическому признаку. В OPNsense это реализуется с помощью GeoIP-алиасов, которые позволяют создавать правила межсетевого экрана на основе страны, к которой относится IP-адрес.

Настройка базы GeoIP

Для работы GeoIP необходимо подключить базу данных MaxMind GeoLite2.

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

После этого перейдите в Firewall → Aliases → GeoIP settings и в поле URL укажите ссылку следующего вида, заменив your-license-key на полученный лицензионный ключ:

1
https://download.maxmind.com/app/geoip_download?edition_id=GeoLite2-Country-CSV&license_key=your-license-key&suffix=zip

Сохраните изменения.

Более подробно можно почитать тут.

Создание GeoIP-алиасов

После подключения базы данных перейдите в Firewall → Aliases и создайте алиас со следующими параметрами:

Если необходимо разрешить доступ из определенной страны, создайте еще один GeoIP-алиас. Например, для России:

Создание правил межсетевого экрана

Теперь необходимо создать соответствующие правила межсетевого экрана.

Перейдите в Firewall → Rules → WAN и создайте правило блокировки:

Если требуется предоставить доступ к определенному сервису только из выбранной страны, создайте правило разрешения:

Важно. Правила межсетевого экрана в OPNsense обрабатываются сверху вниз. Поэтому правило Pass должно располагаться выше правила Block, иначе соединение будет заблокировано раньше, чем система дойдет до разрешающего правила.

Автоматическое обновление базы GeoIP

База MaxMind регулярно обновляется, поэтому рекомендуется настроить ее автоматическое обновление.

Перейдите в System → Settings → Cron и создайте новое задание:

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

Основные параметры

После применения настроек OPNsense начнет собирать статистику по всем указанным интерфейсам и отправлять данные в локальный collector.