Sitem Deface Edildi: Ana Sayfam Değiştirildi, Ne Yapmalıyım?

Sabah siteyi açıyorsunuz ve ana sayfanın yerinde siyah zeminli bir ekran, bir imza, bir marş, belki bir Telegram adresi var. Deface saldırısı budur: saldırgan sitenizi çalmaz, satmaz, veriyi sessizce sızdırmaz — sizi ve ziyaretçilerinizi doğrudan karşısına alır, çünkü amacı görünürlüktür. "Sitemi hacklediler ne yapmalıyım" diye arayan çoğu kişi bu ekranı gördükten sonraki ilk beş dakikada arama yapar ve tam o beş dakikada, bilmeden, olayın en kritik kanıtlarını yok eder.

Bu yazı bir tanım yazısı değil, sıralı bir olay müdahalesi rehberidir. Deface'in ne olduğunu bir paragrafta geçip asıl işe — kanıt toplama, siteyi kontrollü kapatma, giriş yolunu bulma, temizleme, kimlik bilgisi rotasyonu, KVKK açısından değerlendirme ve güvenli biçimde yayına dönme — geçeceğiz. Türkçe kaynaklarda neredeyse hiç yazılmayan iki nokta özellikle vurgulanacak: siteyi hemen düzeltip yayına almak kanıtı imha eder ve giriş yolu kapatılmadığı için saldırı aynı gün tekrarlar; ikincisi, kişisel veri barındıran bir sitede deface, sadece teknik değil hukuki bir olaydır.

Deface Saldırısı Nedir ve Neyi Gösterir#

Deface (defacement), sitenin görünen içeriğinin saldırgan tarafından değiştirilmesidir. Genellikle index.php veya index.html üzerine yazılır, bazen tema dosyası değiştirilir, bazen de site köküne saldırganın kendi dosyası bırakılıp sunucu yapılandırmasıyla öne alınır.

Görünürde tek bir dosya değişmiş gibi durur. Ama deface'in size söylediği gerçek şudur: saldırgan dosya yazma yetkisi elde etmiştir. Ana sayfayı değiştirebilen biri, arka kapı bırakabilir, veritabanını okuyabilir, e-posta gönderebilir, aynı sunucudaki diğer sitelere geçebilir. Bu yüzden "index dosyasını yedekten geri kopyaladım, sorun çözüldü" cümlesi teknik olarak yanlıştır; çözülen tek şey, saldırganın görünmesidir. Görünmez hâle gelmiş bir saldırgan, görünen saldırgandan tehlikelidir.

İlk 15 Dakikada Yapmamanız Gereken 4 Şey#

En pahalı hatalar bu ilk dakikalarda yapılır. Sırasıyla:

1. Bozulan dosyayı hemen üzerine yazmayın. O dosyanın son değişiklik tarihi, sahibi ve içeriği, saldırının nasıl geldiğini anlatan tek kanıt olabilir. Üzerine yazdığınız an zaman damgası da içerik de gider.
2. Siteyi "düzelip" yayında bırakmayın. Giriş yolu açıkken ana sayfayı geri koymak, saldırgana aynı gün ikinci kez deface yapma daveti çıkarmaktır. Uygulamada gördüğüm tipik döngü budur: sabah düzeltilir, öğleden sonra tekrar bozulur, akşam üçüncü kez.
3. Logları döndürmeyin, sunucuyu yeniden kurmayın, hesabı silmeyin. Yeniden kurulum "temiz başlangıç" gibi görünür ama nasıl girildiğini asla öğrenemezsiniz; aynı açık yeni kurulumda da vardır.
4. Tüm eklentileri toplu güncelleyip "hallettim" demeyin. Güncelleme, arka kapıyı silmez. Zararlı dosya uploads klasöründe duruyorsa güncel WordPress'te de çalışır.

Adım 1: Kanıt Toplama#

Kanıt toplama beş dakika sürer ve sonraki her adımı kolaylaştırır. Sırayla:

Ekran görüntüsü ve HTTP yanıtı. Bozuk sayfanın ekran görüntüsünü alın, ayrıca ham yanıtı kaydedin:

curl -sD - https://alanadiniz.com/ -o deface-sayfa.html > deface-basliklar.txt

Değişen dosyaların listesi. Hangi dosyaların ne zaman değiştiğini dondurun:

cd /home/kullanici/public_html
find . -type f -newermt "2026-08-09" -printf "%TY-%Tm-%Td %TH:%TM:%TS  %s  %u  %p\n" \
  | sort > ~/kanit-degisen-dosyalar.txt

# Bozulan dosyanın kendisini silmeden kopyalayın
cp -a index.php ~/kanit-index.php
sha256sum index.php >> ~/kanit-hashler.txt

Logların kopyası. Bu, en çok kaybedilen kanıttır. Barındırma tarafında erişim ve hata logları düzenli olarak döner; birkaç gün sonra bakmak istediğinizde silinmiş olur.

mkdir -p ~/olay-loglari
cp -a /home/kullanici/logs/* ~/olay-loglari/ 2>/dev/null
cp -a /var/log/nginx/*access* ~/olay-loglari/ 2>/dev/null
cp -a /var/log/secure ~/olay-loglari/ 2>/dev/null   # SSH giriş denemeleri

Veritabanı ve dosya sistemi anlık kopyası. Temizlik öncesi hâli tamamen saklayın; birazdan yapacağınız silme işlemlerinin geri dönüşü yok.

tar -czf ~/olay-dosyalari-$(date +%F).tar.gz -C /home/kullanici/public_html .
mysqldump -u db_kullanici -p db_adi > ~/olay-db-$(date +%F).sql

Bu paketleri sunucunun dışına, kendi bilgisayarınıza veya bağımsız bir yedek alanına indirin. Sunucuda kalan kanıt, saldırgan hâlâ erişimdeyse kanıt değildir.

Adım 2: Siteyi Kontrollü Biçimde Kapatın#

Siteyi kapatmak, sildiğiniz anlamına gelmez; ziyaretçiye doğru sinyali veren geçici bir duruma almak demektir. Doğru yanıt kodu 503'tür, çünkü arama motorlarına "bu geçici" der ve sıralamanızı korur. Bakım sayfası dönerken kendi IP'nizi dışarıda tutun:

# .htaccess — site kökü
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^88\.77\.66\.55$
RewriteCond %{REQUEST_URI} !^/bakim\.html$
RewriteRule ^(.*)$ /bakim.html [R=503,L]

ErrorDocument 503 /bakim.html
Header always set Retry-After "7200"

Nginx tarafında karşılığı şudur:

location / {
    if ($remote_addr != 88.77.66.55) {
        return 503;
    }
    try_files $uri $uri/ /index.php?$args;
}
error_page 503 /bakim.html;
location = /bakim.html { internal; }

Kapatma yöntemlerinin karşılaştırması:

Saldırı hâlâ devam ediyor, sürekli yeni istek geliyorsa trafiği önce kenarda süzmek mantıklıdır; Cloudflare Under Attack modu bu geçici pencerede işinizi kolaylaştırır. Kapatma sırasında CDN veya önbellek kullanıyorsanız önbelleği de temizleyin, yoksa bozuk sayfa saatlerce servis edilmeye devam eder.

Adım 3: Giriş Yolunu Bulun#

Bu bölüm atlanırsa müdahalenin geri kalanı boşa gider. Elinizde iki veri var: bozulan dosyanın değişim zamanı ve erişim logları. İkisini birleştirin.

cd ~/olay-loglari

# Bozulan dosya 03:47'de değişmişse o dakikadaki tüm POST istekleri
grep "10/Aug/2026:03:4" access.log | grep '"POST' \
  | awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn | head -25

# Aynı IP'nin o günkü tüm hareketi
grep "^203.0.113.44 " access.log | awk '{print $4, $6, $7, $9}' | head -60

# Yükleme uç noktalarına yapılan çağrılar
grep -E "admin-ajax\.php|async-upload|upload\.php|fileupload|\.php\?" access.log | grep '"POST' | tail -40

# SSH tarafı
grep -E "Accepted (password|publickey)" secure | tail -20
grep "Failed password" secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

Aradığınız kalıp neredeyse her zaman aynıdır: bir IP önce bir uç noktaya POST atar (200 veya 302 alır), sonra daha önce hiç var olmayan bir dosyaya GET yapar. O ikinci istekteki dosya yolu, arka kapının adresidir.

Giriş yolları ve loglarda bıraktıkları iz:

Logda hiçbir iz yoksa ve dosya sahibi sizin kullanıcınız değilse, olay sizin siteniz üzerinden değil sunucu üzerinden gelmiştir; bu, paylaşımlı barındırmada komşu hesap açığına işaret eder ve sağlayıcıyla birlikte incelenmesi gerekir.

Adım 4: Temizlik ve Temiz Yedekten Dönüş#

Giriş yolunu bulduktan sonra temizlik iki yoldan biriyle yapılır.

Yol A — Temiz yedekten dönüş (tercih edilen). Elinizde bulaşma tarihinden önceye ait bir yedek varsa en hızlı ve en güvenilir yol budur. Sıralama önemlidir:

1. Açığı kapatın (eklenti güncellemesi, parola değişimi, izin düzeltmesi).
2. Mevcut dizini tamamen boşaltın — üzerine yazmak yetmez, saldırganın eklediği dosyalar kalır.
3. Yedeği açın.
4. Veritabanını yedekten geri yükleyin.
5. Yedekteki WordPress çekirdeğini ve eklentileri güncel sürüme çıkarın.

Yol B — Yerinde temizlik. Temiz yedek yoksa dosyaları elle ayıklamanız gerekir:

# Çekirdek bütünlüğü
wp core verify-checksums
wp plugin verify-checksums --all

# Kökte olmaması gereken dosyalar
find wp-content/uploads -name "*.php"
ls -la wp-content/mu-plugins/ 2>/dev/null

# Şüpheli fonksiyonlar
grep -rn --include="*.php" -E "eval\(|base64_decode\(|gzinflate\(|assert\(" . | head -40

# Sahte yönetici kontrolü
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Deface'in yanında neredeyse her zaman bir arka kapı vardır; ana sayfayı geri koyup arka kapıyı bırakmak en yaygın hatadır. Arka kapı avının tam listesi için yönlendirme zararlısı temizliği yazısındaki bölümü uygulayın; oradaki kontroller (uploads içi PHP, mu-plugins, .user.ini içindeki auto_prepend_file, cron görevleri, uygulama parolaları) deface olayları için birebir geçerlidir. Daha geniş bir kurtarma akışı için hacklenmiş site kurtarma yazısı süreci baştan sona özetler.

Adım 5: Tüm Kimlik Bilgilerini Yenileyin#

Temizlik bittiğinde şu varsayımı yapın: saldırgan sunucudaki her parolayı okumuştur. wp-config.php içinde veritabanı parolası düz metin durur; bir arka kapı o dosyayı okuyabildiyse veritabanı parolası da yanmıştır.

Rotasyon listesi, bu sırayla:

1. Barındırma paneli (cPanel/WHM) parolası
2. Tüm FTP hesapları — kullanılmayanları silin, kullanılanların parolasını yenileyin
3. Veritabanı kullanıcısı parolası (wp-config.php içinde de güncelleyin)
4. SSH parolası; ~/.ssh/authorized_keys dosyasındaki tanımadığınız anahtarları silin
5. Tüm WordPress yönetici parolaları
6. Alan adı kayıt firması ve DNS paneli hesabı
7. Sitede tanımlı SMTP/e-posta hesapları

Parola değiştirmek açık oturumları kapatmaz. WordPress'te oturumları düşürmek için güvenlik anahtarlarını yenileyin:

wp config shuffle-salts
wp user session destroy --all --all-users

Bu iki komut, saldırganın elinde geçerli bir çerez kalmasını engeller. Aynı mantıkla API anahtarlarını, ödeme sağlayıcısı entegrasyon bilgilerini ve varsa uygulama parolalarını da yenileyin.

KVKK Açısından Değerlendirme: Bu Sadece Teknik Bir Olay Değil#

Türkçe kaynakların tamamen atladığı kısım burasıdır. Siteniz üye kaydı, iletişim formu, sipariş bilgisi ya da e-posta listesi tutuyorsa, sisteme yetkisiz erişim sağlanmış olması KVKK kapsamında bir veri ihlali ihtimali doğurur. Deface görünürde sadece ana sayfayı etkilemiş olsa bile, dosya yazma yetkisi elde eden bir saldırgan veritabanını da okuyabilir; dolayısıyla "sadece ana sayfa değişmişti" demek, teknik olarak ispatlanması gereken bir iddiadır.

Yapmanız gerekenler:

• Kapsamı belirleyin. Veritabanına erişim izi var mı? Erişim logunda phpMyAdmin, adminer, .sql uzantılı dosya indirme ya da olağandışı büyüklükte yanıt var mı? Bunları arayın:

grep -iE "adminer|phpmyadmin|\.sql|dump|backup.*\.zip" access.log | grep -v " 404 " | tail -40

• Bulgularınızı yazılı hâle getirin. Olay zaman çizelgesi (ilk erişim, deface anı, tespit anı, kapatma anı), etkilenen sistemler, alınan önlemler. Bu kayıt hem sağlayıcıyla iletişimde hem olası bir bildirimde işinizi görür.
• Veri sorumlusu iseniz bildirim yükümlülüğünü değerlendirin. KVKK'ya göre veri ihlali öğrenildiğinde en kısa sürede Kişisel Verileri Koruma Kurulu'na bildirim yapılması, ayrıca ilgili kişilerin bilgilendirilmesi gerekir. Sürenin ve kapsamın kendi durumunuza uygulanmasını bir hukukçuya danışarak netleştirin; bu yazı hukuki görüş değildir.
• Şifre sıfırlama duyurusu yapın. Üye parolaları hash'li saklansa bile, ihlal şüphesi varsa kullanıcılara parola değiştirmelerini önermek doğru ve düşük maliyetli bir adımdır.

Adım 6: Güvenli Biçimde Yayına Dönün ve İzleyin#

Yayına almadan önce şu kontrol listesini geçin:

1. Giriş yolu kapatıldı mı (açık eklenti güncellendi/kaldırıldı, parola yenilendi)?
2. find . -name "*.php" -newermt "olay tarihi" çıktısında tanımadığınız dosya kaldı mı?
3. Yönetici listesinde tanımadığınız kullanıcı var mı?
4. Cron görevleri temiz mi (wp cron event list, crontab -l)?
5. Dosya izinleri doğru mu (dizin 755, dosya 644, wp-config.php 640, hiçbir yerde 777 yok)?
6. Yedekleme çalışıyor ve yedek sunucudan bağımsız bir yerde mi duruyor?

Yayına aldıktan sonra ilk 72 saat izleme kritiktir. Basit ama etkili bir kontrol:

# Her saat çalışacak dosya değişim kontrolü
find /home/kullanici/public_html -name "*.php" -mmin -60 -newer /home/kullanici/.izleme-damgasi \
  && touch /home/kullanici/.izleme-damgasi

Kalıcı sertleştirme tarafında HTTP güvenlik başlıklarını devreye almak, yönetim paneline erişimi IP ile sınırlamak ve başarısız giriş denemelerini otomatik engelleyen bir araç kurmak, aynı saldırının tekrarını büyük ölçüde önler.

Sıkça Sorulan Sorular#

Deface saldırısında verilerim çalınmış olur mu#

Muhtemelen evet, en azından bunu varsaymanız gerekir. Ana sayfayı değiştirebilen bir saldırgan sunucuda dosya yazma yetkisine sahiptir; bu yetki genellikle wp-config.php dosyasını okuyabilmek, dolayısıyla veritabanı erişimi elde edebilmek anlamına gelir. Erişim loglarında veritabanı yönetim araçlarına, .sql indirmelerine veya olağandışı büyük yanıtlara bakarak kapsamı daraltabilirsiniz. Kesin bir kanıt bulamıyorsanız da kişisel veri barındıran bir sitede ihlal ihtimalini yok saymak doğru bir yaklaşım değildir.

Siteyi hemen düzeltip yayına alsam ne olur#

Büyük olasılıkla aynı gün içinde tekrar deface edilirsiniz. Ana sayfayı geri yüklemek, saldırganın kullandığı giriş yolunu ve bıraktığı arka kapıyı ortadan kaldırmaz; sadece görünen sonucu siler. Ayrıca bozulan dosyanın üzerine yazdığınız için zaman damgası ve içerik kanıtını kaybedersiniz, bu da giriş yolunu bulmayı ciddi biçimde zorlaştırır. Doğru sıra, önce kanıt almak, sonra kapatmak, sonra giriş yolunu bulup kapatmak ve en son yayına dönmektir.

Deface saldırısını kim yapıyor ve neden hedef seçildim#

Çoğu deface, belirli bir siteyi hedefleyen kişisel bir saldırı değil, otomatik taramaların sonucudur. Saldırganlar internet üzerinde bilinen açığa sahip eklenti veya sürümleri toplu tarar, bulduğu her siteye aynı istismarı uygular ve başarılı olanlara imzasını bırakır. Bu yüzden "benim küçük sitem kimin ilgisini çeker" düşüncesi yanıltıcıdır; seçilme kriteriniz büyüklüğünüz değil, açığınız oldu. Bunun tek istisnası, kurumsal ya da siyasi görünürlüğü olan sitelere yapılan hedefli saldırılardır.

Yedeğim yok, ne yapabilirim#

Yedeğiniz yoksa yerinde temizlik yapmanız gerekir ve bu daha uzun sürer ama mümkündür. WordPress çekirdeğini resmi arşivden indirip wp-content ve wp-config.php hariç her şeyi değiştirin, eklenti ve temaları temiz kaynaktan yeniden kurun, wp-content/uploads klasörünü PHP dosyaları için tarayıp temizleyin, veritabanında enjekte edilmiş script aramasını yapın. Barındırma sağlayıcınızda otomatik sunucu yedeği olabileceğini de sormadan geçmeyin; birçok pakette günlük anlık kopyalar tutulur ve bu, saatlerce sürecek bir temizliği dakikalara indirebilir.

Google sitemi cezalandırır mı#

Deface tespit edilirse arama sonuçlarında "Bu site saldırıya uğramış olabilir" etiketi çıkabilir ve zararlı içerik tespit edilirse tarayıcı uyarısı devreye girer. Etiket, tıklama oranınızı ciddi biçimde düşürür ama temizlik sonrası Search Console üzerinden inceleme talebiyle kaldırılabilir. Bu sırada siteyi 503 ile kapatmış olmanız sıralamanız açısından güvenli tarafta kalmanızı sağlar; 404 veya 200 dönen bozuk bir sayfa, geçici kapatmadan çok daha zararlıdır. Bozuk sayfaların dizine girmiş olması hâlinde temizlik sonrası yeniden taranmayı hızlandırmak için sitemap gönderimi yapın.

Saldırganın IP adresini bulup şikayet edebilir miyim#

IP adresini erişim loglarından bulabilirsiniz ancak bu adres çoğunlukla VPN, ele geçirilmiş başka bir sunucu ya da proxy'ye aittir, dolayısıyla saldırganı doğrudan göstermez. Yine de topladığınız kanıtlar — log kayıtları, dosya zaman damgaları, bozulan sayfanın kopyası — resmî şikâyet sürecinde talep edilir, bu yüzden düzenli biçimde saklanmalıdır. Suç duyurusunda bulunmak istiyorsanız kanıtları değiştirmeden, tarih ve saat bilgisiyle birlikte teslim edin. Teknik müdahaleyi bu süreci beklemeden yapabilirsiniz; kanıtın kopyasını almış olmanız yeterlidir.

Paylaşımlı hostingdeyim, komşu siteden mi bulaştı#

Mümkündür ve ayırt edilebilir bir izi vardır: kendi erişim loglarınızda saldırıya işaret eden hiçbir istek yokken dosyalarınızın değişmiş olması, özellikle de değişen dosyaların sahibinin sizin kullanıcınız olmaması bu senaryoyu düşündürür. Bu durumda müdahale sizin elinizde değildir; sağlayıcıya bulguları iletip sunucu genelinde inceleme talep etmeniz gerekir. Tekrarını önlemenin en kalıcı yolu, hesabınızı kaynağı ve dosya sistemi izole bir sunucuya taşımaktır; komşu hesabın açığı sizi etkilemez hâle gelir.

Kapanış#

Deface saldırısında paniğin yönlendirdiği her hareket geri dönüşü zor bir hata üretir: dosyayı üzerine yazmak kanıtı, siteyi hemen açmak günü, "temizledim" varsayımı ise haftayı kaybettirir. Doğru akış her zaman aynıdır — kanıt al, 503 ile kapat, logdan giriş yolunu bul, açığı kapat, temizle veya temiz yedekten dön, tüm parolaları ve oturumları yenile, kişisel veri boyutunu değerlendir, kontrollü biçimde aç ve 72 saat izle. Bu sekiz adımı sırasıyla uygulayan bir müdahalede saldırının tekrar etme ihtimali dramatik biçimde düşer; adım atlandığında ise ikinci deface neredeyse kaçınılmazdır.

Bu süreci tek başınıza yürütmek istemiyorsanız Clou.TR tarafında yardımcı olabilecek birkaç başlık var: kurulum, sertleştirme ve olay sonrası kontrolleri sizin yerinize üstlenen sunucu yönetimi hizmeti, açığa yönelik istekleri uygulamaya ulaşmadan eleyen WAF, saldırı anında trafiği kenarda süzen DDoS koruma ve en önemlisi, "temiz yedeğim var mı" sorusuna her zaman evet dedirten sunucudan bağımsız yedekleme altyapısı.