13.07.2026 · Самуил Арсов · MikroTik, Киберсигурност, Рутери

Валиден SSL сертификат за MikroTik с Let’s Encrypt и защита на портовете срещу brute-force

Управлението на MikroTik рутер през браузър (WebFig) по подразбиране става със самоподписан сертификат — браузърът показва предупреждение „връзката не е сигурна“, а трафикът, макар и криптиран, не е удостоверен. В тази статия ще покажем как да насочим домейн към рутера, да издадем безплатен валиден сертификат от Let’s Encrypt директно от RouterOS, и — най-важното — как да оставим портове 80 и 443 отворени към интернет, но защитени с автоматичен firewall, който банва всеки, който се опитва да разбива паролата, докато ние си влизаме спокойно.

Примерите са направени на MikroTik L009UiGS с RouterOS 7, но важат за всеки RouterOS 7 модел. За домейн ще ползваме router1.itservice-bg.net.

Какво ни трябва

MikroTik с RouterOS 7.x (вградената поддръжка на Let’s Encrypt е от версия 7.x нагоре)
Публичен IP адрес на WAN интерфейса на рутера (или port-forward на 80/443, ако е зад NAT)
Достъп до DNS зоната на домейна, за да добавим запис
Точен часовник на рутера (NTP) — сертификатите са валидни в конкретен времеви прозорец

Стъпка 1: Насочваме домейна (DNS A запис)

Първо създаваме A запис, който сочи името към публичния IP на рутера. В DNS управлението на зоната добавяме:

router1    IN    A    <публичния-IP-на-рутера>

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

dig +short router1.itservice-bg.net
# трябва да върне публичния IP на рутера

Важно: Let’s Encrypt проверява собствеността чрез т.нар. HTTP-01 challenge — свързва се към http://router1.itservice-bg.net на порт 80. Затова името задължително трябва да сочи публично към рутера, а порт 80 да е достъпен от интернет в момента на издаване (и после при подновяване).

Ако рутерът е зад NAT, направете port-forward на TCP 80 (и 443) към вътрешния му адрес.

Стъпка 2: Проверяваме часовника и услугите

Точното време е задължително. Уверяваме се, че NTP клиентът работи:

/system ntp client set enabled=yes
/system ntp client servers add address=time.cloudflare.com
/system clock print

Проверяваме, че уеб услугите са включени:

/ip service print

Трябва www (порт 80) и www-ssl (порт 443) да са активни (без флаг X).

Стъпка 3: Издаваме сертификата от Let’s Encrypt

RouterOS 7 има вградена ACME/Let’s Encrypt поддръжка — една команда прави всичко: генерира ключ, минава challenge-а, изтегля сертификата и го закача към HTTPS услугата.

/certificate enable-ssl-certificate dns-name=router1.itservice-bg.net

Какво прави тази команда автоматично:

Пуска временно вътрешен уеб отговор на порт 80 за HTTP-01 challenge-а
Заявява сертификат от Let’s Encrypt за router1.itservice-bg.net
Импортира издадения сертификат в /certificate
Присвоява го на услугата www-ssl (HTTPS WebFig)
Настройва автоматично подновяване преди изтичане

Проверяваме резултата:

/certificate print

Трябва да видим издаден сертификат с издател Let’s Encrypt и флагове KAT, примерно:

Flags: K - PRIVATE-KEY; A - AUTHORITY; T - TRUSTED
 #      NAME                             COMMON-NAME
 0 KAT  router1.itservice-bg.net_...     router1.itservice-bg.net

И проверяваме, че е закачен към HTTPS услугата:

/ip service print detail where name=www-ssl

Готово — вече отваряме https://router1.itservice-bg.net в браузъра и виждаме валиден сертификат без предупреждения.

Съвет: След като HTTPS работи, можете да изключите чистия HTTP WebFig (/ip service disable www), за да не се влиза без криптиране. Но оставете firewall-а да пропуска порт 80 — Let’s Encrypt се нуждае от него при автоматичното подновяване на всеки ~60 дни.

Стъпка 4: Оставяме портовете отворени — но защитени

Ето същината. За да работи Let’s Encrypt (порт 80) и за да достъпваме WebFig от интернет (порт 443), тези портове стоят отворени. Но отворен порт към интернет = постоянни автоматизирани атаки, които пробват пароли (brute-force).

Решението в MikroTik е елегантно: staged address-lists. Firewall-ът брои новите връзки от всеки адрес и след определен брой опити за кратко време го добавя в черен списък и го блокира — напълно автоматично. Управляващите ни мрежи слагаме в бял списък, за да не бъдат никога засегнати.

4.1 Бял списък (whitelist) на доверените мрежи

Първо описваме адресите, на които се доверяваме — нашите офисни/управляващи мрежи и локалната мрежа. Те никога няма да бъдат брояни или банвани:

/ip firewall address-list
add list=accept address=192.168.0.0/16   comment="LAN"
add list=accept address=203.0.113.0/24   comment="управление - офис 1"
add list=accept address=198.51.100.0/24  comment="управление - офис 2"
# ... добавете вашите реални публични управляващи диапазони

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

4.2 Правилата за brute-force защита

Добавяме четири правила във веригата input, преди правилото, което приема портовете. Логиката: всяка нова връзка от адрес извън белия списък минава stage1 → stage2, а на 3-тия опит влиза в черния списък и се блокира за 1 час.

/ip firewall filter

# 1) Който вече е в черния списък — блокирай и логвай
add chain=input action=drop protocol=tcp dst-port=80,443,8291 \
    src-address-list=brute_blacklist \
    log=yes log-prefix="BRUTE-DROP" \
    comment="brute: drop blacklisted"

# 2) 3-ти опит (вече е в stage2) -> в черния списък за 1 час + лог
add chain=input action=add-src-to-address-list connection-state=new \
    protocol=tcp dst-port=80,443,8291 \
    src-address-list=brute_stage2 \
    address-list=brute_blacklist address-list-timeout=1h \
    log=yes log-prefix="BRUTE-BAN" \
    comment="brute: 3rd attempt -> blacklist 1h"

# 3) 2-ри опит (в stage1) -> премести в stage2
add chain=input action=add-src-to-address-list connection-state=new \
    protocol=tcp dst-port=80,443,8291 \
    src-address-list=brute_stage1 \
    address-list=brute_stage2 address-list-timeout=1m \
    comment="brute: stage1 -> stage2"

# 4) 1-ви опит от адрес ИЗВЪН белия списък -> в stage1
add chain=input action=add-src-to-address-list connection-state=new \
    protocol=tcp dst-port=80,443,8291 \
    src-address-list=!accept \
    address-list=brute_stage1 address-list-timeout=1m \
    comment="brute: new conn -> stage1 (skip whitelist)"

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

add chain=input action=accept protocol=tcp dst-port=80,443,8291

Ако вече имате такова accept правило, вмъкнете горните преди него с place-before=[find dst-port="80,443,8291" action=accept].

Защо това работи — механизмът стъпка по стъпка

Ключът е в реда на правилата и в това, че add-src-to-address-list е passthrough (пропуска пакета нататък). Проследяваме един атакуващ:

Опит	Състояние преди	Кое правило хваща	Резултат
1-ва връзка	в нито един списък	#4 (`!accept`)	→ влиза в `brute_stage1`
2-ра връзка	в `stage1`	#3	→ влиза в `brute_stage2`
3-та връзка	в `stage1+stage2`	#2	→ бан в `brute_blacklist` за 1 час
4-та+ връзка	в `brute_blacklist`	#1	→ DROP + лог

Понеже правилата за по-високите stage-ове стоят над тези за по-ниските, един пакет не може да „прескочи“ няколко нива наведнъж — движи се точно с една стъпка на връзка. Броячът се нулира след 1 минута без опити (address-list-timeout=1m), така че случаен потребител няма да бъде наказан за няколко бързи презареждания, а системна атака се хваща веднага.

Понеже правило #4 съдържа src-address-list=!accept, нашите доверени мрежи изобщо не влизат в брояча — влизаме си спокойно с валидния сертификат по всяко време.

Стъпка 5: Наблюдение и поддръжка

Виж кой е блокиран в момента:

/ip firewall address-list print where list=brute_blacklist

Виж логовете от защитата:

/log print where message~"BRUTE"

Ръчно освобождаване на адрес (ако е сбъркан легитимен потребител):

/ip firewall address-list remove [find list=brute_blacklist address=1.2.3.4]

Проверка на сертификата и подновяването — RouterOS подновява автоматично:

/certificate print detail where common-name=router1.itservice-bg.net

Няколко важни съвета за сигурност

Оставете SSH на нестандартен порт извън защитените (напр. 2222) и извън brute-листа — така винаги имате авариен достъп за възстановяване, дори WebFig да е блокиран.
Сменете администраторската парола със силна и по възможност преименувайте потребителя admin.
HTTP challenge порт 80 трябва да остане отворен (макар и защитен) — иначе автоматичното подновяване на сертификата ще се провали.
Ограничете WebFig/Winbox допълнително чрез Available From в /ip service, ако достъпвате само от фиксирани адреси.
Тествайте банването с адрес извън белия списък, преди да разчитате на защитата в продукция.

Заключение

С една команда (enable-ssl-certificate) RouterOS 7 ни дава безплатен, автоматично подновяван сертификат от Let’s Encrypt, а с няколко firewall правила превръщаме отворените портове 80 и 443 от риск в контролирана, самозащитаваща се услуга. Атакуващите се банват на третия опит, а ние си управляваме рутера през браузър с валиден сертификат — сигурно и удобно.