Mi történt
A lengyel CERT szeptember 5-én figyelmeztetést adott ki: MikroTik RouterOS eszközöket aktívan támadnak. A támadás lényege, hogy ha a router SSH szolgáltatása elérhető az internet felől, a támadó hitelesítés nélkül teljes adminisztrátori hozzáférést szerez az eszközön. A megfigyelt támadások legalább szeptember 2-ig nyúlnak vissza.
A CERT két hiba láncolatáról ír, amit MikroTrick néven emlegetnek. Azt nem hozták nyilvánosságra, pontosan melyik két sérülékenységről van szó, és azt sem lehet a nyilvános adatokból eldönteni, hogy volt-e már javítás a támadások kezdete előtt. Ez a gyakorlat szempontjából mindegy: a javítás létezik, a támadás fut, a döntés innentől időzítés kérdése.
Áldozatszámot és támadói csoportot senki nem közölt.
Miért érint ez téged
MikroTik routerből rengeteg van magyar kis- és középvállalkozásoknál. Olcsó, jól bírja, sokat tud, ezért sok helyen ez az internetes végpont: ezen fut a tűzfal, a NAT, a VPN, sokszor a VLAN-ok közti forgalomirányítás is.
Ha ez az eszköz kerül idegen kézbe, akkor nem "egy eszköz" veszett el. A támadó a teljes hálózati forgalmat látja és átirányíthatja, VPN-t nyithat magának a belső hálózatba, DNS-t hamisíthat, tükrözheti a forgalmat, és tartós hátsó kaput építhet script vagy scheduler formájában. A végpontvédelem és a levelezés kétfaktoros hitelesítése ilyenkor keveset ér, mert a támadó a hálózat alatt ül.
A gyártó alapértelmezett tűzfalszabályai a lakossági eszközökön blokkolják a menedzsment portok internet felőli elérését. A gond ott van, ahol ezt valaki évekkel ezelőtt átírta, hogy "csak gyorsan ránézzek távolról", és úgy is maradt. Ez a leggyakoribb eset, amit a gyakorlatban látok.
Mit kell tenni, ebben a sorrendben
1. Frissítsd a RouterOS-t még ma
A javított verziók:
| Érintett tartomány | Első javított kiadás | Amit telepíts |
|---|---|---|
| 6.0.0 és 6.49.21 között | 6.49.21 | RouterOS 6 biztonsági kiadás |
| 7.0.0 és 7.23.4 között | 7.23.4 | 7.23.5 a long-term csatornán |
| 7.24 és 7.24.2 között | 7.24.2 | stable csatorna biztonsági kiadás |
| fejlesztői ág | 7.25beta3 | development csatorna |
Long-term ágon konkrétan a 7.23.5 kell, ne a 7.23.4. A 7.23.4 behozott egy IPv6 DHCP hibát, amit a 7.23.5 javít úgy, hogy a biztonsági javítás benne marad.
A firmware-t mindig a MikroTik hivatalos letöltési oldaláról szedd le, ne kereső első találatából.
2. Amíg nem tudsz frissíteni, zárd le a felületeket
Kapcsold ki, vagy korlátozd megbízható menedzsment hálózatra ezeket:
- SSH (22/tcp)
- WWW és WWW-SSL (a webes felület)
- bandwidth-test
Konkrétan: az IP > Services alatt állítsd be az Available From mezőt a saját menedzsment tartományodra, és a tűzfalon is dobd el a WAN felől érkező menedzsment forgalmat. Ne csak portot cserélj. A port átrakása 2222-re nem védelem, csak lassítja a szkennert néhány perccel.
Amíg az eszköz nem frissített, ne indíts róla TLS kapcsolatot és ne használd a RouterOS beépített SSH kliensét. Ez a korlátozás a hibacsoport többi elemére vonatkozik, és nem helyettesíti a frissítést.
3. Frissítés után ellenőrizd, nem jártak-e már bent
Ez az a lépés, amit a legtöbben kihagynak. A frissítés megállítja a következő támadót, de nem takarítja el azt, aki már ott volt.
Nézd át:
- A device-mode állapotot. A RouterOS induláskor ellenőrzi a konfigurációt, és gyanús beállítás esetén Flagged állapotba teszi az eszközt, letiltva az érintett elemeket. Fusson le a
/system/device-mode/print, és nézd meg az eredményt. - A felhasználókat. Van-e olyan fiók, amit nem te hoztál létre, főleg magas jogosultsággal.
- A naplót. A CERT szerint árulkodó jel, ha egy fióklétrehozási bejegyzésben
ssh:-2@szerepel. - A konfigurációt. Ismeretlen script, scheduler, netwatch, új VPN felhasználó, idegen NAT szabály, módosított DNS beállítás, forgalomtükrözés.
Fontos: akkor is nézd át ezeket, ha az eszköz nem került Flagged állapotba. A figyelmeztetés hiánya nem bizonyíték.
4. Ha kompromittálódott, ne kezdj el javítgatni
Ha a napló, a konfiguráció vagy a Flagged státusz kompromittálódásra utal:
- Válaszd le az eszközt a hálózatról, és mentsd ki a naplót és a konfigurációt, mielőtt bármit resetelnél. A Flagged státuszt ne töröld, amíg a bizonyítékokat el nem mentetted és az elemzés nem zárult le.
- Gyári visszaállítás, majd újraépítés ellenőrzött, megbízható konfigurációból. Ne töltsd vissza vakon a teljes mentést a fertőzött eszközről, mert azzal a hátsó kaput is visszahozod.
- Cserélj minden jelszót és kulcsot, ami az eszközön volt vagy rajta keresztül ment: admin jelszavak, VPN kulcsok, RADIUS titkok, API kulcsok, wifi jelszavak.
Amit ebből érdemes tanulni
Ez a hét minden évben eljön, csak más gyártó nevével. Az igazi kérdés nem az, hogy MikroTik-ed van-e, hanem az, hogy tudod-e fejből megválaszolni ezt a három kérdést:
- Melyik eszközöd elérhető az internet felől, és pontosan milyen szolgáltatással?
- Melyik eszközön milyen firmware verzió fut most?
- Ha holnap kijön egy kritikus javítás, mennyi idő alatt van felrakva mindenhol?
Ha ezekre nincs kész válaszod, akkor nem a MikroTik a probléma, hanem az, hogy nincs eszközleltár és nincs frissítési folyamat. A javítás egy óra munka. A leltár hiánya viszont minden ilyen hírnél újra megkérdőjelezi, hogy a cég hálózata biztonságos-e.
Segítek átnézni. Ha Békés megyében vagy a környéken üzemeltetsz MikroTik alapú hálózatot, és nem vagy biztos benne, hogy mi látszik ki az internetre, egy IT biztonsági felmérés pontosan ezt méri fel: kitett szolgáltatások, firmware állapot, konfigurációs kockázatok, írásos riporttal és javítási prioritásokkal.
Forrás: CERT Polska figyelmeztetés (2026. szeptember 5.), MikroTik biztonsági közlemény, The Hacker News.