Hacked PHP Sitelerini Temizleme Rehberi: Backdoor Tespiti, Tarama ve Güvenli Taşıma

Neden Hacked PHP Sitelerini Temizlemek Zorlaştı?

Son yıllarda PHP tabanlı sitelere yönelik saldırılar çok daha sofistike hale geldi. Artık saldırganlar sadece ana sayfayı bozup gitmiyor; 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 DCHost ekibinde sahada sıkça gördüğümüz vakalardan süzülmüş, 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’nin altındaki framework (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.

Adımları sırasıyla uyguladığınızda, sadece mevcut saldırıyı temizlemekle kalmayacak, benzer bir saldırının tekrar yaşanma ihtimalini de ciddi şekilde azaltacaksınız. Ayrıca rehberin sonunda, DCHost altyapısında bu süreci nasıl daha güvenli ve kontrollü yönetebileceğinize 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, muhtemelen sisteminizde kötü amaçlı PHP dosyaları ve backdoor’lar vardır. İ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 hemen değiştirin: Hosting paneli, FTP/SFTP, SSH, veritabanı kullanıcıları, CMS admin hesapları.
• 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: Mevcut durumu belgelemek ve geri dönebileceğiniz bir nokta oluşturmak adına tam yedek alın; ancak bu yedekte de backdoor olabileceğini unutmayın.

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?

Eğer siteniz aktif kötü amaçlı yazılım dağıtıyorsa (tarayıcı uyarıları, zararlı indirmeler, phishing sayfaları vb.), en güvenli hareket kısa süreliğine yayından almak olabilir. Ancak çoğu projede bu mümkün olmadığından, şu orta yolu önerebiliriz:

• Önce admin erişimlerini kısıtlayın.
• Şifreleri değiştirin.
• Kod temelli en kritik açıkları (örneğin tüm wp-config.php veya framework yapılandırma dosyalarına enjekte edilmiş kötü kod) tespit ettiğinizde hızlıca temizleyin.
• Gerekirse bakım sayfası (503 Maintenance) ile geçici bir ekran verin.

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. DCHost altyapısında Apache/Nginx loglarını doğrudan veya panel üzerinden görebilirsiniz. Şu tip istekler dikkat çekicidir:

• Var olmayan PHP dosyalarına yoğun istekler (/wp-login.php, /xmlrpc.php, rastgele .php yolları).
• 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ı Kod 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:

• eval(base64_decode('...'));
• eval(gzinflate(base64_decode('...')));
• preg_replace('/.*/e', $_POST['x'], ''); (eskiden çok yaygındı)
• 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 çoğu zaman sitenizin kök dizininde değil, daha “masum” görünen klasörlerde (örneğin uploads, cache, tmp) saklanır. Dosya isimleri de genelde functions.php, index-old.php, image.php gibi normalde şüphe çekmeyecek şekildedir.

3.3. SSH Üzerinden Dosya Sistemi Taraması

SSH erişiminiz varsa, PHP dosyalarında hızlı bir imza taraması yapmak mümkündür. Örneğin:

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 tek başına “bu dosya kesin backdoor” demez; ancak şüpheli dosyaların listesini çıkarmak için çok yararlıdır. Özellikle uploads gibi normalde PHP dosyası olmaması gereken klasörlerde PHP dosyası bulursanız ekstra dikkatli olun.

3.4. FTP/SFTP ile İndirip Yerelde Tarama

SSH erişiminiz yoksa, tüm site dosyalarınızı yerel bilgisayarınıza indirip antivirüs ve ek zararlı yazılım tarayıcıları ile tarayabilirsiniz. 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.

İ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 güvenilir bir tam yedeğiniz varsa, çoğu zaman en güvenli çözüm şudur:

1. Yeni bir hosting hesabı veya izole bir ortam hazırlayın (DCHost’ta ayrı bir kullanıcı veya ayrı bir VPS hesabı gibi).
2. Temiz yedeği bu yeni ortama geri yükleyin.
3. Veritabanını da aynı tarihteki temiz yedekle değiştirin.
4. Alan adını DNS üzerinden bu yeni ortama yönlendirin.

Bu yaklaşım, mevcut kirlenmiş ortamda “neyi silip neyi bırakacağım” karmaşasını büyük ölçüde azaltır. Ancak çoğu vakada, ya yedek yoktur ya da ne kadar temiz olduğu belirsizdir. O zaman biraz daha detaylı ilerlemek gerekir.

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

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

• Çekirdek dosyaları (core) yeniden yükleyin: Resmi kaynaktan aynı veya güncel sürümü indirip wp-admin, wp-includes ve kökteki çekirdek PHP dosyalarını üzerine yazın.
• Temalar ve eklentiler: Mümkünse resmi depolardan yeniden indirin ve mevcut temayı/eklentileri silip temiz kopyayı yükleyin.
• Yükleme (uploads) klasörü: Normalde burada PHP dosyası olmamalıdır. .php dosyası görüyorsanız çok dikkatle inceleyin; büyük çoğunluğunu silmeniz gerekir.

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ı

Kendi yazılımcınızın geliştirdiği özel bir PHP uygulama kullanıyorsanız, genellikle Git deposu veya yerel bir geliştirme kopyası vardır. Bu durumda yapmanız gereken:

• Canlı sunucudaki kodu git deposuyla karşılaştırın: Versiyon kontrol sistemi kullanıyorsanız, git status çıktısı size hangi dosyaların son deploy’dan sonra değiştiğini gösterecektir.
• Değişiklikleri inceleyin: Beklenmeyen, sizin veya ekibinizin yapmadığı değişiklikler büyük ihtimalle saldırganın bıraktığı izlerdir.
• Gerekirse komple yeniden deploy yapın: Temiz olduğundan emin olduğunuz bir commit’ten itibaren canlı ortama tekrar deploy edin.

Eğer versiyon kontrolü yoksa, bu saldırı sizin için acı ama değerli bir ders olsun; temizlik işlemi biter bitmez bir Git akışı oluşturup canlı ortama sadece kontrollü deploy yapmanızı kesinlikle öneririz.

4.4. Dosya İzinlerini Gözden Geçirin

Birçok saldırı, yanlış dosya izinleri yüzünden büyür. PHP dosyalarınız herkese yazılabilir (777) durumdaysa, saldırgan bir kez girdikten sonra her şeyi çok kolay değiştirir. Güvenli izinler için genel kural:

• PHP dosyaları: 644
• Klasörler: 755
• Asla gereksiz yere 777 vermeyin.

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 çoğu zaman sadece dosyalara değil, veritabanına da iz bırakır. Özellikle:

• 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 veya kullanılmayan admin hesaplarını silin.
• Gerçek admin hesaplarının şifrelerini mutlaka değiştirin.
• Mümkünse iki faktörlü kimlik doğrulama (2FA) ekleyin.

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

İçerik başlıkları, açıklamalar, özel alanlar (custom fields) gibi metin alanlarına enjekte edilmiş zararlı kodlar için veritabanı üzerinde arama yapabilirsiniz. Örneğin MySQL için:

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

Benzer şekilde, sitenizde hiç kullanmadığınız, ancak veritabanında yoğun şekilde geçen keyword’leri (örneğin yabancı dilde kumar terimleri) arayıp, toplu temizlik veya manuel düzeltme yapmanız gerekebilir.

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

6.1. Saldırgan Nereden Girdi?

Backdoor’ları temizlemeniz çok değerli, ancak saldırganın içeriye nasıl girdiğini anlamazsanız, aynı sorun tekrarlar. En yaygın giriş noktaları:

• 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

Hosting panelinizde veya DCHost müşteri arayüzünde FTP/SSH erişim loglarına genellikle ulaşabilirsiniz. Şu noktalara bakın:

• Beklenmeyen ülke/IP adresleri.
• Gece çok geç saatlerde veya olağandışı zamanlarda yapılan bağlantılar.
• Kısa sürede çok sayıda başarısız login denemesi.

Bu IP’leri güvenlik duvarı üzerinden engelleyebilir, ayrıca SSH için port değiştirme, anahtar bazlı kimlik doğrulama gibi önlemler alabilirsiniz. SSH güvenliğini daha derinlemesine ele aldığımız VPS sunucu güvenliği rehberimizi de incelemenizi öneririz.

6.3. Tüm Erişim Şifrelerini Sıfırlama

Temizlik süreci tamamlanırken:

• Hosting panel şifresi
• FTP/SFTP hesapları
• SSH kullanıcıları (ve mümkünse anahtarlar)
• Veritabanı kullanıcıları
• Uygulama admin hesapları

için yeni, güçlü ve benzersiz şifreler oluşturun. Aynı şifreleri birden fazla yerde kullanmaktan kaçının; bir yerde sızan şifre diğer tüm sistemlere giriş anahtarı haline gelebilir.

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

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

Bazı durumlarda, mevcut hosting hesabının tamamen kirlenmiş olduğu ve her köşesindeki dosyaya tek tek bakmanın ekonomik olmadığı bir noktaya gelinir. Örneğin:

• 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.

Bu senaryoda, yeni bir DCHost hesabı veya izole bir VPS ortamına temiz bir kurulum + sadece doğrulanmış dosyaların taşınması ile baştan başlamak çoğu zaman daha güvenlidir.

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

1. Yeni ortamı hazırlayın: DCHost üzerinde yeni bir hosting hesabı veya VPS oluşturun. PHP sürümü, veritabanı sürümü ve gerekli uzantıları projeye uygun şekilde ayarlayın.
2. Temiz uygulama kurulumunu yapın: Kullanılan CMS veya framework’ün temiz bir kopyasını yeni ortama kurun.
3. Sadece doğrulanmış dosyaları taşıyın:
   • Örneğin sadece resim, PDF gibi statik dosyalar.
   • Özel yazılım kodlarını, git deposundan yeniden deploy edin.
   • Eski ortamda “emin olmadığınız” hiçbir PHP dosyasını taşımayın.
4. Veritabanını taşıyın ve temizleyin: Eski ortamdan mysqldump ile aldığınız veritabanını yeni ortama yükleyin, ardından önceki adımlardaki veri temizliklerini (admin kullanıcılar, spam içerikler, enjekte scriptler) burada da yapın.
5. DNS kesintisiz geçiş: Yeni ortamda her şey test edildikten sonra, alan adının DNS kayıtlarını DCHost’taki yeni sunucuya yönlendirin. TTL değerlerini daha önce düşürdüyseniz, geçiş süreci daha da sorunsuz olacaktır.

DNS geçişlerini kesinti olmadan yapabilmek için hazırladığımız Zero-downtime taşıma ve TTL stratejileri rehberi de bu aşamada oldukça faydalı olacaktır.

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

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

Dosyaları ve veritabanını temizledikten sonra, benzer bir saldırının tekrar yaşanmaması için WAF (Web Application Firewall) kullanmanız güçlü bir koruma katmanı sağlar. Hem DCHost tarafında sunucuya entegre ModSecurity gibi çözümler, hem de Cloudflare gibi önde gelen servislerin WAF katmanı, yaygın saldırı vektörlerini daha PHP kodunuza ulaşmadan engelleyebilir.

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

Hacked PHP sitelerin önemli bir kısmı, güncellenmeyen çekirdek sistemler, temalar ve eklentiler yüzünden hackleniyor. Temizlikten sonra mutlaka:

• CMS, framework ve kütüphanelerinizi en güncel kararlı sürüme yükseltin.
• Artık kullanmadığınız eklentileri sadece devre dışı bırakmayın, tamamen kaldırın.
• Mümkünse güvenlik güncellemelerini otomatik olarak alan bir yapı kurun (örn. güvenlik patch’leri için otomatik güncelleme).

8.3. Güvenlik Check-list’i Oluşturun

Temizledikten sonra her şeyin yolunda kalmasını sağlamak için kendi “mini güvenlik check-list”inizi oluşturun. Örneğin:

• Maksimum 3 ayda bir şifre değişimi.
• Aylık tam yedek ve geri yükleme testleri.
• Aylık zararlı taraması (dosya ve veritabanı seviyesinde).
• Üçüncü parti erişimlerin (ajans, freelancer) düzenli gözden geçirilmesi.

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. DCHost Üzerinde Hacked PHP Siteleri İçin Pratik Yol Haritası

9.1. Ayrı Ortamda Temizlik

DCHost olarak müşterilerimize her zaman, hacked bir PHP siteyi aynı ortamda değil, izole bir alanda temizlemeyi öneriyoruz. Örneğin:

• Mevcut hesabınızın yanına yeni bir DCHost hosting hesabı veya VPS açıyoruz.
• Temiz kopya + seçili verilerinizi bu yeni ortama taşıyoruz.
• Testleri tamamladıktan sonra DNS’i yeni ortama yönlendiriyoruz.

Böylece hem mevcut üretim ortamını bir süre daha referans olarak kullanabiliyor hem de temiz ortama geçişi kontrollü şekilde yapabiliyorsunuz.

9.2. Yönetilen Güvenlik ve İzleme

Özellikle e-ticaret, SaaS veya kritik kurumsal sitelerde, güvenlik ayarlarını bir kere yapıp unutmak gerçekçi değil. DCHost üzerinde:

• 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

gibi süreçleri, altyapı seviyesinde planlayıp işletmenize özel bir yol haritası çiziyoruz. Böylece bir sonraki saldırı girişimi, siteniz tamamen ele geçirildiğinde değil, ilk denemelerde fark edilebiliyor.

Sonuç: Tek Seferlik Temizlik Değil, Sürekli Bir Güvenlik Kültürü

Hacked bir PHP siteyi temizlemek, çoğu zaman “tek seferlik bir operasyon” gibi düşünülüyor. Aslında yaşanan şey, size altyapınızın, kod tabanınızın ve operasyonel alışkanlıklarınızın nerelerde zayıf olduğunu gösteren sert ama öğretici bir geri bildirim. Bu rehberde anlattığımız adımlar –backdoor tespiti, dosya ve veritabanı temizliği, FTP/SSH log analizi ve güvenli taşıma– sürecin teknik kısmını kapsıyor; ancak asıl değer, bu deneyimi bir güvenlik kültürüne dönüştürdüğünüzde ortaya çıkıyor.

DCHost olarak PHP tabanlı projeleri sadece barındırmakla kalmıyor, aynı zamanda güvenli mimari tasarımı, yedekleme stratejisi ve WAF/Firewall ayarları konusunda da müşterilerimize rehberlik ediyoruz. Siteniz hacklendiyse ve nereden başlayacağınızı bilmiyorsanız, yukarıdaki adımları bir kontrol listesi gibi uygulayabilir, ardından altyapınızı daha sürdürülebilir ve güvenli hale getirmek için bizimle çalışabilirsiniz. Böylece bir sonraki saldırı girişimi, projenizin kabusu değil, iyi tasarlanmış savunma hattınızın sıradan bir testi olur.