Bir güvenlik olayını okumakla, gerçekten yönettiğiniz canlı bir sunucuda o olayın ortasında kalmak arasında ciddi fark var.

Yakın zamanda Linux üzerinde çalışan, web sunucusu, kontrol paneli ve WordPress barındıran bir sistemde yaşanan güvenlik ihlalini incelemek ve sistemi toparlamak zorunda kaldım.

Burada özellikle özel altyapı detaylarını, saldırganın kullandığı yöntemlerin tüm ayrıntılarını ya da hassas müdahale adımlarını paylaşmıyorum. Bu yazı bir exploit rehberi değil.

Amacım daha çok geliştiricilerin, sistem yöneticilerinin ve site sahiplerinin bir şeylerin yolunda gitmediğini hissettikleri anda daha doğru hareket edebilmesine yardımcı olmak.

Özellikle de ilk belirtiler kafa karıştırıcı, eksik veya yanıltıcı olduğunda.

Bu süreçten çıkardığım en önemli ders oldukça basitti:

En görünür sorun, her zaman saldırının başladığı yer değildir.

Gerçek bir olayda ilk belirti garip bir giriş yönlendirmesi olabilir.

Beklenmedik bir yönetim sayfası görebilirsiniz.

Tanımadığınız kullanıcı hesapları ortaya çıkabilir.

Giriş davranışları değişebilir.

Loglarda tuhaf hareketler görebilirsiniz.

Ama yalnızca ekranda gördüğünüz ilk probleme odaklanırsanız, daha büyük resmi kaçırabilirsiniz.

Bu yazıda daha güvenli ve daha uygulanabilir bir müdahale sürecinden bahsedeceğim.

1. Önce Durun ve Kanıtları Koruyun

Bir güvenlik olayında yapılabilecek en kolay hatalardan biri temizliğe gereğinden erken başlamaktır.

Şüpheli dosyaları hemen silmek, servisleri kapatmak veya ne olduğunu anlamadan rastgele bir yedeğe dönmek ilk anda mantıklı gelebilir.

Ama bunu yaptığınızda saldırının nasıl gerçekleştiğini anlamanızı sağlayacak kanıtları da yok edebilirsiniz.

İlk aşamadaki hedefiniz:

“Her şeyi hemen düzeltmek” olmamalı.

Önce:

  • sorunu sınırlandırın,

  • devam eden riski azaltın,

  • kanıtları koruyun,

  • olayın ne kadar yayıldığını anlamaya çalışın,

  • ardından temiz şekilde sistemi kurtarın.

İlk yapılabilecek iyi adımlar

  • Yetkili hesapların şifrelerini değiştirin

  • Mümkünse açık oturumları iptal edin

  • Yönetici erişimini geçici olarak kısıtlayın

  • Olayların zamanlarını not alın

  • Log rotasyonu gerçekleşmeden önce logların kopyasını alın

  • Şüpheli dosyaları belgelemeyi bitirmeden silmeyin

Örneğin:

# Son güvenlik loglarını güvenli bir yere kopyala
cp /var/log/secure /root/incident-secure.log
cp /var/log/messages /root/incident-messages.log

# Web sunucusu loglarını arşivle
tar -czf /root/web-logs-backup.tar.gz /var/log/nginx /var/log/httpd 2>/dev/null

Sizin sisteminizde yollar farklı olabilir.

Ama mantık değişmiyor:

Önce koru, sonra temizle.

2. Gerçekten Bir Güvenlik İhlali Olup Olmadığını Doğrulayın

Her garip davranış hacklendiğiniz anlamına gelmez.

Bazen bir eklenti çakışması, yanlış yönlendirme kuralı, süresi dolmuş token ya da bot trafiği oldukça korkutucu görünebilir.

Ama bazı belirtiler varsa daha ciddi yaklaşmak gerekir:

  • beklenmedik yönetici erişim yolları

  • tanımadığınız kullanıcı hesapları

  • bilinmeyen cron görevleri

  • değiştirilmiş çekirdek dosyalar

  • webshell benzeri PHP dosyaları

  • şüpheli dış bağlantılar

  • mevcut yapılandırmayla uyuşmayan giriş davranışları

  • sizin onayınız olmadan değişmiş güvenlik ayarları

Kontrol edilmesi gereken yerler

  • web sunucusu access logları

  • error logları

  • authentication logları

  • cron klasörleri

  • başlangıç servisleri

  • WordPress kullanıcıları ve eklentiler

  • yakın zamanda değiştirilmiş dosyalar

Örneğin:

# Web root içinde son 7 günde değişen dosyalar
find /var/www/html -type f -mtime -7 | less

# Şüpheli PHP kalıplarını ara
grep -RInE "base64_decode|eval\(|shell_exec|assert\(|gzinflate" /var/www/html 2>/dev/null

Bu komutlardan bir sonuç çıkması tek başına saldırıya uğradığınızı kanıtlamaz.

Ama ilk inceleme için oldukça faydalıdır.

3. Sorunun Tek Bir Katmanda Olmadığını Varsayın

Yapılan en yaygın hatalardan biri şu düşünce:

Bu sadece WordPress problemi.

Bazen gerçekten öyledir.

Ama her zaman değil.

Bir site saldırıya uğradığında sistemi katmanlar halinde düşünmek daha doğru olur:

  • uygulama katmanı: WordPress, tema, eklenti, uploads

  • web sunucusu katmanı: Nginx, Apache, redirect ve proxy kuralları

  • işletim sistemi katmanı: kullanıcılar, servisler, cron, SSH anahtarları, firewall

  • kontrol paneli / hosting katmanı: yönetim paneli, hesap erişimi, vhost yapılandırmaları

  • kimlik bilgileri katmanı: tekrar kullanılan şifreler, sızan secret'lar, API tokenları

Bu bakış açısı önemli.

Çünkü saldırgan bir yerden içeri girip kalıcılığı tamamen başka bir katmanda sağlayabilir.

4. Derin Temizliğe Geçmeden Önce Erişimi Sınırlandırın

Sistem hâlâ dışarıya açıksa, siz inceleme yaparken yönetim arayüzlerini olduğu gibi internete açık bırakmak iyi fikir değil.

Geçici olarak şu önlemler alınabilir:

  • admin yollarını IP bazlı sınırlandırmak

  • gereksiz uzaktan erişimleri kapatmak

  • daha güçlü kimlik doğrulama kullanmak

  • kullanılmayan servisleri devre dışı bırakmak

  • hassas panelleri VPN veya özel ağ arkasına almak

  • tehlikeli doğrudan erişim yollarını engellemek

Örneğin geçici bir kısıtlama şöyle olabilir:

location /admin/ {
    allow 203.0.113.10;
    deny all;
}

Bu yalnızca örnek.

Buradaki esas fikir şu:

Olayı incelerken önce saldırı yüzeyini küçültün.

Mümkünse kritik yönetim alanlarını şunların arkasına alın:

  • VPN

  • private tunnel

  • IP allowlist

  • ayrı bir admin hostname

  • MFA korumalı erişim akışı

5. WordPress'i Ayrıntılı Kontrol Edin, Ama Orada Durmayın

WordPress tarafında ilk bakılması gereken alanlar şunlar:

WordPress kontrol listesi

  • yönetici kullanıcıları

  • eklentiler

  • temalar

  • uploads klasörü

  • must-use plugins

  • .htaccess veya benzeri rewrite davranışları

  • gizli login eklentileri

  • cron event'leri

  • application password'ler

  • REST API davranışı

  • redirect, login yolu veya enjekte edilmiş kodla ilgili veritabanı ayarları

WP-CLI kullanabiliyorsanız işinizi ciddi anlamda kolaylaştırabilir:

wp user list
wp plugin list
wp theme list
wp option list --search=siteurl
wp cron event list

WordPress çekirdek dosyalarını da karşılaştırmak gerekir:

wp core verify-checksums

Checksum kontrolünün başarısız olması otomatik olarak sunucunun hacklendiği anlamına gelmez.

Ama dosyaların neden farklı olduğunu araştırmanız gerektiği anlamına gelir.

6. Sadece Görünür Zararı Değil, Kalıcılık Noktalarını Arayın

Saldırganlar her zaman görünür hasar bırakmak istemez.

Çoğu zaman daha değerli olan şey sistemde kalıcı erişim sağlamaktır.

Bu nedenle görünen zararlı dosyaları temizleseniz bile başka bir mekanizma problemi geri getirebilir.

Kontrol edilmesi gereken yaygın kalıcılık noktaları

  • cron job'lar

  • systemd servisleri

  • yeni SSH anahtarları

  • değiştirilmiş startup scriptleri

  • gizli PHP backdoor'ları

  • mu-plugin'ler

  • drop-in dosyaları

  • çalıştırılabilir kod barındıran yazılabilir dizinler

  • eklenti veya enjekte edilmiş kod tarafından oluşturulmuş zamanlanmış görevler

Bazı faydalı kontroller:

crontab -l
ls -la /etc/cron.*
systemctl list-unit-files --state=enabled
find ~/.ssh -type f -maxdepth 2 2>/dev/null

WordPress tarafında da:

find wp-content/uploads -type f -name "*.php"
find wp-content/mu-plugins -type f

Uploads klasöründe PHP dosyası bulunması her zaman zararlı olduğu anlamına gelmez.

Ama kesinlikle incelenmeye değer bir durumdur.

7. Yedeklere Körü Körüne Güvenmeyin

Bir saldırıdan sonra akla gelen ilk çözüm genellikle:

Eski yedeği geri yükleyelim.

Ama eski olması, temiz olduğu anlamına gelmez.

Yedek ancak saldırının başladığı tarihten önce alındığını biliyorsanız ve hangi parçaların etkilendiğini anladıysanız güvenli bir çözüm olabilir.

Saldırgan sisteme uzun süredir erişebiliyorsa yedekle birlikte şunları da geri getirebilirsiniz:

  • enfekte dosyalar

  • değiştirilmiş konfigürasyon

  • backdoor içeren eklentiler

  • zararlı kullanıcı hesapları

  • değiştirilmiş veritabanı içeriği

Daha doğru kurtarma yaklaşımı

Bir yedeği geri yüklemeden önce:

  1. olayın yaklaşık ne zaman başladığını tespit edin

  2. hangi dosya ve ayarların değiştiğini bulun

  3. birden fazla yedek noktasını karşılaştırın

  4. yedeği production'a almadan önce doğrulayın

Mümkünse yedeği önce izole bir ortamda test edin.

8. Kimlik Bilgilerini Doğru Sırayla Değiştirin

Şifre değiştirmek önemlidir.

Ama yanlış sırayla yaparsanız çok fazla işe yaramayabilir.

Saldırgan başka bir kanaldan hâlâ sisteme erişebiliyorsa değiştirdiğiniz şifreleri tekrar sıfırlayabilir.

Kimlik bilgilerini değiştirme önceliği

  1. root / sunucu yöneticisi erişimi

  2. hosting veya kontrol paneli hesabı

  3. SSH anahtarları ve yetkili kullanıcılar

  4. veritabanı şifreleri

  5. WordPress admin hesapları

  6. API anahtarları ve application password'ler

  7. üçüncü taraf servis tokenları

  8. şifre kurtarma süreçlerine bağlı e-posta hesapları

Özellikle hosting veya e-posta hesabını atlamak ciddi hata olabilir.

Saldırgan bu hesaplara erişebiliyorsa her şeyi yeniden sıfırlayabilir.

9. Loglar Düşündüğünüzden Daha Değerli

Bir güvenlik olayında ne olduğunu geriye dönük anlayabilmenizin en önemli sebeplerinden biri loglardır.

Ama logların da kusursuz olmadığını unutmamak gerekir.

Eksik olabilirler.

Gürültülü olabilirler.

Hatta yanıltıcı olabilirler.

WordPress siteleri sürekli botlar tarafından taranır.

404 istekleri gelir.

Otomatik vulnerability scanner'lar dolaşır.

Her şüpheli request saldırının sebebi değildir.

Bu yüzden tek bir log satırına bakmak yerine farklı kaynakları bir araya getirmek gerekir:

  • access logları

  • error logları

  • auth logları

  • dosya değiştirilme zamanları

  • servis restart'ları

  • kullanıcı işlemleri

  • eklenti ve tema değişiklikleri

Amaç tek bir şüpheli satıra takılmak değil.

Bir zaman çizelgesi oluşturmak.

Loglardan cevaplamaya çalışmanız gereken sorular

  • İlk doğrulanmış şüpheli olay neydi?

  • Hangi IP veya user-agent'lar diğerlerinden ayrılıyor?

  • Admin yollarına sıra dışı şekilde erişilmiş mi?

  • Login aktivitelerinden hemen sonra dosya değişiklikleri olmuş mu?

  • Yetki değişikliği girişimleri var mı?

  • Beklenmedik dış bağlantılar gerçekleşmiş mi?

Bu sorulara birlikte cevap verebilirseniz saldırının yapısını çok daha iyi anlayabilirsiniz.

10. Sistemi Güçlendirmek Kurtarma Sürecinin Bir Parçasıdır

Zararlı dosyaları temizlemek işin bittiği anlamına gelmez.

Eğer ortamı güçlendirmezseniz yalnızca bir sonraki saldırı için sahneyi yeniden hazırlamış olabilirsiniz.

Olay sonrası yapılabilecek güçlendirmeler

  • WordPress core, eklenti ve temaları güncel tutun

  • kullanılmayan eklenti ve temaları kaldırın

  • yazılabilir dizin sayısını azaltın

  • admin alanlarına erişimi kısıtlayın

  • hassas panelleri özel erişim arkasına alın

  • mümkün olan yerlerde MFA kullanın

  • gereksiz servisleri kapatın

  • firewall kurallarını gözden geçirin

  • dosya değişikliklerini takip edin

  • logları merkezi bir yerde tutun veya koruyun

  • belgelenmiş bir kurtarma planı oluşturun

Örneğin dosya izinlerini kontrol etmek için:

find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

Bunu doğrudan her sisteme uygulamak doğru değildir; kendi ortamınıza göre uyarlamanız gerekir.

Ama genel fikir değişmez:

Güvenli varsayılanlar, bir sonraki olayın verebileceği zararı azaltır.

11. Uygulanabilir Basit Bir Olay Müdahale Akışı

Bu deneyimin tamamını tekrar kullanılabilir bir sürece indirgemem gerekseydi şöyle yapardım.

Adım 1 — Doğrula

Problemin gerçekten var olup olmadığını ve ilk görünen belirtilerin ne olduğunu belirle.

Adım 2 — Sınırlandır

Admin alanlarına erişimi azalt, şifreleri değiştir ve sistemin dışarıya açıklığını küçült.

Adım 3 — Kanıtları Koru

Logları, zaman damgalarını, şüpheli dosyaları ve konfigürasyon kopyalarını sakla.

Adım 4 — Kapsamı Belirle

Sorunun yalnızca WordPress tarafında mı kaldığını yoksa daha derin katmanlara mı yayıldığını kontrol et.

Adım 5 — Temizle

Zararlı dosyaları, yetkisiz kullanıcıları, kalıcılık mekanizmalarını ve kötü konfigürasyonları kaldır.

Adım 6 — Kurtar

Yalnızca temiz olduğunu doğruladığın bileşenleri geri yükle ve kritik akışları yeniden test et.

Adım 7 — Güçlendir

Erişimi sıkılaştır, yazılımları güncelle, izlemeyi geliştir ve yaşananlardan çıkardığın dersleri dokümante et.

Bu sıralama, panikle alınan yanlış kararların önüne geçmeye yardımcı oluyor.

12. Bana Göre En Önemli Ders

Bu olaydan çıkardığım en değerli ders aslında teknik değildi.

Daha çok operasyonel bir dersti.

Bir güvenlik olayı şu durumlarda çok daha zor hale geliyor:

  • dokümantasyon eksikse

  • erişim yöntemleri tutarsızsa

  • gizli login mantıkları belgelenmemişse

  • birden fazla güvenlik katmanı birbirini beklenmedik şekilde etkiliyorsa

  • hangi kuralın hangi davranışa sebep olduğunu kimse tam bilmiyorsa

Bu yüzden küçük sistemlerde bile şunlar ciddi fark yaratıyor:

  • belgelenmiş erişim mimarisi

  • açık şekilde isimlendirilmiş güvenlik katmanları

  • acil geri dönüş adımları

  • admin erişim diyagramları

  • public ve private arayüzlerin birbirinden net şekilde ayrılması

İyi güvenlik yalnızca saldırganı engellemek değildir.

Bir şeyler ters gittiğinde sistemi savunan kişinin işi ne kadar kolay olduğu da güvenliğin bir parçasıdır.

Son Düşünceler

Bir WordPress sitesi ya da Linux sunucusu yönetiyorsanız bir gecede profesyonel incident responder olmanız gerekmiyor.

Ama sakin ve net bir sürece ihtiyacınız var.

Bir şeyler ters gittiğinde:

  • panik yapmayın

  • körlemesine temizlik yapmayın

  • varsayımlara güvenmeyin

  • yalnızca en görünür probleme odaklanmayın

Dikkatli araştırın.

Erken sınırlandırın.

Temiz şekilde kurtarın.

Sonrasında sistemi güçlendirin.

Bu yaklaşım, çoğu zaman tek bir güvenlik aracından çok daha fazla işinize yarar.

Hızlı Müdahale Kontrol Listesi

Kısa bir sürüm isteyenler için yanınızda tutulabilecek liste şu olabilir:

  • yetkili hesapların şifrelerini değiştirin

  • admin erişimini kısıtlayın

  • logları hemen saklayın

  • kullanıcıları, eklentileri, temaları ve cron görevlerini kontrol edin

  • şüpheli dosya değişikliklerini araştırın

  • web sunucusu ve authentication loglarını inceleyin

  • problemin yalnızca WordPress ile sınırlı olup olmadığını doğrulayın

  • anahtarları ve tokenları yenileyin

  • yalnızca temizliği doğrulanmış bileşenleri geri yükleyin

  • kurtarma sonrasında sistemi mutlaka güçlendirin