Site hacklendi mi? Önce şunları yapın

Sitenin ana sayfası İngilizce metinli siyah bir sayfaya dönüştü, ya da Google arama sonuçlarının altına "This site may be hacked" yazdı, ya da müşteri arayıp banka kartından ödeme sayfanız üzerinden para çekildiğini söyledi. Bunlardan herhangi biri, sitenin hacklendiği ve şu anda bir karar vermeniz gerektiği anlamına gelir. İlk karar şudur: dosyalara dokunmayın. Şimdi şüpheli dosyaları silmeye başlarsanız, saldırganın izini sonsuza dek yok etme ve iki hafta sonra aynı olayın tekrar yaşanma olasılığı yüksektir.

Doğru sıra dört aşamadan oluşur: kontrol altına alma, kanıtları koruma, temizleme, geri yükleme. Çoğu site yöneticisi birinci ve ikinci aşamayı atlayıp doğrudan üçüncü aşamaya geçer. İşte tam bu noktada işler bozulur.

Birinci aşama: Dosyaları değil, saldırganın erişimini kesin

Bu aşamanın tek amacı vardır: saldırgan artık giremesin. Henüz hiçbir dosyayı silmeyin.

Her şeyden önce hosting panelinin ve alan adı panelinin parolasını değiştirin; hem de bulaşmış olabilecek aynı sistemden değil, başka bir cihazdan. Ardından SSH anahtarlarını kontrol edin:

cat ~/.ssh/authorized_keys

Tanımadığınız her anahtarı silin. Sunucunuz SSH portunu 22'de bırakmışsa ve parola ile kimlik doğrulama etkinse, saldırganın muhtemelen girdiği kapı tam da burasıdır. SSH güvenliği; port değiştirmekten fail2ban ve açık anahtara rehberi tam olarak bu senaryoyu ele alıyor.

Sıra kullanıcılara gelir. MySQL veya MariaDB'de:

SELECT user, host FROM mysql.user;
SELECT user, host, command, time, state FROM information_schema.processlist;

Var olmaması gereken bir kullanıcı ya da yanlış host'tan bağlanan bir kullanıcı, bir veritabanı backdoor'u anlamına gelir. Tüm uygulama kullanıcılarının parolasını değiştirin ve wp-config.php veya benzeri yapılandırma dosyasını güncelleyin.

Site WordPress üzerindeyse, yönetici kullanıcılarını kontrol edin. Saldırgan genellikle anlamsız bir isimle administrator rolüne sahip bir kullanıcı oluşturur:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Şimdi ve ancak şimdi, gerekliyse siteyi genel erişimden çıkarın. Basit bir 503 sayfası yeterlidir; tüm sunucuyu kapatmanıza gerek yok, çünkü sunucuyu kapatmakla canlı logları da kaybedersiniz.

İkinci aşama: Kanıtları temizlemeden önce saklayın

Bu, neredeyse herkesin atladığı ve sonra pişman olduğu aşamadır. Daha sonra siber suçlara şikâyet etmek, sigorta şirketine bildirmek ya da sadece saldırganın nereden geldiğini anlamak isterseniz, tam da bu dosyalara ihtiyacınız olacak.

Her şeyden önce mevcut durumun bir snapshot'ını alın. Sanal veya bulut sunucudaysanız, panelden tam bir snapshot alın ve adına tarihi yazın. Snapshot mevcut değilse, en azından şunları kopyalayın:

tar czf /root/evidence-$(date +%F).tar.gz \
  /var/log/nginx /var/log/apache2 /var/log/auth.log \
  /var/www/html/wp-content/uploads 2>/dev/null

Web sunucusu loglarına bakın ve tuhaf kalıpları arayın. Girdi almaması gereken bir PHP dosyasına yapılan POST isteği ya da bir IP'den gelen olağandışı trafik hacmi:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Bir IP'nin önündeki sayı dört veya beş haneliyse ve diğerleri iki haneliyse, o IP'yi ciddiye alın. Ancak dikkatli olun: saldırı dağıtık türdeyse bu komut işe yarar bir şey göstermez ve zaman aralıklarını analiz etmeye yönelmeniz gerekir. Tam da bu tür saldırılar için DDoS koruması katmanı, trafik web sunucusuna ulaşmadan önce devreye girer.

Değiştirilmiş dosyaları zamanlarıyla bulun. Son sağlam yedeğiniz varsa, karşılaştırmak en basit yoldur:

find /var/www/html -type f -newermt "2024-01-01" -printf "%T+ %p\n" | sort

WordPress'te çekirdek checksum kontrolü, kurcalanmış dosyayı bulmanın en hızlı yoludur:

wp core verify-checksums
wp plugin verify-checksums --all

Bu iki komutun çıktısı genellikle kısa bir dosya listesi verir. Bunları ayırın ve bir kenara koyun; sonra analiz için faydalı olacaklar.

İşte burada hata yapıyorlar

Defalarca gördüğüm yaygın hata: site yöneticisi hemen bulaşmış dosyaları siler, site ayağa kalkar, herkes mutlu olur ve üç hafta sonra tam da aynı siyah sayfa geri döner. Neden? Çünkü saldırgan sadece bir dosya bırakmamıştır. /etc/cron.d/ içinde bir cron job, temanın functions.php dosyasında eklenmiş bir fonksiyon ya da wp_options tablosunda bir satır kalmıştır ve her gece bulaşmış dosyayı yeniden oluşturur. Belirtisi de şudur: dosyayı silersiniz, birkaç saat sonra aynı içerik ve yeni timestamp ile geri döner. Yeniden üretim kaynağını bulana kadar dosyayı silmek işe yaramaz.

Üçüncü aşama: Temiz bir noktadan temizleme

Bulaşmış bir siteyi yerinde temizlemek riskli bir iştir. Sağlam bir yedeğiniz varsa, onu tercih edin. Yoksa şu sırayı izleyin:

1. Çekirdeği ve tüm eklentileri ve temaları sunucudaki mevcut dosyalardan değil, resmi kaynaktan yeniden kurun.
2. uploads veya cache içindeki rastgele adlı her PHP dosyasını silin. Yükleme klasöründe hiçbir çalıştırılabilir dosya olmamalıdır.
3. Veritabanında şüpheli dizeleri arayın: eval(, base64_decode, bilinmeyen alan adıyla <script src=.
4. Yönetici kullanıcılarını gözden geçirin ve hepsinin parolasını değiştirin.
5. API anahtarlarını, ödeme token'larını ve dış servislerin parolalarını iptal edip yeniden oluşturun.

Az söylenen bir nokta: Saldırgan veritabanına eriştiyse, müşteri verilerini kopyalamış olabilir. Bu artık teknik bir mesele değil, hukuki bir meseledir. Veri gizliliği; İran siteleri için pratik rehber, ne zaman ve nasıl bilgilendirme yapmanız gerektiğini açıklıyor.

Dördüncü aşama: Geri yükleme ve giriş açığını kapatma

Siteyi ayağa kaldırdığınızda iş bitmiş değildir. Girişe neden olan aynı açık kalmaya devam ederse, tüm bu çalışmalar tekrarlanır. Mutlaka üç şey yapın:

• PHP, WordPress ve tüm eklentileri en son kararlı sürüme yükseltin. Terk edilmiş eklentileri devre dışı bırakmayın, silin.
• Tüm yönetici hesapları için iki adımlı kimlik doğrulamayı etkinleştirin.
• Yönetim paneline erişimi, ya IP ile ya da ek bir kimlik doğrulama katmanıyla sınırlayın.

Ve çoğu ekibin yapmadığı bir iş: Denetim loglarını açın ve saldırganın silemeyeceği bir yerde saklayın. Nereden başlayacağınızı bilmiyorsanız, Denetim logu nedir ve nasıl bozulmadan korunur? iyi bir başlangıç noktasıdır. Log olmadan, bir dahaki sefere de nereden darbe aldığınızı anlayamazsınız.

Bir ekibiniz varsa ve parolaları sohbet üzerinden paylaşıyorsanız, sorunun köklerinden biri tam da orasıdır. Ekiplerde parola yönetimi; sohbet üzerinden paylaşım neden yasak? yazısını okuyun ve gerçek bir parola yöneticisi kurun.

Ne zaman dışarıdan yardım almalısınız

Siteniz bir e-ticaret sitesiyse ve müşteri verisi barındırıyorsa, ya da iki tur temizlemeden sonra hâlâ bulaşmış dosya geri dönüyorsa, kendi başınıza devam etmeyin. Kötü amaçlı yazılım analizi ve derin temizleme uzmanlık işidir ve maliyeti genellikle bir veri sızıntısının ya da birkaç günlük downtime'ın maliyetinden daha düşük olur. Kritik siteler için ServerNet sunucu güvenliği hizmetleri tam da bu katmanı kapsıyor.

Bir sınırlamayı da dürüstçe söyleyeyim: Hiçbir otomatik temizleme aracı, manuel incelemenin yerini tutmaz. Tarayıcılar bilinen dosyaları bulur, ancak saldırganın özellikle siteniz için yazdığı özel backdoor'ları genellikle görmez. Tarayıcı "temiz" dediyse ve site hâlâ tuhaf davranıyorsa, tarayıcıya güvenmeyin.

Sık sorulan sorular

Site hacklendikten sonra yapmam gereken ilk şey nedir?

Hosting panelinin, alan adı panelinin ve veritabanının parolasını başka bir cihazdan değiştirin ve tanımadığınız SSH anahtarlarını silin. Bu aşamada dosyaları silmeyin, çünkü giriş yöntemini anlamak için gereken kanıtları yok edersiniz.

Siteyi hemen erişimden çıkarmalı mıyım?

Site ziyaretçilere kötü amaçlı içerik sunuyorsa ya da banka kartı bilgileri aktarılıyorsa, evet. Basit bir 503 sayfası yeterlidir ve tüm sunucuyu kapatmaya gerek yoktur, çünkü sunucuyu kapatmakla canlı logları kaybedersiniz.

Saldırganın hangi noktadan girdiğini nasıl anlarım?

Web sunucusu logunu, kimlik doğrulama logunu ve değiştirilmiş dosya listesini birlikte karşılaştırın. WordPress'te wp core verify-checksums komutu, kurcalanmış dosyaları bulmanın en hızlı yoludur. Denetim logu önceden etkin değildiyse, giriş yolunu yeniden oluşturmak daha zor ama imkânsız değildir.

Temizledikten sonra tekrar hacklenmeyeceğimden nasıl emin olurum?

Mutlak bir garanti yoktur, ancak tüm bileşenleri güncelleme, iki adımlı kimlik doğrulama, terk edilmiş eklentileri silme ve denetim loglarının etkin olması kombinasyonu tekrarlanma olasılığını büyük ölçüde azaltır. Bulaşmış dosya silindikten sonra kendi kendine geri dönüyorsa, cron job ya da temada gizli kod gibi bir yeniden üretim kaynağı kalmış demektir.