Web sitesi hack’lendi: İlk 10 dakikada yapılacak net adımlar

Web sitesi hack’lendiğinde ilk dakikalarda yapılacaklar, hem zararın büyümesini engeller hem de sonradan kanıt toplamanı ve geri dönüş sürecini hızlandırır. Bu rehberde, ilk 10 dakika içinde atmanız gereken adımları net bir sırayla anlatıyorum: erişimi kesme, etkilenen dosyaları işaretleme, log ve kanıt saklama, panel/servis durumunu kontrol etme ve temizleme hazırlığı. Amaç “panik anında ne yapacağımı bilmek” değil; zararı durdurup doğrulara dayanarak hareket etmektir.

İlk 10 dakikada hedef: Zararı durdur + kanıtı sakla

Hack saldırılarının çoğu iki şeye odaklanır: siteyi kullanarak ek zararlı içerik yaymak ve/veya sunucuda kalıcı erişim kurmak. Bu nedenle ilk aşamada “silmeye başla” değil, kesintisiz inceleme için veriyi kaybetmemek gerekir.

Dakika 0-2: Erişimi durdur (ama veriyi kaybetmeden)

Aşağıdaki adımların amacı sitenin trafiğini ve/veya saldırganın giriş kanalını kesmektir:

CDN / WAF / proxy varsa (ör. Cloudflare benzeri) ilgili özelliği anlık kapatma yapmadan, yönetim panelinden mevcut güvenlik ayarlarını kontrol edin. Amaç, saldırıyı anlık daha kötüleştirmemektir.
Sunucuda shell erişiminiz varsa:
Web uygulamasının çalıştığı kullanıcıyla oturum açın (ör. www-data, nginx, apache değil; kendi kullanıcı adınız).
Panel/FTP gibi girişleri durdurmak için servis seviyesinde “kapat-aç” yerine önce erişimi kısıtla.
Eğer saldırı devam ediyorsa (sayfalar sürekli değişiyor, yeni dosya akışı var, tarama artıyor):
Varsa fail2ban tetiklerini ve SSH deneme oranlarını kontrol edin.
SSH erişimi gerekiyorsa sadece doğrulanmış IP ile erişimi sınırlandırın.

Net hedef: Saldırganın yeni dosya yükleyemeyeceği bir duruma geçmek. Erişimi keserken logları yok etmeyin.

Dakika 2-5: Kontrol paneli ve web dizininde “ne değişti”yi işaretle

Siteniz hack’lendiğinde izlerin çoğu web dizininde saklanır. İlk beş dakikada dosya karşılaştırması yapmak, ileride temizlik planını hızlandırır.

Şunları hızlıca yapın:

Web root dizinini (ör. /var/www/html veya kontrol panelindeki public_html) tarayın.
Son değişiklik zamanlarını listeleyin:
Dosya/klasör listesinde “en son 1-2 saat içinde oluşturulan”ları işaretleyin.
Özellikle şu dosya türlerini arayın:
*.php içinde şüpheli “base64” veya “eval” kullanımı
*.sh, *.pl gibi script dosyaları
index.php, header.php, functions.php gibi temas/çekirdek dosyalarda beklenmedik değişiklik

Aşağıdaki yaklaşım, temizlemeye başlamadan önce kapsamı görmenizi sağlar.

Dakika 5-7: Log (kayıt) saklama ve saldırı kanıtını toplama

Loglar olmadan “nasıl oldu?” ve “ne etkilendi?” sorularına net cevap veremezsiniz. Sunucu sağlayıcınızın kontrol panelinde log seçenekleri varsa ilk tercih edin.

Web server logları:
Nginx: genelde /var/log/nginx/access.log ve /var/log/nginx/error.log
Apache: genelde /var/log/apache2/access.log ve /var/log/apache2/error.log
Uygulama logları:
PHP-FPM logları (varsa)
WordPress kullanıyorsanız wp-content ve uygulama debug logları
Sistem logları:
SSH girişleri için /var/log/auth.log

Net kural: Logları “sildikten sonra” tekrar almak mümkün değildir. Bu nedenle logları okunur halde bir kopya olarak saklayın.

Dakika 7-10: Veritabanını ve kalıcı erişimi kontrol etme

Saldırganlar sadece web dosyası ile kalmaz; veritabanı şifreleri, admin hesapları veya cron (zamanlanmış görev) ile kalıcı erişim kurabilir.

Veritabanı kullanıyorsanız (MySQL/MariaDB/PostgreSQL):
İlgili kullanıcıların son bağlantılarını kontrol edin.
Şüpheli tablolara (özellikle rastgele isimli) bakın.
Zamanlanmış görevleri kontrol edin:
crontab -l (uygulama kullanıcıları ve root için)
/etc/cron.* klasörleri
Şüpheli servis/arka kapı işaretleri:
Yeni çalışan süreçler (yüksek CPU kullanan scriptler)
Yeni açılan portlar

Net hedef: Saldırganın geri dönmesini sağlayan kapıları tespit etmek.

Hangi sistem etkilenmiş olabilir? Hızlı teşhis matrisi

Aşağıdaki liste, saldırının türüne göre hangi kaynağı önce kontrol etmeniz gerektiğini belirler.

Kod enjeksiyonu / web shell şüphesi

Dosya listesinde sonradan eklenen PHP dosyaları
PHP dosyalarında olağan dışı fonksiyon kullanımı (eval, base64_decode)
Tema/eklentilerde sonradan yapılan küçük ama işlevsel değişiklikler

Site içeriği değiştirme (defacement)

index.php, header.php, footer.php gibi dosyalarda iz bırakacak düzenlemeler
Web root içinde sürüm/dizin değişiklikleri

Saldırı veritabanı üzerinden

Admin kullanıcı şifresi değişimi
Yeni kullanıcı ekleme
Şüpheli içerik tablolarda (CMS’e göre)

Sunucuda kalıcılık (persistence)

Cron/cronjob eklenmiş olması
Yeni SSH key eklenmesi
Sistemde şüpheli ikili dosyalar

Net bir “ilk müdahale” kontrol listesi (kopyala-uygula)

Aşağıdaki kontrol listesi, ilk 10 dakikada bitirilmesi gereken işleri netleştirir.

[ ] Sunucuya ve panele erişim var mı? Varsa saldırıyı büyütmeden erişimi kısıtla.
[ ] Web root içinde son değişiklik zamanlarını listele ve şüpheli dosyaları işaretle.
[ ] Web server loglarını (access/error) kopyala.
[ ] SSH loglarını (auth) kopyala.
[ ] Uygulama/CMS için şüpheli admin değişikliklerini kontrol et.
[ ] Cron ve planlanmış görevleri kontrol et.
[ ] Veritabanında son bağlantı ve şüpheli tablo/işlem izlerini kontrol et.
[ ] Temizleme sırasında “logları silme” kuralını uygula.

Temizleme için doğru yaklaşım: Dosyaları “tek tek düzeltme” yerine doğrulama

Hack temizliğinde en sık yapılan hata, saldırganın bıraktığı tek bir dosyayı silip diğer kalıcı noktaları gözden kaçırmaktır. İlk 10 dakika tamamlandıktan sonra “temizleme” aşamasına geçerken şu prensipleri uygula:

Dosyaları orijinal kaynakla karşılaştır

CMS kullanıyorsanız (WordPress vb.) çekirdek dosyaları resmi sürümle karşılaştırın.
Tema/eklentiler için kaynak kontrol (version) yapın.
Değişiklik zamanı saldırı zamanına yakın olan dosyalar önceliklidir.

Veritabanında şifre ve yetkiyi yeniden doğrula

Uygulamanın kullandığı DB kullanıcılarının yetkilerini gözden geçir.
Saldırı sırasında parolalar sızdıysa DB şifresini değiştir.
Admin hesapları için mümkünse parola sıfırlama + kullanıcı doğrulaması yap.

Kalıcılık vektörlerini kapat

Cronjob’ları temizle.
Kullanıcı eklenmişse yetkileri daralt.
SSH için şüpheli key’leri kaldır.

Hosting tarafında önlem: Bir daha aynı hatayı hızlıca engelle

İlk müdahale bittiğinde, “bir daha olmasın” için atacağınız adımlar teknik olarak ölçülebilir olmalıdır.

Yedek (backup) stratejisi: Doğru geri dönüş süresi (RTO) hedefle

Yedek aldığınızdan emin olun; sadece “var” olması yetmez.
Yedek geri yükleme testi yapın: Son geri yüklemede hata var mı?
Dosya + veritabanı yedeklerini ayrı ayrı kontrol edin.

Erişim kontrolü: SSH ve panel girişlerini standardize et

SSH için şifre girişi yerine key tabanlı erişim standardı uygulayın.
Panel (kontrol paneli) erişiminde IP kısıtı kullanın.
Yönetici hesaplarında parola politikasını netleştirin.

Loglama: Erken uyarı için sinyal toplayın

Web access logları olmadan saldırı başlangıcını geriye dönük tespit etmek zordur.
Sunucu seviyesinde “anormal istek” ve “hızlı dosya değişimi” gibi metrikleri izleyin.

Sonuç: Bugün uygulayın, ilk 10 dakikayı protokole çevirin

Web sitesi hack’lendiğinde ilk 10 dakika, zararı büyütmemek ve sonradan geri dönüşün hızını belirlemek için kritik. Bu rehberdeki adımları bir plan dosyasına dönüştürün: logları nasıl kopyalayacağınız, web root’ta hangi listeyi alacağınız ve hangi kalıcılık noktalarına (cron, SSH key, DB yetkisi) bakacağınız netleşsin. Bu çalışmayı bugün başlayın: en azından kontrol listesi maddelerini iş akışınıza ekleyin ve bir “geri yükleme testi” için yedeklerinizi doğrulayın.