Web sitesi hack’lendi: İlk 10 dakikada yapılacak 15 adım

Web sitesi hack’lendiğinde ilk 10 dakika, hem hasarı büyütmeyi durdurur hem de adli/teknik inceleme için kanıt (log) kaybını engeller. Bu rehberde, erişim kesintisini doğru ayarlayarak iz sürmeyi bozmadan nasıl hareket edeceğinizi adım adım anlatıyorum. Hedef; suçlunun yeniden girişini engellemek, değişen dosyaları izole etmek ve kontrolü en hızlı şekilde geri almaktır.

1) İlk 60 saniye: Hasarı büyütmeyi durdur

Hack sonrası ilk amaç, saldırganın yeniden yazma/komut çalıştırma şansını azaltmaktır. Bu aşamada “hemen karartmak” ile “kanıtları yok etmek” arasındaki dengeyi kurmalısınız.

Hemen yap (0–2 dk)

• Erişimi kes (mümkünse sadece siteyi): WordPress/CDN/WAF kullanıyorsanız ilgili trafiği filtreleyin. WAF yoksa web sunucusu (Nginx/Apache) üzerinden domain’e gelen trafiği geçici kısıtlayın.
• Kontrol paneli girişlerini askıya al: Sunucu/hosting paneli (cPanel/Plesk/DirectAdmin) varsa admin girişlerini kapatın veya IP kısıtı uygulayın.
• Şifreyi değiştirmeden önce log al: Parolayı hemen değiştirmek bazen saldırganın izlenmesini zorlaştırır. Log/kanıt toparlamadan aksiyon almayın.

Hızlı önlem (2–5 dk)

• Dosya değişikliği varsa karantina: Web kök dizininde (ör. /public_html) yeni dosya/skript/unknown zip içeriğini yayına kapatın. En doğrusu: web kökünü değil, şüpheli parçaları “karantina dizinine” taşıyıp web erişimini kesmektir.
• Cron/job’ları kontrol et: Saldırganlar kalıcı olmak için cron (cron job) yazar. Kontrol paneli cron bölümünü ve sunucu cron dosyalarını tarayın.

Bu aşamada hedef, siteyi tamamen kapatmak değil; saldırganın geri dönmesini engellemek ve kanıtları güvene almaktır.

2) Logları ve kanıtları 5 dakikadan önce topla

Saldırı “dosya içerisine gömülü” bir web kabuğu (webshell) olsa bile, doğru loglar olmasa kalıcı çözüm zorlaşır. Bu yüzden ilk 10 dakikada log/iz toplayın.

Mutlaka toplanacaklar (3–7 dk)

Aşağıdaki loglar, saldırı vektörünü anlamak için kritik:

• Web sunucusu access log: Hangi IP, hangi URL’leri denedi? Özellikle POST, wp-admin, şüpheli endpoint’ler.
• Web sunucusu error log: PHP parse hataları, izin hataları, “file not found” sonrası istenmeyen 404 paternleri.
• SSH auth log (varsa): /var/log/auth.log veya sistemin eşdeğeri.
• PHP hata/servis logları: Uygulamanın çöküp yeniden ayağa kalkması sırasında hangi dosyaya erişildi.
• Panel audit/işlem logları (varsa): Dosya yöneticisiyle hangi tarihte kim neyi değiştirdi.

Trafik ve DNS izleri (5–10 dk)

• DNS değişikliği oldu mu: Domain sağlayıcıda son 24-48 saatte A/AAAA/CNAME/MX/TXT değişti mi kontrol edin.
• Mail yönlendirme (MX) veya SPF/DKIM/TLS kayıtları: Saldırgan mail sunucusunu kullanarak kimlik avına (phishing) başlayabilir.

3) Erişimi güvene al: Yetki ve kimlik doğrulama kontrolü

Hack sonrası en sık yapılan hata, şifreyi hemen değiştirip log toplamadan yola devam etmek. Bunun yerine kimlik doğrulama katmanlarını sırayla kontrol edin.

Hemen kontrol edin (5–8 dk)

• Panel kullanıcıları: WordPress admin kullanıcılarını, hosting paneli kullanıcılarını ve FTP/SFTP hesaplarını gözden geçirin.
• Yeni kullanıcı oluşturma / rol değişimi: WordPress’te admin dışı görünse bile “kullanıcı ekleme” olayları.
• SSH anahtarları: authorized_keys içinde yeni anahtar eklenip eklenmedi.

Parola değişimi ne zaman? (8–10 dk)

• Loglar toplandıktan sonra şu değişimleri yapın:
• Hosting paneli
• FTP/SFTP kullanıcıları
• SSH kullanıcı parolaları/anahtarları
• WordPress admin hesapları (tek tek)
• Veritabanı (MySQL/MariaDB) parolası (varsa)

Eğer saldırı kısa süre önce başladıysa bile, şifre değişimi saldırganın geri dönüş penceresini kapatır.

4) Dosyaları güvenli şekilde incelemeden “silmeyin”: Karantina yaklaşımı

Web kabuğu gibi zararlı dosyalar genellikle gizlenir: ad/uzantı benzerliği, farklı encoding, base64 ile saklama gibi. Bu nedenle “hemen silmek” yerine “izole etmek” daha güvenlidir.

Karantinaya alın (6–9 dk)

Aşağıdaki yollarla zararlı olabilecek içerikleri web yayından ayırın: - /public_html (veya uygulama kökü) altında şüpheli yeni klasör/zip - En son değiştirilme zamanı “ani sıçrama” yapan dosyalar - PHP dosyası gibi görünen fakat garip içerik taşıyan dosyalar (ör. *.php içinde sistem komutu çağrısı)

Hızlı kontrol listesi (örnek)

• Son 24 saatte değişen dosyaları listeleyin
• Kökte beklenmeyen dosyalar var mı (ör. sıradışı isimli .php, .phtml, .phar)
• index.php/wp-config.php gibi kritik dosyalarda değişiklik var mı

WordPress kullanıyorsanız temalar/eklenti klasörleri yerine özellikle kök dosyaları ve wp-content içindeki olağandışı değişiklikler öne çıkar.

5) Veritabanında iz sürme: Kalıcı izler sadece dosyada olmaz

Saldırganlar çoğu zaman veritabanına da iz bırakır: admin hesap ekleme, wp_options veya benzeri tabloları manipüle etme, SEO spam üretme, bağlantı ekleme.

Neye bakılır (7–10 dk)

• Admin kullanıcıları: WordPress’te wp_users ve wp_usermeta değişimi
• Yeni eklenen admin rolü: var olmayan hesap/rol
• Şüpheli cron/option değerleri: uygulama ayarlarına gömülü dış script referansları

Veritabanını “şu an temizleyeyim” diye kurcalamak bazen daha fazla hasara yol açabilir. Önce yedek alın ve değişim farklarını çıkarın.

6) Geri dönüş planı: Temiz bir sürümle yayına dönün

Hack sonrası en güvenli yaklaşım, “hacklenen sürüm üstüne yamalayarak devam” yerine, bilinen temiz bir referansa dönmektir.

Yayına dönüş için doğru rota (9–10 dk ve sonrası)

• Güvenilir yedekten geri dönün (backup): Eğer günlük/haftalık yedek var ise, hack zamanından önceki sürümü geri yükleyin.
• Yedek yoksa: Yayına alınan dosyaları karantina sürecinde tutun ve önce zararlı bileşeni doğrulayın.
• Güncelleme stratejisi: WordPress teması/eklenti çekirdek sürümleri ve PHP sürümü en güncel güvenli sürümlere alınmalıdır.

7) Hosting ve sunucu tarafı: Paylaşımlı mı, VDS mi? Kurtarma farkı

Hack sonrası “nerede” temizleneceği, sunucu türüne göre değişir. Burada doğru kategoriyi netleştirmek, ilk 10 dakikada doğru aksiyon almayı sağlar.

Sunucu tipi → ilk aksiyon özeti

8) Saldırı türüne göre hızlı teşhis (ilk 10 dakikada yön bulma)

İlk 10 dakikada kapsamlı tersine mühendislik yapmanız beklenmez. Ama saldırı türü, hangi kontrol paneli/servisin önce durdurulacağını belirler.

Sık görülen işaretler

• Webshell şüphesi: Kökte garip isimli PHP dosyaları, kısa sürede çok sayıda istek, URL parametreleriyle komut denemeleri
• WordPress eklenti yolu: Belirli bir eklenti klasöründe ani dosya artışı, tema dosyalarına küçük script ekleri
• Yetki yükseltme (privilege escalation): SSH/cron’da yeni kayıtlar, sudo denemeleri, anormal süreçler
• Spam/redirect: Sayfa HTML içine gömülü dış scriptler, fark edilir yönlendirme davranışı

9) Aşağıdaki kontrol listesiyle 10 dakikada ilerleyin

Aşağıdaki listeyi “zaman kutusu” gibi düşünün. Her maddeyi geçmeden diğerini yapmayın.

0–2 dk

• [ ] Site erişimini kısıtla (tam kapat yerine kontrollü karartma)
• [ ] Panel/SSH/FTP erişimlerini gözlemle (kilitlemeden önce kanıt al)

2–5 dk

• [ ] Web server access/error logları topla
• [ ] Panel işlem logları varsa al
• [ ] Şüpheli dosyaları web yayından ayır (karantina)

5–8 dk

• [ ] SSH authorized_keys ve cronları kontrol et
• [ ] WordPress kullanıcı/rol değişikliklerini incele

8–10 dk

• [ ] Parolaları ve kritik anahtarları loglar sonrası değiştir
• [ ] Veritabanı yedek al
• [ ] Hack öncesi güvenilir yedek varsa geri dönüşü planla

Sonuç: 10 dakikada durdur, kanıtla, karantinaya al, geri dön

Hack sonrası “hemen temizlik” yapmak kadar “hemen iz” toplamak da kritiktir. İlk 10 dakikada erişimi kısıtlayın, logları kaybetmeden toplayın, değişen dosyaları karantinaya alın ve bilinen temiz yedekle geri dönüş planını başlatın. Hemen şimdi sitenizde son 24 saatte yapılan dosya değişikliklerini ve cron/panel kullanıcılarını kontrol edin; ardından log dosyalarınız hazırken parolaları ve anahtarları güncelleyin. Bu sırayı uyguladığınızda, hem yeniden ele geçirilme ihtimali azalır hem de kalıcı çözüm için elinizde net veri olur.