Balans mellan inspelning och blockering i WAF

Informatec Digital » Resurser » Balans mellan inspelning och blockering i WAF

Hitta balans mellan registrering och låsning i en WAF Det har blivit ett av de vanligaste problemen för säkerhets- och driftsteam. En brandvägg för webbapplikationer kan stoppa mycket allvarliga attacker, men om den konfigureras för aggressivt kan den blockera legitima köp, åtkomst eller API-anrop. Om den konfigureras för löst blir den nästan rent dekorativ. Nyckeln är att noggrant justera när man ska logga, när man ska räkna, när man ska tillåta och när man ska blockera.

I den här artikeln kommer vi att fördjupa oss i hur man uppnår denna balans med hjälp av moderna WAF-funktioner (tillåtelselistor, frekvensbaserade regler, inlärningslägen, SIEM-integration, maskininlärning etc.), med stöd av konkreta exempel på AWS WAF, ModSecurity, moln-WAF och lokala lösningarDu kommer att se hur man begränsar falska positiva resultat utan att sänka skyddsnivån, hur man organiserar policyer efter applikation och hur man använder registret som en allierad, inte som ett konstant, ohanterligt brus.

Vad är en WAF och varför är registrering så viktig?

En webbapplikationsbrandvägg fungerar som en intelligent lager mellan användaren och servernAnalysera HTTP/HTTPS-trafik i realtid. Till skillnad från en traditionell nätverksbrandvägg, som bara tittar på portar och IP-adresser, går en WAF in på detaljer: URL:er, parametrar, förfrågningstexter, rubriker, cookies, HTTP-metoder etc.

Deras uppdrag är upptäcka och stoppa typiska lager 7-attackerSQL-injektion, XSS, LFI/RFI, åtkomstkontrollattacker, API-missbruk, aggressiv scraping, brute force och även vissa DDoS-mönster på applikationsnivå är alla skyddade mot dessa attacker. Detta uppnås genom ständigt uppdaterade uppsättningar regler, signaturer och säkerhetspolicyer.

Loggning är myntets andra sida. Varje WAF-beslut – tillåt, blockera eller bara räkna – kan åtföljas av en detaljerad händelse i loggarnaDessa register tillåter:

• Utreda incidenterrekonstruera vad som hände och hur ett försök gjordes att utnyttja en sårbarhet.
• Anpassa reglerupptäcka falska positiva resultat genom att se vilka legitima förfrågningar WAF blockerar.
• Följ föreskrifternavisa att aktiva kontroller finns (PCI DSS, GDPR, internrevisioner etc.).
• Matning av en SIEMKorrelera applikationsattacker med nätverks-, system-, identitets- etc. händelser.

Problemet är att en dåligt inställd WAF kan fylla loggarna med tusentals irrelevanta händelservilket gör det omöjligt att hitta det viktiga och dessutom orsakar omotiverade avslag på legitim trafik. Det är där konsten att manipulera registrerings-, räknings- och blockeringsmetoder kommer in i bilden.

Säkerhetsmodeller i WAF: blocklistor, tillåtelselistor och en hybridmetod

De flesta moderna WAF:er kombinerar flera filtreringsmetoder, vilket har direkt inverkan på hur förfrågningar loggas och blockerasI stort sett kan vi tala om två klassiska filosofier, plus en mycket vanlig blandmodell.

En WAF baserad på blockeringslista Den följer en negativ säkerhetsmodell. Dess idé är: ”Jag tillåter allt utom det jag vet är dåligt.” Den fungerar baserat på signaturer från kända attacker (SQL-injektion, XSS, botmönster etc.) och regler som definierar vad som anses misstänkt. Den är lättare att driftsätta initialt, men om du enbart förlitar dig på den här modellen riskerar du att nya vektorer eller varianter av attacker slinka in oupptäckt.

En WAF av tillåtelselista Det är raka motsatsen: "blockera allt utom det som uttryckligen är tillåtet". Det är baserat på en positiv säkerhetsmodell. Endast trafik som passar det definierade legitima beteendet – rutter, metoder, parametrar, format, storlekar etc. – accepteras. Det är mycket säkrare, men kräver betydande finjusteringar och kan generera falska positiva resultat i början om den inte är ordentligt förberedd.

På grund av fördelarna och nackdelarna med varje tillvägagångssätt blir en enda modell allt vanligare. hybrid av tillåtelselista + blockeringslistaI det här scenariot definieras förväntade trafikprofiler (till exempel vad som utgör en normal inloggning eller betalningsbegäran), och samtidigt tillämpas signaturer och heuristik för att upptäcka typiska skadliga mönster. För loggningsändamål möjliggör hybridmetoden:

• Markera como högriskhändelse det som bryter mot listan över tillåtna varor.
• Behandla som varningar med medelhög/låg prioritet allmänna blocklistmönster.
• Använd "räkna"-läget för att se vad som skulle bryta mot en regel innan blocket aktiveras.

WAF i nätverk, på värd och i molnet: påverkan på loggning och låsning

WAF-distributionsmodellen påverkar i hög grad hur trafikloggning och blockering hanteras. Att logga förfrågningar på en nätverksenhet är inte detsamma som att logga dem på en agent i servern eller på en hanterad molntjänst.

En WAF nätverksbaserad Den används vanligtvis som en fysisk eller virtuell apparat inom infrastrukturen, mellan internet och applikationer. Detta är den klassiska metoden för tillverkare som F5. Den har fördelen att erbjuda hög prestanda och detaljerad kontrollKonfiguration och hantering kan dock vara komplexa. Loggar skickas vanligtvis till syslog eller en central SIEM, och det är viktigt att noggrant filtrera vad som sparas för att undvika överbelastning av lagring, analysverktyg och diagnostik. IP- och DNS-nätverksproblem.

WAF värdbaserad Den körs på samma servrar (eller containrar) där applikationen finns, vanligtvis som en modul eller agent (till exempel ModSecurity integrerad i Nginx eller Apache; kombinerad med Linux-härdning med SELinux (förbättrar säkerhetsställningen). Den här modellen låter dig ha Mer applikationskontext och mycket specifika regler per tjänst, vilket i sin tur förbrukar lokala resurser och kräver mer distribuerad logghantering. De kan lagras i lokala filer och sedan vidarebefordras, eller integreras med centraliserade loggtjänster.

WAF i molnet (Cloudflare, Akamai, Imperva Cloud, AWS WAF, etc.) integreras med lastbalanserare, CDN:er eller virtuella nätverk. Här erbjuder leverantören vanligtvis paneler, instrumentpaneler och loggar exportera till S3, BigQuery, fjärrsyslog eller SIEM. Det är oftast enklare att aktivera, men du måste anpassa dina loggningspolicyer till leverantörens modell: händelsetyper, kvarhållning, allvarlighetsgradsfilter etc.

Att välja en modell framför en annan är inte bara ett tekniskt beslut; det beror också på hur du vill balansera loggning och blockering. En molnhanterad tjänst förenklar många aspekter, men du kanske vill... absolut kontroll över var loggarna lagras på grund av efterlevnads- eller sekretesspolicyer, vilket driver mot lokala modeller eller hybridmodeller.

Villkor, regler och webb-ACL:er: hur WAF beslutar om att blockera, tillåta eller endast registrera

Oavsett tillverkare är alla moderna WAF:er baserade på idén om villkor, regler och åtkomstpolicyerAtt förstå detta är nyckeln till att experimentera med räknings-, loggnings- och låsningslägen utan att störa produktionen.

den termer De beskriver vilken del av begäran som inspekteras: käll-IP, specifika HTTP-rubriker (Host, User-Agent, Accept, Content-Type…), frågeparametrar, begäran, cookies, HTTP-metod, ursprungsland etc. I AWS WAF Classic kan du till exempel definiera ett IP-villkor med upp till 10 000 adresser eller intervall, eller ett strängmatchningsvillkor på en del av URL:en.

den regler De kombinerar ett eller flera villkor och tilldelar en avsikt: tillåt, blockera eller räkna. När en regel har flera villkor utvärderas de vanligtvis med en logiskt OCHAlla villkor måste vara uppfyllda för att regeln ska aktiveras. En vanlig regel utan villkor matchar i praktiken ingenting och dess åtgärd utlöses aldrig.

Många WAF:er, inklusive AWS WAF, har också räntebaserade reglerDessa regler räknar antalet förfrågningar som kommer från en IP-adress (eller en uppsättning IP-adresser som uppfyller vissa villkor) under ett tidsfönster, till exempel fem minuter. Om ett tröskelvärde överskrids – säg 1 000 förfrågningar på fem minuter – träder regeln i kraft: den blockerar eller räknar helt enkelt. Detta är mycket användbart för:

• kontroll brute force på inloggningsformulär.
• Begränsa aggressiv skrapning eller oförskämda bots.
• Mildra vissa typer av DDoS-attacker på applikationsnivå.

Nästa nivå är Webb-ACL (åtkomstkontrolllista)Här grupperas reglerna, och en utvärderingsordning och en standardåtgärd (TILÅT eller BLOCK) definieras. En begäran passerar genom reglerna i ordning; om den matchar en, tillämpas dess åtgärd, och utvärderingen av resten stoppas. Om den inte matchar någon, tillämpas standardåtgärden som definierats i ACL:n.

När det gäller balansen mellan loggning och låsning är det i ACL:n du bestämmer om du vill att systemet som standard ska vara tillåtande (TILLÅT och blockera endast enligt specifika regler) eller mycket restriktiva (BLOCK förutom i vissa fall). Dessutom tillåter många lösningar dig att ställa in regler i "räkna"-läge inom ACL:n, så att de registrerar matchningar men inte blockerar trafik, perfekt för finjusteringsfasen.

Vitlistor och brusreducering i loggar

Tillåtelselistor är ett grundläggande verktyg för minska falska positiva resultat och brus i journalenIdén är enkel: i vissa sammanhang säger du till WAF att inte tillämpa ett direktiv eller en uppsättning regler på viss specifik trafik som du redan har kategoriserat som betrodd eller som du vet ligger utanför normen men är legitim.

Till exempel kan du i AWS WAF skapa regler för tillåtelselistor så att om begäran kommer från en IP-adress eller specifikt intervallEller, om den matchar ett känt URL-mönster och HTTP-metod, tillämpas inte vissa signaturinspektioner. Detta bidrar till att:

• Förhindra interna API:er som använder "konstiga" mönster generera konstanta falska positiva.
• Minska latensen som introduceras av djupgående inspektion i trafik som du redan anser vara pålitlig.
• Minska volymen av onödiga poster i WAF-loggarna.

På plattformar som ModSecurity är den rekommenderade metoden att inte modifiera standardreglerna (t.ex. OWASP Core Rule Set), utan att skapa specifika undantag efter regel-ID för specifika parametrar, rutter eller användare. Detta möjliggör upprätthållande av övergripande skydd utan att skapa stora sårbarheter genom att inaktivera hela webbplatsövergripande regler.

Det viktiga är att de tillåtna listorna är kirurgiskInte en drastisk åtgärd. Det är mycket bättre att utesluta en specifik kombination (regel X + parameter Y i URL Z) än att inaktivera regel X globalt. På så sätt förblir loggningen användbar och du skapar inga onödiga blinda fläckar.

Protokollregler och begränsningar: när man ska blockera, när man ska varna

Många WAF:er innehåller en uppsättning saneringsregler för HTTP-protokoll som fungerar som första felaktiga eller misstänkta trafikfiltretDessa regler granskar obligatoriska rubriker, metoder, argumentstorlekar etc., och är en frekvent källa till både gott skydd och falska positiva resultat om de inte är väl förstådda.

Några mycket vanliga exempel:

• Acceptrubrik saknas (Accept-rubrik saknas): Detta är inte strikt sett en RFC-överträdelse, men många förfrågningar utan denna rubrik kommer från automatiserade verktyg eller dåligt skrivna skript. Det kan påverka anpassade API:er eller klienter som inte skickar den. I många miljöer är loggning och räkning att föredra framför direkt blockering.
• Värdhuvud saknasEnligt HTTP/1.1-standarder är Host-headern obligatorisk. WAF:er behöver den också för att avgöra vilken policy som ska tillämpas. Blockering här är vanligtvis rimligt, men det kan generera falska positiva resultat under testning eller på grund av felkonfigurerad intern trafik; det är lämpligt att övervaka loggarna innan strikt blockering aktiveras.
• Användaragentrubrik saknasDenna regel försöker begränsa rudimentära botar och oidentifierad trafik. Problemet är att många legitima API:er kanske inte skickar en användaragent. Det mest förnuftiga tillvägagångssättet är vanligtvis att logga och, om ett konsekvent och legitimt API upptäcks, lägga till deras IP-adress eller mönster i en tillåtelselista.
• GET/HEAD-validering med brödtextÄven om RFC inte strikt förbjuder att skicka texten med GET- eller HEAD-förfrågningar, är det inte vanlig praxis och kan tyda på försök att undvika attacker. I många fall är ett första steg att logga alla dessa förfrågningar och, om de visar sig vara misstänkta avvikelser, fortsätta att blockera dem.
• Saknar innehållstyp med brödtextOm det finns en brödtext men ingen Content-Type är det en tydlig indikation på felaktig protokollanvändning eller ett försök att undvika analys. I dessa fall är en mer aggressiv blockeringsmetod vanligtvis klok, särskilt i internetbaserade miljöer.

Utöver dessa protokollregler är det vanligt att hitta argumentens gränser För att skydda mot översvämningar på applikationsnivå och DoS-attacker. Till exempel:

• Maximalt antal argument per begäran (som standard 255 i vissa WAF:er).
• Maximal längd för ett enskilt argument (till exempel 400 tecken).
• Total kombinerad storlek för alla argument (till exempel 64 000 byte).

Dessa värden är rimliga för många applikationer, men det finns fall – komplexa formuläruppladdningar, avancerade filter, stora JSON-inläsningar – där falska positiva resultat uppstår. I dessa scenarier är den mest försiktiga metoden börja med att registrera och räknaGranska vilka slutpunkter som bryter mot gränserna och justera endast för dessa rutter, istället för att häva alla gränser för hela webbplatsen.

Falska positiva resultat: hur man upptäcker dem och inte dör i försöket

Ett falskt positivt är en legitim begäran som WAF identifierar sig som skadlig och blockerar eller markerar som en attack. De är oundvikliga, särskilt när du aktiverar breda regeluppsättningar som OWASP CRS, men de kan hanteras professionellt så att de inte blir ett dagligt problem.

Upptäckten av falska positiva resultat börjar med en noggrann observation av loggarnaGranska vilka förfrågningar som blockeras, vilken regel som utlöser dem och i vilket sammanhang (URL, parametrar, användare, ursprung etc.). Visuella verktyg och dashboards hjälper till att identifiera toppar i 403-fel eller ovanliga mönster.

En starkt rekommenderad metod, både av molnleverantörer och ModSecurity-communityn, är att använda en simuleringsläge eller räknelägeI det här läget loggar de regler du vill testa varje matchning, men blockerar inte. Detta låter dig till exempel se hur många legitima förfrågningar en ny SQLi-regel skulle ha blockerat innan du vågade aktivera den i produktion.

Det är också en bra idé att testa reglerna i en staging- eller förproduktionsmiljö som tar emot verklig eller simulerad trafik. Verktyg som OWASP ZAP eller trafikåteruppspelningsskript kan hjälpa dig att simulera legitima mönster och kända attacker för att testa WAF:ens beteende.

Dessutom är det avgörande att beakta den operativa och anseendemässiga effekten av falska positiva resultat: betalningsavbrott, misslyckade användarregistreringsfel, kritiska API-anrop som misslyckas utan förklaring – allt detta kan ha en direkt kostnad i intäkter och varumärkesimage. Ett överskott av falska positiva resultat överväldigar också säkerhetsteamet med varningar som inte tillför något värde, vilket gör det svårt att identifiera genuina incidenter.

Strategier för att justera regler och intelligent användning av registret

Att hantera falska positiva resultat handlar inte om att stänga av regler tills "allt fungerar", utan om finjustera WAF med en skalpellDet är här goda metoder som följande kommer in i bilden:

Först, undvik att inaktivera regler globalt. Det är att föredra att skapa mycket specifika undantagExkludera regel-ID:t endast för en specifik rutt, för vissa parametrar eller för intern trafik. På så sätt förblir du skyddad i resten av applikationen och underhåller användbara loggar.

För det andra, dra nytta av modo de conteo Innan blockering kan du mäta hur många legitima förfrågningar som skulle påverkas genom att aktivera nya regler initialt endast i loggningsläge. Du kan komplettera detta med SIEM-aviseringar för att snabbt upptäcka om en regel genererar en onormal volym av matchningar.

För det tredje, integrera WAF med en SIEM eller centraliserad loggplattformDetta gör det enklare att korrelera WAF-händelser med andra indikatorer: ovanlig systemaktivitet, massautentiseringsfel, misstänkta konfigurationsändringar etc. Det hjälper också till att prioritera vilka regler som ska justeras först baserat på händelsernas allvarlighetsgrad och frekvens.

För det fjärde, dokumentera varje ändring: vilken regel som har förfinats, för vilken slutpunkt, under vilken motivering och med vilka bevis. För detta, se servermanualer guide Denna dokumentation kan vara användbar. Den hjälper inte bara till att upprätthålla intern kontroll, utan är också ovärderlig vid revisioner och säkerhetsgranskningar, där du vill visa att... Kontrollerna inaktiveras inte lättvindigt.

Automatisering, maskininlärning och adaptiva regler i WAF

Allt eftersom applikationerna växer och trafiken blir mer komplex blir det orealistiskt att hantera WAF manuellt. Det är här Automatisering, avancerad logganalys och i vissa fall användning av maskininlärning.

För det första möjliggör integration med SIEM byggandet korrelationsregler och automatiserade svarOm till exempel en uppsättning IP-adresser upprepade gånger utlöser injektions- eller XSS-regler, kan en automatiserad åtgärd genereras för att lägga till dessa IP-adresser i en tillfällig blockeringslista eller stärka inspektionsnivån.

För det andra innehåller vissa WAF:er maskininlärningslägen (inlärningsläge) som observerar legitim trafik under en definierad period. Baserat på dessa data föreslår eller justerar den tröskelvärden, mönster och profiler av normalt beteende. Detta hjälper till att minska falska positiva resultat när regler ställs in i blockeringsläge och upptäcker efterföljande trafikavvikelser.

I forsknings- och laboratoriemiljöer har övervakade inlärningstekniker använts för att träna modeller att skilja mellan legitim och skadlig trafik, och förfina policyer som sedan används i produktionen. Även om det inte är en mirakelkur kan denna metod hjälpa. upptäck subtila mönster som klassiska signaturbaserade regler inte lätt upptäcker.

Slutligen kontinuerlig automatiserad testning (Med hjälp av verktyg som OWASP ZAP, anpassade skript eller CI/CD-pipelines) kan du validera att ändringar i WAF inte förstör kritisk funktionalitet eller lämnar uppenbara sårbarheter. Att integrera dessa tester i distributionscykeln gör säkerhet till en naturlig del av utvecklingsflödet, snarare än en patch i sista minuten.

Policydesign per applikation och svartlistor per tjänst

I komplexa miljöer – till exempel en webbhotellleverantör eller en internetleverantör – räcker det inte med en enda WAF-policy som passar alla, särskilt när det finns IT i skugganDet är vanligt att ha flera domäner eller applikationer bakom samma lastbalanserare, var och en med olika säkerhetsbehov och trafikprofilerDet är här det är klokt att utforma tjänstespecifika policyer och listor.

Ett illustrativt exempel är en HTTP/S-belastningsutjämnare som fungerar som omvänd proxy för flera webbplatser (till exempel www.företag1.com och www.företag2.com) bakom en enda virtuell IP-adress. I det här scenariot är det möjligt att konfigurera WAF:en så att värdheadern och käll-IP:n utvärderas så snart begäran anländer, redan innan lastbalanseringsmodulen öppnas.

Logiken skulle vara ungefär så här: WAF kontrollerar om kombinationen av SERVER_NAME (värd) och klient-IP Den matchar en webbplatsspecifik svartlista. Om IP-adressen är listad som blockerad för www.company2.com men inte för www.company1.com, returneras ett 403 Forbidden-svar endast i det första fallet. "Ren" trafik skickas sedan till lastbalanseringsmodulen, som avgör vilken backend som hanterar begäran.

Detta gör att du kan underhålla, till exempel, svartlistor efter domänIstället för en global lista för hela åtkomstpunkten loggas varje avslag i sysloggen med detaljer som regel-ID, matchande villkor, URL, värden och klientens IP-adress, vilket underlättar efterföljande analys och utökning eller felsökning av dessa listor.

Sensmoralen i historien är att ju mer segmenterade dina policyer är (efter applikation, efter miljö, efter användartyp), desto bättre kan du hitta balansen mellan loggning och blockering: du kan vara mycket strikt på administrativa portaler och något mer flexibel på informativa webbplatser, till exempel, alltid med bevis i loggarna för varför varje beslut fattades.

Utöver den klassiska WAF: WAAP- och API-skydd

Hotlandskapet har inte förblivit statiskt. Idag är många applikationer molnbaserade, använder mikrotjänstarkitekturer och exponerar Offentliga och privata API:er vilket blir det primära målet för angripare. Den traditionella WAF har utvecklats till bredare plattformar som kallas WAAP (Web Application and API Protection) eller WAAS (Web Application & API Security).

Dessa lösningar upptäcker inte bara webbapplikationer automatiskt, utan också identifiera API-slutpunkterDe accepterar specifikationer som OpenAPI eller Swagger och använder den definitionen för att kontrollera efterlevnaden av förfrågningar: förväntade datatyper, tillåtna parametrar, storleksgränser etc. Beroende på slutpunkten (till exempel en som hanterar mycket känslig data) kan en mycket högre nivå av granskning och blockering tillämpas.

På loggningsnivå tenderar WAAP att generera händelser rikare i kontextDetta möjliggör mer exakta blockeringsbeslut, snarare än att enbart förlita sig på generiska nyttolastmönster. Denna information kan användas för att fastställa exakt vilken API-slutpunkt som attackerades, vilken specifik operation som var inblandad (GET, POST, PUT, etc.), vilken användare eller token som var inblandad, vilken del av specifikationen som kränktes och så vidare.

Dessutom inkluderar många WAAP-verktyg applikations- och API-specifikt DoS-skydd, geolokaliseringsfiltrering, IP-rykteshantering, bot- och scraping-detektering samt alternativ för att anpassa varningsnivåer per tjänst. Återigen handlar det om att ha flexibiliteten att bestämma. där du vill ha en fast hand och där du vill prioritera flytutan att offra en god registerbas för att utreda någon incident.

Sammantaget blir en väl avstämd WAF – oavsett om den är klassisk, WAAP-baserad eller integrerad i ett molnekosystem – en viktig komponent i modernt applikations- och API-försvar, kapabel att kombinera Detaljerad inspelning, intelligent låsning och kontinuerlig anpassning till det föränderliga hotbilden.