Egyszerű módja a Mikrotik védelmének támadások ellen.

Szeretném megosztani a közösséggel egy egyszerű és működő módszert, amellyel a Mikrotik segítségével megvédhetjük a hálózatunkat és az azt használó szolgáltatásokat a külső támadásoktól. Nevezetesen mindössze három szabállyal létrehozhatunk egy honeypot-ot a Mikrotik-en.

Tegyük fel, hogy van egy kis irodánk, ahol egy RDP szerver található a külső IP mögött, hogy a munkavállalók távolról dolgozhassanak. Az első szabály természetesen az, hogy változtassuk meg a 3389-es portot a külső interfészen egy másikra. De ez nem tart sokáig, pár nap múlva a terminálszerver audit naplója elkezd mutatni néhány sikertelen bejelentkezést másodpercenként ismeretlen kliensektől.

Egy másik helyzet, amikor a Mikrotik mögött egy asterisk bújik meg, természetesen nem a 5060-as udp porton, és pár nap múlva már kezdődik a jelszavak feltörése... igen, tudom, hogy a fail2ban a megoldásunk, de azon is még dolgozni kell... például nemrégiben telepítettem az Ubuntu 18.04-re, és meglepetésemre felfedeztem, hogy a fail2ban alapból nem tartalmaz aktuális beállításokat az asterisk-hez ugyanarról az Ubuntu disztról... és nem tudok gyors beállításokat keresni a kész "receptekhez", mert az új verziók számai egyre nőnek az évek múlásával, míg a régi verziókhoz írt cikkek már nem működnek, és az újabbak alig bukkannak fel... De elkalandoztam...

Tehát, mi az a honeypot röviden — ez egy csali, a mi esetünkben egy népszerű port a külső IP-n, bármilyen kérés erre a portra a külső kliens részéről automatikusan a forrás IP-t fekete listára küldi. Ennyi.

/ip firewall filter
add action=add-src-to-address-list address-list="Honeypot Hacker" 
    address-list-timeout=30d0h0m chain=input comment="block honeypot ssh rdp winbox" 
    connection-state=new dst-port=22,3389,8291 in-interface=
    ether4-wan protocol=tcp
add action=add-src-to-address-list address-list="Honeypot Hacker" 
    address-list-timeout=30d0h0m chain=input comment=
    "block honeypot asterisk" connection-state=new dst-port=5060 
    in-interface=ether4-wan protocol=udp 
/ip firewall raw
add action=drop chain=prerouting in-interface=ether4-wan src-address-list=
    "Honeypot Hacker"

Az első szabály a népszerű TCP portok 22, 3389, 8291 esetén az ether4-wan külső interfészen a "vendég" IP-jét a "Honeypot Hacker" listára küldi (a ssh, rdp és winbox portokat előre letiltottuk vagy másokra változtattuk). A második szabály ugyanezt teszi a népszerű UDP 5060-as porton is.

A harmadik szabály a pre-routing szakaszban eldobja azokat a "vendég" csomagokat, akiknek a forrás címe a "Honeypot Hacker" listára került.

Két hét otthoni Mikrotikom működése után a "Honeypot Hacker" lista körülbelül másfél ezer IP címet tartalmazott, akik szerették volna "megszorongatni" a hálózati erőforrásaimat (otthon saját telefonálás, e-mail, nextcloud, rdp található). A brute-force támadások megszűntek, eljött a boldogság.

A munkahelyen nem minden olyan egyszerű, ott az rdp szervert továbbra is támadják a jelszavak feltörése révén.

Úgy tűnik, hogy a port számát a szkenner már régóta észlelte a honeypot bekapcsolása előtt, és a karantén alatt nem volt olyan egyszerű átkonfigurálni több mint 100 felhasználót, akiknek 20%-a 65 év felett van. Ha a portot nem lehet megváltoztatni, van egy kis működő recept. Hasonlót láttam az interneten, de itt van egy kis finomhangolás:

Port Knocking beállítási szabályok

 /ip firewall filter
add action=add-src-to-address-list address-list=rdp_blacklist 
    address-list-timeout=15m chain=forward comment=rdp_to_blacklist 
    connection-state=new dst-port=3389 protocol=tcp src-address-list=
    rdp_stage12
add action=add-src-to-address-list address-list=rdp_stage12 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage11
add action=add-src-to-address-list address-list=rdp_stage11 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage10
add action=add-src-to-address-list address-list=rdp_stage10 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage9
add action=add-src-to-address-list address-list=rdp_stage9 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage8
add action=add-src-to-address-list address-list=rdp_stage8 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage7 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage6
add action=add-src-to-address-list address-list=rdp_stage6 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage5
add action=add-src-to-address-list address-list=rdp_stage5 
    address-list-timeout=4m chain=forward connection-state=new dst-port=
    3389 protocol=tcp src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage4 
    address-list-timeout=4m chain=forward connection-state=new dst-port=
    3389 protocol=tcp src-address-list=rdp_stage3
add action=add-src-to-address-list address-list=rdp_stage3 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage2
add action=add-src-to-address-list address-list=rdp_stage2 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage1
add action=add-src-to-address-list address-list=rdp_stage1 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp 
/ip firewall raw
add action=drop chain=prerouting in-interface=ether4-wan src-address-list=
rdp_blacklist

4 perc alatt a távoli kliensnek csak 12 új 'kérést' engedélyeznek az RDP-hez. szerverhez. Egy bejelentkezési kísérlet 1-4 'kérést' jelent. A 12. 'kérés' esetén 15 perces tilalom lép életbe. Az én esetemben a támadók nem hagyták abba a szerver feltörését, alkalmazkodtak az időzítőkhöz, és most nagyon lassan csinálják, ez a sebesség gyakorlatilag nullára csökkenti a támadás hatékonyságát. A vállalat munkatársai az elfogadott intézkedésektől gyakorlatilag nem szenvednek kényelmetlenséget a munkájuk során.

Még egy kis trükk
Ez a szabály időzítve van éjfélkor bekapcsolva és 5 órakor kikapcsolva, amikor az élő emberek biztosan alszanak, míg az automatizált keresők tovább ébren vannak.

/ip firewall filter 
add action=add-src-to-address-list address-list=rdp_blacklist 
    address-list-timeout=1w0d0h0m chain=forward comment=
    "night_rdp_blacklist" connection-state=new disabled=
    yes dst-port=3389 protocol=tcp src-address-list=rdp_stage8

Már a 8. kapcsolódáskor a támadó IP-jét egy hétre feketelistára helyezik. Szépség!

A fent említetthez még annyit fűznék hozzá, hogy itt van egy link a Wiki cikkhez, a Mikrotik védelmi beállításairól a hálózati szkennerekkel szemben. wiki.mikrotik.com/wiki/Drop_port_scanners

Az én eszközeimen ez a beállítás a fent leírt honeypot szabályokkal együtt működik, jól kiegészítve őket.

UPD: Ahogy a kommentekben jelezték, a csomagok eldobásának szabályát a RAW-ba helyezték, hogy csökkentsék a router terhelését.

Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster