Erişim günlüklerinde bulunan saldırı örnekleri

 (nishtahir.com)
1 puan yazan GN⁺ 2024-01-29 | 1 yorum | WhatsApp'ta paylaş
  • 10 yılı aşkın süredir self-hosting yapılan herkese açık bir IP’nin erişim günlükleri, kimlik bilgisi aramalarından IoT cihazlarını hedefleyen komut enjeksiyonlarına kadar internete açık hizmetlerin rutin olarak maruz kaldığı saldırı girişimlerini gösteriyor
  • En yaygın desen, .env, .aws/credentials, .git/config, backup/, test/ gibi yolları yoklayan yapılandırma dosyası ve dizin keşfi idi; bazı istekler Mozlila/5.0 gibi yazım hatalı User-Agent’lar kullanıyordu
  • Shellshock denemeleri, User-Agent içine Bash fonksiyonu biçiminde payload yerleştirerek /etc/passwd dosyasını okumaya çalıştı ve çeşitli CGI yollarını tekrar tekrar tahmin etti
  • LuCI ve Zyxel hedefli saldırılar, yönlendirici ve gömülü cihazların web arayüzlerine komut ekleyerek uzaktaki script’leri ve farklı mimarilere uygun ikili dosyaları indirip çalıştırmayı amaçladı
  • İnternete açık bırakılan hedeflerin sayısı azaltılmalı, gerekli araç ve dizinlere kimlik doğrulama ile IP kısıtlamaları uygulanmalı, IoT cihazları güncel tutulmalı ve mümkünse genel ağdan ayrılmalı

Herkese açık internete maruz kalan hizmetlerin aldığı trafik

  • 10 yılı aşkın süredir self-hosting yaparak verilerini doğrudan sahiplenme ve bulut barındırma dışındaki platformlara bağımlılığı azaltma deneyimi sürdürülüyor
  • Bir IP herkese açık internete çıkarıldığında hemen çok miktarda kötü amaçlı trafik geliyor ve erişim günlükleri incelenerek yakın dönemde hangi saldırıların denendiği takip edilebiliyor
  • Bu analiz, bir güvenlik uzmanının adli incelemesinden çok meraklı bir geliştiricinin gözlemlerine yakın
  • Saldırgan IP adresleri ve bazı saldırganların kullandığı aşağılayıcı ifadeler ihtiyat amacıyla gizlenmiş

Kimlik bilgileri ve yapılandırma dosyası keşfi

  • En yaygın saldırı, dizin dolaşımıyla kimlik bilgileri bulma girişimiydi; özellikle .env dosyası istekleri çok sık görülüyordu
    • İstek yolu örnekleri: /laravel/.env, /backend/.env, /api/.env, /.env, //.env
    • .env, genellikle uygulama secret’larını içeren bir dosya olarak kullanılır
  • AWS ile ilgili dosyalar ve Git depo yapılandırmaları da keşif hedefleri arasındaydı
    • Örnekler: /aws.yml, /.env.bak, /info.php, /.aws/credentials, /config/aws.yml, /.git/config
  • Yanlışlıkla bırakılmış olabilecek yaygın dizinler de tekrar tekrar istendi
    • Örnekler: /old/, /new/, /test/, /backup/, /temp/
  • Bazı User-Agent’larda Mozilla/5.0 yazım hatası gibi görünen Mozlila/5.0 bulunuyordu
    • GitHub arama sonuçları, bu hatanın yaygın bir araçtan üretilip kopyala-yapıştır ile yayılmış olabileceğine işaret ediyor
  • Uzaktan erişim araçları veya yapılandırma araçlarını arayan istekler de görüldü
    • Örnekler: /actuator/gateway/routes, /hudson, /ui/login.action, /?XDEBUG_SESSION_START=phpstorm
  • Herkese açık internete yalnızca kesinlikle gerekli en az sayıda unsur açılmalı; araçlar veya dizinler açılacaksa kimlik doğrulama katmanı ve mümkünse belirli IP kısıtlamaları uygulanmalı

Shellshock denemeleri

  • Birden fazla istek, Shellshock zafiyetini hedefliyor gibi görünüyordu
  • Bu saldırı, CGI script’lerini savunmasız Bash sürümleriyle çalıştıran web sunucularında rastgele komut çalıştırmayı hedefler
    • CGI programı başlarken istek içeriğinden ortam değişkenleri ayarlanır ve HTTP_USER_AGENT bunlardan biridir
    • () { :; }; gibi karakterler varsa Bash bunu çalıştırılması gereken bir fonksiyon olarak yorumlar
  • Gerçek günlüklerdeki User-Agent içinde şu payload’lar vardı
    • () { ignored; }; echo Content-Type: text/html; echo ; /bin/cat /etc/passwd
    • () { ignored; };, Bash fonksiyon tanımı biçimindedir
    • echo Content-Type: text/html; echo ;, HTTP yanıtının Content-Type değerini ve boş bir satırı yazdırır
    • /bin/cat /etc/passwd, kullanıcı hesap bilgilerini içeren /etc/passwd dosyasının içeriğini göstermeye çalışan komuttur
  • Saldırı başarılı olsaydı kullanıcı kimlik bilgilerine erişim ve sunucuda rastgele kod çalıştırma ile sonuçlanabilirdi
  • Saldırgan, dizin dolaşımına benzer biçimde /cgi-bin/status, /cgi-bin/stats, /cgi-bin/test, /cgi-bin/status/status.cgi, /test.cgi, /debug.cgi, /cgi-bin/test-cgi gibi yaygın yolları tahmin ediyordu

LuCI hedefli komut enjeksiyonu

  • Bir istek, OpenWRT yönlendiricileri için web arayüzü olan LuCI’yi hedefliyor gibi görünüyordu
  • Saldırı URL’si, country alanına komut ekleyerek uzaktaki tenda.sh kabuk script’ini indirip çalıştırmayı amaçlayan bir yapıdaydı
    • URL decode edildikten sonra komut, /tmp dizinine geçiyor, dosyaları siliyor, wget ile script’i alıyor, çalıştırma izni veriyor ve sonra çalıştırıyordu
  • İndirilen script, ek ikili dosyaları indirip çalıştırmaya yönelik içerik taşıyordu
    • Hedef mimari adları gibi görünen mips, mpsl, x86_64, arm, arm5, arm6, arm7, i586, i686, powerpc, sh4, m68k, sparc yer alıyordu
    • Birden fazla mimari için ikili dosya denemek, saldırganın hedef cihazın mimarisini bilmediği durumlarda kapsamı genişletme amacı taşıyor gibi görünüyor
  • Ek inceleme için ortamla uyumsuz bir ikili indirildi ve Ghidra ile incelendi
    • Başta yalnızca 3 fonksiyon vardı ve çok fazla string verisi görünmüyordu
    • Büyük veri alanında $Info: This file is packed with the UPX executable packer ve UPX 3.94 string’leri doğrulandı
  • Bu, UPX ile sıkıştırılmış bir ELF ikilisiydi ve UPX header’ı ya da packed binary değiştirilmemişse upx -d ile açılabiliyor
    • Gerçekten de upx -d mips çalıştırıldıktan sonra dosya boyutu 34932 bayttan 93732 bayta çıktı ve daha fazla string görülebildi
  • Açılmış ikilideki string’ler arasında M-SEARCH * HTTP/1.1, ST: urn:dial-multiscreen-org:service:dial:1 ve Huawei cihaz yükseltmeleri için XML payload vardı
    • Bu, ağda DIAL protokolünü destekleyen cihazları bulmaya yönelik bir UPnP komutu gibi görünüyor
    • XML payload, komut enjeksiyonuna açık Huawei cihazlarını tarayacak şekilde yapılandırılmış görünüyordu
    • Bu davranışın Mirai botnet’inin bir parçası olduğu belirlendi
  • Başvurulan yeye.mips dosyası indirilmeye çalışıldığında artık erişilebilir değildi
    • Sunucuda nmap çalıştırıldığında yalnızca 22/tcp ssh ve 646/tcp filtered ldp açık portları görüldü

Zyxel hedefli komut enjeksiyonu

  • Başka bir istek, GET URL’si içinde kabuk komutları barındırıyordu ve ${IFS} kabuk yer değiştirmeleri kaldırıldığında daha okunur hale geliyordu
    • Düzenlenmiş komut, /tmp dizinine gidiyor, *mips* dosyalarını siliyor, huhu.mips dosyasını indiriyor, çalıştırma izni veriyor ve ardından zyxel.selfrep argümanıyla çalıştırıyordu
  • Bu saldırı, Zyxel cihazlarındaki zhttpd exploit’ini hedefliyor gibi görünüyordu
  • Bu kez ikili dosya packed değildi, bu yüzden Ghidra’da string’ler doğrudan görülebildi
    • String’ler arasında M-SEARCH * HTTP/1.1, DIAL ile ilgili ST header’ı, skyljne.arm, skyljne.arm5, skyljne.arm6, skyljne.arm7, skyljne.mips, skyljne.mpsl, skyljne.x86_64, skyljne.sh4 bulunuyordu
    • Ayrıca Huawei cihazlarını hedefleyip huhu.mips dosyasını indirerek selfrep.huawei olarak çalıştıran bir XML payload da vardı
  • Bir başka string, /goform/set_LimitClient_cfg adresine POST gönderen bir komut içeriyordu
    • Cookie: user=admin header’ı ile birlikte mac parametresine komut eklenerek huhu.mpsl indirilip çalıştırılmak isteniyordu
    • Akamai yazısına göre bu zafiyet yönlendiricileri hedefliyor ve özel bir kimlik doğrulama veya yetkilendirme kontrolü olmadığı için ön kimlik doğrulama olmadan istismar edilebiliyor
  • Bu ikilinin büyük olasılıkla Mirai botnet’inin ajanı olduğu değerlendirildi
    • Bazı kaynaklar Linux Medusa ile olası bağlantılardan da söz ediyor

Operasyonel açıdan alınabilecek önlemler

  • İncelenen günlükler bütünün yalnızca bir kısmı; her gün denenen başka exploit’ler de çok sayıda
  • Cihazları, özellikle IoT cihazlarını, güncel tutmak önemli
  • Mümkünse IoT cihazları doğrudan herkese açık internete maruz bırakılmamalı
  • Mutlaka açılmaları gerekiyorsa mümkün olduğunca ayrı bir VLAN içinde izole edilmeliler

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-29
Hacker News yorumları

  • İlginç biçimde bazı saldırganlar yeni verilmiş sertifikaları bulmak için Certificate Transparency günlüklerini izliyor gibi görünüyor
    Yeni bir sunucuyu yeni bir IP’de bir haftadan uzun süre açık bırakırsanız erişim günlüklerinde yalnızca birkaç rastgele tarama görünürken, Let’s Encrypt sertifikası aldıktan yaklaşık bir saat sonra makaledekilere benzer yüzlerce isteğin akın ettiği birkaç kez oldu
    Sonuç şu: Yeni hizmetler mümkün olduğunca erken, ideal olarak internete açılmadan önce güvenli hale getirilmeli

    • İlk kez herkese açık hale geldiği andan itibaren önüne en azından Basic Authentication gibi bir şey koymak gerekiyor gibi geliyor
      Ya da kendi sertifika otoritenizi kullanıp geçişe kadar self-signed sertifika ve mTLS kullanmak da bir yol
      Örneğin bir yazılım, yönetici hesabı oluşturma veya DB bağlantısı gibi ilk kurulum ekranını olduğu gibi açığa çıkarıyorsa; bunları en baştan ortam değişkeni, yapılandırma dosyası veya özel bir sır yönetim aracıyla belirtme yöntemine göre daha riskli hale gelir
    • Yakın zamanda Certificate Transparency günlüklerine baktım; CT günlüklerini sorgulamak için kullanışlı bir araç ya da yöntem var mı merak ediyorum
      Örneğin belirli bir dönem içindeki alan adlarını aramak gibi
      Cloudflare’in Merkle Town’ı[0] genel görünüm için yararlı, ancak CT günlüklerini kolayca sorgulamanın bir yolunu hâlâ bulamadım; ct-woodpecker[1] da umut verici görünüyor
      [0] https://ct.cloudflare.com/
      [1] https://github.com/letsencrypt/ct-woodpecker
    • Daha fazla wildcard sertifika kullanmak da yararlı olur. Yalnızca CT günlüklerinden saldırılacak belirli alt alan adını öğrenmeyi zorlaştırır
    • Bu çoğu zaman saldırgandan ziyade, CT günlüklerini izleyip zararlı yazılım bulmak için web’i tarayan urlscan.io gibi servisler oluyor
    • Birkaç hizmeti kendim barındırıyorum ama bunları doğrudan internete açmaktan tamamen vazgeçtim
      Günümüzde VPN’ler o kadar iyi ki içim rahat ediyor; özellikle fotoğraf barındırma ya da yedekleme gibi şeyleri herkese açık hale getirmek istemiyorum

  • Kendi barındırdığım bir siteyi yönetmeye başladığımda erişim günlüklerine de bakıyordum; bir süre boyunca gelen saldırı girişimlerini gösteren verileri toplayan bir saldırı tespit sistemi de kullandım
    Sonunda günlükleri proaktif olarak incelemeyi de, saldırı tespit sistemine para ödemeyi de bıraktım; zaman kaybı ve dikkat dağıtıcı bir işti
    Yaygın zafiyetleri ve saldırıları iyi özetleyen kaynaklar kolayca bulunabiliyor; bunu sunucu yönetimi için ölçüt almak yeterli. Yaygın web sunucusu teknolojilerinin her biri için çok sayıda en iyi uygulama rehberi var ve bunları %100 uygulamak bile sizi neredeyse tüm saldırganların çok önüne geçirir
    Sonrasında zamanı ve kaynakları iyi kullanmanın yolu, mümkün olan en hızlı yama döngüsünü önceliklendirmektir. Saldırıların çoğu kamuya açıklanmış zafiyetleri hedefler
    Günlüklerin özellikle işe yaradığı zaman, bir sorun yaşandıktan sonra tanılama yaparken oluyor. Günlük analiz yazılımıyla saklayıp arayarak başarılı saldırıların kök nedenini bulmakta 2-3 kez yardımcı oldu; her seferinde neden, çok geç yamalanmış bilinen bir zafiyetti

    • Tüm vakalar geç yamalanmış bilinen zafiyetlerse, yalnızca yamalara güvenen bir yaklaşım er ya da geç başarısız olmaya mahkûmdur. Bu bir 0-day zafiyeti olabilir ya da saldırgan daha hızlı davranabilir
      Çözüm katmanlı savunmadır; kişisel servisleri kendiniz barındırırken çoğu durumda bunu uygulamak oldukça kolaydır
      Öne bir güvenlik duvarı koyun veya VPN/Tailscale arkasına saklayın; otomatik saldırıların hedeflediği /phpmyadmin/ yerine /mawer/phpmyadmin/ gibi bir alt klasöre gizlerseniz %99,9’u bulamaz. Buna güvenlik yoluyla gizleme denir ve yalnızca buna güvenilmemelidir, ancak ek bir katman olarak çok yararlıdır
      Uygulamayı sandbox’a alın ve sunucuyu izole edin; içeri girilse bile başka yerlere geçmeyi zorlaştırın. Ayrıca saldırı olup olmadığını ve başarılı olup olmadığını kontrol edebilmek için günlük tutmalısınız
      Asıl nokta, yama ya da güvenlik duvarı olsun, tek bir savunma aracına güvenmemektir. Sonunda bunlardan biri başarısız olur
    • En hızlı yama döngüsünü önceliklendirme kısmını merak ediyorum. Yama zamanını belirlerken bir araç mı kullanıyorsunuz, yoksa belirli zaman aralıklarına mı dayanıyorsunuz?
      Şu anda paketleri üç ayda bir güncellemeyi deniyorum[0], ancak bilinen zafiyetleri bildirip hemen tepki vermemi sağlayacak bir araç olsa iyi olurdu
      [0] Burada “deniyorum” derken, en yeni sürüme geçmeyi zorlaştıran uyumluluk kırılmaları varsa veya henüz güvenmediğim bir X.0.0 sürümüyse hemen yükseltemediğimi kastediyorum

  • Yazar güvenlik uzmanı olmadığını söylediğine göre küçük bir düzeltme yapayım: Baştaki örnek kimlik bilgisi/yapılandırma keşfi, dizin geçişi değil
    Bildiğim kadarıyla dizin geçişi, saldırganın web root’tan “kaçması” ya da sunucuyu normal dizinlerin dışındaki dosyaları sunmaya kandırması tekniği için kullanılan bir ifade

    • Normalde barındırılmaması gereken dosyaları dahil etme yöntemi söz konusuysa teknik olarak ikisi de olabilir. Örneğin "/../../passwd/etc" gibi

  • En azından benim deneyimime göre bu saldırıların önemli bir kısmının düşmanca devlet aktörlerinden gelmesi kilit nokta
    Tartışmalı olabilir ama iş yapmayacağınız sorunlu ülkelerin tüm IP aralıklarını engellemek faydalı olabilir. Bu şekilde yeni bir hizmete gelen keşif girişimlerini %100 engellediğim oldu

    • Asıl mesele bu değil; birçok kişi yalnızca o bölgedeki meşru kullanıcıları da engellemek istemiyor
    • Devlet aktörlerinin başka bir ülkede sunucu satın alıp saldırıları oradan yürütmesinin hiçbir yolu olmasa keşke
    • 15 yıldan fazla önce, barındırdığımız küçük yerel işletmelerin sunucu günlüklerine bakarken APNIC IP adreslerinin hepsini engelleyebileceğimiz sonucuna varmıştık
    • Bölgesel engelleme nihayetinde meşru trafiği kesip, kararlı saldırganları sadece proxy kullanmaya itmez mi diye düşünüyorum
    • Öyleyse ABD ve Hollanda’yı engellemek gerekir
      Sunucuma gelen keşiflerin çoğu ABD’den geliyor; oldukça geriden ikinci sırada Hollanda var. Muhtemelen çoğu AWS ve diğer veri merkezlerinden geliyor

  • Uygulama/ürün güvenliği alanında çalışıyorum ve milyarlarca dolarlık şirketlerin WAF’larını yıllarca yönettim.
    DNS’i Cloudflare’a taşıyıp siteye birkaç WAF kuralı koymak yeterli. Örneğin bot puanı 2’nin altındaysa managed challenge uygulamak ya da saldırı puanı belirli bir değere geldiğinde işlem yapmak gibi. Maliyeti de büyük olasılıkla neredeyse yoktur ve birçok sorunu çözer.
    Ancak prodüksiyona almadan önce mutlaka test etmek gerekir. Bir test domain’i bulundurmak da iyi olur. WAF her şeyi çözen sihirli bir çözüm değil, daha çok geçici bir önlem sayılır; uygulamanın kendisi saldırılara dayanacak şekilde güçlendirilmemişse, ne kadar gelişmiş WAF ya da bot koruması kullanırsanız kullanın onu kurtaramazsınız.

    • Bu konuya aşina olmayanlar için bırakıyorum: https://blog.cloudflare.com/waf-for-everyone/
      Free Managed Ruleset varsayılan olarak dağıtılıyor gibi görünüyor; Cloudflare değişiklik günlüğünü burada tutuyor: https://developers.cloudflare.com/waf/change-log
    • Kendi kendine barındıran biri olarak, CloudFlare’in WAF’ı ve karşılıklı TLS kuralları ile yalnızca bildiğim meşru çağıranların geçmesine izin veriyorum.
      Çok iyi çalışıyor. Erişenler sadece ailem olduğu için ayarlaması da kolaydı; herkes kendi benzersiz sertifikasını alıyor ve gerekirse iptal edilebiliyor.
    • Bu günlerde genellikle yalnızca dahili uygulamaları yönettiğim için saldırı yüzeyi herkese açık servislere göre çok daha küçük.
      Bu alanı iyi biliyor gibi görünüyorsun; merak ettiğim şey, Azure altyapısı ile Cloudflare’ı birlikte kullanan çözümler de yönetip yönetmediğin ve yönettiysen, OWASP gibi genel konular dışında insanların sıkça gözden kaçırdığı noktalar olup olmadığı.
    • Standart WordPress sitelerine iyi uyuyor; ek katman olarak GuardGiant ve Sucuri eklentileri takılabilir.
    • Uygulamanın önüne WAF koyup işin bittiğini sanmak, domuza ruj sürmekten farksız.
      Bir şirketin herhangi bir nedenle güncel olmayan bir şeyi mutlaka çalıştırması gerekiyorsa gerekli olabilir, ama sonuçta bu sadece geçici bir önlemdir.

  • Kendi tasarladığım 400 satırlık bir HTTP/S sunucusunu yaklaşık bir yıldır kendim barındırıyorum; açık 3 porta (22, 80, 443) gelen saldırı trafiği şaşırtıcı derecede fazla.
    Ancak saldırganın gerçekten ne yapmaya çalıştığını analiz etmeye zaman ayırmadım; bu yazı birçok boşluğu doldurdu.
    /var/log/auth.log içinde görünen tuhaf şeyleri de aynı şekilde analiz etmek iyi olurdu.
    Kodun tamamı açık kaynak ve sunucu tarafında durum da yok; saldırganın özellikle beni hedeflemesi garip. Saldırganın elde edebileceği en iyi şey, aylık 5 dolarlık bir VPS’te root erişimi ve kimsenin uğramadığı bir domain’in geçici olarak tahrif edilmesi olur.

    • Bunların hepsi otomasyon botları. Kimse özellikle umursamıyor.
      En bilinen 3 portu açarsan bağlantılar gelir; ne çalıştırdığını bilmezler ve umursamazlar.
    • VPN’ine erişirlerse, başka makineleri hedeflemek için iyi bir çıkış noktası olarak kullanılabilir ve izleri gizlemek için bir katman daha eklenmiş olur.
      Zararlı yazılım barındırmak ya da kripto para madencisi çalıştırmak da mümkün.
    • 22 numaralı portta yalnızca kendi IP’ne izin verip geri kalanını engellemeyi düşünebilirsin.
      Benim ISP’m IP’yi gerçekten çok nadiren değiştiriyor; değişirse barındırma web yönetici paneline giriş yapıp kuralı güncelleyebiliyorum.

  • Her sunucuda mutlaka fail2ban çalıştırıyorum ve açığa sunduğum site işlevlerinin türüne uygun saldırıları yakalamak için özel jail’ler de ekliyorum.
    Ancak fail2ban’in diğer varsayılanlarının hâlâ yaygın saldırıları engellemek için yeterli olup olmadığını kontrol etmeyeli uzun zaman oldu. Daha sonra bakabilmek için bu bağlantıyı yer imlerine eklemeliyim.

    • Sistemde bu kadar kolay hedef alınabilen bir zafiyet açıktaysa fail2ban seni kurtaramaz.

  • Kendi barındırdığım servisin erişim günlüklerini ben de inceliyorum; bu analizde göze çarpan şekilde eksik kalan bir ayrıntı var.
    Kötü niyetli isteklerin önemli bir kısmı, sıradan kişilerin GitHub gibi yerlerden kolayca bulabildiği güvenlik tarayıcılarını çalıştırmasından ibaret. Genelde sofistike olmayan saldırılar; bu tür proje örnekleri, yanıtı bile görmeden ve rate limit’e takılıp takılmadığını umursamadan sunucuyu yoklayıp duruyor.
    Bazı saldırılar doğrudan IP’yi hedeflemez; domain ve alt domain’leri izler, aynı IP aralığından periyodik olarak aynı taramayı tekrarlar.
    Önceki iş yerimde Türkiye’deki tek bir sabit IP’den sürekli tekrarlanan taramalar geliyordu; ekip ona “Türk” demeye başlamıştı ve garip istek kalıpları gördüğümüzde önce o kişinin servisimize dokunup dokunmadığını kontrol etmek olay müdahale sürecinin bir adımı hâline gelmişti.

  • AWS’de bu günlükleri görüyorsanız, lütfen VPC’nin önüne AWS WAF koymanız iyi olur.
    Pahalı değil ve böyle durumlarda birçok baş ağrısını azaltmaya epey yardımcı oluyor. Servise ulaşan her şeyi engellemese bile büyük fayda sağlayabilir.

    • İyi bir öneri, ama varsayılan kural setlerine dikkat etmek gerekir. Biz SOC 2 uyumluluğu nedeniyle AWS WAF’ı açtık.
      Aşırı çalışan birkaç kural, uygulamanın bazı bölümlerini fark ettirmeden bozdu.
      İstek gövdesinde "localhost" varsa engelleyen bir istek gövdesi kuralı vardı; User-Agent başlığı olmayan istekleri engelleyen bir kural da vardı. Daha önce API isteklerinde User-Agent istemiyorduk, bu yüzden nedeni bulana kadar bazı kullanıcıların API’sinin tamamını bozduk.
    • Yazıda geçen saldırılar herhangi modern bir web uygulaması için sorun olmayacaktır. Bu yüzden neden WAF eklemek gerektiğini anlamıyorum.
    • AWS WAF varsayılan kurallarını kullanmak o kadar kolay değil. Bizim uygulamamızda birçok meşru istek ve IP engellendi.
      Neyin engellendiğini bilmek ve önce doğrulamak gerekir; aksi hâlde bazı durumlarda müşteri kaybedersiniz.
    • Aslında WAF çoğu zaman faydadan çok zarar verir.
      Kolayca aşılabildiği hâlde güvenlik sağladığı yanılsaması yaratır, performans maliyeti de büyüktür ve meşru trafiği engelleme olasılığı da hayli yüksektir: https://www.macchaffee.com/blog/2023/wafs/
    • WAF’lar geniş kapsamlı engelleme eğilimindedir ve bazen nedeni de belirsizdir.
      Örneğin üniversitemizdeki araştırmacılar Twitter verilerini inceliyor; tweet’lerden alınan küçük, rastgele bir örneklemdeki bağlantıları takip ettikleri için üniversite IP’si çoğu WAF tarafından engelleniyor.

  • Bazen, bu saldırılardan birine düzgün yanıt veren bir Express sunucusu yapıp birilerinin zamanını boşa harcatmanın eğlenceli olabileceğini düşünüyorum
    Ama bunu yaparsam kendi zamanımı da boşa harcamış olurum