Киберзащита за малкия бизнес (част 1): напълно защитен MikroTik рутер

Тази статия описва реална операция, изпълнена в рамките на инициатива за защита на малките и средните предприятия в България. Целта беше да превърнем един обикновен офис рутер в напълно защитена входна точка към мрежата — с IPS, IDS, защита срещу brute-force, blacklist, anti-spoofing и anti-DDoS — използвайки само възможностите на самия MikroTik, без допълнителен хардуер. Макар и с доста дискусии и различни мнения в екипа ни, все пак изпълнихме задачата.

Текстът е подробен и стъпка по стъпка, за да може всеки администратор да го повтори. Всички IP адреси в примерите са генерализирани (примерни диапазони) от съображения за сигурност — заменете ги с вашите.

Какви атаки понася един рутер в офиса

Всеки рутер, който „гледа“ към интернет с публичен адрес, е под постоянен обстрел — независимо дали е малък офис, фирма или предприятие. В по-голямата си част това не са насочени лично срещу вас атаки, а автоматизиран, денонощен шум от ботнети, които сканират целия интернет. Най-честите видове:

• Brute-force (налучкване на пароли) срещу всяка публикувана услуга — FTP, SSH, RDP, уеб панели, пощенски сървъри, а напоследък особено често срещу IP камери и DVR/NVR.
• Сканиране и разузнаване (port scanning) — търсене на отворени портове и уязвими услуги, преди същинската атака.
• DoS/DDoS — наводняване с трафик, целящо да изчерпи ресурсите и да свали връзката.
• IP spoofing — пакети с фалшив адрес на подателя, за заобикаляне на правила или за атаки с отражение (reflection/amplification).
• Експлоатация на уязвимости в изложени услуги (стар фърмуер на камери, непачнат сървър) — често от ботнети тип Mirai, които превземат IoT устройства.
• Credential stuffing — масово пробване на изтекли комбинации потребител/парола.

Добрата новина: с MikroTik можем да се предпазим от голяма част от тези атаки — при условие, че устройството е достатъчно мощно (за да поеме инспекцията, без да задушим трафика) и че знаем как да го конфигурираме. Защото MikroTik не идва готов — от кутията с която е купен, той е функционален рутер, но не и защитен когато го включите в контакта.

MikroTik не е „бутон за защита“

Важно е да се разбере едно: MikroTik не е продукт от типа „влизаш през уеб интерфейса, намираш бутон СПАМ, натискаш го и спамът спира“. Тук няма магически бутон „Защити ме“. RouterOS е изключително мощен инструмент, но изисква реални познания по мрежи, защитни стени (firewall) и разбиране на материята. Правилата, които ще видите по-долу, не се „включват“ — те се проектират, подреждат в правилен ред и тестват. Точно затова и в нашия екип имаше дискусии: добрата защита е инженерна работа, а не отметка в чек-лист.

Какво не може никой рутер (легендата за Deep Packet Inspection)

Преди да продължим, важно уточнение, за да няма илюзии: има неща, които не само MikroTik, а никой хардуер не може да направи — защото ако можеше, целият интернет щеше да е компрометиран. Най-разпространеният мит е за „Deep Packet Inspection“ (дълбока инспекция на пакетите) — идеята, че защитната стена „чете“ съдържанието на трафика и хваща заплахите вътре в него.

Проблемът е, че днес почти целият трафик е криптиран: браузвате през HTTPS, изпращате поща през TLS, качвате файл на сървъра си през SFTP. Това е съдържание, което и най-скъпите защитни стени не могат да прочетат — и слава богу, защото ако можеха, това би означавало, че криптирането е счупено и целият интернет е компрометиран. Затова не залагайте на „вълшебна кутия, която вижда всичко“.

Но това не значи, че сме безсилни. Една умна защитна стена не чете съдържанието — тя работи с поведението и метаданните: кой се свързва, откъде, колко често, към кои портове и с какво темпо. Точно това ни позволява да се скрием от света, доколкото е възможно, и да блокираме нападателя, без изобщо да ни трябва да четем какво носи трафикът. Именно това прави конфигурацията по-долу.

И все пак нека изясним: има не един специализиран софтуер за това с възможности в пъти над MikroTik, например Suricata:

Какво вижда Suricata в криптирания HTTPS (TLS) трафик?

Когато трафикът е HTTPS, Suricata не може да прочете самото съдържание (payload) на данните (не вижда пароли, съдържание на страници или свалени файлове). Въпреки това, Suricata извлича метаданни от TLS (Handshake), което протича в чист текст преди криптирането да се задейства: Когато браузърът се свързва с https://e-gov.bg, той изпраща името на домейна в чист текст в полето SNI, за да знае сървърът кой сертификат да върне. Suricata чете това и знае точно кой сайт се посещава. Версия на TLS: Дали се използва стара и уязвима версия (TLS 1.0/1.1) или сигурна (TLS 1.2/1.3). Suricata използва JA3 и JA4 отпечатъци (Fingerprints): Mощен инструмент за засичане на зловреден софтуер. JA3 анализира специфичния начин, по който даден софтуер (браузър, ботнет или малуер) изброява поддържаните от него криптографски алгоритми (Cipher Suites). Зловредният софтуер често има уникален JA3 отпечатък, различен от този на стандартен Chrome или Firefox, което позволява на Suricata да го засече веднага, дори без да декриптира нищо.

IDS и IPS — каква е разликата

Преди да започнем, две понятия, около които се върти всичко:

• IDS (Intrusion Detection System) — пасивна система. Само наблюдава трафика и алармира при проблем, но не го спира. Работи като датчик за дим.
• IPS (Intrusion Prevention System) — активна система. Не само алармира, но и реагира и спира атаката, преди тя да достигне целта си. Работи като автоматична противопожарна система.

В нашата конфигурация имаме и двете: IDS „досие“ на сканиращите + активно IPS блокиране на атакуващите.

Изходна точка и анализ

Рутерът е MikroTik RB5009 с RouterOS 7.23 — типичен офис gateway (4-ядрен ARM, 1 GB RAM). Топологията:

• WAN = ether1 (публичен адрес от доставчика по DHCP);
• LAN = bridge1 (портове ether2–8, мрежа 192.168.1.0/24, DHCP сървър).

Зад рутера има реални услуги, публикувани към интернет чрез port forwarding (NAT): FTP сървър, уеб сървър, DVR/NVR видеонаблюдение и IP камери. Точно тези отворени услуги са най-честата мишена за brute-force и сканиране.

Какво заварихме като защита: почти нищо — елементарен whitelist на input и напълно отворена forward верига. Тоест препращаният трафик минаваше без никаква защита. Това е типичното състояние на „рутер от кутията“.

Архитектура на защитата — слоеве

Преди правилата — две думи как работи защитната стена в RouterOS. Всеки пакет, който пристига от интернет, преминава поетапно през няколко „вериги“ (chains) — подредени набори от правила, които пакетът минава отгоре надолу, докато някое правило не реши съдбата му (пусни или блокирай). Най-важните вериги:

• RAW — най-ранната обработка, преди connection tracking. Тук дроп е най-евтин (идеално за anti-spoofing и ранно отрязване на познати злонамерени адреси).
• INPUT — пакети, насочени към самия рутер (управление, услуги на рутера). Тук решаваме кой има право да достъпва рутера.
• FORWARD — пакети, които минават през рутера от една мрежа към друга (например интернет → камера в LAN, или LAN → интернет). Тук е защитата на мрежата зад рутера.

Така един пакет от интернет първо минава през RAW, после — ако е насочен към устройство зад рутера — през FORWARD; ако е към самия рутер, през INPUT. Изграждаме защитата точно в този ред:

Стъпка 0: Интерфейсни листи и доверени мрежи

За чисти и четими правила дефинираме WAN/LAN листи и списък с доверените мрежи, от които ще е разрешено управлението:

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

# доверени мрежи (заменете с вашите!) — напр. администраторската ви мрежа
/ip firewall address-list add list=accept address=192.168.0.0/16
/ip firewall address-list add list=accept address=203.0.113.0/24

⚠️ Най-важното предупреждение: не се блокирвайте

Ние управлявахме рутера от страната на WAN (отдалечено, през публичния адрес). Това означава, че всяка грешка във firewall-а може да ни отреже достъпа и да наложи физическо посещение. Затова правилото за достъп до управлението винаги трябва да е преди финалния drop, а доверените мрежи трябва да са освободени от IPS банване (за да не се блокираме).

Стъпка 1: INPUT верига (достъп до рутера)

INPUT веригата контролира кой може да достъпва самия рутер. Изграждаме я наново:

/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="01 established,related,untracked"
add chain=input action=drop   connection-state=invalid comment="02 drop invalid"
add chain=input action=drop   src-address-list=blacklist comment="03 drop blacklist (IPS)"
add chain=input action=accept protocol=icmp limit=50/5s,5:packet comment="04 ICMP (rate-limit)"
add chain=input action=accept src-address-list=accept comment="05 достъп само от доверени (ПАЗИ ДОСТЪПА)"
add chain=input action=accept in-interface-list=LAN comment="06 от LAN"
add chain=input action=accept protocol=udp dst-port=68 in-interface-list=WAN comment="06b DHCP клиент на WAN"
add chain=input action=drop comment="07 drop всичко друго"

Правило 05 е това, което пази достъпа ни. Правило 06b е важно: при default-drop рутерът трябва изрично да си позволи DHCP отговорите на WAN, иначе при подновяване на lease може да „загуби“ публичния си адрес.

Стъпка 2: FORWARD верига (трафик през рутера)

Тук е същинската защита на мрежата зад рутера. Преминаваме от „отворено“ към default-drop — разрешено е само това, което е изрично позволено:

/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related comment="F00 fasttrack (скорост)"
add chain=forward action=accept connection-state=established,related,untracked comment="F01 established,related,untracked"
add chain=forward action=drop   connection-state=invalid comment="F02 drop invalid"
add chain=forward action=drop   src-address-list=blacklist comment="F03 drop blacklist (IPS)"
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN comment="F04 LAN към интернет"
add chain=forward action=accept connection-nat-state=dstnat in-interface-list=WAN src-address-list=accept comment="F04b доверените пропускат IPS"
# ... тук идват IPS правилата (Стъпка 3) ...
add chain=forward action=accept connection-state=new connection-nat-state=dstnat in-interface-list=WAN comment="F05 публикуваните услуги (NAT)"
# ... тук идва IDS досието (Стъпка 4) ...
add chain=forward action=drop in-interface-list=WAN comment="F06 drop всичко друго от WAN"

F04b е защитата да не се блокраме: доверените източници, които ползват публикуваните услуги, се пропускат преди IPS детекцията, така че никога не могат да попаднат в blacklist. Ключът connection-nat-state=dstnat елегантно хваща точно трафика, минал през port forwarding — без да трябва да изброяваме всеки порт.

Бонус: камерите само от вашите адреси (ограничаване по източник)

Публикуването на камери/NVR директно към целия интернет е удобно, но рисковано. Често обаче потребителят гледа камерите само от 2–3 места: домашния си интернет и мобилния телефон. И тук има един полезен трик: мобилният оператор сменя вашия IP адрес, но мрежата (диапазонът адреси на оператора) остава същата. Затова можем да направим списък с разрешените източници — домашния ви IP плюс мрежата на мобилния оператор — и да позволим достъп до камерите само оттам:

/ip firewall address-list
add list=camera_allowed address=203.0.113.45   comment="домашен IP адрес"
add list=camera_allowed address=100.64.0.0/10  comment="мрежа на мобилния оператор"

# Dahua NVR на порт 38777 — достъпен само от разрешените адреси
/ip firewall nat
add chain=dstnat action=dst-nat to-addresses=192.168.1.208 to-ports=38777 \
    protocol=tcp in-interface-list=WAN dst-port=38777 src-address-list=camera_allowed

Сега камерите просто не съществуват за останалата част от интернет — ботнетите, които сканират за отворени Dahua/Hikvision портове, не получават никакъв отговор. Това е огромно намаляване на изложеността само с едно поле (src-address-list).

Бележка: whitelist-ването на цялата мобилна мрежа е по-широко (теоретично друг абонат на същия оператор също би могъл да опита), затова услугата зад него все пак трябва да има силна парола. За максимална сигурност най-чистото решение е VPN (WireGuard/IPsec) до рутера и достъп до камерите само през тунела — но за повечето малки обекти описаният подход е отличен баланс между удобство и сигурност а и да прекарвате трафика от камерите през криптиран тунел а малко като да сложите на Ферари квадратни гуми (големите производители на камери имат собствени криптирани протоколи за транзит)

Стъпка 3: IPS — активно блокиране

Brute-force защита — каскада от address-листи

Класическата и много ефективна техника на MikroTik: при всеки нов опит за връзка качваме източника едно ниво нагоре по „стълба“ от списъци. Достигне ли горното ниво за кратко време — отива в blacklist. В примера пазим FTP (порт 21):

/ip firewall filter
add chain=forward action=add-src-to-address-list address-list=blacklist address-list-timeout=1d \
    protocol=tcp dst-port=21 connection-state=new connection-nat-state=dstnat src-address-list=ftp_stage3 \
    log=yes log-prefix="IPS-BAN-FTP" comment="4-ти опит -> БАН 1 ден"
add chain=forward action=add-src-to-address-list address-list=ftp_stage3 address-list-timeout=1m \
    protocol=tcp dst-port=21 connection-state=new connection-nat-state=dstnat src-address-list=ftp_stage2
add chain=forward action=add-src-to-address-list address-list=ftp_stage2 address-list-timeout=1m \
    protocol=tcp dst-port=21 connection-state=new connection-nat-state=dstnat src-address-list=ftp_stage1
add chain=forward action=add-src-to-address-list address-list=ftp_stage1 address-list-timeout=1m \
    protocol=tcp dst-port=21 connection-state=new connection-nat-state=dstnat

Резултат: IP, което направи 4 нови връзки към FTP в рамките на минута, се блокира за 1 ден. Легитимните потребители не достигат този праг.

Същата техника важи за всяка услуга, не само за FTP. Достатъчно е да смените порта (и при нужда прага): по абсолютно същия начин защитавате SSH, HTTPS, RDP, пощенски услуги, уеб панели на камери/NVR и т.н. Принципът е универсален — следим темпото на новите връзки и банваме този, който прехвърли разумна граница.

Anti-DDoS / flood guard

Един източник, който отвори твърде много едновременни връзки към публикуваните услуги, очевидно не е нормален клиент — банваме го:

add chain=forward action=add-src-to-address-list address-list=blacklist address-list-timeout=1d \
    protocol=tcp connection-nat-state=dstnat connection-limit=100,32 in-interface-list=WAN \
    log=yes log-prefix="IPS-BAN-FLOOD" comment="над 100 връзки/IP -> БАН"

Важно ограничение: тази защита има предел. Колкото и мощен да е рутерът, ако флудът премине от един пакет към хиляди или милиони пакети в секунда (което е напълно възможно при сериозна DDoS атака), нито един клиентски рутер няма да го поеме — самият канал към вас се запушва, преди трафикът изобщо да стигне до рутера. В такъв случай единственото решение е да се обърнете към вашия интернет доставчик (който може да филтрира или blackhole-не атаката нагоре по веригата) и да докладвате инцидента там, където е необходимо. Рутерът защитава от ежедневния шум и средните по обем атаки — той не замества DDoS защитата на оператора.

Стъпка 4: IDS — досие на сканиращите (+ ескалация)

Всичко, което достигне до финалния drop от WAN, е непоискан трафик — на практика сканиране. Записваме тези източници в „досие“ (пасивно наблюдение). А ако някой се появи повторно, го ескалираме до активен бан:

# ескалация: повтарящ се скенер -> БАН (преди досието)
add chain=forward action=add-src-to-address-list address-list=blacklist address-list-timeout=1d \
    protocol=tcp connection-state=new in-interface-list=WAN src-address-list=wan_scanners \
    log=yes log-prefix="IPS-BAN-SCAN" comment="повтарящ се скенер -> БАН"

# досие: първо засичане -> записваме (1 час), без доверените
add chain=forward action=add-src-to-address-list address-list=wan_scanners address-list-timeout=1h \
    protocol=tcp connection-state=new in-interface-list=WAN src-address-list=!accept comment="IDS досие"

Така единичен случаен пакет само се записва, а упоритият скенер бива блокиран. Това е точно връзката IDS → IPS: наблюдение, което при нужда преминава в действие.

Стъпка 5: RAW — anti-spoofing и anti-DDoS на ниско ниво

RAW таблицата се обработва преди connection tracking. Дроп тук е по-евтин откъм ресурси и по-устойчив на DDoS, защото баннатите пакети изобщо не натоварват conntrack.

# списък с bogon (непублични) адреси
/ip firewall address-list
add list=bogons address=0.0.0.0/8
add list=bogons address=10.0.0.0/8
add list=bogons address=127.0.0.0/8
add list=bogons address=169.254.0.0/16
add list=bogons address=172.16.0.0/12
add list=bogons address=192.168.0.0/16
add list=bogons address=224.0.0.0/4
add list=bogons address=240.0.0.0/4

/ip firewall raw
add chain=prerouting action=accept protocol=udp dst-port=67,68 in-interface-list=WAN comment="DHCP (преди anti-spoof)"
add chain=prerouting action=drop  src-address-list=blacklist in-interface-list=WAN comment="ранен дроп на баннатите"
add chain=prerouting action=drop  src-address-list=bogons    in-interface-list=WAN comment="anti-spoofing"

Anti-spoofing-ът дропва пакетите, които идват от WAN с частен/невалиден source адрес — такива никога не идват легитимно от интернет и почти винаги са спуфнати. В нашия случай това правило започна да лови спуфнати пакети още в първите минути.

Стъпка 6: Аларма (IDS логване)

Не логваме всеки пакет (това би заляло лога). Логваме само самото събитие „бан“ — нискообемна, смислена аларма. Освен в паметта, можем да насочим тези събития и към отделен дисков лог, който оцелява и след рестарт (трайно досие на атаките) — но в повечето случаи това не е нужно, защото това е рутер, а не файлов или база-данни сървър:

/system logging action add name=ipsalarm target=disk disk-file-name=ips-alarm disk-lines-per-file=2000 disk-file-count=4
/system logging add topics=firewall action=ipsalarm

Как да четем лога

След като алармите работят, ето как да ги преглеждаме и какво да търсим:

# всички бан-събития (IPS алармите)
/log print where message~"IPS-BAN"

# на живо — следим в реално време
/log print follow where message~"IPS-BAN"

# текущо блокираните адреси
/ip firewall address-list print where list=blacklist

# досието на сканиращите (още не баннати)
/ip firewall address-list print where list=wan_scanners

# колко са блокираните в момента
:put [:len [/ip firewall address-list find list=blacklist]]

Какво да гледаме в записите:

• Префиксът показва кое правило е сработило: IPS-BAN-FTP (brute-force), IPS-BAN-FLOOD (flood/DDoS), IPS-BAN-SCAN (упорит скенер).
• Адресът на източника — кой е атакуващият. Ако виждате много адреси от един и същ диапазон, помислете за бан на цялата подмрежа.
• Честотата — рязък скок на бановете може да е признак за насочена атака (тогава погледнете и към доставчика).
• Фалшиви положителни — ако легитимен ваш адрес попадне в списъка, добавете го към доверените (accept), за да го изключите занапред.

Полезни уроци от практиката

• Не банвайте собствените си доверени мрежи. Тъй като drop blacklist стои преди правилото за достъп, едно самозаключване = отрязан достъп. Решението е доверените да пропускат IPS детекцията (правило F04b).
• device-mode. На по-новите RouterOS устройства режимът device-mode може да блокира scheduler и fetch. Това означава, че автоматичното изтегляне на външни blacklist списъци по график няма да работи, докато не смените device-mode (изисква физическо потвърждение с рестарт). IPS чрез address-листи работи и без това.
• „Невалидни“ правила за миг. Новодобавено правило в RouterOS често се показва с флаг I (invalid) за секунда, докато firewall-ът се прекомпилира — после става активно. Не се плашете.
• Тествайте достъпа в нова сесия, а не само в текущата (която е „established“ и оцелява). Така хващате грешка, преди да е станала фатална.

Какво още може да се направи (но за повечето офиси е малко прекалено)

Конфигурацията по-горе е напълно достатъчна за реален офис. За по-високо ниво на сигурност може да се добави и:

• Централизирано известяване (SIEM): изпращане на алармите към външен syslog/мониторинг сървър за известяване в реално време (по-добре през VPN, тъй като syslog е некриптиран). Отделен syslog daemon изобщо не е труден за инсталиране — например на Ubuntu server — но е малко безсмислен, ако имате само един рутер: просто местите лога от рутера на сървъра. Съвсем друг е сценарият, ако имате, да речем, 3 рутера и 2 сървъра — тогава единен syslog веднага би показал кое е слабото място в мрежата.
• Външни blacklist feed-ове (DShield, Spamhaus DROP, Team Cymru bogons): автоматично обновяван списък с известни злонамерени мрежи. Конфигурират се много лесно в MikroTik — както с прост скрипт, който ги изтегля и блокира, така и чрез отделен Linux сървър, който генерира много по-сложен списък с готови за изпълнение команди. Проблемът е, че тези листи са предназначени за „другия свят“: нападателите от Китай и Северна Корея са известни на всички и ги има в списъците, но нападателят от някоя мрежа в българското интернет пространство го няма в нито една листа. Затова е добре да разчитаме преди всичко на собствената си защита (като описаната по-горе), не само на чужди списъци.
• Истински сигнатурен IDS (Suricata / Zeek) на отделна машина, към която рутерът клонира (не е най правилната дума) трафика (port mirroring): MikroTik няма вграден сигнатурен анализ. За малък офис обаче това е по-скоро излишен ресурс — ние вече имаме защита (рязък скок на трафика блокираме още на публичния адрес), а устройствата ни са зад рутера с частни адреси, които светът изобщо не вижда. На нас не ни трябва дълбок анализ — трябва ни защита, която вече сме осигурили. Сериозен сигнатурен анализ (какъвто Suricata предоставя отлично) има смисъл, когато имате много публични адреси и услуги, видими за целия свят. Но нашата идея тук е точно обратната — да се скрием, а не да дадем достъп да ни анализират.
• IPv6 firewall: ако се ползва IPv6, той има нужда от собствен набор правила — атакуващите все по-често търсят забравената IPv6 страна, а атаките през IPv6 чувствително зачестяват. За съжаление, големите доставчици се опитват да доставят IPv6 до клиентите си, но често по доста неудачен начин: при всеки рестарт на рутера клиентът получава съвсем нова мрежа (префикс). Така дори да създадете правила в защитната стена, на следващия рестарт те може вече да не важат — нещо, което задължително трябва да се има предвид.
• Втвърдяване на управлението: SSH само с ключове и силни алгоритми, смяна на портовете по подразбиране, изключване на неизползваните услуги (API, Winbox от WAN и т.н.) — и преди всичко силни пароли. Колкото и да отегчава и колкото и да не ви се иска, това е най-голямата защита. И една добра новина за нас: българският език е предимство. Парола като @Towa$moyata%parola_ в реалния свят на практика може да бъде разбита единствено от квантов компютър — комбинацията от смисъл на кирилица, изписан на латиница, символи и дължина я прави практически непробиваема за обичайните речникови и brute-force атаки.
• Сегментация с VLAN-и: отделяне на камерите, гостите и работните станции в различни мрежи, така че компрометиран IoT уред да не вижда останалите. Тук обаче внимавайте — една от честите грешки на администраторите е прекаленото „виланизиране“ на мрежата, което понякога води до… „маратонковата система“ (шега, разбира се): когато служител в един VLAN не вижда колегата си в друг, той просто взима флашка (често пълна с вируси) и я разнася на ръка по всички компютри. В малки мрежи — до един сегмент — златната среда често е порт изолация на Layer 2, с DHCP и IGMP snooping, евентуално + storm control и loop protection. Но тези теми вече са от защитата на самата локална мрежа (LAN) и са извън обхвата на тази статия.

Тези мерки повишават сигурността още, но за типичен малък и среден бизнес описаната по-горе конфигурация дава отличен баланс между защита, производителност и поддръжка.

Заключение

С няколко добре подредени слоя правила превърнахме обикновен MikroTik рутер в сериозно защитена входна точка: IPS (активно блокиране на brute-force, flood и упорити скенери), IDS (досие на сканиращите + аларми), blacklist, anti-spoofing и anti-DDoS на RAW ниво — без допълнителен хардуер и без да жертваме производителността (NAT и публикуваните услуги останаха непокътнати).