Hacklenen PHP Siteyi Temizleme Rehberi

Neden Hacked PHP Sitelerini Temizlemek Zordur?

PHP tabanlı sitelere yönelik saldırılar yalnızca ana sayfanın bozulmasıyla sınırlı kalmayabilir; saldırganlar sistemin derinliklerine backdoor (arka kapı) yerleştirip haftalarca, hatta aylarca fark edilmeden içeride kalabiliyor. Özellikle ajanslarda ve KOBİ’lerde, birden fazla sitenin aynı hosting hesabında tutulduğu senaryolarda, tek bir hacked site tüm hesabı ve markaları riske atabiliyor.

Bu rehberde, saldırıya uğramış PHP sitelerini incelemek ve temizlemek için uygulanabilir bir yol haritası paylaşacağız. Amacımız; panikle her şeyi silmek yerine, sistematik bir şekilde teşhis yapmanız, backdoor’ları bulup temizlemeniz ve sonrasında sitenizi güvenli bir ortama taşımanız için net adımlar sunmak. PHP tabanlı CMS, framework veya özel uygulamanız (WordPress, Laravel, kendi yazılımınız vb.) değişebilir; ancak anlatacağımız prensipler neredeyse tüm PHP siteler için geçerli.

Bu adımlar mevcut saldırıyı gidermeye ve tekrarını önlemeye yardımcı olabilir; sonuç, giriş yolunun ve kalıcılık mekanizmalarının bulunup kapatılmasına bağlıdır. Rehberin sonunda, temizlik ortamı ve izleme için hosting planınızda değerlendirmeniz gereken ölçütlere de değineceğiz.

1. İlk Tepki: Panik Yapmadan Hasarı Sınırlama

1.1. Hemen Yapmanız Gerekenler

Sitenizde garip yönlendirmeler, SEO spam içerikleri, antivirüs uyarıları veya arama sonuçlarında “bu site zararlı” uyarıları görmeye başladıysanız, bir güvenlik ihlalinden şüphelenmelisiniz; bu belirtiler tek başına kötü amaçlı PHP dosyası veya backdoor bulunduğunu kanıtlamaz. İlk adımda şu temel önlemleri alın:

• Admin panellerine erişimi kısıtlayın: Mümkünse IP ile kısıtlama (htaccess, Nginx kuralı, panel ayarı) uygulayın.
• Şifreleri güvenilir bir cihazdan değiştirin: Hosting paneli, FTP/SFTP, SSH, veritabanı kullanıcıları ve CMS admin hesaplarını kapsayın. Şüpheli SSH anahtarlarını ve erişim token’larını da iptal edin. Yeni kimlik bilgileri kirli ortamda kullanıldıysa temizlikten sonra yeniden yenileyin.
• Oturumları sonlandırın: Admin panelde açık oturumları (session) sonlandıran eklenti/özellik varsa kullanın.
• Yedek alın ama “temiz” diye güvenmeyin: Dosyaları silmeden veya değiştirmeden önce mevcut durumu belgeleyin; tam yedeği ve erişebildiğiniz logları webden erişilemeyen ayrı bir konumda saklayın. Bu yedekte de backdoor bulunabilir; inceleme kopyası olarak tutun, doğrudan yayına geri yüklemeyin.

cPanel kullanıyorsanız, hızlıca sistemli bir yedek almak için cPanel’de tüm siteyi yedekleme rehberimizi takip edebilirsiniz. Yedeklerinizin uzun vadede gerçekten işinizi görmesi için de 3-2-1 yedekleme stratejisini mutlaka gözden geçirin.

1.2. Siteyi Tamamen Kapatmalı mıyım?

Siteniz aktif olarak zararlı yazılım dağıtıyor, phishing içeriği sunuyor veya ziyaretçileri zararlı adreslere yönlendiriyorsa, etkilenen uygulamaya dış erişimi kesin. Hizmet sürekliliği gerekiyorsa, şüpheli PHP kodunu çalıştırmayan temiz bir ortamdan statik bakım sayfası sunun. Yalnızca admin erişimini kısıtlamak veya görünen zararlı kodu silmek ziyaretçileri korumaya yetmez. Ardından şu adımları uygulayın:

• Önce admin erişimlerini kısıtlayın.
• Şifreleri değiştirin.
• Yedek ve log kopyalarını koruduktan sonra, wp-config.php veya framework yapılandırma dosyalarına enjekte edilmiş kötü kod gibi bulguları inceleyip temizleyin. Enjekte edilmiş kod saldırının sonucudur; saldırganın kullandığı açığı veya ele geçirilmiş hesabı da belirleyip güvenceye alın.
• Bakım yanıtında HTTP 503 durum kodunu kullanın; yalnızca bakım ekranı göstermek, diğer URL’lerden şüpheli uygulamaya erişimi engellemez.

2. Hacked PHP Sitenin Belirtileri ve İlk Analiz

2.1. Saldırı Gerçekten Var mı, Nasıl Anlarız?

Her performans sorunu veya hata bir saldırı değildir. Ancak şu işaretler genellikle hacked bir PHP siteye işaret eder:

• Google arama sonuçlarında sitenizin başlık/açıklama kısmında “casino, porno, viagra” benzeri spam kelimeler.
• Rastgele linklere yönlendiren JavaScript kodları veya iframe’ler.
• Sunucu üzerinde bilmediğiniz PHP dosyaları (özellikle image.php, config-old.php, cache.php gibi masum isimlerle).
• Antivirüs veya güvenlik tarayıcılarının zararlı kod uyarıları.
• FTP/SSH loglarında sizden gelmeyen bağlantılar veya beklenmedik IP adresleri.

2.2. Loglar Üzerinden İlk İzler

PHP sitenizin saldırıya uğrayıp uğramadığını anlamanın en iyi yollarından biri de web sunucusu ve erişim loglarına bakmaktır. Apache/Nginx erişim ve hata loglarına erişim yöntemi hosting planına ve yetkilerinize bağlıdır. Şu tip istekler incelemeye değerdir; tek başlarına saldırının başarılı olduğunu göstermezler:

• Sitenizde bulunmayan PHP yollarına veya giriş/API uç noktalarına yoğun istekler (/wp-login.php, /xmlrpc.php, rastgele .php yolları); ilk iki yol WordPress kurulumlarında meşru dosyalar olabilir.
• Uzun, şüpheli query string’ler içeren istekler (özellikle base64, eval, assert gibi kelimeler gösteren).
• Tek bir IP adresinden çok kısa sürede yüzlerce POST isteği.

Log okumaya yabancıysanız, HTTP hata kodları ve log analizi için hazırladığımız Apache/Nginx loglarını okuma rehberini de inceleyebilirsiniz.

3. Backdoor Tespiti: Sadece Görünen Zararlı Kodu Temizlemek Yetmez

3.1. Backdoor Nedir, Neden Bu Kadar Tehlikeli?

Backdoor, saldırganın sisteme istediği zaman geri dönebilmesini sağlayan gizli kapıdır. Genellikle şu amaçlarla kullanılır:

• İstediği PHP kodunu uzaktan çalıştırmak (örneğin web shell).
• Yeni admin kullanıcılar eklemek.
• Spam gönderimi veya SEO spam içeriklerini otomatik üretmek.
• Yeni zararlı dosyalar yüklemek.

Bu yüzden sadece görünen zararlı dosyaları silmek yetmez; asıl mesele, sisteme tekrar girişe izin veren arka kapıların tamamını bulup ortadan kaldırmaktır.

3.2. Tipik PHP Backdoor İmzaları

PHP backdoor’lar genelde şu yapılara benzer:

Aşağıdaki kodlar yalnızca tanıma ve statik inceleme içindir; çalıştırmayın. Bir fonksiyon adı veya kodlama işlemi tek başına zararlı yazılım kanıtı değildir. assert() ile metni PHP kodu olarak değerlendirme PHP 7.2’de kullanımı önerilmemeye başlandı (deprecated), PHP 8.0’da kaldırıldı; assert() fonksiyonunun kendisi kullanılmaya devam eder. create_function() da PHP 7.2’de deprecated ilan edildi ve PHP 8.0’da kaldırıldı. Bulguyu olay sırasında kullanılan PHP sürümü ve gerçek veri akışıyla birlikte değerlendirin.

• eval(base64_decode('...'));
• eval(gzinflate(base64_decode('...')));
• preg_replace('/.*/e', $_POST['x'], ''); (eski PHP sürümlerine ait bir göstergedir; /e değerlendirme desteği PHP 7.0’da kaldırıldı. Örnek yalnızca inceleme içindir, çalıştırmayın)
• system($_GET['cmd']);, shell_exec, passthru, exec gibi fonksiyonların POST/GET girdileriyle kullanımı
• Garip değişken isimleri ile dolu, tek satıra sıkıştırılmış, okunaksız PHP kod blokları

Backdoor sitenizin kök dizininde de, daha “masum” görünen klasörlerde de (örneğin uploads, cache, tmp) saklanabilir. Dosya isimleri functions.php, index-old.php, image.php gibi normalde şüphe çekmeyecek şekilde olabilir.

3.3. SSH Üzerinden Dosya Sistemi Taraması

SSH erişiminiz varsa, site dizinindeki dosyalarda hızlı bir metin taraması yapabilirsiniz. Aşağıdaki örnek yalnızca PHP dosyalarıyla sınırlı değildir:

cd /home/kullanici/public_html

# base64_decode içeren dosyaları bul
grep -R "base64_decode" -n . | head

# eval, assert, system gibi kritik fonksiyonları ara
grep -R "eval(" -n . | head
grep -R "assert(" -n . | head
grep -R "shell_exec" -n . | head

Bu komutlar eşleşen satırları gösterir; her aramanın çıktısı head nedeniyle ilk 10 satırla sınırlıdır, dolayısıyla tam bir bulgu listesi değildir. Eşleşme tek başına backdoor kanıtı sayılmaz; bu ifadeler meşru kodda da bulunabilir. Eşleşme olmaması da sitenin temiz olduğunu göstermez. Özellikle uploads gibi yüklenen içerikler için kullanılan klasörlerdeki beklenmedik PHP dosyalarını inceleyin.

Örnekteki /home/kullanici/public_html bir yer tutucudur. İnceleme kopyanızın doğru dizinine geçtiğinizi doğrulamadan aramalara başlamayın; cd başarısız olursa sonraki satırlar başka dizinde çalışabilir. GNU grep için -R sembolik bağları da izler; tarama alanının ve erişim yetkilerinin inceleme kapsamını aşmadığını kontrol edin. Yorum satırında “system” yazsa da gösterilen komutlar system() için ayrı arama yapmaz. Büyük çıktı ve erişim hataları ayrıca değerlendirilmelidir; örnek bir tam tarama prosedürü değildir.

3.4. FTP/SFTP ile İndirip Yerelde Tarama

SSH erişiminiz yoksa, tüm site dosyalarınızı yerel bilgisayarınızda web sunucusunun yayın dizini dışında ayrı bir klasöre indirip antivirüs ve ek zararlı yazılım tarayıcıları ile tarayabilirsiniz. Şüpheli dosyaları çalıştırmayın; tarayıcının bulgu vermemesi PHP backdoor bulunmadığını kanıtlamaz. Bu aşamada FTP yerine her zaman SFTP/FTPS kullanmanız gerektiğini hatırlatalım; zira düz FTP şifrelerinizi ağ üzerinde şifrelenmemiş biçimde iletir. Bu konuda detaylar için FTP yerine SFTP kullanmanın zamanı geldi yazımıza mutlaka göz atın.

Gizli dosyaları ve web kökü dışındaki ilgili yapılandırmaları da kapsam envanterine alın. İndirme kopyasını ayrı ve erişimi sınırlı bir analiz ortamında tutun; siteyi tarayıcıda açmayın. Yalnızca FTP erişimiyle tüm hesabı göremeyebilirsiniz: cron görevleri, SSH anahtarları, panel kullanıcıları, e-posta yönlendirmeleri ve aynı hesabı paylaşan siteler için sağlayıcıdan erişilebilir kayıtları isteyin.

İndirdiğiniz klasör üzerinde metin editörü veya IDE kullanarak da benzer imza aramaları yapabilirsiniz. Örneğin VS Code içinde “base64_decode(” veya “gzinflate(” gibi aramalar çoğu zaman işe yarar.

4. Dosya Temizliği: Çekirdek Kodlar, Eklentiler ve Özel Yazılım

4.1. Temiz Yedek Varsa: En Kolay Senaryo

Eğer saldırıdan önce alınmış, çalışır durumda ve içeriği incelenerek güvenilirliği değerlendirilmiş bir tam yedeğiniz varsa, yeni ortamda geri yükleme uygun bir seçenek olabilir. Yedeğin ilk belirtiyi gördüğünüz tarihten eski olması tek başına temiz olduğunu göstermez:

1. Yeni bir hosting hesabı veya izole bir ortam hazırlayın (ayrı bir VPS gibi). Seçtiğiniz ortamın etkilenen hesaptan erişilemediğini ve hesaplar arası izolasyonu doğrulayın.
2. Temiz yedeği bu yeni ortama geri yükleyin.
3. Veritabanını da aynı tarihteki temiz yedekle değiştirin. Bunun sonraki sipariş, içerik ve kullanıcı değişikliklerini kaybettirebileceğini hesaba katın; gerekli yeni kayıtları inceleyerek ayrı biçimde kurtarın.
4. Yayına açmadan önce yedekteki açıkları giderin, bileşenleri güncelleyin, erişim bilgilerini yenileyin ve dosyalarla veritabanını yeniden inceleyin. İzole ortamda işlevleri kontrol ettikten sonra alan adını DNS üzerinden yeni ortama yönlendirin; DNS geçişi boyunca eski zararlı uygulamayı erişime kapalı tutun.

Bu yaklaşım, mevcut kirlenmiş ortamda “neyi silip neyi bırakacağım” karmaşasını büyük ölçüde azaltır. Yedek yoksa veya ne kadar temiz olduğu belirsizse, daha detaylı inceleme gerekir.

4.2. CMS Tabanlı Siteler (Örn. WordPress)

WordPress gibi yaygın CMS’lerde takip edebileceğiniz tipik yaklaşım:

• Çekirdeği güvenilir kaynaktan yeniden kurun: Önce kanıt kopyasını ayırın. Karşılaştırma için kurulu sürüm ve dilin resmi dosyalarını kullanın; yayına alınacak sürümün desteklenen ve uygulamayla uyumlu olmasını ayrıca doğrulayın. Yalnızca wp-admin, wp-includes ve kök dosyaların üzerine yazmak, sonradan eklenmiş zararlı dosyaları kaldırmaz. İzole ortamda temiz bir dizin kurup gereken dosyaları inceleyerek aktarın.
• Temaları ve eklentileri yeniden temin edin: Resmi depo veya doğrulanmış geliştirici kaynağını kullanın. Özel değişiklikleri önce inceleyip kaydedin; eskimiş ya da terk edilmiş bileşenleri uygun biçimde güncelleyin veya kaldırın.
• Uploads ve yapılandırmaları inceleyin: Beklenmedik PHP dosyalarını araştırın; yalnızca uzantıya veya isme göre silmeyin. wp-config.php, .htaccess, .user.ini, mu-plugin ve drop-in dosyaları ile web kökü dışındaki ilgili dosyaları da kapsayın. Çekirdek sağlama toplamlarının eşleşmesi bütün hesabın temiz olduğunu kanıtlamaz.

WordPress için detaylı güvenlik önlemleri ve sık tekrarlanan saldırı senaryolarını paylaşımlı hosting’de WordPress güvenliği rehberimizde ve “WordPress siteniz sürekli hackleniyorsa” yazımızda ayrıntılı şekilde ele aldık; bu makaleyi okuduktan sonra mutlaka onlara da göz atın.

4.3. Özel Geliştirilmiş PHP Uygulamaları

Özel geliştirilmiş PHP uygulamasında, sunucunun dışındaki güvenilir bir Git deposu veya doğrulanmış dağıtım paketi karşılaştırma kaynağı olabilir. Depo ve CI/CD erişimleri de olaydan etkilenmişse önce bunların güvenilirliğini değerlendirin:

• Dağıtılan sürümü belirleyin: İnceleme kopyasını, gerçekten dağıtılmış commit veya paketle karşılaştırın. git status çalışma ağacı, index ve HEAD arasındaki değişiklikleri gösterir; tek başına son deploy’u kanıtlamaz. Yok sayılan dosyalar varsayılan görünümde bulunmayabilir; izlenmeyen, üretilen ve web kökü dışındaki ilgili dosyaları da inceleyin.
• Farkları bağlamıyla değerlendirin: Yetkili hotfix, derleme çıktısı ve yerel yapılandırma değişikliklerini saldırı izlerinden ayırın. Şüpheli değişiklikleri loglarla ilişkilendirin.
• Güvenilir paketten yeniden dağıtın: İncelenmiş kaynak ve bağımlılıklardan temiz bir dağıtım hazırlayın; üretim dosyalarını körlemesine Git durumuna döndürmeyin. CI/CD anahtarlarını ve bağımlılık kaynağını da doğrulayın.

Sürüm kontrolünüz yoksa temizliği tamamladıktan sonra gözden geçirilmiş kaynakla bir Git ve dağıtım akışı kurun. Üretime hangi sürümün, kim tarafından ve ne zaman alındığını kaydetmek sonraki incelemeleri kolaylaştırır.

4.4. Dosya İzinlerini Gözden Geçirin

Gereksiz yazma yetkileri, ele geçirilen uygulamanın başka dosyalara müdahale etmesini kolaylaştırabilir. İzin bitlerini dosya sahibi, grup ve PHP işleminin çalıştığı kullanıcıyla birlikte değerlendirin. Aşağıdaki değerler bazı kurulumlarda başlangıç örneğidir; her dosyaya uygulanacak evrensel güvenli ayar değildir:

• Genel web dosyaları için 644, dizinler için 755 bazı kurulumlarda kullanılabilir; dosya sahibi uygulama kullanıcısıysa sahibin yazma yetkisi sürer.
• Veritabanı parolası veya anahtar içeren dosyalar daha dar izin ve webden erişim engeli gerektirebilir. Uygulamanın ihtiyaç duyduğu erişimi test edin.
• 777 ile genel yazma izni vermeyin. Uploads ve cache gibi gerekli yazılabilir alanları sınırlandırın; kod dizinlerini mümkün olduğunca dağıtım sürecinin kontrolünde tutun.
• Uploads alanında PHP çalıştırılmasını engelleyin; kullanılan web sunucusu ve PHP işleyicisine uygun yapılandırmanın gerçekten etkili olduğunu, alternatif çalıştırma yollarının bunu aşmadığını doğrulayın. Dosya izinleri tek başına bu kontrolün yerine geçmez.

Ayrıntılı açıklama için Linux dosya izinleri ve güvenli ayarlar rehberimize göz atabilirsiniz.

5. Veritabanı Temizliği: Gizli Adminler ve Enjekte İçerikler

5.1. Neden Sadece Dosyalar Yetmez?

Saldırganlar dosyaların yanında veritabanını da değiştirebilir. İncelemeye alınacak örnekler:

• Admin kullanıcı listesine kendi hesaplarını ekleyebilirler.
• İçeriğe gizli JavaScript veya iframe’ler enjekte edebilirler.
• Ayarlara (örneğin site URL, footer kodu, reklam kodları) zararlı scriptler ekleyebilirler.

Dolayısıyla, dosyalar ne kadar temizlenirse temizlensin, veritabanını kontrol etmeden “tamamen temiz” demek mümkün değildir.

5.2. Kullanıcılar ve Roller

Öncelikle admin kullanıcı listesine bakın:

• Tanımadığınız yönetici hesaplarının sahibini ve işlem geçmişini doğrulayın. Şüpheli erişimi devre dışı bırakıp kanıtı koruyun; hesabı silmeden önce içerik sahipliği ve iş gereksinimlerini inceleyin.
• Meşru yönetici parolalarını temiz bir cihazdan yenileyin. Oturumları, uygulama parolalarını ve ilgili erişim token’larını iptal edin; kalıcı yeni sırları temiz ortama yerleştirin.
• Destekleniyorsa 2FA etkinleştirin; kurtarma yöntemleri ve yedek erişimin de güvenli olduğunu kontrol edin.

Rol bazlı yetkilendirme kullanan sistemlerde, normalde “editör” olması gereken bir kullanıcının “süper admin” yapılmadığından emin olun.

5.3. İçerik Alanlarında Zararlı Kod Tespiti

Başlık, içerik, açıklama ve özel alanları inceleyin; ayar tablolarını da unutmayın. Aşağıdaki MySQL sorgusu yalnızca varsayımsal articles(id, title, content) şeması içindir ve sadece content alanında arar. Kendi tablo/kolon adlarınıza uyarlayıp erişimi kısıtlı inceleme kopyasında salt okunur yetkiyle kullanın:

SELECT id, title
FROM articles
WHERE content LIKE '%<script%'
   OR content LIKE '%base64_decode%';

Bu SELECT sorgusu veri değiştirmez; dönen satırlar kanıt değil inceleme adaylarıdır. LIKE içinde % sıfır veya daha çok karakteri, _ tek karakteri eşleştirir. Örnekte base64_decode içindeki alt çizgi kaçırılmadığından base64Xdecode gibi metinler de eşleşebilir. Eğitim içeriğinde script örnekleri, meşru iframe veya kod parçaları bulunabilir; eşleşme olmaması da temizlik kanıtı değildir. Beklenmedik spam kelimelerini, alan adlarını ve kodları bağlamıyla inceleyin. Değişiklikten önce veritabanı yedeğini koruyun; CMS API’si veya doğrulanmış kayıt düzeltmesi kullanın. Körlemesine toplu silme/değiştirme, meşru içeriği ve serileştirilmiş ayarları bozabilir.

6. FTP/SSH Erişim Logları ve Hesap Güvenliği

6.1. Saldırgan Nereden Girdi?

Backdoor temizliğiyle birlikte giriş yolunu araştırın. Aşağıdaki olasılıkları dosya, kimlik doğrulama ve uygulama loglarıyla karşılaştırın; tek bir belirtiyi kesin kök neden saymayın:

• Zayıf FTP/SFTP şifreleri veya daha önce sızmış şifreler.
• Eski, güncellenmemiş PHP uygulamaları (zafiyetli eklentiler, temalar).
• Paylaşılan cihazlardan çalınan SSH anahtarları.
• Panel (cPanel, Plesk vb.) giriş bilgilerinin oltalama (phishing) ile ele geçirilmesi.

6.2. FTP/SSH Loglarını İnceleme

FTP/SFTP/SSH ve panel giriş kayıtlarının nerede tutulduğu, hosting planına ve yetkilerinize bağlıdır. Sağlayıcıdan erişilebilir kayıtları gecikmeden isteyin. Başarılı ve başarısız girişleri, saat dilimini, kullanıcıyı ve yapılan işlemleri birlikte inceleyin:

• Beklenen kullanıcı ve ağlarla uyuşmayan girişler; IP konumu VPN, proxy veya ortak ağ nedeniyle yanıltıcı olabilir.
• Yetkili bakım/deploy saatleriyle açıklanamayan bağlantılar; gece saati tek başına saldırı kanıtı değildir.
• Yoğun başarısız denemeler ve bunları izleyen başarılı erişimler; istek sayısı tek başına başarılı ihlal veya saldırgan kimliği göstermez.

Doğrulanmış kötüye kullanım için geçici ağ kısıtlamaları uygularken kendi yönetim erişiminizi koruyun. SSH anahtarlarının sahibini doğrulayın, ele geçirilmiş anahtarları iptal edin ve uygun erişim politikası uygulayın. SSH portunu değiştirmek tarama gürültüsünü azaltabilir; güçlü kimlik doğrulamanın yerine geçmez. Ayrıntılar için VPS sunucu güvenliği rehberimizi inceleyebilirsiniz.

6.3. Parolaları, Anahtarları ve Token’ları Yenileme

Temiz ortam hazırlandığında ve tekrar yayına açılmadan önce şu erişimleri gözden geçirin:

• Hosting paneli, alan adı kayıt hesabı ve DNS/CDN hesabı
• FTP/SFTP ve SSH hesapları; yetkili anahtarlar
• Veritabanı kullanıcıları ve uygulama yönetici hesapları
• Deploy/CI anahtarları, API token’ları, uygulama sırları ve oturum imzalama anahtarları

Parolalar için uzun, güçlü ve benzersiz değerler kullanın. Anahtar ve token’ları ilgili sistemin yenileme/iptal akışıyla değiştirin; parola değişimi bunları kendiliğinden iptal etmez. Bağlı servisleri ve oturum geçersizleştirmesini test edin. Yeni sırları şüpheli ortama geri yazmayın; ilk müdahalede orada kullanılmış olanları yeniden yenileyin.

7. Güvenli Taşıma: Kirli Ortamdan Temiz Ortama Geçiş

7.1. Neden Yeni Ortama Taşımak Bazen Daha Mantıklı?

Mevcut ortama ne ölçüde güvenilebildiği, temizliği yerinde yapma kararını belirler. Şu durumlarda kapsamlı inceleme ve yeniden kurulum değerlendirilmelidir:

• Aynı hesapta onlarca site var ve hangisinin ilk kaynak olduğu belirsiz.
• Çok sayıda zararlı cron job veya sisteme yayılmış backdoor var.
• Paneldeki diğer kullanıcı ayarları, mail hesapları, subdomain’ler de karışmış durumda.

Güvenilirliği gösterilemeyen bir ortamda, incelenmiş verilerle temiz kurulum yapmak uygun olabilir. İşletim sistemi veya yönetici hesabı ele geçirilmişse aynı sunucuda yeni bir klasör ya da panel hesabı açmak yeterli izolasyon sağlamaz; sağlayıcıyla sistemin yeniden kurulmasını veya ayrı güvenilir bir sunucuyu değerlendirin. Yeni ortamın eski hesabın anahtarlarıyla erişilemediğini doğrulayın.

7.2. Adım Adım Güvenli Taşıma Planı

1. İzole yeni ortamı hazırlayın: Desteklenen PHP, veritabanı ve gerekli uzantıları uygulamayla test edin. Erişimi sınırlandırın, dosya sahipliğini ayarlayın ve yeni sırları koruyun.
2. Temiz uygulamayı kurun: Resmi kaynak, doğrulanmış geliştirici paketi veya incelenmiş bağımlılıklarla güvenilir derleme kullanın. Sadece aynı ana sürüm değil, karşılaştırılan tam sürüm bilinmelidir.
3. Dosyaları seçerek aktarın:
   • Resim ve PDF gibi statik dosyalar da otomatik olarak güvenli sayılmaz; içerik ve dosya türlerini inceleyin.
   • Özel kodu güvenilir depodan yeniden dağıtın; repo ve dağıtım erişimleri etkilenmişse önce doğrulayın.
   • Şüpheli PHP dosyalarını taşımayın; gereken özel kod için geliştirici incelemesi yapın.
4. Veritabanını izole ortamda inceleyin: mysqldump ile alınmış olması dökümün temiz olduğu anlamına gelmez. İlgili admin kullanıcıları, roller, ayarlar ve içerik temizlenmeden uygulamayı dışarı açmayın. Uygun düşük yetkili hesapla çalışın; e-posta, ödeme ve webhook gibi dış entegrasyonların istemsiz çalışmasını engelleyin.
5. Doğrulayın ve geçişi planlayın: Gerçek alan adı/TLS davranışını, girişleri, formları ve sipariş akışını kontrollü biçimde test edin. Son veri aktarımı sırasında yazma işlemlerini durdurarak veya uygulamaya uygun senkronizasyonla tutarlı durum elde edin. DNS’i değiştirirken eski zararlı uygulamayı erişime kapalı tutun. TTL’nin erken düşürülmesi beklemeyi azaltabilir; önceden önbelleğe alınmış yanıtların süresini kısaltmaz ve kesintisizliği garanti etmez.

DNS ve uygulama geçişini birlikte planlamak için taşıma için TTL stratejileri rehberini inceleyin. Eski sunucuyu tekrar açan bir geri dönüş planı kullanmayın; geri dönüş hedefi de doğrulanmış temiz bir ortam olmalıdır.

8. Temizlikten Sonra Güvenliği Sertleştirme

8.1. WAF (Web Uygulama Güvenlik Duvarı) Kullanımı

WAF (Web Application Firewall), yapılandırılmış kurallara uyan bazı zararlı istekleri engellemeye yardımcı olur. ModSecurity veya Cloudflare WAF kullanılabilirliği, kuralları ve yönetim sorumluluğu planınıza göre değişir. WAF mevcut backdoor’u temizlemez, çalınmış tüm erişimleri iptal etmez ve açıkların yamalanmasının yerini tutmaz. Kuralları meşru trafik üzerinde test edin.

WAF’ların nasıl çalıştığını ve hangi kuralları aktif etmeniz gerektiğini detaylıca anlattığımız Web Uygulama Güvenlik Duvarı rehberi ve Cloudflare güvenlik ayarları yazısı bu noktada iyi bir tamamlayıcı olacaktır.

8.2. Güncellemeler ve Otomatik Yama Stratejisi

Güncellenmemiş bileşenlerdeki açıklar giriş yolu olabilir. Temizlik sonrasında uygulanacak güncellemeleri bağımlılıklar ve uygulama uyumluluğuyla birlikte planlayın:

• CMS, framework, PHP, tema, eklenti ve kütüphaneleri desteklenen güvenlik güncellemelerine taşıyın; yeni sürümü izole ortamda test edin.
• Kullanılmayan bileşenleri, gerekli veri ve kanıt kopyasını koruduktan sonra kaldırın; yalnızca devre dışı bırakılmış dosyaların hâlâ erişilebilir olabileceğini değerlendirin.
• Uygun bileşenlerde güvenlik güncellemelerini otomatikleştirin. Hata bildirimi, uyumluluk kontrolü ve temiz geri dönüş planını da belirleyin.

8.3. Düzenli Güvenlik Kontrol Listesi

Kontrolleri verinin önemi ve değişiklik sıklığına göre takvime bağlayın; sorumluları ve müdahale adımlarını yazın. Başlangıç listesi:

• İhlal veya ele geçirilme şüphesinde ilgili parolaları/anahtarları yenileyin; sabit 90 günlük zorunlu parola değişimi yerine benzersiz güçlü parolalar, 2FA ve erişim iptalini esas alın.
• Kabul edilebilir veri kaybına göre yedekleme sıklığı belirleyin. Hesaptan bağımsız, erişimi sınırlı ve sürümlü kopyalar tutup geri yüklemeyi düzenli test edin.
• Dosya bütünlüğü, kullanıcı/rol değişiklikleri, cron görevleri, hata ve kimlik doğrulama logları için izleme ve alarm kurun. Tarama sıklığını risk ve değişikliklere göre belirleyin; temiz tarama sonucu tek başına güvence değildir.
• Ajans ve diğer üçüncü tarafların hesaplarını, anahtarlarını ve yetkilerini düzenli gözden geçirip gereksiz erişimi kaldırın.

Başlangıç noktası olarak yeni açılan web siteleri için hazırladığımız güvenlik check-list’ini de kendi sitenize uyarlayabilirsiniz.

9. Hosting Ortamı ve Müdahale Sorumlulukları

9.1. Ayrı Ortamda Temizlik

Hosting sağlayıcınızla, inceleme ve temiz kurulum için hangi izolasyon seçeneklerine erişebildiğinizi netleştirin. Seçilecek planı şu işlere göre değerlendirin:

• Etkilenen hesaptan erişilemeyen yeni bir hesap veya güvenilir VPS ortamı hazırlama
• Temiz uygulama ve incelenmiş dosya/veritabanını ayrı ortama aktarma
• Kontrollü testlerden sonra DNS geçişi, eski erişimin kapatılması ve izleme

Eski ortamı halka açık bir referans sitesi olarak bırakmayın. Kanıt kopyasını ayrı ve kısıtlı erişimle saklayın; aktif zararlı işlemleri durdurun. Saklama süresi, iş gereksinimi ve varsa olay incelemesi tamamlandığında eski hesabın güvenli biçimde kapatılmasını planlayın.

9.2. Güvenlik ve İzleme Kapsamını Belirleme

E-ticaret, SaaS ve kurumsal sitelerde kontrollerin kimin sorumluluğunda olduğunu belirleyin. Hosting teklifinde veya hizmet kapsamınızda şu başlıkları ayrı ayrı doğrulayın:

• Güvenlik duvarı (Firewall) ve WAF ayarlarının düzenli gözden geçirilmesi,
• Yedekleme stratejisinin (3-2-1) planlanması ve test edilmesi,
• Logların merkezi şekilde izlenmesi ve şüpheli aktivitelerde alarm üretilmesi

Bu kontrollerin sahibi, erişilebilir kayıtlar, alarm kanalı ve müdahale süresi belli olmalıdır. İzleme her girişimi ilk aşamada yakalamayı garanti etmez; alarm geldiğinde araştırma ve izolasyon işlemlerinin kim tarafından yapılacağını önceden tanımlayın.

Temizliği Doğrulayın ve Tekrarını Önlemeye Çalışın

PHP site temizliği; backdoor tespiti, dosya ve veritabanı incelemesi, FTP/SSH log analizi ve gerektiğinde temiz ortama geçişi birlikte gerektirir. Giriş yolunu, hesap erişimlerini ve kalıcılık mekanizmalarını değerlendirmeden yalnızca görünen dosyaları silmek yeterli değildir. Bulguları ve yapılan değişiklikleri kaydedin.

Yayına açmadan önce işlevleri, erişim yetkilerini ve temiz geri yükleme yolunu test edin. Düzenli yedek, kontrollü dağıtım, güncelleme ve izleme sorumluluklarını netleştirin. DCHost planınızı değerlendirirken gereken izolasyon, kayıt erişimi ve güvenlik yönetiminin hizmet kapsamına dahil olup olmadığını doğrulayın; bu adımlar hiçbir ortam için mutlak güvenlik garantisi vermez.

Google zararlı yazılım veya phishing uyarısı gösteriyorsa, sorunu giderdikten sonra Search Console Güvenlik Sorunları raporundan inceleme isteyin. Google incelemesi birkaç günden birkaç haftaya sürebilir; tüm tarayıcı ve güvenlik sağlayıcıları için ortak bir kaldırılma süresi yoktur. Sonuç gelmeden veya sorun çözülmeden tekrar başvurmayın. HTTPS/TLS sertifikası kaynaklı “güvenli değil” uyarısı ise ayrı bir sertifika veya yapılandırma sorunudur.

Birincil Teknik Kaynaklar

• WordPress — My Site Was Hacked
• WordPress — Hardening
• PHP — assert
• PHP — create_function
• PHP — Migration to PHP 7.0
• Git — git status
• OWASP — File Upload
• NIST — Digital Identity Guidelines
• Google — Security Issues Report