Véd-e a Windows tűzfal az RDP brute force ellen?

Egy gyakori feltételezés Windows-adminisztrátorok körében így hangzik: a Windows tűzfal be van kapcsolva, az RDP elérhető a TCP 3389-es porton, és ez elég. Nem az. A Windows tűzfal az OSI 3. és 4. rétegén szűr — azt dönti el, hogy egy csomag elérheti-e az adott portot. Amint egy TCP-kapcsolat átjut a 3389-re, a tűzfal kilép a képből. Az ezt követő autentikációs kézfogás — az a rész, ahol a támadó megpróbálja az Administrator fiókot Password123 jelszóval, majd Password1234-gyel, majd még tízezerszer — a tűzfal látómezején kívül zajlik.

Ebben a résben él az RDP brute force támadás. Ha üzemeltetsz egy Windows Servert nyílt RDP-vel, ez a cikk pontosan megmutatja, mit csinál a beépített tűzfal, mit nem lát, és mit kell hozzátenni ahhoz, hogy az ismételt bejelentkezési kísérletek tényleg leálljanak.

Mit csinál valójában a Windows tűzfal az RDP esetében?

A Windows Defender tűzfal egy állapot-követő (stateful) csomagszűrő. A Microsoft hivatalos leírása szerint forrás-IP, cél-IP, port és protokoll alapján vizsgálja a csomagokat, és szabályok alapján dönt arról, hogy átengedi vagy blokkolja őket. RDP esetében a releváns szabály szinte mindig: "TCP 3389 bejövő engedélyezve."

Ez hasznos. Azt jelenti, hogy:

• Az RDP-t korlátozhatod egy adott forrás-IP-tartományra, például az iroda statikus publikus IP-jére.
• Az internet felé néző interfészen teljesen blokkolhatod a 3389-et, miközben egy menedzsment VLAN-on nyitva tartod.
• Kombinálhatod a szabályokat a Publikus, Privát és Tartomány hálózati profilokkal, így egy laptop, amely egy kávézó Wi-Fi-jére csatlakozik, automatikusan szigorít.

Ha a csapatod egyetlen statikus IP-ről dolgozik, ez az IP-alapú korlátozás valóban erős védelem. A támadó még a bejelentkező képernyőt sem éri el. A baj az, hogy a legtöbb valós környezet nem így néz ki — az adminok otthonról, mobilhálózatról, ügyfelek irodájából dolgoznak. A forrás-IP-szűrés gyakorlatilag kivitelezhetetlen, ha a forrás folyamatosan változik.

Így a gyakorlatban a 3389-es port széles tartomány felé, vagy a teljes internet felé nyitva marad. Abban a pillanatban, ahogy ez megtörténik, a tűzfal feladata véget ér. Minden, ami ezután következik — felhasználónevek, jelszavak, fiókzárolások, audit naplók — egy olyan rétegben történik, amit a tűzfal nem olvas.

Megvéd-e a Windows tűzfal a brute force támadások ellen?

Nem. Ezt a tévedést érdemes egyértelműen tisztázni.

Egy RDP elleni brute force támadás nem hálózati szintű hibát akar kihasználni. Megnyit egy teljesen szabályos TCP-kapcsolatot a 3389-re, befejezi a kézfogást, és elkezdi az alkalmazási rétegen találgatni a hitelesítő adatokat. A tűzfal szemszögéből ez ugyanúgy néz ki, mint egy normál felhasználói bejelentkezés. Ugyanaz a port. Ugyanaz a protokoll. Ugyanolyan csomagok.

Minden sikertelen bejelentkezés egy Event ID 4625 bejegyzést hoz létre a Windows biztonsági eseménynaplójában. Pontosan ez az a jel, amire reagálni szeretnél — egyetlen IP, ami percek alatt több tucat vagy több száz 4625-öt termel, egy folyamatban lévő brute force kísérlet. De a Windows tűzfal nem olvassa az eseménynaplót. Nincs fogalma arról, hogy "ez az IP 200-szor próbált meg belépni sikertelenül". Nem tudja az autentikációs hibákat tűzfalszabályokká alakítani.

A CISA következetesen az internet egyik legtöbbet támadott protokolljaként azonosítja az RDP-t — különösen az AA22-137A tanácsadóban, amely a kitett RDP-t rutinszerűen kihasznált kezdeti hozzáférési vektorként sorolja fel. Az incidenskezelési adatok megerősítik ezt: a Sophos Active Adversary Report több egymást követő évben is az externálisan elérhető távelérési szolgáltatásokat — elsősorban az RDP-t — nevezi meg vezető belépési vektorként a valós esetekben. Ezek azok a brute force és credential-stuffing támadások a kitett RDP ellen, amelyeket a tűzfal önmagában nem tud megállítani.

Miért nem tudja egyedül megállítani a Windows tűzfal az RDP brute force-t?

Három strukturális ok, mindegyik érdemes megérteni:

Nem számolja a sikertelen bejelentkezéseket. Egy tűzfalszabály statikus. Vagy átenged egy IP-t, vagy blokkolja. Nem követi, hány session-t indított az adott IP, közülük hány végződött LogonFailure-rel, vagy milyen gyorsan ismétlődnek.

Nem tud dinamikusan IP-t blokkolni. Manuálisan hozzáadhatsz egy blokkoló szabályt egy adott IP-re, de ez reaktív, utólagos művelet — és a modern brute force eszközök több száz vagy több ezer forrás-IP közt rotálnak. A kézi blokkolás nem skálázódik.

A fiókzárolás nem helyettesíti. A Windows tartalmaz egy Account Lockout Threshold beállítást a Helyi biztonsági házirendben. Alapértelmezett értéke 0, ami azt jelenti, hogy a fiókok soha nem záródnak. Ha bekapcsolod — például 5 sikertelen próbálkozás után zár —, megállítottad a brute force-t az adott fiókon, de egyúttal egy denial-of-service eszközt is adtál a támadó kezébe. Az igazi Administrator fiókodat bárhonnan, bármikor ki tudja zárni a hálózatról. Az IP közben tovább próbálkozik. Csak a felhasználónév lakol.

A Network Level Authentication (NLA), amely Windows Vista és Windows Server 2008 óta elérhető, segít valamennyit. Megköveteli, hogy a kliens még a teljes RDP-session létrejötte előtt hitelesítse magát, ami csökkenti az erőforrás-költséget és blokkol néhány autentikáció előtti exploit-utat. De az NLA is elfogad jelszó-próbálkozásokat — csak épp CredSSP-be csomagolva kéri őket. Egy CredSSP-t beszélő brute force eszközt nem nehezebb megírni, mint egy nélkülit. Az NLA szükséges, de nem elégséges.

A támadás mechanikájáról bővebben: mi az az RDP brute force támadás.

Mit ad hozzá egy dedikált RDP brute force védelem?

A hiányzó láncszem egy folyamat, amely valós időben figyeli a biztonsági eseménynaplót, forrás-IP-nként számolja a sikertelen belépéseket, és egy Windows tűzfalszabályt ír, amely blokkolja az adott IP-t, amint átlép egy küszöböt.

Ennyi a feladat. Egyszerűnek hangzik, és architektúrálisan az is — de megbízhatóan elvégezni (a 4625-ös események parse-olása, a forrás-IP kinyerése a megfelelő mezőből, IPv6 kezelése, blokkok megőrzése újraindítás után, a saját, jelszót kétszer elgépelő felhasználók kihagyása) az, ahol egy dedikált eszköz létjogosultsága megjelenik.

A BruteFence pontosan ezt csinálja. Figyeli az RDP-hez kötődő Event ID 4625 bejegyzéseket, forrás-IP-nként számolja a sikertelen kísérleteket, és amikor egy IP átlép egy konfigurálható küszöböt — tipikusan 3 és 10 közötti sikertelen kísérlet —, hozzáad egy blokkoló szabályt a Windows tűzfalhoz az adott IP-re. A blokkolást továbbra is a tűzfal végzi. A BruteFence csak olyan információt ad neki, amit önmagában nem tudna összegyűjteni.

A lényeges különbség az Account Lockout Policy-hoz képest: a BruteFence az IP-t blokkolja, nem a fiókot. Az igazi Administrator fiók használható marad. A támadó, bárhonnan is jön, megszűnik csomagot kapni.

A telepítés körülbelül 5 percet vesz igénybe, teljesen a szerveren fut, nincs felhő-függőség, és normál üzem mellett körülbelül 1% CPU-t használ. 7 napos ingyenes próba is van, ha látni szeretnéd, ahogy a blokkoló szabályok valós időben megjelennek a tűzfaladon. A lépésről lépésre útmutató a BruteFence telepítéséről szóló cikkben olvasható.

Ez nem a Windows tűzfal helyettesítője — hanem egy vezérlője.

Megéri-e még megtartani a Windows tűzfalat?

Igen, kétségtelenül. A helyes keret a rétegelt védelem, nem a vagy-vagy. Mit csinál pontosan az egyes rétegek:

| Réteg | Mit csinál | Mit nem csinál | |---|---|---| | Windows tűzfal | IP, port, protokoll alapján blokkol csomagot | Nem látja az autentikációs hibákat | | Account Lockout Policy | N sikertelen próba után zárolja a fiókot | A jogosult felhasználót is kizárja; nem blokkol IP-t | | Network Level Authentication | Pre-autentikációt követel meg a session előtt | Továbbra is elfogad korlátlan jelszó-próbálkozást | | Dedikált védelem (BruteFence) | Automatikusan blokkolja a támadó IP-t küszöb átlépésekor | Nem helyettesíti a hálózati szegmentációt vagy az MFA-t |

Egy értelmes Windows Server-telepítés mind a négyet használja. A tűzfal az alap. Az NLA kötelező. A fiókzárolást átgondoltan állítod be — elég magas küszöb és elég rövid időtartam, hogy a valódi felhasználók ne szenvedjenek tőle. És egy dedikált brute force eszköz tölti be azt a rést, amelyet a többi nem tud.

Teljes rétegelt ellenőrzőlista: Windows Server biztonsági checklist 2026.

Hogyan érdemes konfigurálni a Windows tűzfalat RDP-hez?

Még egy dedikált eszközzel együtt is számít a tűzfal konfigurációja. Öt praktikus lépés:

1. Szűkítsd a forrás-IP-t, ahol csak lehet. Nyisd meg az RDP bejövő szabályt a wf.msc-ben, lépj a Scope (Hatókör) fülre, és add hozzá az ismert jó IP-tartományokat a "Remote IP address" (Távoli IP-cím) alatt. Már az is jelentősen csökkenti a támadási felületet, ha a Bármely helyett az ország IP-blokkjára szűkítesz.

2. Kösd az RDP-t adott hálózati interfészhez. Több NIC-es szerveren (egy menedzsment interfész, egy publikus) a tűzfalszabály "Interface types" vagy "Profiles" fülén engedélyezd az RDP-t kizárólag a menedzsment profilra. Az Azure és AWS szervereknek gyakran van dedikált menedzsment alhálózatuk — használd.

3. Fontold meg az RDP port megváltoztatását — de ne becsüld túl. Ha az RDP-t a 3389-ről egy magas portra mozgatod, csökkented a célzott scannelőkből származó zajt. Egy elhatározott támadót nem állít meg, aki órákon belül megtalálja az új portot. Kezeld ezt naplócsökkentésként, nem biztonsági intézkedésként.

4. Kapcsold be a tűzfal-naplózást. Az Advanced Settings → Properties → Logging menüben kapcsold be a pfirewall.log-ot az eldobott csomagokra. Hasznos bizonyíték, ha korreláld egy aktív brute force támadás 5 jelével.

5. Ha az IP-szűrés nem megoldható, tegyél hozzá dedikált eszközt. Ha az adminoknak valóban bárhonnan kapcsolódniuk kell, a forrás-IP-szűrés ellehetetlenül. Ez az a helyzet, amikor dedikált RDP brute force védelem kell — ezt a dinamikus blokkolást a tűzfal nem tudja.

Mit tegyél most azonnal?

Nyisd meg az Eseménynézőt a Windows Servereden. Navigálj a Windows Logs → Security menüpontba. Szűrd az aktuális naplót Event ID 4625-re. Nézd meg az elmúlt 24 órát.

Ha a szám tucatban vagy százban mérhető, a Windows tűzfal ezeket a próbálkozásokat éppen átengedi — mert csak ennyit tehet. Mindegyik bejegyzés egy olyan kapcsolat, amit a tűzfal elfogadott, egy olyan autentikáció, amit nem látott, és egy olyan hiba, amire nem reagált.

Ez az a réteg, ami hiányzik. Hozzáadása nem azt jelenti, hogy a tűzfalat lecseréled. Azt jelenti, hogy szemet adsz neki, ami eddig nem volt.

Ha kíváncsi rá, mi történik a szerverén, próbálja ki a BruteFence-t 7 napig ingyen.