Web Sitesi Hacklendi, Ne Yapmalı? İlk 24 Saatlik Müdahale Planı

Telefon çoğunlukla mesai dışında gelir ve ilk cümle hep aynıdır: “Her şeyi silip yedekten dönelim mi?” Bu soruya cevabım neredeyse her zaman “henüz değil” oluyor. Yedekten dönmek, saldırganın bıraktığı izleri de, girdiği kapıyı gösteren log satırlarını da siler. Üstelik açık hâlâ yerindeyse aynı kişi aynı yoldan tekrar gelir.

İlk çeyrek saatte sorunu çözmeye çalışmayın, büyümesini durdurun yeter. Aşağıdaki beş adım bu süreye sığar ve hiçbiri sonraki incelemeyi zorlaştırmaz.

1. 1Siteyi kapatın ama silmeyinBakım sayfasına alın, hosting panelinden geçici olarak erişimi kısıtlayın ya da yalnız kendi IP adresinize açın. Amaç ziyaretçinin zararlı yönlendirmeye düşmesini ve kart formunun veri kopyalamasını durdurmak.Yapmayın: Dosya klasörünü “temizlemek” için toplu silme
2. 2Kopyayı alınTüm dosyaların arşivini, veritabanı dökümünü (dump) ve erişim/hata loglarını sunucunun dışına indirin. Hosting firmasının otomatik yedeklerinin silinmesini veya üzerine yazılmasını da şimdiden durdurmasını isteyin.Yapmayın: Panelden “geri yükle” düğmesine basmak
3. 3Parolaları temiz bir cihazdan değiştirinÖnce e-posta hesabınız (parola sıfırlama bağlantıları oraya gider), sonra hosting paneli, FTP/SFTP, veritabanı ve site yönetici hesapları. Bilgisayarınızda zararlı yazılım şüphesi varsa telefonunuzdan ya da başka bir cihazdan yapın.Yapmayın: Aynı cihazdan, aynı parolanın küçük bir varyasyonunu kullanmak
4. 4Zaman damgalı not tutmaya başlayınNe gördünüz, saat kaçta fark ettiniz, kimi aradınız, hangi ayarı değiştirdiniz? İlk not, KVKK’nın 72 saatlik süresinin başladığı anı da kanıtlar.Yapmayın: Ekip içinde yalnızca sözlü haberleşmek
5. 5Doğru kişileri arayınHosting firmanız, siteyi yapan geliştirici veya ajans ve şirketinizde kişisel verilerden sorumlu kişi. Ödeme alıyorsanız ödeme sağlayıcınıza da kısa bir ön bilgi verin.Yapmayın: Sosyal medyada açıklama yapıp teknik ayrıntı paylaşmak

Hacklenen sitelerin çoğu sahibine kendini belli etmez. Saldırgan için en değerli site, uzun süre fark edilmeyen sitedir: Google’a spam sayfaları gösterir, mobil ziyaretçiyi kumar sitesine gönderir, yöneticiye ise her şeyi normal gösterir. Bu tekniğe cloaking (gizleme) denir ve “bende sorun yok, ben girince açılıyor” cümlesinin en yaygın nedenidir.

Aşağıdaki belirtilerden birini görüyorsanız testi kendi tarayıcınızda yapmayın. Gizli pencere açın, Wi-Fi’yi kapatıp mobil veriye geçin ve siteye Google arama sonucundan tıklayarak girin. Yönetici oturumu açık tarayıcı, zararlı kodun bilerek es geçtiği ilk ziyaretçidir.

1. 01YönlendirmeGoogle’dan veya mobilden gelince başka siteye gidiyorNasıl bakılır: Gizli pencerede Google’da markanızı arayıp sonuca tıklayın; mobil veriyle tekrar deneyin.
2. 02SEO spamsite: aramasında Japonca, ilaç veya kumar sayfalarıNasıl bakılır: Google’a site:alanadiniz.com yazın; tanımadığınız başlıkları ve yabancı dildeki açıklamaları arayın.
3. 03Google uyarısı“Bu site saldırıya uğramış olabilir” etiketiNasıl bakılır: Arama sonucunda başlığın altında görünür. Chrome’daki tam sayfa kırmızı uyarı ise Google Güvenli Tarama’dan gelir; ikisi de Search Console’da Güvenlik sorunları raporuna düşer.
4. 04Google uyarısıSearch Console’dan güvenlik e-postasıNasıl bakılır: Güvenlik ve Manuel İşlemler → Güvenlik sorunları raporuna bakın; örnek URL’leri not alın.
5. 05HesapTanımadığınız yönetici hesabıNasıl bakılır: Kullanıcı listesini oluşturma tarihine göre sıralayın; rolü sonradan yükseltilmiş hesapları da kontrol edin.
6. 06HostingHosting firması hesabı askıya aldıNasıl bakılır: Askıya alma e-postasında genellikle neden (zararlı dosya, spam gönderimi) ve örnek dosya yolu yazar.
7. 07HesapSunucudan spam e-posta çıkıyorNasıl bakılır: Gönderilmiş e-posta kuyruğuna ve IP adresinizin kara liste durumuna bakın; iletişim formu dışında PHP mail çağrısı var mı?
8. 08ÖdemeÖdeme sayfasında yabancı scriptNasıl bakılır: Ödeme adımını açıp tarayıcı geliştirici araçlarında Ağ sekmesine bakın; tanımadığınız bir alan adına giden istek var mı?
9. 09SunucuAni CPU artışı, açıklanamayan yavaşlıkNasıl bakılır: Panelde işlem listesine bakın; kripto madenciliği yapan veya saldırı başlatan PHP süreçleri sık görülür.

Listede olmayan iki belirti daha var ve ikisi de en ağır sınıftandır: fidye notu ya da şifrelenmiş dosyalar, bir de müşterilerinizin sizin adınıza gönderilmiş sahte e-posta veya veritabanınızın satıldığı iddiası. Bunlarda doğrudan sihirbaza ve kanıt koruma bölümüne geçin.

Kanıt dediğimde mahkeme salonunu düşünmeyin; ilk kullanıcısı sizsiniz. Saldırganın hangi gün, hangi dosya üzerinden girdiğini gösteren tek kaynak log satırları ve dosyaların değişiklik tarihleridir. Bunlar silinirse kök nedeni tahminle bulmaya çalışırsınız, yedeğin temiz olup olmadığını da bilemezsiniz.

İkinci kullanıcı KVKK ve hukuk tarafıdır. Kurul, veri sorumlusundan ihlalle ilgili olguları, etkilerini ve alınan önlemleri kayıt altına almasını bekliyor. Suç duyurusunda bulunmaya karar verirseniz savcılık da aynı kayıtları isteyecektir. Üçüncü kullanıcı ise sigorta veya sözleşme tarafı olabilir: siber sigortası olan işletmeler, poliçenin olay bildirimi ve kanıt koruma şartlarını önceden okumalı.

Kopyayı alırken tek bir kural var: orijinali değiştirmeyin. Dosyaları arşivleyin, arşivin özet değerini (hash) yazın ve sunucu dışında, yazma yetkisi kısıtlı bir yerde saklayın.

# 1) Son 30 günde değişen dosyaları tarihleriyle listele
find /var/www/site -type f -mtime -30 -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort > degisen-dosyalar.txt

# 2) Site klasörünü, izin ve tarihleri koruyarak arşivle
tar --numeric-owner -czpf site-kopya-$(date +%F).tar.gz /var/www/site

# 3) Veritabanı dökümü (tek tutarlı anlık görüntü)
mysqldump --single-transaction -u kullanici -p veritabani > db-$(date +%F).sql

# 4) Logları arşivle ve hepsinin özet değerini kaydet
tar -czf loglar-$(date +%F).tar.gz /var/log/nginx /var/log/auth.log
sha256sum *.tar.gz *.sql > ozet-degerleri.txt

Olay günlüğü için özel bir yazılım gerekmez; paylaşılan bir belge yeter. Her satırda zaman (saat ve dakikasıyla), işlemi yapan kişi, yapılan iş ve varsa ilgili dosya veya ekran görüntüsü olsun. Sihirbazın ürettiği şablon bu sütunlarla gelir.

En sık duyduğum hikâye şu: “Yedekten döndük, her şey düzeldi, bir hafta sonra aynı spam sayfaları geri geldi.” Yedekten dönmek evi eski hâline getirir ama kırık kapıyı tamir etmez. Saldırganlar çoğu zaman otomatik araçlarla binlerce siteyi tarar; açık yerindeyse aynı araç sitenizi bir sonraki turda yine bulur.

Kök neden analizi, logda bulduğunuz ilk şüpheli olaydan geriye doğru yürümektir. Örneğin uploads klasöründeki bir PHP dosyasının oluşturulma saatini bilirseniz, erişim logunda o saniyedeki POST isteğini ve hangi eklentinin yükleme ucunun kullanıldığını bulabilirsiniz. Sızma testi raporlarında “dosya yükleme üzerinden uzaktan kod çalıştırma” ya da “kimlik doğrulama atlatan SQL enjeksiyonu” olarak gördüğünüz bulgular, gerçek olaylarda tam olarak bu izi bırakır.

Temizlik stratejisini iki soru belirler: elinizde ihlalden önce alındığından emin olduğunuz bir yedek var mı, ve saldırganın nereden girdiğini biliyor musunuz? İki sorunun cevabı da evetse yedekten dönmek en hızlı yoldur. Biri hayırsa daha zahmetli ama daha güvenli yollara geçersiniz.

“İhlalden önce” ifadesine dikkat edin. İlk belirtiyi gördüğünüz gün, saldırganın girdiği gün değildir. Japon spam sayfalarını fark ettiğiniz gün, arka kapı haftalardır orada duruyor olabilir. Bu yüzden yedeğin tarihini kanıt bölümünde bulduğunuz ilk şüpheli log satırıyla karşılaştırın, belirtiyle değil.

• En hızlıYedekten dönmekNe zaman: Yedek, logdaki ilk şüpheli olaydan önce alınmış ve kök neden biliniyor.Risk: Açık kapatılmadan dönülürse saldırı tekrarlar; yedekten sonraki siparişler ve içerikler kaybolur.
• Orta yolÇekirdeği yeniden kurmakNe zaman: Temiz yedek yok ama içerik ve veritabanı kurtarılabilir durumda.Risk: Veritabanına enjekte edilmiş script ve kötü niyetli kullanıcılar elle temizlenmelidir.
• En güvenliSıfırdan kurmakNe zaman: Sunucu seviyesinde erişim, tekrarlayan saldırı veya bakımsız eski bir sistem.Risk: En uzun yol; içerik taşıma ve URL yapısının korunması ayrıca planlanmalı.

Temizlik sırası

1. 1Kopya alındıktan sonra çalışmayı mümkünse ayrı bir ortamda (staging) yapın; canlı site bakım modunda kalsın.
2. 2Çekirdek dosyaları (WordPress, OpenCart, framework) resmî kaynaktan, aynı sürümde yeniden indirip üzerine yazın; yalnız içerik klasörlerini ve yapılandırmayı koruyun.
3. 3Eklenti ve temaları kendi sitenizden değil, üreticinin sitesinden yeniden indirin. Kullanmadıklarınızı kurmayın.
4. 4.htaccess, wp-config.php veya config.php, index.php ve zamanlanmış görevleri satır satır okuyun; yönlendirme ve auto_prepend_file gibi ayarlar sık kullanılan gizlenme noktalarıdır.
5. 5Veritabanında script, iframe ve tanımadığınız alan adlarını arayın; seçenekler ve kullanıcılar tablolarını kontrol edin.
6. 6Dosya izinlerini düzeltin: web sunucusu kullanıcısı kod dosyalarına yazabiliyorsa bir sonraki açıkta zararlı kod yine kalıcı olur.
7. 7Canlıya almadan önce gizli pencere, mobil veri ve Googlebot kullanıcı aracısıyla test edin.

OpenCart mağazalarında saldırgan genellikle yönetici klasörünü, system/storage altını ve OCMOD değişikliklerini kullanır; ödeme ve sipariş onay şablonlarını da mutlaka karşılaştırın. OpenCart tarafında bakım ve yönetilen barındırma için OpencartExtra markamızla çalışıyoruz. Eski ve bakımsız bir altyapıyı yamamak yerine yeniden yazmak daha mantıklı olabilir; bu kararı eski sistem modernizasyonu sayfamızda ve web yazılım geliştirme hizmetimizde ele alıyoruz. Sıfırdan kurulumda URL yapısını korumak için SEO kaybetmeden site taşıma rehberini kullanın.

Güncel tutulan bir WordPress çekirdeği nadiren giriş kapısı olur; açıkların büyük kısmı eklenti ve temalardan çıkar. Önüme gelen WordPress olaylarında tablo genelde şu üçünden biri: aylardır güncellenmemiş bir form ya da sayfa oluşturucu eklentisi, bir forumdan indirilmiş “ücretsiz” premium tema veya iki yıl önce ayrılan çalışanın hâlâ açık duran yönetici hesabı.

Wordfence ya da benzeri bir güvenlik eklentisiyle tarama yapmak iyi bir başlangıç ama yetmez. Eklentiler bilinen imzaları bulur. Veritabanına gömülmüş bir yönlendirme, mu-plugins klasöründeki tek satırlık bir dosya ya da meşru görünen bir yönetici hesabı çoğu zaman taramadan geçer.

• ?Kullanıcılar ve rollerKullanıcılar ekranında rolü Yönetici olanları filtreleyin; tanımadığınız hesapları ve son eklenenleri kontrol edin.
• ?uploads içindeki PHP dosyalarıwp-content/uploads görsel ve belge içindir; içinde .php dosyası olmamalı. Bulduğunuz her dosya ciddi şüphelidir.
• ?mu-plugins ve drop-in dosyalarıwp-content/mu-plugins panelde görünmeden otomatik çalışır. object-cache.php gibi drop-in dosyaları da kontrol edin.
• ?Zamanlanmış görevler (wp-cron)Silinen zararlı kodu her saat yeniden yazan bir görev, temizliğin geri gelmesinin klasik nedenidir.
• ?Çekirdek dosya bütünlüğüWP-CLI ile wp core verify-checksums komutu çekirdek dosyaları resmî özet değerleriyle karşılaştırır.
• ?Eklenti envanteriEtkin olmayan eklentiler de çalıştırılabilir dosyadır. Kullanmadığınızı silin, kalanları güncelleyin.

# Yönetici rolündeki kullanıcılar ve kayıt tarihleri
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Çekirdek ve eklenti dosyalarını resmî özet değerleriyle karşılaştır
wp core verify-checksums
wp plugin verify-checksums --all

# uploads içinde PHP dosyası var mı?
find wp-content/uploads -type f -name "*.php"

# Zamanlanmış görevler
wp cron event list

# wp-config.php: panelden tema/eklenti dosyası düzenlemeyi kapat
define( 'DISALLOW_FILE_EDIT', true );

Google bir sitede zararlı yazılım, yönlendirme veya enjekte edilmiş spam tespit ettiğinde arama sonucuna uyarı ekler, Chrome’da da tam sayfa uyarı gösterebilir. Bu uyarı kendi kendine hemen kalkmaz; site temizlendikten sonra sizin inceleme istemeniz gerekir.

Süreci Search Console yürütür. Siteniz Search Console’da doğrulanmamışsa ilk iş bunu yapmaktır; DNS kaydıyla alan adı mülkü eklemek tüm alt alan adlarını tek seferde kapsar ve saldırganın oluşturduğu alt alan adlarını da görmenizi sağlar.

1. 1Raporu açınSearch Console sol menüsünde Güvenlik ve Manuel İşlemler altındaki Güvenlik sorunları raporu. Sorun türünü (“Saldırıya Uğradı: İçerik yerleştirme”, “Kod yerleştirme” veya “URL yerleştirme”) ve örnek URL’leri not alın.
2. 2Tüm sayfaları temizleyinGoogle örnek URL listesinin dışında da kontrol eder. Yalnız bazı sayfaları temizlemek kısmi geri dönüş sağlamaz.
3. 3Spam URL’lerini kapatınSaldırganın ürettiği sayfalar 404 veya 410 döndürsün. 410, sayfanın bilerek kaldırıldığını daha açık söyler.
4. 4İnceleme isteğinde bulununRapordaki düğmeyle isteği gönderin; sorunun ne olduğunu, ne yaptığınızı ve sonucu kısa ve somut yazın.
5. 5Bekleyin, tekrar göndermeyinGoogle’a göre inceleme birkaç gün ile birkaç hafta sürebilir. Karar gelmeden yeni istek göndermeyin; sorun tam düzelmeden gönderilen istekler süreyi uzatır.

Sitemizde [tarih] tarihinde tespit edilen içerik yerleştirme (spam sayfaları) sorununu giderdik.

Sorun: Güncel olmayan bir eklentinin dosya yükleme ucu üzerinden sunucuya zararlı PHP dosyası yerleştirilmiş, bu dosya yabancı dilde spam sayfaları üretiyordu.

Yaptıklarımız:
- Açığı içeren eklentiyi kaldırdık, tüm eklenti ve temaları resmî kaynaktan yeniden kurduk.
- Çekirdek dosyaları yeniden yükledik, uploads klasöründeki çalıştırılabilir dosyaları sildik.
- Tüm yönetici, panel, FTP ve veritabanı parolalarını değiştirdik; tanımadığımız hesapları kaldırdık.
- Spam URL'leri artık 410 yanıtı veriyor; temiz sitemap'i yeniden gönderdik.

Sonuç: Siteyi gizli pencere, mobil cihaz ve Googlebot kullanıcı aracısıyla test ettik; zararlı içerik veya yönlendirme kalmadı.

Japon anahtar kelime saldırısında (Japanese keyword hack) saldırgan, sitenizde binlerce otomatik sayfa üretir ve Google’a gönderir. Temizlikten sonra bu URL’ler bir süre daha arama sonuçlarında görünebilir. Kaldırmalar aracı onları geçici olarak (yaklaşık altı ay) gizler; kalıcı çözüm, URL’lerin 404 veya 410 döndürmesi ve Google’ın bunları yeniden taramasıdır.

Saldırgan Search Console’a kendini sahip olarak eklemiş olabilir: Ayarlar → Kullanıcılar ve izinler ekranında tanımadığınız hesap varsa ve doğrulama yöntemi sitenize yüklenmiş bir HTML dosyasıysa, dosyayı silip kullanıcıyı kaldırın. Aksi hâlde saldırgan size ait sitenin sitemap’ini gönderebilir.

Sıralamalar genellikle temizlik ve uyarının kalkmasından sonra toparlanır ama bu kendiliğinden ve garantili değildir. Spam URL’leri temizlenmiş, teknik altyapısı sağlam bir site daha hızlı toparlanır; kalan sorunlar için teknik SEO audit kontrol listesi iyi bir başlangıç noktasıdır.

6698 sayılı Kişisel Verilerin Korunması Kanunu’nun 12. maddesinin 5. fıkrası, işlenen kişisel verilerin kanuni olmayan yollarla başkaları tarafından elde edilmesi hâlinde veri sorumlusunun bunu en kısa sürede ilgili kişiye ve Kurul’a bildirmesini ister. Kurul, 24.01.2019 tarihli ve 2019/10 sayılı kararıyla “en kısa süre”yi, ihlalin öğrenildiği andan itibaren 72 saat olarak yorumladı.

Burada iki ayrıntı pratikte çok şeyi değiştiriyor. Birincisi, saat sayacı saldırının gerçekleştiği anda değil, sizin öğrendiğiniz anda başlar. Bu yüzden ilk notunuzun saati önemlidir. İkincisi, tüm bilgileri 72 saatte toplamak zorunda değilsiniz: Kurul, bilgilerin gecikmeksizin aşamalı olarak verilebileceğini kabul ediyor. Haklı bir nedenle süre kaçtıysa, bildirimde gecikmenin nedeni de açıklanmalı.

Bildirim Kurum’un çevrim içi sistemi ihlalbildirim.kvkk.gov.tr üzerinden yapılır. Aynı sayfadaki “Bildirim Sorgula / Bildirim Güncelle” bağlantısıyla ilk bildirimi sonradan tamamlayabilirsiniz; aşamalı bildirim pratikte böyle işliyor. Etkilenen kişilere ise, kim olduklarını belirledikten sonra makul olan en kısa sürede, ulaşılabiliyorsa doğrudan, ulaşılamıyorsa web siteniz gibi uygun bir yöntemle bildirim yapılır.

Süre

İhlalin öğrenilmesinden itibaren gecikmeksizin, en geç 72 saat

Kanal

ihlalbildirim.kvkk.gov.tr (Kurum’un çevrim içi bildirim sistemi)

Eksik bilgi

Gecikmeye yol açmadan aşamalı olarak tamamlanabilir

Gecikme

Bildirimle birlikte gecikmenin nedenleri açıklanır

İlgili kişiler

Etkilenenler belirlendikten sonra makul olan en kısa sürede

Veri işleyen

Hosting veya yazılım firması ihlali öğrenince gecikmeksizin size bildirir

Bir de 19 Mart 2025’te Resmî Gazete’de yayımlanarak yürürlüğe giren 7545 sayılı Siber Güvenlik Kanunu var. Kanun, bilişim sistemleri üzerinden hizmet sunan, veri toplayan veya işleyen kişi ve kuruluşlara, hizmet sundukları alanda tespit ettikleri zafiyet ve siber olayları gecikmeksizin Siber Güvenlik Başkanlığı’na bildirme yükümlülüğü getiriyor. Kapsamın ve uygulama ayrıntılarının nasıl netleşeceği ikincil düzenlemelere bağlı; KVKK bildirimiyle tutarlı yürütülmesi gerekiyor. İşletmenizin bu kapsamda olup olmadığını hukuk danışmanınızla değerlendirin.

Askıya alma can sıkar ama çoğu zaman sizin de işinize yarar. Hosting firması hesabınızdan spam gittiğini veya zararlı dosya sunulduğunu görmüş, sunucunun IP itibarını ve diğer müşterileri korumak için erişimi kesmiştir. Destek ekibiyle tartışmayın; elindeki tarama raporu ve loglar sizin için şu an en değerli bilgi.

Paylaşımlı hostingte ayrıca komşu riski vardır. Hesaplar düzgün yalıtılmamışsa, aynı sunucudaki başka bir sitenin açığından sizin dosyalarınıza ulaşılabilir. Aynı panel hesabında bakımsız bir test kurulumu veya eski bir alt alan adı tutuyorsanız, komşu siz olabilirsiniz. Ayrı ve yalıtılmış ortam ihtiyacını hosting, VPS, bulut ve dedicated farkı yazımızda karşılaştırdık.

Kendi VPS’iniz veya dedicated sunucunuz söz konusuysa durum farklıdır: hosting firması işletim sisteminin içine bakmaz, sorumluluk sizdedir. Saldırgan kök (root) yetkisi aldıysa sunucuda rootkit bırakmış olabilir ve bu durumda yapılan her “temizlik” şüphelidir. Bizim pratiğimizde bu tabloda en güvenli yol temiz bir işletim sistemi kurup yalnız veriyi, incelendikten sonra taşımaktır. Yeni sunucunun ilk saatlerinde yapılacakları Linux sunucu güvenliği: yeni VPS’te ilk 24 saat yazısında anlattık.

Güncellemeleri, yedekleri ve malware taramasını kendi başınıza takip edemiyorsanız yönetilen bir ortam daha mantıklıdır. Web hosting paketlerimizden Business ve üstünde Imunify360 ile malware taraması ve WAF hazır geliyor; ayrı ve yalıtılmış kaynak gerekiyorsa bulut sunucu kiralama seçeneğine bakın. Hacklenmeden sonra sitenin yavaş açılması da sık görülür; madencilik süreci veya spam kuyruğu temizlendikten sonra hâlâ yavaşsa sorun hostingte mi, sitede mi yazısındaki teşhis adımlarına bakın.

E-ticaret sitesinde en sessiz ve en pahalı saldırı türü kart verisi kopyalamadır (Magecart tipi skimming). Saldırgan ödeme sayfasına birkaç satırlık bir JavaScript ekler. Müşteri kart numarasını yazarken script bu bilgiyi aynı anda başka bir sunucuya gönderir; ödeme normal şekilde tamamlanır, kimse bir şey fark etmez. Çoğu zaman olayı ilk fark eden, müşterilerin kartlarında ortak bir mağaza gören banka olur.

Riskin büyüklüğü ödeme entegrasyonunuzun türüne bağlıdır. Kart bilgisi sizin sayfanızdaki bir formda yazılıyorsa, sayfanıza eklenen her script o alanları okuyabilir. Ödeme sağlayıcının kendi barındırdığı ödeme sayfasına yönlendiriyorsanız kart alanları sizin sunucunuzda değildir; yine de saldırgan yönlendirme bağlantısını sahte bir sayfaya çevirebilir. 3D Secure doğrulaması kartın izinsiz kullanımını zorlaştırır ama kart bilgisinin kopyalanmasını engellemez.

PCI DSS 4.0 bu senaryo için iki madde ekledi: ödeme sayfasında çalışan scriptlerin envanterinin tutulması ve her birinin yetkilendirilmesi (6.4.3), ödeme sayfasındaki yetkisiz değişikliklerin tespit edilmesi (11.6.1). Bu maddeler 31 Mart 2025’ten itibaren zorunlu. Küçük bir mağaza için pratik karşılığı şu: ödeme sayfanızda hangi scriptlerin yüklendiğini bilin ve değiştiğinde haberiniz olsun.

Skimming şüphesinde sıra

1. 1Ödeme modülünü veya siteyi geçici olarak kapatın; zararlı scripti silmeden önce kopyasını ve hedef alan adını kayda alın.
2. 2iyzico, PayTR gibi ödeme kuruluşunuzu ya da bankanızın sanal POS birimini arayın; şüpheli dönem için işlem izlemesi isteyin.
3. 3Scriptin ne zamandan beri durduğunu dosya tarihleri ve loglarla belirleyin; bu aralık, etkilenmiş olabilecek işlemleri tanımlar.
4. 4Ödeme entegrasyon anahtarlarını yenileyin; ödeme sağlayıcısı panelinin parolasını değiştirin ve iki adımlı doğrulamayı açın.
5. 5Kart sahipleri etkilendiyse bu bir kişisel veri ihlalidir; KVKK süreci ödeme sağlayıcıyla yazışmalarla paralel yürür.
6. 6Müşteri iletişimini hukuk danışmanınızla birlikte, net ve teknik jargon olmadan hazırlayın: ne oldu, hangi tarihler, ne yapmalılar.

Yeni bir mağaza altyapısı veya ödeme akışı tasarlıyorsanız güvenliği baştan kurmak çok daha ucuzdur. E-ticaret platformu için web yazılım ve fintech ve ödeme sistemleri sayfalarımızda bu tasarımı nasıl ele aldığımızı anlatıyoruz.

Temizlik bittiğinde site en savunmasız dönemindedir: saldırgan sitenizi listesinde tutuyor, siz de yorgunsunuz. İlk ayı dört haftaya bölmek hem işi yönetilebilir kılar hem de “bir ara yaparız” listesinin kaybolmasını engeller.

1. 1. haftaKimlik ve erişim
   • Tüm panel ve yönetici hesaplarında iki adımlı doğrulama
   • Parola yöneticisi ve paylaşılan parolaların kaldırılması
   • Ayrılan çalışan ve eski ajans hesaplarının silinmesi
   • FTP yerine SFTP; panel erişiminde IP kısıtı
2. 2. haftaGüncelleme ve kenar koruması
   • Eklenti, tema ve çekirdek için yazılı güncelleme takvimi
   • WAF ve kaba kuvvet (brute force) koruması
   • Güvenlik başlıkları: HSTS, CSP, X-Content-Type-Options
   • Geçerli SSL sertifikası ve HTTP’den HTTPS’e tek yönlendirme
3. 3. haftaYedek ve görünürlük
   • Sunucu dışında, değiştirilemez (immutable) yedek
   • Bir geri yükleme testinin gerçekten yapılması
   • Log saklama süresinin uzatılması ve merkezi toplama
   • Dosya bütünlüğü ve yeni yönetici hesabı uyarıları
4. 4. haftaBağımsız doğrulama
   • Kapsamı belirlenmiş bir sızma testi
   • Bulguların önceliklendirilip kapatılması
   • Kapanışı doğrulayan yeniden test
   • Olay günlüğünden çıkarılan dersler toplantısı

SSL tarafında sertifikanın türünden çok geçerliliği ve doğru kurulumu önemlidir; ihtiyaç duyarsanız lisans satış üzerinden sertifika tedarik ediyoruz. Dördüncü haftadaki testin neleri kapsadığını ve raporun nasıl okunduğunu sızma testi nedir yazımızda anlattık; bütçe sorusu için sızma testi fiyatları yazısına bakabilirsiniz.

Hacklenmiş bir siteye test yaptırmanın avantajı, test ekibinin bilinen bir saldırı izinden başlayabilmesidir. Biz bu durumda olay günlüğünü ve kök neden notlarını kapsam toplantısına getirmenizi istiyoruz; aynı yolun gerçekten kapandığını ilk olarak doğrularız.

Her hack olayı bir müdahale ekibi gerektirmez. Ana sayfasına slogan yazılmış, form kaydı bile tutmayan bir tanıtım sitesini düşünün; kök neden de belli bir eklenti açığıysa kendi geliştiriciniz bu yazıdaki adımlarla işi toparlayabilir. Böyle bir olay için günlerce sürecek adli inceleme satın almanızı önermem.

Aşağıdakilerden biri varsa iş, kendi başına çözülecek bir web sorunu olmaktan çıkar.

• !Kişisel veri veya ödeme verisi etkilenmiş olabilir
• !Kök neden bulunamadı ya da site ikinci kez hacklendi
• !Sunucu seviyesinde (root, SSH) erişim şüphesi var
• !Fidye notu bırakıldı veya dosyalar şifrelendi
• !Ödeme sağlayıcısı, banka veya bir kurum sizinle iletişime geçti

Hukuki yol da açık: Türk Ceza Kanunu’nun 243–245. maddeleri bilişim sistemine izinsiz girme, verileri bozma veya değiştirme ve banka ya da kredi kartlarının kötüye kullanılmasını suç olarak tanımlar. Suç duyurusu Cumhuriyet başsavcılığına yapılabilir; kanıt bölümünde topladığınız kopyalar ve özet değerleri bu başvurunun dayanağıdır. Ulusal Siber Olaylara Müdahale Merkezi’nin (USOM) yürüttüğü siber ihbar süreçleri de 7545 sayılı Kanun’la birlikte Siber Güvenlik Başkanlığı’nın siberguvenlik.gov.tr adresine taşındı.