WAF'ta kayıt ve engelleme arasındaki denge

Informatec Digital » Kaynaklar » WAF'ta Günlük Kaydı ve Engelleme Arasında Denge Kurma

Web uygulama güvenlik duvarlarında (WAF) kayıt tutma ve engelleme arasında doğru dengeyi bulmak , güvenlik ve operasyon ekipleri için en yaygın sorunlardan biri haline geldi. Bir web uygulama güvenlik duvarı çok ciddi saldırıları durdurabilir, ancak çok agresif yapılandırılırsa meşru satın alımları, erişimi veya API çağrılarını engelleyebilir. Çok gevşek yapılandırılırsa, neredeyse tamamen dekoratif bir işlev görür. Önemli olan, ne zaman kayıt tutulacağını, ne zaman sayılacağını, ne zaman izin verileceğini ve ne zaman engelleneceğini dikkatlice ayarlamaktır.

Bu makalede, AWS WAF, ModSecurity, bulut tabanlı WAF'lar ve şirket içi çözümlerden somut örneklerle desteklenen modern WAF yeteneklerini (izin listeleri, frekans tabanlı kurallar, öğrenme modları, SIEM entegrasyonu, makine öğrenimi vb.) kullanarak bu dengeyi nasıl sağlayacağımızı inceleyeceğiz. Koruma seviyesini düşürmeden yanlış pozitifleri nasıl sınırlayacağınızı, politikaları uygulamaya göre nasıl düzenleyeceğinizi ve günlük kaydını sürekli, yönetilemez bir gürültü kaynağı olarak değil, bir müttefik olarak nasıl kullanacağınızı göreceksiniz.

WAF nedir ve kayıt neden bu kadar önemlidir?

Bir web uygulama güvenlik duvarı, kullanıcı ile sunucu arasında akıllı bir katman görevi görerek HTTP/HTTPS trafiğini gerçek zamanlı olarak analiz eder. Portları ve IP adreslerini izleyen geleneksel ağ güvenlik duvarlarının aksine, bir WAF daha derine iner: URL'ler, parametreler, istek gövdeleri, başlıklar, çerezler, HTTP yöntemleri ve daha fazlasını inceler.

Görevi, tipik Katman 7 saldırılarını tespit etmek ve durdurmaktır : SQL enjeksiyonu, XSS, LFI/RFI, erişim kontrolüne yönelik saldırılar, API kötüye kullanımı, agresif veri kazıma, kaba kuvvet saldırıları ve hatta belirli uygulama düzeyindeki DDoS saldırı modelleri. Bunu yapmak için sürekli güncellenen kurallar, imzalar ve güvenlik politikaları kümelerine güvenir.

Kayıt tutma, madalyonun diğer yüzüdür. Her WAF kararı (izin verme, engelleme veya yalnızca sayma) kayıtlarda ayrıntılı bir olayla birlikte yer alabilir . Bu kayıtlar şunlara olanak tanır:

• Olayları araştırınOlayların nasıl geliştiğini ve bir güvenlik açığından nasıl yararlanıldığını yeniden kurgulamak.
• Kuralları ayarlayınWAF'ın hangi meşru istekleri engellediğini görerek yanlış pozitifleri tespit edin.
• Yönetmeliklere uyunAktif kontrollerin mevcut olduğunu gösterin (PCI DSS, GDPR, iç denetimler vb.).
• SIEM'e veri aktarmaUygulama saldırılarını ağ, sistem, kimlik vb. olaylarla ilişkilendirmek.

Sorun şu ki, kötü ayarlanmış bir WAF (Web Uygulama Güvenlik Duvarı), logları binlerce alakasız olayla doldurarak önemli olanı bulmayı imkansız hale getirebilir ve bunun da ötesinde, meşru trafiğin haksız yere reddedilmesine neden olabilir. İşte burada loglama, sayma ve engelleme modlarıyla oynamanın incelikleri devreye giriyor.

WAF'ta güvenlik modelleri: engelleme listeleri, izin verilenler listeleri ve hibrit bir yaklaşım

Modern WAF'ların çoğu , isteklerin nasıl kaydedildiğini ve engellendiğini doğrudan etkileyen çeşitli filtreleme yaklaşımlarını bir araya getirir . Genel olarak, iki klasik felsefenin yanı sıra çok yaygın bir hibrit model belirleyebiliriz.

Kara liste tabanlı bir WAF, negatif güvenlik modelini izler. Temel prensibi şudur: "Kötü amaçlı olduğunu bildiğim şeyler hariç her şeye izin veririm." Bilinen saldırıların (SQL enjeksiyonu, XSS, bot kalıpları vb.) imzalarını ve şüpheli kabul edilen şeyleri tanımlayan kuralları kullanarak çalışır. Başlangıçta kurulumu daha kolaydır, ancak yalnızca bu modele güvenmek, yeni saldırı vektörlerinin veya varyantlarının tespit edilmeden geçmesine izin verme riskini taşır.

İzin verilenler listesine sahip bir WAF ( Web Uygulama Güvenlik Duvarı) tam tersi şekilde çalışır: "Açıkça izin verilenler dışında her şeyi engeller." Pozitif bir güvenlik modeline dayanır. Yalnızca tanımlanmış meşru davranışa (rotalar, yöntemler, parametreler, formatlar, boyutlar vb.) uyan trafik kabul edilir. Çok daha güvenlidir, ancak önemli ölçüde ince ayar gerektirir ve doğru şekilde hazırlanmazsa başlangıçta yanlış pozitifler üretebilir.

Her yaklaşımın avantaj ve dezavantajları nedeniyle, izin verilenler listeleri ve engellenenler listelerini birleştiren hibrit bir model giderek daha yaygın hale gelmektedir . Bu senaryoda, beklenen trafik profilleri tanımlanır (örneğin, normal bir giriş veya ödeme isteğinin ne olduğu) ve tipik kötü amaçlı kalıpları tespit etmek için eş zamanlı olarak imzalar ve sezgisel yöntemler uygulanır. Kayıt tutma amacıyla, bu hibrit yaklaşım şunlara olanak tanır:

• Marcar gibi yüksek riskli olay İzin verilen ürünler listesini ihlal eden şey.
• Şöyle davranın: orta/düşük öncelikli uyarılar Genel engelleme listesi kalıpları.
• Engelleme işlemini etkinleştirmeden önce hangi durumların kuralı ihlal edeceğini görmek için "sayım" modunu kullanın.

Ağda, sunucuda ve bulutta WAF: günlük kaydı ve kilitleme üzerindeki etkisi

WAF dağıtım modeli, trafik kaydı ve engelleme işlemlerinin nasıl ele alındığını büyük ölçüde etkiler. Bir ağ cihazında isteklerin kaydedilmesi, sunucu içindeki bir aracıda veya yönetilen bir bulut hizmetinde isteklerin kaydedilmesiyle aynı şey değildir.

Ağ tabanlı bir WAF ( Web Uygulama Güvenlik Duvarı) , genellikle altyapı içinde, internet ile uygulamalar arasında fiziksel veya sanal bir cihaz olarak konuşlandırılır. Bu, F5 gibi üreticilerin kullandığı klasik yaklaşımdır. Yüksek performans ve ayrıntılı kontrol avantajı sunar, ancak yapılandırma ve yönetim karmaşık olabilir. Kayıtlar genellikle syslog'a veya merkezi bir SIEM'e gönderilir ve depolama ve analiz araçlarının aşırı yüklenmesini önlemek ve IP ve DNS ağlarındaki sorunları teşhis etmek için kaydedilenleri dikkatlice filtrelemek önemlidir.

Sunucu tabanlı WAF'lar, uygulamanın bulunduğu aynı sunucularda (veya konteynerlerde) genellikle bir modül veya ajan olarak çalışır (örneğin, Nginx veya Apache'ye entegre edilmiş ModSecurity; SELinux kullanarak Linux güvenliğini artırmak, güvenlik duruşunu iyileştirir). Bu model, yerel kaynakları tüketme ve daha dağıtık günlük yönetimi gerektirme pahasına, daha geniş uygulama bağlamı ve hizmet başına oldukça spesifik kurallar sağlar . Günlükler yerel dosyalarda saklanabilir ve daha sonra iletilebilir veya merkezi günlük hizmetleriyle entegre edilebilir.

Bulut tabanlı WAF'lar (Cloudflare, Akamai, Imperva Cloud, AWS WAF, vb.) yük dengeleyiciler, CDN'ler veya sanal ağlarla entegre olur. Sağlayıcılar genellikle kontrol panelleri ve S3, BigQuery, uzak sistem günlükleri veya SIEM'lere günlük dışa aktarma seçenekleri sunar . Kurulumları genellikle daha kolaydır, ancak günlük kaydı politikalarınızı sağlayıcının modeline uyarlamanız gerekir: olay türleri, saklama süreleri, önem derecesi filtreleri vb.

Bir modeli veya diğerini seçmek sadece teknik bir karar değil, aynı zamanda günlük kaydı ve kilitleme arasında nasıl bir denge kurmak istediğinizle de ilgilidir: bulut tabanlı bir hizmet birçok yönü basitleştirir, ancak uyumluluk veya gizlilik politikaları nedeniyle günlüklerin nerede saklandığı konusunda mutlak kontrol isteyebilirsiniz ; bu da sizi şirket içi veya hibrit modellere yönlendirir.

Şartlar, kurallar ve web ACL'leri: WAF'ın engelleme, izin verme veya yalnızca kayıt yapma kararı nasıl verilir?

Üreticiden bağımsız olarak, tüm modern WAF'lar erişim koşulları, kurallar ve politikalar kavramına dayanmaktadır . Bunu anlamak, üretimde sayma, kayıt tutma ve kilitleme modlarını başarıyla kullanmanın anahtarıdır.

Koşullar, isteğin hangi bölümünün inceleneceğini tanımlar: kaynak IP, belirli HTTP başlıkları (Host, User-Agent, Accept, Content-Type…), sorgu parametreleri, istek gövdesi, çerezler, HTTP yöntemi, menşe ülke vb. Örneğin, AWS WAF Classic'te 10.000'e kadar adres veya aralık içeren bir IP koşulu veya URL'nin bir bölümünde dize eşleşme koşulu tanımlayabilirsiniz.

Kurallar, bir veya daha fazla koşulu birleştirir ve bir amaç atar: izin vermek, engellemek veya saymak. Bir kuralın birden fazla koşulu olduğunda, bunlar genellikle mantıksal VE ile değerlendirilir : kuralın tetiklenmesi için tüm koşulların karşılanması gerekir. Koşulsuz normal bir kural, pratikte hiçbir şeyle eşleşmez ve eylemi asla tetiklenmez.

AWS WAF dahil olmak üzere birçok WAF'ın da oran tabanlı kuralları vardır . Bu kurallar, belirli bir zaman dilimi içinde (örneğin beş dakika) bir IP adresinden (veya belirli koşulları karşılayan bir IP adresi kümesinden) gelen istekleri sayar. Bir eşik aşılırsa (örneğin, beş dakikada 1.000 istek), kural devreye girer: engelleme veya sadece sayma. Bu, aşağıdakiler için çok kullanışlıdır:

• Kontrol Giriş formlarında kaba kuvvet saldırısı.
• Saldırgan veri kazıma işlemlerini veya kaba botları sınırlayın.
• Uygulama düzeyinde belirli DDoS saldırı türlerinin etkilerini azaltmak.

Bir sonraki seviye Web ACL'dir (Erişim Kontrol Listesi) . Burada kurallar gruplandırılır ve bir değerlendirme sırası ile varsayılan bir işlem (İZİN VER veya ENGELLE) tanımlanır. Bir istek, kurallardan sırayla geçer; bir kurala uyarsa, ilgili işlem uygulanır ve geri kalanının değerlendirilmesi durdurulur. Hiçbir kurala uymuyorsa, ACL'de tanımlanan varsayılan işlem uygulanır.

Kayıt tutma ve engelleme arasında denge kurma açısından, ACL (Erişim Kontrol Listesi), sistemin varsayılan olarak izin verici (YALNIZCA belirli kurallarla İZİN VERME) mi yoksa son derece kısıtlayıcı (istisnai durumlar dışında ENGELLEME) mi olmasını istediğinize karar verdiğiniz yerdir. Ayrıca, birçok çözüm, ACL içinde "sayım" modunda kurallar belirlemenize olanak tanır, böylece eşleşmeleri kaydeder ancak trafiği engellemez; bu da ayarlama aşaması için idealdir.

Günlük kayıtlarında beyaz listeler ve gürültü azaltma

İzin verilenler listeleri , yanlış pozitifleri ve loglardaki gürültüyü azaltmak için temel bir araçtır . Fikir basittir: belirli bağlamlarda, WAF'a, zaten güvenilir olarak sınıflandırdığınız veya norm dışı ancak meşru olduğunu bildiğiniz belirli trafiğe bir yönerge veya kural kümesi uygulamamasını söylersiniz.

Örneğin, AWS WAF'ta, bir istek belirli bir IP adresinden veya aralığından geliyorsa veya bilinen bir URL kalıbı ve HTTP yöntemiyle eşleşiyorsa, belirli imza denetimlerinin uygulanmaması için izin listesi kuralları oluşturabilirsiniz . Bu, şunlara yardımcı olur:

• "Garip" kalıplar kullanan dahili API'leri engelleyin. sürekli yanlış pozitifler üretmek.
• Güvenilir olarak değerlendirdiğiniz trafikte derinlemesine incelemenin yol açtığı gecikmeyi azaltın.
• WAF günlüklerindeki gereksiz kayıtların sayısını azaltın.

ModSecurity gibi platformlarda önerilen yaklaşım, standart kuralları (örneğin, OWASP Temel Kural Seti) değiştirmek değil, belirli parametreler, yollar veya kullanıcılar için kural kimliğine göre özel istisnalar oluşturmaktır . Bu, site genelinde tüm kuralları devre dışı bırakarak büyük güvenlik açıkları oluşturmadan genel korumayı sürdürmenizi sağlar.

Önemli olan, izin listelerini genel bir yaklaşım yerine, hassas bir şekilde uygulamaktır . Belirli bir kombinasyonu (URL Z'deki kural X + parametre Y) hariç tutmak, kural X'i genel olarak devre dışı bırakmaktan çok daha iyidir. Bu şekilde, kayıtlar kullanışlı kalır ve gereksiz kör noktalar oluşturmazsınız.

Protokol kuralları ve sınırları: ne zaman engelleme yapılmalı, ne zaman uyarı verilmeli

Birçok WAF (Web Uygulama Güvenlik Duvarı) , hatalı veya şüpheli trafiği filtreleyen bir dizi HTTP protokolü temizleme kuralı içerir . Bu kurallar gerekli başlıkları, yöntemleri, argüman boyutlarını vb. kontrol eder ve doğru anlaşılmadığı takdirde hem iyi koruma hem de yanlış pozitif sonuçların sıkça kaynağıdır.

İşte bazı çok yaygın örnekler:

• Eksik Kabul Başlığı (Eksik Accept başlığı): Bu, kesin olarak bir RFC ihlali değildir, ancak bu başlık olmadan yapılan birçok istek otomatik araçlardan veya kötü yazılmış komut dosyalarından gelir. Bu, özel API'leri veya bu başlığı göndermeyen istemcileri etkileyebilir. Birçok ortamda, doğrudan engelleme yerine kayıt tutma ve sayma tercih edilir.
• Eksik Ana Bilgisayar BaşlığıHTTP/1.1 standartlarına göre Host başlığı zorunludur. WAF'lar da hangi politikayı uygulayacaklarını belirlemek için buna ihtiyaç duyar. Burada engelleme genellikle mantıklıdır, ancak test sırasında veya yanlış yapılandırılmış dahili trafik nedeniyle yanlış pozitif sonuçlar üretebilir; katı engellemeyi etkinleştirmeden önce günlükleri izlemek önerilir.
• Eksik Kullanıcı Aracısı BaşlığıBu kural, basit botları ve tanımlanamayan trafiği engellemeyi amaçlamaktadır. Sorun şu ki, birçok meşru API, User-Agent bilgisi göndermeyebilir. En mantıklı yaklaşım genellikle kayıt tutmak ve tutarlı ve meşru bir API tespit edilirse, IP adreslerini veya kalıplarını izin verilenler listesine ekle.
• GET/HEAD doğrulaması (body ile birlikte)RFC, GET veya HEAD istekleriyle birlikte gövde göndermeyi kesin olarak yasaklamasa da, bu yaygın bir uygulama değildir ve kaçınma girişimlerini gösterebilir. Çoğu durumda, ilk adım tüm bu istekleri kaydetmek ve şüpheli anormallikler olarak tespit edilirse bunları engellemektir.
• Gövde içeren içerik türü eksik.Eğer bir gövde mevcut ancak İçerik Türü yoksa, bu açıkça protokolün yanlış kullanıldığının veya analizden kaçınma girişiminin bir göstergesidir. Bu gibi durumlarda, özellikle internete açık ortamlarda, daha agresif bir engelleme yaklaşımı genellikle mantıklıdır.

Bu protokol kurallarına ek olarak, uygulama düzeyindeki veri saldırılarına ve DoS saldırılarına karşı koruma sağlamak için genellikle argüman sınırları da bulunur . Örneğin:

• İstek başına maksimum argüman sayısı (bazı WAF'larda varsayılan olarak 255).
• Tek bir argümanın maksimum uzunluğu (örneğin, 400 karakter).
• Tüm argümanların toplam boyutu (örneğin, 64.000 bayt).

Bu değerler birçok uygulama için makul olsa da, karmaşık form yüklemeleri, gelişmiş filtreler, büyük JSON yüklemeleri gibi durumlarda yanlış pozitifler ortaya çıkabilir. Bu senaryolarda en ihtiyatlı yaklaşım, öncelikle kayıt tutarak ve sayarak başlamak , hangi uç noktaların limitleri aştığını incelemek ve tüm site için limitleri kaldırmak yerine yalnızca bu rotalar için ayarlama yapmaktır.

Yanlış pozitifler: Bunları nasıl tespit edersiniz ve bunu yaparken ölmekten nasıl kaçınırsınız?

Yanlış pozitif, WAF'ın kötü amaçlı olarak tanımladığı ve saldırı olarak engellediği veya işaretlediği meşru bir istektir. Özellikle OWASP CRS gibi kapsamlı kural setleri etkinleştirildiğinde kaçınılmazdırlar, ancak günlük bir baş ağrısı haline gelmemeleri için profesyonelce yönetilebilirler.

Yanlış pozitifleri tespit etmek, logların dikkatli bir şekilde incelenmesiyle başlar . Bu, hangi isteklerin engellendiğini, hangi kuralın bunları tetiklediğini ve bunların hangi bağlamda meydana geldiğini (URL, parametreler, kullanıcı, kaynak vb.) incelemeyi içerir. Görsel araçlar ve kontrol panelleri, 403 hatalarındaki ani artışları veya olağandışı kalıpları belirlemeye yardımcı olabilir.

Hem bulut sağlayıcıları hem de ModSecurity topluluğu tarafından şiddetle tavsiye edilen bir yaklaşım, simülasyon veya sayım modunu kullanmaktır . Bu modda, test etmek istediğiniz kurallar her eşleşmeyi kaydeder ancak engelleme yapmaz. Bu, örneğin, yeni bir SQL enjeksiyonu kuralının üretimde etkinleştirmeden önce kaç meşru isteği engelleyeceğini görmenizi sağlar.

Kuralları, gerçek veya simüle edilmiş trafik alan bir hazırlık veya ön üretim ortamında test etmek de iyi bir fikirdir . OWASP ZAP veya trafik tekrar oynatma komut dosyaları gibi araçlar, WAF'ın davranışını test etmek için meşru kalıpları ve bilinen saldırıları simüle etmenize yardımcı olabilir.

Ayrıca, yanlış pozitiflerin operasyonel ve itibar üzerindeki etkisini de göz önünde bulundurmak çok önemlidir: ödeme kesintileri, kullanıcı kayıt hataları, açıklama yapılmadan başarısız olan kritik API çağrıları; bunların tümü gelir ve marka imajı açısından doğrudan maliyete yol açabilir. Aşırı miktarda yanlış pozitif, güvenlik ekibini değer katmayan uyarılarla boğarak gerçek olayları belirlemeyi zorlaştırır.

Kuralların ayarlanmasına yönelik stratejiler ve sicil kaydının akıllıca kullanımı

Yanlış pozitifleri yönetmek, "her şey çalışana" kadar kuralları kapatmakla ilgili değil, WAF'ı cerrahi hassasiyetle ince ayarlamakla ilgilidir . İşte burada aşağıdaki gibi iyi uygulamalar devreye giriyor:

Öncelikle, kuralları global olarak devre dışı bırakmaktan kaçının. Çok özel istisnalar oluşturmak daha iyidir : kural kimliğini yalnızca belirli bir rota, belirli parametreler veya dahili trafik için hariç tutun. Bu şekilde, uygulamanın geri kalanında korunmuş olursunuz ve yararlı günlükler tutarsınız.

İkinci olarak, engellemeden önce sayma modundan yararlanın . Yeni kuralları başlangıçta yalnızca kayıt modunda etkinleştirmek, kaç meşru isteğin etkileneceğini ölçmenizi sağlar. Bunu, bir kuralın anormal sayıda eşleşme oluşturup oluşturmadığını hızlı bir şekilde tespit etmek için SIEM'deki uyarılarla tamamlayabilirsiniz.

Üçüncüsü, WAF'ı bir SIEM veya merkezi günlük kaydı platformuyla entegre edin . Bu, WAF olaylarını diğer göstergelerle ilişkilendirmeyi kolaylaştırır: olağandışı sistem etkinliği, toplu kimlik doğrulama hataları, şüpheli yapılandırma değişiklikleri vb. Ayrıca, olayların ciddiyetine ve sıklığına bağlı olarak hangi kuralların önce ayarlanacağına öncelik verilmesine yardımcı olur.

Dördüncüsü, her değişikliği belgeleyin: hangi kuralın ince ayarının yapıldığı, hangi uç nokta için, hangi gerekçeyle ve hangi kanıtlarla yapıldığı. Sunucu kılavuzlarına başvurmak bu konuda yardımcı olabilir. Bu dokümantasyon yalnızca iç kontrolün sağlanmasına yardımcı olmakla kalmaz, aynı zamanda kontrollerin kolayca devre dışı bırakılmadığını göstermek istediğiniz güvenlik denetimleri ve incelemelerinde de paha biçilmezdir.

WAF'ta Otomasyon, Makine Öğrenimi ve Uyarlanabilir Kurallar

Uygulamalar büyüdükçe ve trafik daha karmaşık hale geldikçe, WAF'ı manuel olarak yönetmek gerçekçi olmaktan çıkıyor. İşte bu noktada otomasyon, gelişmiş günlük analizi ve bazı durumlarda makine öğrenimi devreye giriyor.

Öncelikle, SIEM ile entegrasyon, korelasyon kuralları ve otomatik yanıtlar oluşturmanıza olanak tanır : örneğin, bir IP kümesi tekrar tekrar enjeksiyon veya XSS kurallarını tetikliyorsa, bu IP'leri geçici bir kara listeye eklemek veya denetim seviyesini güçlendirmek için otomatik bir işlem oluşturabilirsiniz.

İkinci olarak, bazı WAF'lar, belirli bir süre boyunca meşru trafiği gözlemleyen makine öğrenimi modlarını içerir . Bu verilere dayanarak, normal davranış eşiklerini, kalıplarını ve profillerini önerir veya ayarlarlar. Bu, kurallar engelleme moduna geçirildiğinde yanlış pozitifleri azaltmaya ve sonraki trafik sapmalarını tespit etmeye yardımcı olur.

Araştırma ve laboratuvar ortamlarında, denetimli öğrenme teknikleri, meşru ve kötü amaçlı trafiği ayırt eden modelleri eğitmek ve daha sonra üretimde kullanılan politikaları iyileştirmek için kullanılmıştır. Sihirli bir çözüm olmasa da, bu yaklaşım, klasik imza tabanlı kuralların kolayca tespit edemediği ince kalıpları ortaya çıkarmaya yardımcı olabilir.

Son olarak, sürekli otomatik testler (OWASP ZAP, özel komut dosyaları veya CI/CD işlem hatları gibi araçlar kullanarak), WAF'ta yapılan değişikliklerin kritik işlevselliği bozmadığını veya bariz güvenlik açıkları bırakmadığını doğrulamanıza olanak tanır. Bu testleri dağıtım döngüsüne entegre etmek, güvenliği son dakika yaması olmaktan ziyade geliştirme akışının doğal bir parçası haline getirir.

Uygulama bazında politika tasarımı ve hizmet bazında kara listeler.

Karmaşık ortamlarda—örneğin, bir hosting sağlayıcısı veya internet servis sağlayıcısı—özellikle gölge BT söz konusu olduğunda, tek bir WAF politikası yeterli değildir. Aynı yük dengeleyicinin arkasında, her birinin farklı güvenlik ihtiyaçları ve trafik profilleri olan birden fazla alan adı veya uygulama bulunması yaygındır . İşte bu noktada hizmete özgü politikalar ve listeler tasarlamak hayati önem taşır.

Örnek olarak, tek bir sanal IP adresinin arkasında birden fazla site (örneğin, www.company1.com ve www.company2.com) için ters proxy görevi gören bir HTTP/S yük dengeleyiciyi ele alabiliriz. Bu senaryoda, WAF, istek yük dengeleme modülüne ulaşmadan önce bile, istek gelir gelmez Host başlığını ve kaynak IP adresini değerlendirecek şekilde yapılandırılabilir.

Mantık şu şekilde işleyecektir: WAF , SERVER_NAME (Ana Bilgisayar) ve istemci IP'sinin birleşiminin siteye özgü bir kara listeyle eşleşip eşleşmediğini kontrol eder. IP adresi www.company2.com için engellenmiş ancak www.company1.com için engellenmemiş olarak listelenmişse, yalnızca ilk durumda 403 Yasak yanıtı gönderilir. "Temiz" trafik daha sonra yük dengeleme modülüne iletilir ve bu modül, isteği hangi arka uç sunucusunun karşılayacağına karar verir.

Bu, örneğin, tüm erişim noktası için tek bir genel liste yerine, alana özgü kara listelerin tutulmasına olanak tanır . Günlük kaydı düzeyinde, her reddetme işlemi, kural kimliği, eşleşen koşul, URL, ana bilgisayar ve istemcinin IP adresi gibi ayrıntılarla birlikte syslog'a kaydedilir; bu da sonraki analizleri ve bu listelerin genişletilmesini veya hata ayıklamasını kolaylaştırır.

Bu hikayenin özü şu ki, politikalarınız ne kadar segmentlere ayrılmışsa (uygulama bazında, ortam bazında, kullanıcı türü bazında), kayıt tutma ve engelleme arasında o kadar hassas bir denge kurabilirsiniz: Örneğin, yönetim portallarında çok katı, bilgilendirme web sitelerinde ise biraz daha esnek olabilirsiniz; her kararın neden alındığına dair kanıtlar her zaman kayıtlarda yer almalıdır.

Klasik WAF'ın ötesinde: WAAP ve API koruması

Tehdit ortamı durağan kalmadı. Bugün birçok uygulama bulut tabanlıdır, mikro hizmet mimarileri kullanır ve halka açık ve özel API'ler sunar ; bu da onları saldırganlar için başlıca hedefler haline getirir. Geleneksel WAF'lar, WAAP (Web Uygulaması ve API Koruması) veya WAAS (Web Uygulaması ve API Güvenliği) olarak bilinen daha geniş platformlara dönüştü.

Bu çözümler yalnızca web uygulamalarını otomatik olarak keşfetmekle kalmaz, aynı zamanda API uç noktalarını tanımlar , OpenAPI veya Swagger gibi özellikleri kabul eder ve bu tanımı kullanarak isteklerin uyumluluğunu kontrol eder: beklenen veri türleri, izin verilen parametreler, boyut sınırları vb. Uç noktaya bağlı olarak (örneğin, son derece hassas verileri işleyen bir uç nokta), çok daha yüksek düzeyde inceleme ve engelleme uygulanabilir.

Günlük kaydı düzeyinde, WAAP bağlam açısından zengin olaylar üretme eğilimindedir : hangi API uç noktasına saldırıldığı, hangi işlemin (GET, POST, PUT…), hangi kullanıcının veya token'ın dahil olduğu, spesifikasyonun hangi bölümünün ihlal edildiği vb. Bu, yalnızca genel yük kalıplarına güvenmek yerine, daha hassas engelleme kararları alınmasına olanak tanır.

Ayrıca, birçok WAAP aracı, uygulama ve API'ye özgü DoS koruması, coğrafi konum filtreleme, IP itibar yönetimi, bot ve veri kazıma tespiti ve hizmet başına uyarı seviyelerini özelleştirme seçenekleri içerir. Yine burada önemli olan, daha sağlam bir yaklaşım istediğiniz yerleri ve sorunsuz çalışmayı önceliklendirmek istediğiniz yerleri belirleme esnekliğine sahip olmaktır ; bu da herhangi bir olayı araştırmak için sağlam bir günlük veritabanından ödün vermeden yapılabilir.

Özetle, ister klasik, ister WAAP tabanlı, isterse de bulut ekosistemine entegre edilmiş olsun, iyi ayarlanmış bir WAF (Web Uygulama Güvenlik Duvarı), ayrıntılı günlük kaydı, akıllı engelleme ve değişen tehdit ortamına sürekli uyum sağlama yeteneğini bir araya getirerek modern uygulama ve API savunmasının temel bir bileşeni haline gelir.