Web Sitesi Güvenliği ve Malware Temizleme: Hacklenen Siteye Acil Müdahale

// Sitenizin hacklendiğini nasıl anlarsınız?

Hacklenen site, çoğu zaman sahibinden önce Google'a, hosting firmasına ya da müşterilere kendini belli eder. Saldırgan siteyi kapatmak yerine gizlice kullanmak ister; bu yüzden ana sayfa normal görünürken arka planda spam sayfalar üretilebilir. Aşağıdaki belirtilerden biri varsa site virüs temizleme ve inceleme gerekir.

• Google arama sonuçlarında "Bu site saldırıya uğramış olabilir" uyarısı ya da tarayıcıda kırmızı güvenlik ekranı çıkıyor
• Arama sonuçlarında hiç oluşturmadığınız sayfalar, Japonca karakterli başlıklar veya ilaç ve kumar spam'i görünüyor
• Ziyaretçiler, özellikle mobilden ya da Google'dan gelenler, başka sitelere yönlendiriliyor
• Hosting firması siteyi "zararlı içerik" gerekçesiyle askıya aldı veya hesabı kısıtladı
• Alan adınızdan giden e-postalar spam klasörüne düşüyor ya da geri dönüyor
• Sunucuda tanımadığınız dosyalar, yönetici hesapları veya zamanlanmış görevler var

Yönlendirme yalnızca belirli ziyaretçilere uygulanabildiği için siz siteyi açtığınızda her şey normal görünebilir. Search Console'daki Güvenlik Sorunları raporu, bu gizli belirtileri ilk gösteren yerdir.

// Hacklenen site nasıl temizlenir?

Hacklenen site, zararlı dosyaları silmekle değil saldırganın nereden girdiğini bulup kapatmakla temizlenir; giriş noktası açık kaldıkça temizlenen site kısa sürede yeniden enfekte olur. Müdahale dört adımdır ve tipik bir vakada 2 ile 3 iş günü sürer. Önce sitenin mevcut halinin yedeği alınır; temizlik sitenin kopyasında doğrulanır ve canlıya düşük trafikli saatte alınır.

Google'ın incelemesi zararlı yazılım vakalarında genellikle birkaç gün, spam vakalarında birkaç hafta sürebilir; süreci Google'ın hacklenen siteler rehberindeki adımlarla yürütüyoruz. Teslimden sonraki 7 gün içinde aynı açıktan yeniden giriş olursa müdahale ücretsizdir.

// Özel yazılımlarda hangi güvenlik açıkları görülür?

Özel PHP ve Node.js yazılımlarda açıklar çoğunlukla koddan gelir: kullanıcı girdisinin denetlenmeden veritabanına, sayfaya ya da dosya sistemine ulaştığı noktalardan. En sık karşılaştığımız türler şunlardır.

• SQL injection: parametreli sorgu yerine metin birleştirmeyle kurulan sorgular, veritabanının tamamının okunmasına yol açabilir
• XSS (siteler arası betik çalıştırma): kaçışlanmadan ekrana basılan yorum, arama veya form içeriği, saldırganın kodunu ziyaretçinin tarayıcısında çalıştırır
• Dosya yükleme açıkları: türü ve uzantısı denetlenmeyen yüklemeler, sunucuya çalıştırılabilir betik bırakmanın en kısa yoludur
• Açıkta kalan dosyalar: web kökünde unutulan .env, .git klasörü, veritabanı dökümü veya .zip yedekleri; içlerindeki parola ve API anahtarları doğrudan indirilebilir
• Kimlik doğrulama ve yetki hataları: sınırsız giriş denemesi, tahmin edilebilir yönetim adresleri, başka kullanıcının kaydına erişim veren kimlik numaraları

İncelemeyi OWASP Top 10 listesindeki kategorilere göre yapıyoruz; bulunan her açık önem derecesi ve düzeltme önerisiyle raporlanır. Açığı kapatmak kod değişikliği gerektiriyorsa düzeltmeyi biz yapabilir ya da kendi geliştiricinize teknik olarak tarif edebiliriz.

// Önleyici site güvenliği neleri kapsar?

Önleyici site güvenliği, saldırganın işini zorlaştıran ve bir saldırı olsa bile zararı sınırlayan katmanlardan oluşur; tek bir eklenti ya da araç bunu tek başına sağlamaz. Temizlik sonrasında ya da hiç saldırı yaşamamış bir sitede şu katmanları kuruyoruz.

• Güncellemeler: çekirdek yazılım, kütüphane, paket ve sunucu yazılımlarının düzenli güncellenmesi; terk edilmiş bağımlılıkların değiştirilmesi
• WAF ve hız sınırlama: bilinen saldırı kalıplarını ve kaba kuvvet giriş denemelerini uygulamaya ulaşmadan durduran güvenlik duvarı
• Güvenlik başlıkları: HTTPS'i zorunlu kılan HSTS, yalnızca izin verilen kaynaklardan betik çalıştıran CSP, X-Content-Type-Options ve Referrer-Policy
• Yedek stratejisi: en az bir kopyası sunucu dışında tutulan, geri yüklemesi denenmiş otomatik yedekler
• Yetki yönetimi ve 2FA: her kişiye ayrı hesap, en az yetki ilkesi, yönetim paneli ve sunucu erişiminde iki adımlı doğrulama

KVKK açısından risk yalnızca sitenin kapanması değildir: form, üyelik veya sipariş verisi sızdırılırsa veri sorumlusu olarak ihlali öğrendiğiniz andan itibaren en geç 72 saat içinde Kişisel Verileri Koruma Kurulu'na bildirim yapmanız gerekir. Bu yüzden kişisel veri tutan sitelerde gereksiz veriyi saklamamayı ve erişim kayıtlarını tutmayı da önlemlerin parçası sayıyoruz. Yedek planının WordPress özelindeki ayrıntıları için WordPress Yedekleme ve Geri Yükleme sayfamıza bakabilirsiniz.

// Kapsama neler dahil, fiyat neye göre belirleniyor?

Kapsam acil müdahale ve önleyici sertleştirme olarak ikiye ayrılır; ikisi ayrı ayrı ya da birlikte alınabilir. Aşağıdaki tablo hangi işin hangi kapsama girdiğini gösterir.

Fiyatı dört değişken belirler: altyapı türü, enfeksiyonun yayıldığı dosya ve veritabanı alanı, sunucuya erişim düzeyi ve sitenin Google ya da e-posta kara listelerine girip girmediği. Tek bir giriş noktası olan küçük bir sitede iş saatlerle ölçülürken, aylarca fark edilmeden kalmış ve binlerce spam sayfa üretmiş bir sitede temizlik ve Google süreci daha uzundur. Ön inceleme ücretsizdir; teklif incelemeden sonra sabitlenir ve sonradan artmaz.

// Hangi altyapılarda çalışıyoruz?

Özel PHP yazılımlar, Node.js ve Next.js uygulamaları, statik HTML siteler, REST API entegrasyonları ve WordPress/WooCommerce siteler üzerinde çalışıyoruz. Statik sitelerde saldırı yüzeyi küçüktür ama sunucu ve FTP erişimi hâlâ risk taşır; dinamik uygulamalarda kod ve bağımlılıklar da incelenir.

Siteniz WordPress ise eklenti açıkları, sahte yönetici hesapları ve tema dosyalarına gizlenen kodlar gibi WordPress'e özgü adımlar için WordPress Güvenlik ve Kurtarma sayfamıza bakın. Wix, Shopify veya Squarespace gibi kapalı platformlarda sunucu ve dosya erişimi olmadığından müdahale alanımız hesap güvenliği, entegrasyonlar ve siteye eklenen betiklerle sınırlıdır; bunu ön incelemede açıkça söylüyoruz. Sorun güvenlik değil de çökme ya da hata mesajıysa Web Sitesi Hata Giderme daha doğru başlangıçtır.

// Projelerimizden örnekler

Geliştirdiğimiz sistemlerde güvenliği sonradan eklenen bir katman olarak değil, tasarımın parçası olarak kuruyoruz. Aşağıdaki iki proje, kişisel veri ve ödeme akışı taşıyan sistemlerde bu yaklaşımın nerede devreye girdiğini gösterir.

• AVM Gazette — AVM, perakende ve ticari gayrimenkul alanında yayın yapan, özel yazılımla geliştirdiğimiz haber portalı. Abonelik sistemi ve KVKK uyumlu çerez yönetimi içerir; abone verisi tutan bir sistemde veri koruması ilk satırdan itibaren tasarımın konusudur.
• Lisansimo — Dijital lisans satışı yapan, geliştirdiğimiz WooCommerce e-ticaret sitesi. Ödeme akışı olan bir mağazada güvenlik; ödeme adımının, sipariş verisinin ve yönetici erişiminin korunması demektir.

Bu projeleri hacklenmiş ya da kurtarılmış siteler olarak değil, güvenliği baştan kurduğumuz örnekler olarak paylaşıyoruz. Bir saldırı vakasında uyguladığımız yöntem, yukarıdaki dört adımlı süreçtir.

Giriş noktası kapatılmadan yapılan temizlik, saldırgana geri dönmesi için zaman kazandırmaktan başka işe yaramaz.

// İşi yürüten ekip ve hangi durumlarda gerekmez?

Müdahaleyi Zep Bilişim'in Kurucu ve Teknik Danışmanı Caner Zep Çelik yürütüyor. 2020'den bu yana Türkiye, Birleşik Krallık ve Almanya'daki müşteriler için 100'ün üzerinde projede yer aldı; sunucu kayıtlarını, kodu ve veritabanını kendisi inceliyor, işi taşerona devretmiyor. Kök neden raporunu da aynı kişi yazıyor.

Belirti yoksa, Search Console'da güvenlik sorunu görünmüyorsa ve yazılım güncel tutuluyorsa acil müdahale gerekmez; önleyici bir kontrol yeterlidir. Tarayıcıdaki "güvenli değil" uyarısı yalnızca SSL sertifikasının süresi dolduğu için çıkıyorsa bu bir saldırı değildir ve sertifika yenilemesiyle çözülür. Ön incelemede durum buysa bunu açıkça söylüyoruz.

// Sıkça Sorulan Sorular