RDP brute-force saldırıları nasıl durdurulur?
İnternete doğrudan açık RDP hizmetleri, otomatik tarama ve parola denemelerinin sık görülen hedefleridir. Bu yazı, bir brute-force saldırısının nasıl tespit edileceğini ve iyi tasarlanmış bir politikayla nasıl durdurulacağını anlatır. RDP güvenliğinin tüm katmanları için önce RDP nasıl güvenli hale getirilir rehberine bakabilirsiniz; burada özellikle brute-force kısmına derinleşiyoruz.
RDP brute-force saldırısı nedir?
Brute-force, bir hesabın parolasını çok sayıda deneme yaparak tahmin etmeye çalışan otomatik bir saldırıdır. RDP’de birkaç biçimde görülür:
- Klasik brute-force: Tek hesap için binlerce parola denenir.
- Password spraying: Az sayıda yaygın parola çok sayıda hesaba uygulanır (kilitlenmeyi tetiklemeden).
- Credential stuffing: Başka sızıntılardan gelen kullanıcı adı/parola çiftleri denenir; bu durumda deneme ilk seferde başarılı olabilir.
Son madde, neden yalnız “deneme sayısını” izlemenin yetmediğini gösterir: geçerli bir parola tek denemede girer. O yüzden durdurma stratejisi hem gürültüyü hem kimliği ele almalıdır.
Saldırı altında olduğunuzu nasıl anlarsınız?
RDP parola hataları çoğunlukla Windows Güvenlik günlüğündeki 4625 olaylarında görülür. İzlenmesi gereken belirtiler:
- Kısa sürede yüzlerce/binlerce başarısız giriş
- Aynı kaynaktan çok sayıda farklı kullanıcı adı denenmesi
- Mesai dışı saatlerde yoğunlaşma
- Farklı ülke ve ağlardan (ASN) gelen denemeler
Administrator,admin,usergibi ortak adların hedeflenmesi
Bir 4625 kaydında dikkat edilecek alanlar şöyledir (değerler giriş yoluna göre değişebilir):
| Alan | Örnek |
|---|---|
| Event ID | 4625 |
| Account Name | Administrator |
| Logon Type | ağ girişini gösteren değer (giriş yoluna göre değişir) |
| Source Network Address | 203.0.113.42 (mevcutsa) |
| Failure Reason | Unknown user name or bad password |
Önemli nüans: 4625 kaydında kaynak ağ adresi her durumda bulunmaz. Kimlik doğrulama sağlayıcısı, NLA, yerel giriş ya da ağ mimarisine göre alan boş olabilir veya beklenen istemciyi göstermeyebilir. (Başarısız giriş olaylarını okumayı ayrı bir yazıda ele alacağız.)
Kaynak IP gerçekten saldırganı mı gösteriyor?
Otomatik engellemeyi açmadan önce cevaplanması gereken en kritik soru budur. Doğrudan RDP bağlantısında kaynak IP genellikle istemcinin adresidir. Ancak arada VPN gateway, RD Gateway, NAT ya da reverse proxy varsa, hedef makine gerçek istemci yerine ara sistemin IP’sini görebilir.
Bu durumda hatalı bir politika ağır sonuç doğurur:
“Gateway IP’sinden 20 başarısız deneme geldi → gateway’i engelle” → tüm kullanıcılar dışarıda kalır.
Bu yüzden otomatik engellemeyi etkinleştirmeden önce loglarda hangi adresin göründüğünü test edin; gateway, VPN çıkışları ve yönetim ağlarını doğrulamadan safelist’e ekleyin.
Saldırı yüzeyini küçültün
VPN veya RD Gateway kullanıldığında RDP hizmeti doğrudan internetten erişilemez hâle gelir. Böylece rastgele internet taramalarının doğrudan RDP oturum açma yüzeyine ulaşması engellenir ve deneme baskısı düşer. Ayrıntı için RDP güvenlik rehberi.
Otomatik engelleme politikasını tasarlayın
Asıl mekanik budur: başarısız girişleri kaynak IP bazında ilişkilendirip bir eşiği aşan adresi makinenin Windows Firewall’ında otomatik engellemek. Ama iyi bir politika “çok deneme oldu, engelle”den fazlasıdır:
İyi bir engelleme politikası şu bileşenleri tanımlar:
| Bileşen | Soru |
|---|---|
| Eşik | Kaç denemede aksiyon alınır? |
| Zaman penceresi | Denemeler ne kadar sürede sayılır? |
| İlk engel süresi | İlk ihlalde ne kadar blok uygulanır? |
| Tekrar politikası | Yeniden saldırırsa süre nasıl artırılır? |
| Kalıcı engel | Israrlı saldırgan ne zaman uzun süre engellenir? |
| Safelist | Hangi güvenilir kaynaklar hariç tutulur? |
| Geri alma | Yanlış engel nasıl ve kim tarafından kaldırılır? |
| Kayıt | Engel nedeni, süresi ve kural değişikliği loglanır mı? |
Bu işi yapan araçlar vardır (IPBan, RdpGuard, CrowdSec gibi) ve Dynacop Shield bunu RDP/SSH için yapar. Not: CrowdSec yalnız bir “IP engelleyici” değil, tespiti ve engellemeyi ayrı bileşenlere bölen bir sistemdir.
Dağıtık ve düşük hızlı saldırıları hesaba katın
Modern saldırılar her zaman tek IP’den gelmez. Bir saldırgan her IP’den yalnız 2–3 deneme yapıp binlerce proxy/botnet adresi kullanabilir ve denemeleri zamana yayabilir. Bu durumda yalnız “IP başına N deneme” politikası saldırıyı kaçırabilir. İki ayrı modeli izlemek gerekir:
- Bir IP → çok sayıda kullanıcı adı (fan-out / password spraying)
- Bir kullanıcı adı → çok sayıda kaynak IP (dağıtık credential saldırısı)
Yani yalnız tek bir IP’nin toplam denemesi değil; aynı IP’den kaç farklı hesabın hedeflendiği, aynı hesabın kaç farklı IP’den denendiği ve denemelerin zaman içindeki davranışı da izlenmelidir. Dağıtık saldırıları IP engelleme tek başına bitiremez — burada MFA belirleyici olur.
MFA ile geçerli parola saldırısını durdurun
Engelleme gürültüyü keser ama kimlik doğrulamaz. Engellenmemiş bir IP’den gelen geçerli/çalınmış parola yine girer. Bu boşluğu MFA kapatır: doğru parola bile ikinci faktör olmadan yetmez.
| Risk | IP engelleme | MFA |
|---|---|---|
| Çok sayıda yanlış parola | ✓ | Sınırlı |
| Çalınmış doğru parola | — | ✓ |
| Dağıtık botnet | Kısmen | ✓ (başarılı oturumu önler) |
| Hesap verilebilirliği | — | Kişi MFA’sıyla ✓ |
“Dağıtık botnet” satırında MFA saldırıyı ağdan silmez ama başarılı oturum açılmasını önler. Engelleme ile MFA’nın neden farklı işler yaptığını MFA mı, brute-force engelleyici mi? yazısında ele alıyoruz.
Hesap kilitlemeyi tamamlayıcı kontrol olarak kullanın
Hesap kilitleme faydalı bir ek kontrol olabilir; ancak tek başına kullanılmamalıdır. Çok düşük eşikler, saldırganın kasıtlı yanlış parolalarla meşru kullanıcıları kilitleyip hizmeti aksatmasına (DoS) yol açabilir. Yani hesap kilitleme kötü değil, yanlış ayarlanırsa DoS riski taşıyan bir kontroldür. Makul kilitleme eşikleri, kaynak-IP analizi, MFA ve olay izleme birlikte kullanılmalıdır.
İzleyin ve politikayı ayarlayın
Engelleme “kur ve unut” değildir. Düzenli gözden geçirilmesi gerekenler:
- Yanlış pozitifler (meşru kullanıcıların engellenmesi)
- Zaman içindeki engel sayısı ve yoğunluğu
- En çok hedeflenen hesaplar
- Tekrar eden saldırgan IP’ler ve ağlar
- Engellenen bir IP’nin saldırıya devam edip etmediği
Örnek bir saldırı sinyali (yalnızca gösterim amaçlı):
| Alan | Değer |
|---|---|
| Kaynak IP | 203.0.113.42 |
| Deneme | 43 |
| Kullanıcı adı | 12 farklı hesap |
| İlk görülme | 03:41 |
| Son görülme | 03:47 |
| Hedef | RDP |
| Karar | 1 saat engellendi |
Kontrol listesi
- RDP mümkünse VPN/RD Gateway arkasında (doğrudan 3389 açık değil)
- Loglarda görünen kaynak IP’nin gerçek istemci olduğu doğrulandı (gateway/NAT kontrolü)
- Başarısız girişler kaynak-IP ve hesap bazında izleniyor
- Eşik/pencere/süre/tekrar/safelist/geri-alma tanımlı
- Konsol ve RDP girişinde MFA açık
- Hesap kilitleme makul eşikle (DoS tuzağına karşı) ve izlemeyle kullanılıyor
- Dağıtık/düşük-hızlı saldırılar için hesap-bazlı davranış izleniyor
- Engel sayısı, yanlış pozitifler ve hedeflenen hesaplar düzenli gözden geçiriliyor
Özet
RDP brute-force’u durdurmak iki farklı işi birlikte yapmayı gerektirir: saldırı gürültüsünü iyi tasarlanmış bir kaynak-IP politikasıyla kesmek ve kimliği MFA ile doğrulamak. Erişim yüzeyini küçültmek baskıyı azaltır; otomatik engelleme botnet gürültüsünü keser; MFA ise geçerli/çalınmış parolalara ve dağıtık saldırılara karşı son kapıdır. Otomatik engellemeyi açmadan önce gerçek kaynak IP’nin göründüğünü doğrulayın, ve hesap kilitlemeye yalnız başına güvenmeyin.
Dynacop Shield, desteklenen RDP ve SSH saldırı kaynaklarını izleyip Windows Firewall’da engeller; Dynacop’ın Windows Login MFA katmanı ise Windows konsol ve RDP oturumlarında kişiyi ayrıca doğrular — Active Directory gerektirmeden.
Kaynaklar
Sık sorulanlar
RDP brute-force saldırısını nasıl anlarım?
En belirgin işaret, kısa sürede çok sayıda başarısız giriş (Windows Olay Kimliği 4625) olmasıdır: aynı kaynaktan çok sayıda kullanıcı adı denenir, mesai dışı yoğunluk artar ve çoğu zaman farklı ülke/ağlardan gelir. Ancak 4625 kaydındaki alanlar giriş yoluna göre değişebilir; kaynak adresi her durumda net olmayabilir.
VPN veya RD Gateway arkasındayken saldırganın gerçek IP'si görünür mü?
Duruma bağlıdır. Doğrudan RDP'de kaynak IP genelde istemcinindir; ancak VPN, RD Gateway, NAT ya da reverse proxy varsa hedef makine gerçek istemci yerine ara sistemin IP'sini görebilir. Otomatik engellemeyi açmadan önce loglarda hangi adresin göründüğünü doğrulayın ve gateway/VPN çıkışlarını safelist'e ekleyin.
Saldırgan sürekli IP değiştirirse ne olur?
IP engelleme saldırı maliyetini yükseltir ama dağıtık saldırıları tek başına bitirmez: saldırgan denemeleri binlerce IP'ye yayarak IP başına eşiğin altında kalabilir. Bu durumda aynı hesabın kaç farklı IP'den denendiğini izlemek ve MFA kullanmak gerekir.
Aynı IP'den çok sayıda meşru kullanıcı bağlanıyorsa ne olur?
Kurumsal NAT, VPN ya da ortak çıkış IP'si yanlış pozitif oluşturabilir — tek bir adres yüzlerce kullanıcıyı temsil edebilir. Eşikleri ve istisnaları buna göre ayarlayın; güvenilir çıkışları safelist'e alın.
Hesap kilitleme politikası brute-force'u durdurur mu?
Kilitleme faydalı bir tamamlayıcı kontroldür ama tek başına kullanılmamalıdır: çok düşük eşikler, saldırganın kasıtlı yanlış parolalarla meşru hesapları kilitleyip hizmeti aksatmasına (DoS) yol açabilir. Makul eşikler + kaynak-IP analizi + MFA birlikte kullanılır.
Windows Firewall yerine ağ firewall'ında engelleme yapılabilir mi?
Yapılabilir. Host seviyesinde engelleme makineyi doğrudan korur; çevre (ağ) firewall'ı saldırıyı daha erken kesebilir. Mimariye göre biri ya da ikisi birlikte kullanılabilir.
Dynacop Shield brute-force'u nasıl engeller?
Shield, desteklenen RDP ve SSH saldırı kaynaklarını izleyip politika eşiğini aşan adresi makinenin Windows Firewall'ında otomatik engeller. Dynacop'ın Windows Login MFA katmanı ise Windows konsol ve RDP oturumlarında kişiyi ayrıca doğrular; böylece hem saldırı gürültüsü kesilir hem kimlik doğrulanır.