Практическая мотивация

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

На графиках выше видно насколько уменьшилось количество "нежелательных" подключений к PMG после включения защиты на роутере.

В моём случае наружу были опубликованы:

Proxmox Mail Gateway - шлюз фильтрации электронной почты

После открытия SMTP (Simple Mail Transfer Protocol - протокол передачи электронной почты) наблюдалась типичная картина:

устойчивый поток входящих TCP-сессий
массовые попытки подбора учётных данных (bruteforce)
подключения от скомпрометированных хостов (ботнетов)
значительное количество короткоживущих SMTP-сессий без полезной нагрузки

При этом на уровне почтовой системы уже были реализованы базовые и продвинутые механизмы защиты:

SPF (Sender Policy Framework)
DKIM (DomainKeys Identified Mail)
DMARC (Domain-based Message Authentication, Reporting and Conformance)
антиспам-фильтрация
механизмы блокировки по событиям (например, fail2ban)

Тем не менее, все эти меры функционируют после установления сетевого соединения, что принципиально важно.

Проблематика: стоимость обработки соединений

TCP-сессия (Transmission Control Protocol session)

TCP-сессия - это установленное соединение между клиентом и сервером, включающее:

трёхстороннее рукопожатие (three-way handshake)
выделение ресурсов в сетевом стеке
создание обработчика на стороне сервиса

В контексте SMTP это означает:

установление TCP-соединения
передача баннера сервера
начало SMTP-диалога (EHLO/HELO)

Даже если соединение впоследствии отклоняется, система уже понесла затраты:

задействован сетевой стек ядра
выделены файловые дескрипторы (sockets)
запущен процесс или поток обработки (например, smtpd в Postfix)
произведена запись в журнал (logging subsystem)

При высокой интенсивности входящих соединений это приводит к:

росту загрузки CPU
увеличению числа процессов/воркеров
росту I/O за счёт логирования
ухудшению латентности для легитимного трафика

Ниже выборка за аналогичный период спустя сутки. Разница очевидна == меньше спама.

Подход к решению: ранняя фильтрация

Вместо реактивной модели (“обработать и отклонить”) была выбрана проактивная:

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

Для этого фильтрация переносится:

с уровня приложений (Application Layer, L7)
на уровень сети (Network Layer / Firewall)

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

Использование Spamhaus как источника репутации

В качестве источника threat intelligence был выбран Spamhaus Project.

Threat Intelligence (разведка угроз)

Под threat intelligence понимаются агрегированные данные о вредоносной активности, включая:

IP-адреса, участвующие в рассылке спама
узлы ботнетов
скомпрометированные системы
инфраструктуру атак

Используемый агрегированный список

zen.spamhaus.org

Данный DNSBL (DNS-based Blackhole List) объединяет:

SBL (Spamhaus Block List) — источники спама
XBL (Exploits Block List) — заражённые хосты
PBL (Policy Block List) — IP, не предназначенные для прямых SMTP-соединений

Принцип работы DNSBL

DNSBL (DNS-based Blackhole List)

DNSBL — это механизм проверки IP-адреса через DNS (Domain Name System).

Алгоритм проверки

Для IP-адреса:

1.2.3.4

выполняются следующие шаги:

инверсия октетов:

4.3.2.1

формирование доменного имени:

4.3.2.1.zen.spamhaus.org

выполнение DNS-запроса

Интерпретация ответа

отсутствие записи (NXDOMAIN) → IP не включён в список
ответ вида:

127.0.0.X

→ IP присутствует в blacklist

Диапазон 127.0.0.0/8 (loopback) используется как код возврата.

Архитектура решения на MikroTik

Решение реализуется на уровне MikroTik RouterOS версии 7.22.1 и состоит из следующих компонентов:

первичный отбор входящих IP
буферизация адресов для проверки
асинхронная проверка через DNSBL
динамическое формирование blacklist
ранняя блокировка на уровне RAW firewall

Ключевые компоненты RouterOS

Connection Tracking

Connection Tracking - механизм отслеживания состояний соединений (stateful inspection), включающий состояния:

new
established
related

Использование connection tracking в скриптах неэффективно из-за высокой вычислительной стоимости.

RAW Table

RAW - таблица firewall, обрабатывающая пакеты до применения connection tracking.

Преимущества:

минимальная задержка обработки
отсутствие затрат на state tracking
эффективная фильтрация “на входе”

Address List

Address List - динамическая структура хранения IP-адресов внутри RouterOS, используемая для:

blacklist/whitelist
промежуточной обработки
интеграции с firewall правилами

Пошаговая реализация

1. Определение WAN-интерфейса

/interface list add name=WAN
/interface list member add list=WAN interface=ether1

2. Сбор новых источников трафика

/ip firewall filter
add chain=forward connection-state=new in-interface-list=WAN \
    action=add-src-to-address-list \
    address-list=spamhaus_check \
    address-list-timeout=10m

Назначение:

отбор новых источников
формирование очереди на проверку

3. Скрипт DNSBL-проверки

/system script
add name=check_spamhaus source={
    :local dnszone "zen.spamhaus.org"

    :foreach i in=[/ip firewall address-list find list=spamhaus_check] do={

        :local srcIP [/ip firewall address-list get $i address]

        :local p1 [:find $srcIP "."]
        :local p2 [:find $srcIP "." ($p1+1)]
        :local p3 [:find $srcIP "." ($p2+1)]

        :local o1 [:pick $srcIP 0 $p1]
        :local o2 [:pick $srcIP ($p1+1) $p2]
        :local o3 [:pick $srcIP ($p2+1) $p3]
        :local o4 [:pick $srcIP ($p3+1) [:len $srcIP]]

        :local revIP ($o4.".".$o3.".".$o2.".".$o1.".".$dnszone)

        :do {
            :local res [:resolve $revIP]

            :if ($res~"127.0.0.") do={
                /ip firewall address-list add \
                    list=spamhaus_block \
                    address=$srcIP \
                    timeout=1d
            }

        } on-error={}

        /ip firewall address-list remove $i
    }
}

Особенности:

обработка только новых IP
исключение повторных проверок
отказоустойчивость через on-error

Проверка нескольких IP адресов из списка на блокировку в онлайн сервисе Spamhaus подтверджает корректность работы скрипта

Для проверки можно воспользоваться ссылкой https://check.spamhaus.org/

4. Блокировка на уровне RAW

/ip firewall raw
add chain=prerouting \
    src-address-list=spamhaus_block \
    action=drop

Назначение:

блокировка до connection tracking
минимизация нагрузки

5. Планировщик выполнения

/system scheduler
add name=spamhaus-check interval=1m \
    on-event="/system script run check_spamhaus"

Влияние на почтовую инфраструктуру

Эффект для Proxmox Mail Gateway

До внедрения:

высокая интенсивность SMTP-сессий
нагрузка на антиспам-движок
увеличение количества DNSBL-запросов
рост времени обработки

После внедрения:

большая часть соединений отфильтровывается на сетевом уровне
снижается количество SMTP handshake

SMTP Handshake

Начальный этап SMTP-сессии:

TCP handshake
передача баннера
EHLO/HELO

При ранней фильтрации этот этап не инициируется для нежелательных источников.

Практический результат

В типичном сценарии наблюдается:

снижение числа входящих соединений на 30–70%
уменьшение нагрузки на CPU
снижение объёма логирования
повышение стабильности обработки легитимной почтыОграничения подхода

Следует учитывать:

DNSBL-запросы зависят от доступности DNS
возможны ограничения со стороны Spamhaus
задержка между появлением IP и его блокировкой

Заключение

Рассмотренный подход реализует классическую модель ранней фильтрации трафика (early packet drop), при которой нежелательные соединения отсекаются до их обработки прикладными сервисами.

Ключевое преимущество:

минимизация затрат ресурсов за счёт устранения нагрузки на максимально раннем этапе

В контексте почтовых систем это особенно важно, поскольку SMTP по своей природе остаётся открытым протоколом.

Таким образом, интеграция MikroTik с DNSBL от Spamhaus позволяет существенно повысить эффективность защиты, не усложняя архитектуру и не увеличивая вычислительную нагрузку на серверы.

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

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

Если Вы только начинаете с MikroTik и хотите безопасно публиковать свои сервисы наружу, этот подход - отличная отправная точка. А если у вас уже есть опыт работы с DNSBL или RAW firewall, вы можете развивать систему дальше: добавлять многоуровневую фильтрацию, интегрировать с Postfix postscreen или расширять скрипты для более интеллектуальной обработки трафика.

Спасибо за внимание! Надеюсь, ваши лаборатории останутся чистыми, а почтовые серверы - стабильными. Будьте внимательны к деталям и не забывайте, что лучший пакет - это тот, который вы никогда не обработали 😉

защита Mikrotik RouterOS Скрипты Spamhaus DNSBL Firewall

Комментарии (0)

Комментировать

Пока нет комментариев

Станьте первым, кто прокомментирует эту запись