Web sitemi yaklaşık üç yıl önce yenilerken 404 sayfalarına gelen istekleri ayrıca kaydetmeye karar vermiştim. Amacım, sitemde artık bulunmayan sayfaları bulmaktan çok, internet üzerinde otomatik olarak yapılan saldırı ve güvenlik taramalarının hangi adresleri denediğini görebilmekti.
Bir başka deyişle, ziyaretçinin yanlış bir URL yazması ya da benim bir şekilde bir bağlantının kırılmasına sebep olup olmadığımın yanı sıra asıl merak ettiğim, botların hangi adresleri denediğiydi.
Aradan geçen yıllarda elimde artık bunun üzerine anlamlı bir tablo çıkarabilecek kadar veri birikti. Veritabanındaki 810 kaydı inceledim ve benzer yolları bir araya getirip gruplandırarak bunların içinden güvenlik açısından anlamlı olanları inceledim.
Bu yazının amacı yalnızca “bana şu saldırılar gelmiş” demek değil. İnternete açık bir web sitesinde saldırganların hangi adresleri kontrol ettiğini, bu istekle neyi öğrenmeye veya hangi açığı bulmaya çalıştığını ve böyle bir durumda site sahibinin ne yapması gerektiğini anlaşılır bir güvenlik kılavuzu haline getirmek.
Çünkü internete açık sunucular, saldırganlar tarafından çoğu zaman özel olarak seçilmekten ziyade otomatik tarama botları tarafından rastgele ve geniş ölçekli biçimde taranıyor. Bu botlar, karşılarına çıkan her alan adında, IP adresinde yüzlerce farklı yazılım, yönetim paneli, bilinen açık ve unutulmuş dosya adresini sırayla deneyebiliyor. Burada önemli olan bu otomatik taramalardan hangilerinin gerçekten sizin sisteminiz açısından risk oluşturabileceğini anlayabilmek.
1. Kayıtlardaki en önemli alarm: /.env
Listenin açık ara en fazla denenen adresi /.env.
Bu yol farklı kayıtların birleştirilmesiyle 34 bin kez denenmiş. Bu kadar yüksek frekans tesadüf değil. .env dosyası, özellikle PHP, Laravel, Node.js ve benzeri modern uygulamalarda veritabanı bağlantıları, API anahtarları, uygulama sırları ve çeşitli kimlik doğrulama bilgilerinin tutulduğu bir dosya olarak kullanılabiliyor.
Saldırganın mantığı oldukça basit: “Bu sunucunun kök dizininde yanlışlıkla web üzerinden okunabilen bir .env dosyası var mı?”
Eğer cevap evetse, saldırgan bazen doğrudan kullanıcı adı, parola, veritabanı bilgisi, SMTP hesabı, API anahtarı veya uygulamanın gizli anahtarlarını elde edebilir. Bundan sonrası artık yalnızca web sitesinin değil, bağlı olduğu başka servislerin de güvenliği açısından problem haline gelebilir.
Yazılım ve web uygulamalarının güvenliğini artırmak için ücretsiz kaynaklar, standartlar ve araçlar sunan küresel bir siber güvenlik topluluğu olan Open Worldwide Application Security Project (OWASP) da sırların kod depolarında, ortam değişkenlerinde ve benzeri yerlerde yanlışlıkla açığa çıkmasının ciddi bir güvenlik problemi olduğunu vurguluyor.
Bu nedenle .env gibi dosyalar kesinlikle web sunucusunun doğrudan erişebileceği bir yerde bırakılmamalı. Dosyanın varlığı gerekiyorsa web kök dizininin dışında tutulması veya web sunucusu tarafından açıkça engellenmesi gerekir.
Daha da önemlisi, böyle bir dosyanın yanlışlıkla internete açıldığı fark edilirse sadece dosyayı silmek yeterli değil. Dosyanın içinde parola veya anahtar bulunduysa bunların sızmış kabul edilip değiştirilmesi gerekir.
Aynı nedenle kayıtlarda görülen /.env.bak, /api/.env, /app/.env, /backend/.env, /admin/.env, /core/.env, /laravel/.env, /public/.env, /storage/.env, /database/.env, /vendor/.env gibi varyasyonlar da tesadüfi değil. Saldırgan tek bir dosyayı değil, geliştiricilerin yanlışlıkla bırakmış olabileceği farklı konfigürasyon dosyalarını arıyor.
2. Kaynak kodunun peşinde: /.git/config
İkinci büyük alarm gruplarından biri /.git/config. Bu adres 4 binden fazla kez denenmiş.
.git dizini, Git ile yönetilen bir projenin depo bilgilerini içerir. config dosyası da bu depoya özgü Git yapılandırmasının bir parçasıdır. Saldırgan açısından önemli nokta şu: Web sunucusunun altında yanlışlıkla .git klasörü bulunuyorsa mesele yalnızca bir konfigürasyon dosyasının açılması olmayabilir. Uygulamanın kaynak koduna, geçmiş sürümlere, dosya adlarına ve daha önce projede bulunmuş hassas bilgilere ulaşmanın ilk adımı olabilir.
Özellikle Git geçmişine yanlışlıkla parola veya API anahtarı eklenmişse, geliştirici daha sonra o satırı silmiş olsa bile geçmiş commit'lerde bulunmaya devam edebilir.
Bu nedenle üretim sunucusunun web kök dizinine .git klasörü koymamak en güvenli çözümdür. Orada bulunması gerekiyorsa web sunucusu seviyesinde erişim kesin olarak engellenmelidir.
/.git/config araması, .env aramasıyla birlikte düşünüldüğünde saldırganın aslında tek bir teknolojiyi hedeflemediğini gösterir. Amaç, geliştiricinin unutabileceği dosyalardan mümkün olduğunca fazla bilgi toplamak.
3. “Bu site WordPress mi?”: /wp-login.php
Kayıtlardaki ikinci en yoğun istek wp-login.php adresine yapılmış; yaklaşık 15 bin deneme.
Burada saldırganın ana amacı bir açığı doğrudan kullanmak değil, sitenin WordPress olup olmadığını anlamak.
Saldırganlar sitenizde kullandığınız altyapıyı öğrenmek ister. İnternete açık yüz binlerce site olduğu için botlar doğrudan standart WordPress yollarını deneyebilir. /wp-login.php cevap verirse “burada WordPress olma ihtimali yüksek” diyerek bir sonraki aşamaya geçebilir.
Eğer gerçekten WordPress çalışıyorsa sıradaki aşama sırayla kullanıcı adı ve parola kombinasyonlarını denemek olabilir. Buna kaba kuvvet saldırısı deniyor. WordPress'in resmi güvenlik dokümantasyonu da kaba kuvvet saldırılarının en yaygın WordPress saldırı türlerinden biri olduğunu belirtiyor.
Burada önemli bir ayrım var: wp-login.php adresinin bulunması kendi başına bir güvenlik açığı değil. Problem, bu giriş noktasının zayıf parolalar, sınırsız deneme, çalınmış parolalar veya başka bir uygulama açığıyla birleşmesidir. Bu nedenle WordPress kullanan sitelerde güçlü ve benzersiz parolaların yanında iki aşamalı kimlik doğrulama, mümkünse passkey veya benzeri güçlü kimlik doğrulama yöntemleri ve özellikle giriş denemelerine hız sınırlaması uygulanması önemlidir.
4. Eski bir özellik, hâlâ canlı bir saldırı noktası: /xmlrpc.php
/xmlrpc.php adresi de en çok denenen adreslerden biri. XML-RPC, WordPress'in uzaktan bazı işlemler yapmasına olanak sağlayan eski bir mekanizma. Günümüzde ise saldırganların özellikle kaba kuvvet denemelerinde sık hedeflediği noktalardan biri haline geldi. WordPress'in kendi güvenlik dokümantasyonu da xmlrpc.php dosyasının, özellikle system.multicall yöntemi nedeniyle sık hedef olduğunu ve kullanılmıyorsa devre dışı bırakılabileceğini belirtiyor.
Bunun saldırgana sağladığı avantajlardan biri, çok sayıda kimlik doğrulama denemesini tek bir XML-RPC isteğinin içinde toplamak olabilir. Dolayısıyla yalnızca /wp-login.php sorgularına bakmak, WordPress'e yönelik bütün parola saldırılarını görmek için yeterli olmayabilir.
XML-RPC'yi kullanmıyorsanız kapatmak, kullanıyorsanız erişimi sınırlandırmak ve hız sınırlaması uygulamak mantıklı bir savunmadır. Özellikle Jetpack veya başka bir entegrasyon kullanılıyorsa doğrudan tamamen kapatmak yerine hangi özelliklerin ihtiyaç duyduğunu kontrol etmek gerekir.
5. WordPress yönetim paneli: /wp-admin/, install.php ve admin-ajax.php
Kayıtlarda /wp-admin/index.php 2.831, /wp-admin/css/ 2.395 ve /wp-admin/install.php 821 kez denenmiş.
Bunların her biri farklı bir bilgi veriyor.
/wp-admin/ ve altındaki adresler, saldırgana sitenin WordPress yönetim panelinin mevcut olup olmadığını gösterir. Buradan sonra hedef doğrudan yönetici hesabına saldırmak olabilir.
/wp-admin/install.php ise daha farklı bir şey arıyor: Kurulum aşamasında bırakılmış veya yanlış yapılandırılmış bir WordPress kurulumu.
Normal durumda zaten kurulmuş bir WordPress sitesinde bu dosyanın saldırgana işe yarar bir kurulum arayüzü sunmaması gerekir. Fakat saldırganlar özellikle unutulmuş test sitelerini, eski kurulumları ve yanlış yapılandırılmış sistemleri de aradıkları için bu URL otomatik tarama listelerinde yer alır.
/wp-admin/admin-ajax.php ise biraz daha ilginçtir. Bu URL'nin bulunması tek başına kötü bir şey değildir; WordPress eklentileri AJAX işlemleri için bu uç noktayı gerçekten kullanabilir. WordPress'in kendi dokümantasyonu da AJAX isteklerinin bu dosya üzerinden işlenebildiğini anlatıyor.
Asıl risk, bu noktayı kullanan eklentilerin yazım hataları veya yetkilendirme problemleridir. Örneğin bir eklenti kritik bir işlemi yalnızca AJAX isteği geldiği için çalıştırıyorsa, saldırgan bu işlemi doğrudan çağırmayı deneyebilir.
WordPress'teki nonce mekanizması bu tür işlemlerde önemli bir savunmadır ancak nonce tek başına yetkilendirme mekanizması değildir; gerçek yetki kontrolünün de yapılması gerekir.
6. WordPress yapıları için daha ciddi bir sinyal: wp-content/themes/seotheme/db.php ve benzeri PHP dosyaları
Kayıtların belki de en dikkat çekici bölümü, gerçek bir WordPress kurulumunda bulunması şüpheli olan çeşitli PHP dosyalarını doğrudan çağıran istekler.
Örneğin:
/wp-content/themes/seotheme/db.php?u
/wp-content/themes/seotheme/mar.php
/wp-content/plugins/seoplugins/mar.php
/wp-content/themes/pridmag/db.php?u
Bunun yanında /shell.php, /wso.php, /mar.php, /up.php, /indoxploit.php, /olux.php, /sidwso.php, /wp-content/alfa.php gibi isimler de yüzlerce kez denenmiş.
Bu artık sıradan “WordPress var mı?” kontrolünden daha saldırgan bir tarama biçimi.
Bu dosya isimlerinin önemli bir kısmı webshell veya arka kapı olarak kullanılmış dosyaları bulmaya çalışan otomatik taramalarda görülüyor. Örneğin seotheme/db.php yolu, güvenlik incelemelerinde gerçekten ele geçirilmiş WordPress sitelerinde oluşturulan kötü amaçlı dosyalarla ilişkilendirilmiş durumda.
Bir saldırgan için mantık şudur: “Bir başka saldırgan bu siteyi daha önce ele geçirdi ve arkasında bir webshell bıraktı mı?”
Çünkü saldırganın kendisi açığı bulup dosyayı yüklemek zorunda değil. Daha önce başka biri tarafından yerleştirilmiş bir shell mevcutsa, onu bulup kullanmak yeterli olabilir.
Webshell bulunduğunda saldırganın yapabileceği şeyler dosyanın yetkilerine göre değişir; dosya okuyabilir, yeni dosyalar oluşturabilir, kötü amaçlı kod çalıştırabilir, kalıcı erişim sağlayabilir veya site üzerinden spam ve başka saldırılarda bulunabilir.
7. Veritabanına giden kestirme yol: adminer.php ve yüzlerce phpMyAdmin adresi
Kayıtlarda doğrudan adminer.php isteği 383 kez görülüyor.
Bunun yanında /phpmyadmin/, /phpmy/, /db/phpMyAdmin/, /sql/phpmyadmin/, /mysql/web/, /dbadmin/ gibi onlarca farklı veritabanı yönetim paneli yolu da taranmış. Bunların toplamı binlerce isteğe ulaşıyor.
Bu tür taramanın amacı açık: “Bu sunucuda internete açık bir veritabanı yönetim arayüzü var mı?”
Adminer tek bir PHP dosyasıyla çalışan güçlü bir veritabanı yönetim aracıdır. Kendisinin belgeleri de yönetim arayüzünün internete açık bırakılmak yerine IP kısıtlaması, ek kimlik doğrulama veya başka erişim kontrolleriyle korunmasını öneriyor.
Risk oldukça büyük olabilir. Böyle bir panel erişilebilir ve kimlik bilgileri ele geçirilmişse saldırgan veritabanını okuyabilir, değiştirebilir veya silebilir. WordPress gibi sistemlerde veritabanına erişim, kullanıcı hesaplarının ve uygulamanın kontrolünün de kaybedilmesine yol açabilir. Konuyla ilgili güvenlik rehberleri de herkese açık Adminer kurulumlarının veritabanına ve dolayısıyla uygulamaya ciddi risk oluşturabileceğini belirtiyor.
Bu nedenle Adminer veya phpMyAdmin yalnızca gerçekten ihtiyaç varsa kullanılmalı; mümkünse yalnızca VPN, iç ağ, IP beyaz listesi veya ek kimlik doğrulama arkasından erişilebilir olmalıdır.
8. Tomcat yönetimini arayan taramalar: /manager/html
/manager/html adresi 2 binden fazla kez denenmiş. Bu adres Java tabanlı Apache Tomcat sunucularının yönetim arayüzü olan Tomcat Manager ile ilişkili.
Normalde bir sitede bu adresin hiçbir anlamı olmayabilir. Ancak saldırganlar sunucuda Tomcat Manager çalışıyor olabileceğini varsayarak bunu da dener. Eğer çalışıyorsa risk ciddidir. Çünkü Tomcat Manager yetkili kullanıcıların uygulamaları listelemesine, yönetmesine ve yeni uygulama dağıtmasına izin verebilir. Tomcat'in resmi belgelerinde WAR dosyası yükleyerek yeni bir uygulama kurma özelliği açıkça yer alıyor.
Dolayısıyla /manager/html gerçekten erişilebilir durumdaysa, yalnızca “bir yönetim sayfası açık kalmış” gözüyle bakılmamalı. Güçlü kimlik doğrulama, ağ seviyesinde erişim sınırlaması ve mümkünse yönetim arayüzünün internete hiç açılmaması gerekir.
9. Uygulamanın nasıl çalıştığını öğrenme hedefi: /actuator/gateway/routes
Kayıtlarda /actuator/gateway/routes yolu ve /actuator/health yolu epeyce kez denenmiş. Bunlar Spring Boot uygulamalarındaki Actuator yönetim uç noktalarını hedefliyor.
Bir saldırganın burada ilgilendiği şey, uygulamanın hangi yönetim arayüzlerini dışarı açtığını ve bunlardan ne kadar bilgi alınabileceğini görmek. Spring Boot'un resmi belgeleri de Actuator uç noktalarının hassas bilgiler içerebileceğini ve yalnızca gerekli uç noktaların HTTP üzerinden açılmasını öneriyor. Varsayılan durumda yalnızca health uç noktasının HTTP üzerinden açılması özellikle güvenlik açısından önem taşıyor.
gateway/routes gibi bir adresin cevap vermesi, kullanılan uygulamanın mimarisi hakkında saldırgana değerli bilgiler sağlayabilir: hangi servislerin bulunduğu, hangi yolların başka sistemlere yönlendirildiği ve uygulamanın nasıl yapılandırıldığı gibi.
Böyle bir uygulama kullanıyorsanız, Actuator uç noktalarının internete açık olup olmadığını mutlaka kontrol etmek gerekir.
10. Bilgi topla: phpinfo.php, /_profiler/phpinfo, /server-status ve /debug/default/view?panel=config
Bu gruptaki yolların ortak amacı doğrudan sisteme girmekten önce bilgi toplamaktır.
Kayıtlarda:
/_profiler/phpinfo
/phpinfo.php
/phpinfo
/server-status
/debug/default/view?panel=config
gibi istekler bulunuyor ve yüzlerce kez bu adresler denenmiş.
phpinfo() PHP sürümü, derlenmiş modüller, sunucu değişkenleri ve çeşitli yapılandırma ayrıntıları hakkında geniş bilgi verebilir. Bilginin kendisi her zaman doğrudan saldırıya izin vermez; fakat saldırganın sonraki denemelerini hedeflemesini kolaylaştırabilir.
/server-status ise Apache'nin sunucu durum sayfasıdır. Apache belgeleri bu sayfanın erişiminin kısıtlanmasını açıkça örneklendiriyor; çünkü sunucunun çalışma durumu ve istekleri hakkında bilgi sağlayabilir.
Benzer şekilde uygulamanın debug arayüzlerinin üretim sunucusunda açık bırakılması da istenmez. Bir debug ekranı, normal ziyaretçinin hiçbir zaman görmemesi gereken yapılandırma, hata ve uygulama bilgilerini açığa çıkarabilir.
Bu nedenle üretim ortamlarında phpinfo, debug toolbar, profiler ve durum ekranları ya kapatılmalı ya da sadece yönetim ağından erişilebilir hale getirilmelidir.
11. Dosya yükleme özelliği varsa aman dikkat: upload.php ve /upload/
/upload.php ve /upload/ gibi adresler büyük zafiyetlere yol açabilir.
Dosya yükleme özellikleri saldırganlar açısından özel öneme sahip. Bunun sebebi dosya yüklemenin doğrudan bir açık olması değil, kötü tasarlanmış bir yükleme mekanizmasının saldırgana sunucuda dosya oluşturma imkânı verebilmesidir.
Örneğin yalnızca resim kabul etmesi gereken bir sistem PHP dosyalarını da kabul ediyorsa, yüklenen dosyanın bulunduğu dizinde PHP çalıştırılabiliyorsa problem çok daha ciddi hale gelebilir.
Bu nedenle dosya yükleme sistemlerinde dosya uzantısını kontrol etmek tek başına yeterli değildir. MIME türü, dosyanın içeriği, yükleme dizininin çalıştırma yetkileri, dosya adlandırması ve erişim izinleri birlikte değerlendirilmeli.
12. Hangi CMS kullanılıyor: /sites/default/files/, templates/beez3/
Kayıtlardaki bazı yollar sitenin WordPress olup olmadığını tespit etmek gibi saldırıdan çok parmak izi çıkarma amacı taşıyor.
Örneğin /sites/default/files/ Drupal kurulumlarıyla, templates/beez3/ gibi yollar ise Joomla ekosistemiyle ilişkilendirilebilir.
WordPress tarafında ise /wp-includes/wlwmanifest.xml isteğinin çok sayıda farklı konum altında denenmesi dikkat çekiyor. /wordpress/, /blog/, /wp/, /test/, /cms/, /site/, /news/ gibi farklı kurulum ihtimallerinin tek tek taranması bunun tipik bir örneği.
Buradaki saldırgan mantığı “hangi CMS açık?” sorusunu cevaplamak.
Bir kez teknoloji ve hatta mümkünse sürüm tespit edildiğinde sonraki tarama çok daha hedefli hale getirilebilir. Örneğin Joomla kullanıldığını anlayan saldırgan genel web açıklarını aramak yerine Joomal eklentilerinin veya temalarının belirli sürümlerindeki açıkları araştırabilir.
Bu yüzden yazılım, tema ve eklentileri güncel tutmak aslında bu tür taramaların en önemli karşılıklarından biri.
13. Router ve IoT yönetim adresleri: /boaform/admin/formLogin, /HNAP1 ve benzerleri
Kayıtlarda /boaform/admin/formLogin, /HNAP1, /portal/redlion gibi normal bir web sitesinde bulunması beklenmeyen yönetim adresleri de var.
Bunların amacı web sitesini değil, farklı cihaz ve ağ ürünlerinde bulunan yönetim arayüzlerini bulmak.
Burada ilginç olan nokta, saldırganların hedef IP'nin gerçekten web sitesi sunucusu olup olmadığını bile önemsememesi. Aynı internet üzerindeki bir adrese yüzlerce farklı ürünün standart yönetim URL'sini deneyen botlar bulunuyor.
Listenin bir yerinde setup.cgi gibi bir yönetim URL'sine doğrudan sistem komutu çalıştırmaya yönelik bir istek de bulunuyor. Bu, otomatik taramanın yalnızca “bu cihaz var mı?” seviyesinde kalmayıp belirli ürünlerde bilinen komut çalıştırma açıklarını da denediğini gösteriyor.
Sunucuda gerçekten bir yönlendirici, IoT cihazı veya benzeri yönetim hizmeti çalışıyorsa internete açık yönetim portlarının yalnızca gerekli ağlardan erişilebilir olması önemlidir.
Bütün bu kayıtların bize söylediği ortak şey
Bu listedeki saldırıların çoğunun aslında üç aşamalı bir mantığı var:
Önce “hangi teknoloji kullanılıyor?” diye bakılıyor.
Sonra “bilgi sızdıran veya yönetim sağlayan standart bir dosya var mı?” diye kontrol ediliyor.
Son olarak da “bilinen bir açık veya önceden bırakılmış bir arka kapı var mı?” diye deneniyor.
Örneğin saldırganın arka arkaya wp-login.php, xmlrpc.php, çeşitli wp-content/plugins/ yolları ve şüpheli PHP dosyalarını denemesi aslında tek bir olay değil; otomatik bir saldırı zincirinin parçaları.
Aynı şekilde .env, .git/config, sftp-config.json, /.aws/credentials, /config/aws.yml ve çeşitli config.json yollarının birlikte denenmesi de saldırganın parolaları ve API anahtarlarını doğrudan uygulamanın açıklarından ziyade yanlışlıkla internete bırakılmış dosyalardan elde etmeye çalıştığını gösteriyor.
Peki site sahibi olarak ne yapmalı?
Bu kayıtların en önemli sonucu saldırıya dayanıklı bir web sitesinin yalnızca uygulama koduyla korunamayacağı.
İlk olarak web kök dizininde .env, .git, .aws, yedek konfigürasyon dosyaları, eski .bak dosyaları ve geliştirme sırasında oluşan dosyalar bulunmadığından emin olmak gerekiyor.
İkinci olarak yönetim panelleri internete açık bırakılmamalı. WordPress, phpMyAdmin, Adminer, Tomcat Manager, debug panelleri veya başka bir yönetim arayüzü gerekiyorsa mümkün olduğunca VPN, IP kısıtlaması veya ayrı bir erişim katmanı arkasında tutulmalı.
Üçüncü olarak WordPress kullanılıyorsa giriş denemeleri sınırlandırılmalı, güçlü kimlik doğrulama kullanılmalı ve gereksiz XML-RPC erişimi kapatılmalı. WordPress de giriş ve XML-RPC için sunucu, proxy veya WAF seviyesinde hız sınırlamasını öneriyor.
Dördüncü olarak tema ve eklentiler güncel tutulmalı. Özellikle kayıtlarda belirli plugin veya theme dizinlerinin hedeflenmesi, saldırganların körlemesine bütün WordPress'i taramaktan ziyade bilinen bileşenleri aradığını gösteriyor.
Beşinci olarak yalnızca HTTP 404 kayıtlarını değil, 200, 403 ve 500 cevaplarını da izlemek gerekiyor. Bir saldırganın /.env dosyasını 10 bin kez denemesi, hiçbir zaman dosyaya ulaşamadıysa gürültüdür. Fakat /.env isteği bir kez bile 200 dönerse, frekansı ne olursa olsun araştırılması gereken ciddi bir güvenlik olayıdır.
Son olarak dosya sistemi değişikliklerini izlemek çok değerli. Özellikle daha önce hiç bulunmayan PHP dosyalarının wp-content, uploads, wp-includes veya benzeri dizinlerde ortaya çıkması, yalnızca URL kayıtlarından çok daha güçlü bir saldırı göstergesidir.
404 kayıtları aslında küçük bir saldırı istihbaratı kaynağı
Üç yıllık bu kayıtları geriye dönüp incelediğimde benim için en ilginç sonuç, 404 sayfasına gelen isteklerin aslında ne kadar fazla bilgi taşıdığı oldu.
Bir URL yalnızca “bulunamadı” mesajı değildir. Hangi URL'nin kaç kez denendiği, saldırganların hangi teknolojileri öncelikle hedeflediğini, hangi dosyaların özellikle aranıp aranmadığını ve internet üzerindeki otomatik taramaların nasıl düşündüğünü gösteren küçük bir saldırı istihbaratı verisi haline gelebiliyor.
Benim kayıtlarımda en çok dikkat çeken adres /.env oldu. Onu WordPress giriş noktaları, XML-RPC, Git yapılandırması, webshell isimleri, veritabanı panelleri ve çeşitli yönetim servisleri izliyor.
Başarısız saldırıların hangi yolları izlediğini görmek de savunmanın önemli bir parçası. Benim üç yıl önce “404'leri kaydedeyim” diye başlattığım sistem, bugün geriye dönüp bakıldığında aslında sitenin internette maruz kaldığı saldırı yüzeyinin küçük bir arşivi olmuş durumda.
Ve belki de bu yazının en pratik sonucu şu: Bir web sitesinde 404 kayıtlarını tutuyorsanız, onları yalnızca SEO açısından “hangi eski adresler bozulmuş?” diye okumayın. O listenin içinde sitenize yapılan saldırıların küçük bir özeti var.