Hacklenmiş Bir Site Nasıl Kurtarılır?

Ekranda "Bu site hacklendi" yazan siyah bir sayfa görmek ya da Google'ın arama sonuçlarında sitenizin altına "Bu site cihazınıza zarar verebilir" uyarısı düşürdüğünü fark etmek, bir site sahibinin yaşayabileceği en sinir bozucu anlardan biridir. İlk refleks genellikle paniğe kapılıp bir şeyleri hemen silmek, tema dosyalarını rastgele değiştirmek ya da barındırma firmasını arayıp "sitem gitti" demek olur. Oysa bir ihlalin ardından yapılacak ilk hamleler, kurtarmanın ne kadar süreceğini ve saldırganın geri gelip gelmeyeceğini belirleyen en kritik kararlardır. Aceleyle atılan yanlış bir adım, saldırganın nasıl girdiğine dair kanıtları yok edebilir ya da temizlik bittikten sonra bile arka kapının açık kalmasına yol açabilir.

Bu rehberde bir olaya müdahale ederken izlediğim sırayı, yıllardır sunucularda gördüğüm gerçek senaryolara dayanarak adım adım aktaracağım. Önce siteyi güvenli biçimde izole edip kanıt toplamayı, ardından zararlı dosyaları ve enjekte edilmiş kodu bulmayı, temiz bir yedekten geri dönmekle elle temizlik arasında nasıl seçim yapacağınızı, en sonunda da tüm parolaları sıfırlayıp sistemi yamalayarak siteyi yeniden — ama bu kez daha sağlam — ayağa kaldırmayı ele alacağız. Amaç yalnızca siteyi çalışır hale getirmek değil; saldırganın kullandığı kapıyı da kalıcı olarak kapatmaktır.

İlk 60 Dakika: Siteyi İzole Edin, Silmeyin#

Bir ihlali fark ettiğiniz ilk anda vermeniz gereken en önemli karar, siteyi tamamen silmek değil izole etmektir. İzole etmek, saldırganın erişimini kesmek ve zararın büyümesini durdurmak demektir; ama aynı zamanda saldırganın izlerini de olduğu gibi korumak demektir. Sitenizi hemen formatlarsanız, saldırganın nasıl girdiğini asla öğrenemez ve büyük ihtimalle aynı açığı açık bırakarak yeniden hacklenirsiniz.

Pratikte izolasyonun en temiz yolu, siteyi geçici olarak çevrimdışı almaktır. Paylaşımlı bir hosting kullanıyorsanız web kökündeki .htaccess dosyasıyla siteyi kendi IP'niz dışındaki herkese kapatabilir, kendi VDS/VPS sunucunuzu yönetiyorsanız web sunucusunu tek bir bakım sayfasına yönlendirebilirsiniz. Aşağıdaki .htaccess bloğu, siteyi ziyaretçilere kapatırken yönetici olarak sizin erişiminizi açık tutar:

# Siteyi bakıma al — yalnızca kendi IP'niz erişebilir
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.45$
RewriteRule .* /bakim.html [R=503,L]

İzolasyon sırasında yapılması gerekenlerin sırasını şöyle özetleyebiliriz. Önce siteyi ziyaretçilere kapatın; böylece kötü amaçlı yönlendirmeler, kripto madenciliği scriptleri ya da ziyaretçilere yayılan zararlı içerik durur. Ardından cron görevlerini geçici olarak durdurun, çünkü saldırganlar sık sık zamanlanmış görevlere kendilerini yeniden enfekte edecek komutlar yerleştirir. Sunucuya FTP/SSH ile bağlanan tüm oturumları kapatın ve mümkünse sunucunun giden bağlantılarını (özellikle 25, 6667 gibi spam/IRC portları) kısıtlayın. Bu aşamada henüz hiçbir dosyayı silmiyoruz; sadece kanamayı durduruyoruz.

Kanıt Toplama ve Olayın Kapsamını Anlama#

Siteyi durdurduktan sonraki iş, temizliğe başlamadan önce ortamın bir "fotoğrafını" çekmektir. Bu adım çoğu kişinin atladığı ama kurtarmanın kaderini belirleyen adımdır: elinizde bozulmamış bir kopya ve zaman damgalı loglar yoksa, saldırganın nereden girdiğini kör tahminle aramak zorunda kalırsınız. Önce bütün dosya sistemini ve veritabanını, "kirli haliyle" ayrı bir yere yedekleyin. Evet, virüslü halini de saklıyoruz; çünkü hangi dosyanın ne zaman değiştirildiğini ancak bu kopya üzerinden analiz edebilirsiniz.

Sunucuya SSH erişiminiz varsa, son değiştirilen dosyaları listelemek olayı anlamanın en hızlı yoludur. Saldırganlar dosyalara dokunduğunda değişiklik zamanı (mtime) güncellenir; bu yüzden son birkaç güne ait değişiklikler genellikle enfeksiyonun izidir:

# Son 5 günde değiştirilen tüm PHP dosyalarını, en yenisi üstte olacak şekilde listele
find /var/www/html -name "*.php" -mtime -5 -printf "%T+ %p\n" | sort -r | head -50

# Web kökünde son 48 saatte değiştirilen HER dosya (uzantı fark etmeksizin)
find /var/www/html -type f -mmin -2880 -ls

Aynı anda web sunucusunun erişim ve hata loglarını inceleyin. Saldırının hangi tarihte, hangi IP'den ve hangi URL üzerinden geldiğini çoğunlukla burada bulursunuz. Örneğin bir dosya yükleme açığı kullanıldıysa, log'da POST /wp-content/uploads/....php gibi olağandışı bir istek görürsünüz:

# Erişim logunda .php içeren POST isteklerini ve şüpheli sorguları ara
grep -E "POST .*\.php" /var/log/nginx/access.log | grep -Ei "uploads|tmp|cache|eval|base64"

# En çok istek yapan ilk 15 IP'yi çıkar — saldırgan IP'sini yakalamak için
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -15

Bu aşamanın sonunda üç soruya cevap arıyoruz: Ne zaman girdiler, nereden girdiler ve nereye dokundular. Bu üç cevap, birazdan yapacağımız temizliğin hedefini daraltır. Değiştirilme tarihlerini not edin; birazdan temiz yedeği seçerken bu tarih, "hangi yedek hâlâ temiz" sorusunun anahtarı olacak.

Zararlı Kodu, Enjekte İçeriği ve Arka Kapıları Bulma#

Kanıtlar elimizdeyken artık zararlı yükü avlamaya başlayabiliriz. Web saldırılarının büyük çoğunluğu birkaç ortak imzayı taşır: kodu gizlemek için kullanılan base64_decode, eval, gzinflate, str_rot13 gibi fonksiyonlar ve uzaktan komut çalıştırmaya yarayan system, shell_exec, passthru çağrıları. Bunları toplu halde taramak, enfekte dosyaların çoğunu birkaç dakikada ortaya çıkarır:

# Klasik gizlenmiş/backdoor imzalarını web kökünde ara
grep -RnE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(|shell_exec\(|passthru\(|assert\(" \
  /var/www/html --include="*.php"

# Uploads gibi olmaması gereken yerlerdeki PHP dosyaları — neredeyse her zaman arka kapıdır
find /var/www/html/wp-content/uploads -name "*.php" -type f

Enjekte edilmiş kod her zaman ayrı bir dosyada olmaz; çoğu zaman meşru bir dosyanın en başına ya da en sonuna tek satırlık bir yük olarak yapıştırılır. WordPress kullanıyorsanız wp-config.php, index.php, tema functions.php dosyası ve wp-load.php en sık kirletilen hedeflerdir. Bir dosyanın ilk satırında <?php @eval($_POST[...]) benzeri bir ifade görürseniz, bu tartışmasız bir arka kapıdır. Arka kapılar (backdoor) bu işin en sinsi tarafıdır: asıl açığı kapatsanız bile, gözden kaçan tek bir arka kapı saldırganın istediği zaman geri dönmesini sağlar. Bu yüzden temizlik ile arka kapı avı ayrı ayrı düşünülmelidir.

Veritabanına enjekte edilen içerik de sık görülür; özellikle SEO spam saldırıları gönderi içeriğine ya da ayarlara gizli linkler, iframe'ler ve yönlendirme scriptleri ekler. WordPress'te bunu şu sorgularla tarayabilirsiniz:

-- Gönderi içeriğine gizlenmiş script/iframe enjeksiyonlarını ara
SELECT ID, post_title FROM wp_posts
WHERE post_content LIKE '%<script%' OR post_content LIKE '%<iframe%';

-- Ayarlara sızmış şüpheli yönlendirme/enjeksiyon değerleri
SELECT option_id, option_name FROM wp_options
WHERE option_value LIKE '%base64%' OR option_value LIKE '%eval(%';

Bu taramalar sırasında bulduğunuz her şüpheli dosyanın ve satırın yolunu bir listeye kaydedin. Bu liste, birazdan vereceğiniz "yedekten dön" ya da "elle temizle" kararında ne kadar ağır bir enfeksiyonla karşı karşıya olduğunuzu gösterecek. WordPress'e özgü daha derin bir sertleştirme kontrol listesi için WordPress güvenliği rehberimize de göz atmanızı öneririm.

Temiz Yedekten Geri Dönüş mü, Elle Temizlik mi?#

Kurtarmanın kalbindeki soru şudur: enfekte siteyi tek tek temizlemeye mi çalışacaksınız, yoksa saldırıdan önceki temiz bir yedeğe mi döneceksiniz? Cevap büyük ölçüde iki şeye bağlıdır: elinizde enfeksiyon tarihinden önceye ait bir yedeğin olup olmadığı ve o yedeğe döndüğünüzde kaybedeceğiniz güncel verinin (yeni siparişler, üye kayıtları, yorumlar) miktarı. Aşağıdaki tablo, hangi durumda hangi yolun daha mantıklı olduğunu özetler:

Genel kural şudur: enfeksiyon tarihinden kesinlikle önce alınmış, doğrulanabilir bir yedeğiniz varsa, her zaman yedekten dönüş tercih edilir. Çünkü elle temizlikte tek bir arka kapıyı bile atlarsanız her şey boşa gider; temiz yedek ise en baştan güvenilir bir zemin verir. Ancak yedeğiniz yoksa, yedeğiniz de enfeksiyon tarihinden sonra alınmışsa (yani o da kirliyse) veya döndüğünüzde katlanamayacağınız kadar veri kaybedecekseniz, elle temizlik kaçınılmaz olur. Bir ara yol da mümkündür: temiz yedekten dönün, sonra yalnızca aradaki güncel veriyi (örneğin son siparişleri) veritabanı düzeyinde ve dikkatle dışarıdan aktarın. Düzenli, tarihli yedeklerin bir olay anında sizi nasıl kurtardığını görmek için cPanel yedekleme rehberimizi mutlaka okuyun; kurtarmanın en kolay olduğu senaryo, elinizde hazır temiz yedeğin bulunduğu senaryodur.

Elle Temizlik: Dosyalar, Veritabanı ve Arka Kapılar#

Yedekten dönmek mümkün değilse elle temizliğe geçeriz. Buradaki felsefe "şüpheli satırları tek tek silmek" değil, bilinen-iyi kaynağı yeniden yerleştirmek olmalıdır. WordPress, Joomla gibi popüler sistemlerde çekirdek (core) dosyaları herkeste aynıdır; bu yüzden en güvenli yol, çekirdeği ve eklenti/temaları resmî kaynaktan indirdiğiniz temiz sürümlerle tamamen değiştirmektir. Kendi yazdığınız özel kodu değiştiremezsiniz; onu ise yukarıda topladığınız imzalarla satır satır incelemeniz gerekir.

WordPress için pratik akış şöyledir: wp-admin ve wp-includes klasörlerini komple silip resmî ZIP'ten gelen temiz sürümle değiştirin; kök dizindeki index.php, wp-load.php, wp-settings.php gibi çekirdek dosyalarını da aynı şekilde yenileyin. wp-config.php dosyanızı silmeyin ama açıp en baştan sona zararlı ekleme olup olmadığını kontrol edin. Ardından tüm eklenti ve temaları silip yalnızca ihtiyaç duyduklarınızı temiz kaynaktan yeniden kurun — kullanmadığınız, aylardır güncellenmeyen eklentiler zaten saldırı yüzeyinizdir. wp-content/uploads altında bulduğunuz her .php dosyasını silin; bu klasörde çalıştırılabilir kod olmaması gerekir.

Temizlik bittikten sonra bir kez daha, en sinsi kısma — arka kapılara — dönün. Aşağıdaki komut, dünyaya yazılabilir izinlere sahip PHP dosyalarını ve şüpheli konumdaki scriptleri bulmanıza yardımcı olur:

# 777 gibi aşırı geniş izinli dosyalar — sık sık arka kapı yuvasıdır
find /var/www/html -type f -perm -o+w -name "*.php" -ls

# Rastgele isimli, tarih damgası tutmayan şüpheli dosyaları gözden geçir
find /var/www/html -name "*.php" -mtime -30 | sort

Bir sonraki adımda uploads gibi kullanıcı içeriği klasörlerinde PHP çalışmasını sunucu düzeyinde engelleyin. Böylece ileride bir dosya yükleme açığı istismar edilse bile, yüklenen kod çalıştırılamaz. Nginx için bu koruma tek bir location bloğuyla sağlanır:

# uploads içindeki hiçbir PHP dosyasının çalışmasına izin verme
location ~* /wp-content/uploads/.*\.php$ {
    deny all;
    return 403;
}

Elle temizlik zahmetli ve hataya açık bir süreçtir; bu yüzden düzenli bakım altında olmayan bir siteyi tek başınıza kurtarmaya çalışmak yerine profesyonel destek almayı düşünebilirsiniz. Clou.TR'nin WordPress bakım hizmeti tam da bu tür zararlı yazılım temizliği ve sürekli izleme işini üstlenir.

Tüm Parolaları Sıfırlama ve Yamalama#

Site dosyaları temizlendiğinde iş bitmiş sayılmaz; çünkü saldırgan büyük ihtimalle en az bir parolayı ele geçirmiştir. Bu aşamada kural nettir: erişimi olan her şeyin parolasını sıfırlayın, sadece şüphelendiklerinizi değil. Bu; hosting/cPanel paneli parolası, tüm FTP ve SFTP hesapları, veritabanı kullanıcı parolası, WordPress yönetici hesapları, e-posta hesapları ve varsa API anahtarlarını kapsar. Veritabanı parolasını değiştirdiğinizde wp-config.php içindeki DB_PASSWORD değerini de güncellemeyi unutmayın.

WordPress'te yeni oluşturulmuş, sizin tanımadığınız yönetici hesaplarını da temizlemelisiniz; saldırganlar sık sık kendilerine gizli bir admin hesabı açar. Bunu SQL ile kontrol edip yönetici parolalarını sıfırlayabilirsiniz:

-- Tüm yönetici (administrator) hesaplarını listele — tanımadığın varsa kaldır
SELECT u.ID, u.user_login, u.user_email FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%';

Parolaları güçlü ve benzersiz seçin; her hesap için farklı, uzun bir parola kullanın ve mümkün olan her yerde iki faktörlü doğrulamayı (2FA) devreye alın. Parola sıfırlama bittiğinde sıra yamalamaya gelir. Kanıt toplama aşamasında saldırganın giriş yolunu tespit ettiyseniz, o açığı kapatmak artık zorunlu: güncel olmayan WordPress çekirdeğini, eklentileri ve temaları en son sürüme yükseltin; işletim sistemi ve web sunucusu paketlerinizi güncelleyin. Yamalanmamış tek bir eklenti bile, tüm temizliği birkaç gün içinde boşa çıkarır. Bu adımı atlarsanız saldırgan aynı kapıdan tekrar girer ve döngü baştan başlar.

Sonrası: Sertleştirme ve Yeniden Enfeksiyonu Önleme#

Site temiz, parolalar yeni ve açık yamalı olduğunda, kurtarmanın son ama en kalıcı aşamasına geçebiliriz: bir daha aynı şeyin yaşanmaması için sistemi sertleştirmek. Buradaki hedef, saldırı yüzeyini daraltmak ve gelecekte bir sorun çıktığında erken haber almaktır. İlk yapılacak, düzenli ve sunucu dışında saklanan otomatik yedeklerdir; çünkü bugün kurtulduysanız bile bir sonraki olayda en büyük dostunuz temiz bir yedek olacaktır.

Uygulamanız önüne bir Web Uygulama Güvenlik Duvarı (WAF) koymak, bilinen istismar denemelerinin çoğunu daha sunucuya ulaşmadan eler. Benzer şekilde tüm trafiği HTTPS'e taşımak ve güçlü bir SSL yapılandırması kullanmak, oturum çalma ve araya girme saldırılarını zorlaştırır. Dosya izinlerini olması gereken en dar seviyeye çekin: dizinler için 755, dosyalar için 644 iyi bir başlangıçtır ve wp-config.php gibi hassas dosyalar 640 ya da daha sıkı olmalıdır.

# WordPress için güvenli varsayılan izinler
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 640 /var/www/html/wp-config.php

Son olarak bir izleme ve tespit katmanı kurun. Dosya bütünlüğü izleme (bir dosya beklenmedik şekilde değişirse haber veren araçlar), başarısız giriş denemelerini engelleyen brute-force koruması ve düzenli zararlı yazılım taraması, bir sonraki saldırıyı gün geçmeden yakalamanızı sağlar. Sertleştirme tek seferlik bir iş değil, süreklilik ister. Güçlü bir altyapıya taşınmak da işin önemli bir parçası: kaynakları izole edilmiş bir VDS sunucu ya da yönetimli sunucu hizmeti, paylaşımlı ortamların komşu sitelerden bulaşma riskini büyük ölçüde ortadan kaldırır. Trafiğinizi kalkan altına almak için WAF ve DDoS koruması çözümlerini, güvenli sertifika için SSL hizmetini değerlendirebilir; taşınma sürecinde de site taşıma desteğinden yararlanabilirsiniz.

Sıkça Sorulan Sorular#

Sitem hacklendi, ilk olarak ne yapmalıyım?#

İlk hamle siteyi silmek değil izole etmek olmalıdır. Siteyi ziyaretçilere geçici olarak kapatın, cron görevlerini durdurun ve dosyaların "kirli" halini de dahil olmak üzere tam bir yedek alın; böylece hem zarar büyümesini durdurur hem de saldırganın nasıl girdiğini gösteren kanıtları korumuş olursunuz. Kanıt toplamadan yapılan aceleci silmeler, aynı açıktan tekrar hacklenmenize yol açar.

Hacklenmiş siteyi yedekten geri dönerek mi yoksa elle temizleyerek mi kurtarmalıyım?#

Enfeksiyon tarihinden kesinlikle önce alınmış, temiz olduğundan emin olduğunuz bir yedeğiniz varsa her zaman yedekten dönüş tercih edilir; çünkü elle temizlikte tek bir arka kapıyı atlamak bile tüm işi boşa çıkarır. Yedeğiniz yoksa, yedeğiniz de kirliyse ya da geri dönünce çok fazla güncel veri kaybedecekseniz elle temizlik kaçınılmaz olur. İki yolu enfeksiyonun ağırlığına ve elinizdeki yedeğe göre değerlendirin.

Arka kapı (backdoor) nedir ve neden ayrıca temizlemem gerekiyor?#

Arka kapı, saldırganın asıl açığı kapatsanız bile sunucuya istediği zaman geri dönmesini sağlayan gizli bir koddur; genellikle meşru bir dosyanın içine ya da uploads gibi beklenmedik bir klasöre yerleştirilir. Görünen zararlı yükü temizleseniz bile gözden kaçan tek bir arka kapı, saldırganın günler içinde geri dönmesi için yeterlidir. Bu yüzden temizlik ile arka kapı avını ayrı adımlar olarak ele almak şarttır.

Temizlik sonrası hangi parolaları değiştirmeliyim?#

Yalnızca şüphelendiklerinizi değil, erişimi olan her şeyin parolasını sıfırlayın. Bu; hosting/cPanel paneli, tüm FTP ve SFTP hesapları, veritabanı kullanıcısı, WordPress yönetici hesapları, e-posta hesapları ve varsa API anahtarlarını kapsar. Veritabanı parolasını değiştirdiğinizde yapılandırma dosyanızdaki değeri de güncellemeyi ve mümkün olan her yerde iki faktörlü doğrulamayı açmayı unutmayın.

Aynı sitenin tekrar hacklenmesini nasıl önlerim?#

Yeniden enfeksiyonu önlemenin özü, saldırganın kullandığı açığı yamalamak ve saldırı yüzeyini daraltmaktır. Çekirdek, eklenti ve temaları güncel tutun, kullanmadıklarınızı silin, dosya izinlerini daraltın, uploads klasöründe PHP çalışmasını engelleyin ve önünüze bir WAF koyun. Buna düzenli sunucu-dışı yedekler, dosya bütünlüğü izleme ve zararlı yazılım taramasını eklerseniz, bir sonraki denemeyi daha ilk gününde yakalarsınız.

Site hacklenince Google beni cezalandırır mı, sıralamam düşer mi?#

Evet, hacklenmiş bir site arama sonuçlarında "Bu site zarar verebilir" uyarısıyla işaretlenebilir ve trafiğinizin büyük kısmını kaybedebilirsiniz. İyi haber şu ki bu ceza kalıcı değildir: siteyi tamamen temizleyip açığı kapattıktan sonra Google Search Console üzerinden yeniden inceleme (review) talep edebilirsiniz. Temizlik eksiksiz yapıldıysa uyarı genellikle birkaç gün içinde kalkar ve sıralamalar zamanla toparlanır.

Kapanış#

Bir siteyi hacklendikten sonra kurtarmak, aslında disiplinli bir sıralamanın işidir: önce izole et, sonra kanıt topla, zararlı kodu ve arka kapıları bul, temiz yedekten dön ya da elle temizle, tüm parolaları sıfırla, açığı yamala ve en sonunda bir daha yaşanmaması için sertleştir. Bu adımları atlamadan izlerseniz, panikle geçen ilk saatler yerini kontrollü ve kalıcı bir kurtarmaya bırakır. Unutmayın, en ucuz ve en hızlı kurtarma senaryosu, olay yaşanmadan önce yapılan hazırlıkla — düzenli temiz yedekler, güncel yazılım ve güçlü bir altyapıyla — mümkün olur.

Sitenizi daha güvenli bir zemine taşımak isterseniz Clou.TR olarak yanınızdayız. İzole kaynaklı WordPress hosting ve web hosting paketlerimiz, otomatik yedekleme, WAF ve WordPress bakım hizmetlerimizle sitenizi hem kurtarır hem de bir daha hacklenmeyecek şekilde sertleştiririz. Kalıcı bir çözüm için hosting ve güvenlik paketlerimizi inceleyebilir, taşınma ya da temizlik konusunda ekibimizden destek isteyebilirsiniz.