Sitenizi temizlediniz, yönlendirmeler bitti, şüpheli dosyalar silindi. Şimdi en sık atlanan ama en önemli adım geliyor: saldırganın içeri girdiği kapıyı kapatmak ve bir daha girmesini zorlaştırmak. Temizlik yapılıp açık kapatılmazsa aynı site kısa süre sonra yeniden ele geçirilebilir; çünkü siteyi bulan otomatik araçlar aynı açığı tekrar dener.
Bu yazı, temizlikten sonra uygulanacak bir sertleştirme kontrol listesidir. Öneriler WordPress'in resmi "Hardening WordPress" ve "Brute Force Attacks" belgelerine ve Google'ın kötü amaçlı yazılımı önleme rehberine dayanır. Her maddeyi sırayla uygulayın; hepsini aynı gün bitirmek zorunda değilsiniz ama ilk bölümdeki şifre ve anahtar adımlarını ertelemeyin.
Önce kontrol: temizlik gerçekten bitti mi?

Sertleştirme, temiz bir sitenin üzerine yapılırsa anlamlıdır. İçeride bir arka kapı dosyası kalmışsa yeni şifreler de işe yaramaz. Başlamadan önce şunlardan emin olun:
- WordPress hacklendi temizleme rehberimizdeki adımları tamamladınız: çekirdek dosyalar temiz kopyayla değiştirildi, eklenti ve temalar resmi kaynaklarından yeniden kuruldu.
- Şüpheli PHP dosyası ve web shell taramasını yaptınız; özellikle wp-content/uploads içinde PHP dosyası kalmadı.
- Sitede tanımadığınız yönetici hesabı, cron görevi veya yönlendirme kuralı yok. Yönlendirme sorunları için site başka siteye yönleniyor yazımıza bakın.
- Temizlenmiş halin yeni bir yedeğini aldınız ve bu yedeği saldırı öncesi/sonrası kopyalardan ayrı etiketlediniz.
1. Tüm şifreleri değiştirin
Saldırganın hangi şifreyi ele geçirdiğini çoğu zaman bilemezsiniz. Bu yüzden siteye dokunan tüm erişim bilgilerini değiştirin. Sıra önemli değildir, ama hepsini aynı gün yapın:
| Erişim | Nerede değiştirilir? | Not |
|---|---|---|
| WordPress yönetici hesapları | Kullanıcılar > Profil | Yalnızca sizin değil, tüm yönetici ve editörlerin şifresi |
| Hosting paneli (cPanel) | Hosting sağlayıcınızın müşteri paneli | Panel şifresi ele geçerse tüm dosyalara erişilir |
| FTP / SFTP hesapları | cPanel > FTP Accounts (panelinizde varsa) | Kullanılmayan FTP hesaplarını silin |
| Veritabanı kullanıcısı | cPanel > MySQL Databases (panelinizde varsa) | Değiştirdikten sonra wp-config.php içindeki DB_PASSWORD değerini güncelleyin |
| Alan adına bağlı e-posta hesapları | cPanel > Email Accounts (panelinizde varsa) | Şifre sıfırlama e-postaları bu kutulara gelir |
WordPress belgeleri; adınıza, şirketinize veya sitenize dayalı, sözlükte geçen, kısa ya da yalnızca rakam veya yalnızca harften oluşan şifrelerden kaçınmayı, uzun ve benzersiz şifreler için şifre yöneticisi kullanmayı önerir. İyi şifrenin neye benzediğini güçlü şifre yazımızda anlatıyoruz. Yönetici paneline giremiyorsanız SQL ile şifre sıfırlama veya admin paneline girilemiyor yazılarımız yardımcı olur.
Ayrıca her kullanıcının profil sayfasındaki Uygulama Şifreleri (Application Passwords) bölümüne bakın. WordPress 5.6 ile gelen bu özellik, uygulamaların kullanıcı şifresi olmadan giriş yapmasını sağlar ve kullanıcı şifresini değiştirmeden ayrı ayrı iptal edilebilir. Sizin oluşturmadığınız bir uygulama şifresi varsa iptal edin.
2. Güvenlik anahtarlarını (salt) yenileyin
wp-config.php içindeki güvenlik anahtarları, giriş çerezlerini imzalamak için kullanılır. Bunları yenilemek, saldırganın elinde kalmış olabilecek oturumlar dahil, tüm açık oturumları geçersiz kılar ve herkesin yeniden giriş yapmasını gerektirir. Hangi değerlerin değiştirileceğini ve nasıl yenileneceğini WordPress güvenlik anahtarları (salt) yazımızda adım adım anlattık. Sunucuda WP-CLI varsa tek komut yeterlidir:
wp config shuffle-salts3. İki adımlı doğrulamayı (2FA) açın
WordPress'in brute force belgesi, tüm yöneticiler ve yetkili kullanıcılar için iki adımlı doğrulamanın açılmasını önerir ve WordPress çekirdeğinin 2FA içermediğini, bunun bir eklentiyle veya kimlik sağlayıcıyla eklenmesi gerektiğini belirtir. WordPress'in "Two Step Authentication" belgesinde sayılan eklentilerden biri olan Two Factor (wordpress.org/plugins/two-factor) bu iş için hafif bir seçenektir. Wordfence Security ve WP 2FA da wordpress.org dizininde bulunan ve 2FA sunan eklentilerdir.
- 2FA'yı önce yönetici hesapları için zorunlu yapın.
- Kodları SMS yerine kimlik doğrulama uygulamasıyla almayı tercih edin; WordPress belgesi SMS'in güvenli bir iletişim kanalı olmadığını not eder.
- Yedek kurtarma kodlarını güvenli bir yere kaydedin. Telefonunuzu kaybederseniz panele bu kodlarla girersiniz.
4. Kullanıcıları ve yetkileri azaltın

WordPress'in brute force belgesi admin kullanıcı adını kullanmamayı, yönetici sayısını sınırlamayı ve günlük işler için en az yetkili rolün kullanılmasını önerir. Her yönetici hesabı, saldırgan için ayrı bir giriş kapısıdır.
| Rol | Ne yapabilir? | Kimde olmalı? |
|---|---|---|
| Yönetici (Administrator) | Her şeyi: eklenti kurma, kullanıcı ekleme, ayarlar | Mümkün olan en az kişide, tercihen bir veya iki |
| Editör (Editor) | Tüm yazıları ve sayfaları yönetir | İçerik ekibini yöneten kişi |
| Yazar (Author) | Kendi yazılarını yayımlar | Düzenli yazı yazanlar |
| Katılımcı (Contributor) | Yazı yazar ama yayımlayamaz | Misafir yazarlar |
| Abone (Subscriber) | Yalnızca profilini düzenler | Üye girişi olan sitelerde ziyaretçiler |
Ayrılmış çalışanların, ajansların veya artık çalışmadığınız geliştiricilerin hesaplarını silin ya da yetkisini düşürün. Bir kullanıcıyı silerken WordPress, o kullanıcının içeriğini başka bir kullanıcıya aktarma seçeneği sunar.
5. Güncel kalın ve kullanılmayanları silin
Google'ın rehberi, web sitesi sahiplerinin sık düştüğü hatayı şöyle anlatır: bir forum veya blog kurup sonra onu unutmak. WordPress belgeleri de eski WordPress sürümlerinin güvenlik güncellemesi almadığını, eklentilerin düzenli güncellenmesi ve kullanılmayanların kaldırılması gerektiğini söyler. Pasif bırakılmış bir eklentinin dosyaları sunucuda durduğu sürece erişilebilir olabilir; pasifleştirmek yerine silin.
- WordPress çekirdeğini, tüm eklentileri ve temaları güncelleyin. Otomatik güncelleme seçenekleri için WordPress otomatik güncelleme ayarları yazımıza bakın.
- Kullanmadığınız eklentileri ve etkin tema ile onun ana teması (parent) dışındaki temaları silin.
- Uzun süredir güncellenmeyen veya wordpress.org dizininden kaldırılmış eklentiler için alternatif arayın.
- Eklenti ve temaları yalnızca wordpress.org'dan veya geliştiricinin resmi sitesinden indirin; "ücretsiz premium" (nulled) sürümler kullanmayın.
- PHP sürümünüzün desteklenen bir sürüm olduğundan emin olun; WordPress PHP sürümü yükseltme yazımız bu konuyu anlatıyor.
6. Panelden dosya düzenlemeyi kapatın
WordPress, yönetim panelinden eklenti ve tema dosyalarının düzenlenmesini kapatan bir sabit sunar. Panel ele geçirildiğinde saldırganın ilk denediği şeylerden biri bu düzenleyiciye kod yazmaktır. wp-config.php dosyasına, /* That's all, stop editing! */ satırının üstüne ekleyin:
define( 'DISALLOW_FILE_EDIT', true );WordPress belgesi bu ayarın saldırganın kötü amaçlı dosya yüklemesini engellemeyeceğini, ancak bazı saldırıları durdurabileceğini belirtir. Daha sıkı bir seçenek olan DISALLOW_FILE_MODS ise panelden eklenti ve tema kurmayı ve güncellemeyi de kapatır (dosya düzenleyiciyi de kapattığı için ikisini birlikte eklemeniz gerekmez). Bu durumda güncellemeleri başka bir yolla yapmanız gerekeceği için çoğu küçük site sahibine yalnızca DISALLOW_FILE_EDIT yeterlidir. Diğer sabitler için wp-config.php sabitleri rehberimize bakın.
7. Dosya izinlerini ve wp-config.php'yi düzeltin
WordPress belgelerine göre tüm dosyalar sizin kullanıcı hesabınıza ait olmalı, web sunucusu yalnızca yazması gereken yerlere yazabilmelidir. Genel kural dizinler için 755, dosyalar için 644'tür; wp-config.php için belgede 400 veya 440 izni önerilir. Hangi dosyaya hangi iznin verileceğini ve neden 777 kullanılmaması gerektiğini WordPress dosya izinleri rehberimizde ayrıntılı anlattık.
Apache sunucularda wp-config.php dosyasına web üzerinden erişimi engellemek için WordPress belgesindeki şu kuralı .htaccess dosyasının en üstüne ekleyebilirsiniz:
<Files "wp-config.php">
Require all denied
</Files>8. Giriş denemelerini sınırlayın ve XML-RPC'yi gözden geçirin
WordPress'in brute force belgesi, giriş denemelerinin mümkünse sunucu veya WAF/CDN seviyesinde, bu mümkün değilse bir güvenlik eklentisiyle sınırlandırılmasını önerir. Belge, eklenti tabanlı sınırlamanın PHP içinde çalıştığı için yoğun saldırı altında kaynak tükettiğini de not eder.
Aynı belgeye göre xmlrpc.php sık hedef alınan bir dosyadır. XML-RPC kullanmıyorsanız kapatılması, kullanıyorsanız (örneğin Jetpack veya WordPress mobil uygulaması) kısıtlanması ve hız sınırına bağlanması önerilir. Kullanmadığınızdan eminseniz Apache'de şu kuralla erişimi kapatabilirsiniz:
<Files "xmlrpc.php">
Require all denied
</Files>Belge ayrıca giriş sayfasının adresini değiştirmenin gürültüyü azaltabileceğini, ancak tek savunma olmaması gerektiğini vurgular.
9. WAF kullanın
WordPress belgeleri, kötü trafiğin sunucunuza ulaşmadan engellendiği kenar (edge) koruma servislerini önerir ve örnek olarak Cloudflare ve Sucuri'yi sayar. Bu servisler /wp-login.php ve /xmlrpc.php için hız sınırı, bot kontrolü ve challenge sayfaları uygulayabilir. Cloudflare'de WordPress için örnek kuralları Cloudflare WAF kuralları ve bot koruması yazımızda anlattık. Belge, kalıcı ülke engellerinin meşru kullanıcıları da engelleyebileceği için önerilmediğini de not eder.
10. Yedekleme ve izleme düzeni kurun

WordPress belgesi, veritabanı dahil düzenli yedek almayı ve saldırı öncesi ile sonrası kopyalarınızın olması için kurulumun zaman damgalı anlık görüntülerini saklamayı önerir. Brute force belgesi de yedeklerin test edilmesini ve geri yükleme işleminin önceden prova edilmesini ister. Bir yedek, geri yüklenip çalıştığı görülene kadar yalnızca bir varsayımdır.
- Hosting yedeklerine ek olarak kendi kontrolünüzde, sunucu dışında bir yedek tutun. Ayrıntılar: WordPress yedekleme ve geri yükleme, veritabanı yedekleme stratejileri.
- Search Console'a sitenizi ekleyin ve mesajların e-postanıza iletilmesini açın. Google, sitede kötü amaçlı yazılım tespit ettiğinde Search Console mesaj panelinde bildirim gösterir.
- Google'ın önerdiği gibi ara sıra
site:alanadiniz.comaraması yapın; tanımadığınız sayfalar veya yazmadığınız konular görürseniz saldırıya uğramış olabilirsiniz. - WordPress belgesinin önerdiği gibi dosya bütünlüğü izlemesi yapın: yeni eklenen veya değişen dosyaları fark etmek için bir güvenlik eklentisinin dosya tarama özelliğini veya WP-CLI ile
wp core verify-checksumskomutunu düzenli çalıştırın. - Erişim günlüklerine (access log) ara sıra bakın. Google, alışılmadık URL parametrelerinin veya yönlendirme URL'lerine ani trafik artışının saldırı işareti olabileceğini belirtir. Günlük okumaya giriş için Linux loglarını okuma yazımıza bakabilirsiniz.
WordPress'in sertleştirme belgesinde güvenlik eklentisi örnekleri arasında Wordfence, All in One WP Security and Firewall, Shield ve Sucuri sayılır. Sucuri Security eklentisi de wordpress.org dizininde denetim (auditing), kötü amaçlı yazılım tarama ve sertleştirme özellikleriyle tanıtılır. Birden fazla güvenlik eklentisini aynı anda kurmayın; çakışabilir ve siteyi yavaşlatabilirler. Birini seçip doğru yapılandırmak daha iyidir.
11. Kişisel veri etkilendiyse KVKK bildirimini unutmayın
Sitenizde üye bilgileri, sipariş kayıtları, iletişim formu mesajları gibi kişisel veriler varsa ve saldırgan veritabanına erişmiş olabilirse, bu yalnızca teknik bir sorun değildir. 6698 sayılı Kanun'un 12. maddesinin 5. fıkrası, işlenen kişisel verilerin kanuni olmayan yollarla başkaları tarafından elde edilmesi halinde veri sorumlusunun durumu en kısa sürede ilgilisine ve Kurul'a bildirmesini öngörür. Bildirimin kime ve nasıl yapılacağını kişisel veri ihlali bildirimi yazımızda anlattık. Emin değilseniz bir hukukçuya danışın.
Kontrol listesi özeti
| Adım | Ne zaman? | Yapıldı mı? |
|---|---|---|
| Tüm şifreler (WP, panel, FTP, DB, e-posta) | Temizlikten hemen sonra | [ ] |
| Güvenlik anahtarlarını yenileme | Temizlikten hemen sonra | [ ] |
| Uygulama şifrelerini kontrol | Temizlikten hemen sonra | [ ] |
| 2FA (yöneticiler için) | İlk gün | [ ] |
| Gereksiz kullanıcı ve yöneticileri kaldırma | İlk gün | [ ] |
| Güncellemeler, kullanılmayan eklenti/tema silme | İlk gün, sonra düzenli | [ ] |
| DISALLOW_FILE_EDIT | İlk gün | [ ] |
| Dosya izinleri ve wp-config.php koruması | İlk hafta | [ ] |
| Giriş sınırlama, XML-RPC kararı, WAF | İlk hafta | [ ] |
| Yedek düzeni ve geri yükleme provası | İlk hafta, sonra düzenli | [ ] |
| Search Console ve izleme | İlk hafta, sonra düzenli | [ ] |
Sık Sorulan Sorular
Güvenlik eklentisi kurarsam başka bir şey yapmama gerek kalır mı?
Hayır. Eklentiler giriş sınırlama, tarama ve 2FA gibi işleri kolaylaştırır, ama güncel olmayan bir eklentiyi, zayıf bir panel şifresini veya gereksiz bir yönetici hesabını telafi etmez. WordPress belgeleri de güvenliği tek bir araca değil, katmanlı önlemlere dayandırır.
Giriş sayfasının adresini değiştirmek yeterli mi?
WordPress'in brute force belgesi, giriş adresini gizlemenin gürültüyü azaltabileceğini ama tek savunma olmaması gerektiğini söyler. Güçlü şifre, 2FA ve hız sınırlaması asıl korumayı sağlar.
Salt anahtarlarını değiştirirsem sitem bozulur mu?
Hayır. Tüm kullanıcıların oturumu kapanır ve herkes yeniden giriş yapar; içerik ve ayarlar etkilenmez. Bu, temizlikten sonra tam olarak istediğiniz şeydir.
XML-RPC'yi kapatmalı mıyım?
Kullanmıyorsanız evet, WordPress belgesi bunu önerir. Jetpack, WordPress mobil uygulaması veya XML-RPC ile yayın yapan bir araç kullanıyorsanız kapatmak yerine WAF ile kısıtlayıp hız sınırı koymak daha doğrudur.
Site tekrar hacklenirse ne yapmalıyım?
Aynı açık kapanmamış olabilir veya ilk temizlikte bir arka kapı gözden kaçmış olabilir. Temizliği baştan, temizleme rehberimizdeki sırayla yapın; Search Console'da sorun varsa güvenlik sorunları raporu yazımızı izleyin ve gerekirse bir güvenlik uzmanından destek alın. Tarayıcılar kırmızı uyarı gösteriyorsa tehlikeli site uyarısı yazımıza bakın.
Yazılım, eklenti ve hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen şirketlerle bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.
İlgili içerikler: WordPress hacklendi: temizleme rehberi · Şüpheli PHP dosyası ve web shell bulma · Site başka siteye yönleniyor · WordPress güvenlik anahtarları (salt) · WordPress dosya izinleri · Cloudflare WAF kuralları