Balance mellem optagelse og blokering i WAF

Informatic Digital » Recursos » Balance mellem optagelse og blokering i WAF

At finde den rette balance mellem logning og blokering i en WAF er blevet en af ​​de mest almindelige hovedpiner for sikkerheds- og driftsteams. En webapplikationsfirewall kan stoppe meget alvorlige angreb, men hvis den konfigureres for aggressivt, kan den blokere legitime køb, adgang eller API-kald. Hvis den konfigureres for løst, ender den med at være næsten udelukkende dekorativ. Nøglen er omhyggeligt at justere, hvornår der skal logges, hvornår der skal tælles, hvornår der skal tillades, og hvornår der skal blokeres.

I denne artikel vil vi dykke ned i, hvordan man opnår denne balance ved hjælp af moderne WAF-funktioner (tilladelseslister, frekvensbaserede regler, læringstilstande, SIEM-integration, maskinlæring osv.), understøttet af konkrete eksempler fra AWS WAF, ModSecurity, cloudbaserede WAF'er og lokale løsninger . Du vil se, hvordan man begrænser falske positiver uden at sænke beskyttelsesniveauet, hvordan man organiserer politikker efter applikation, og hvordan man bruger logføring som en allieret, ikke som en konstant, uhåndterlig kilde til støj.

Hvad er en WAF, og hvorfor er registrering så vigtig?

En webapplikationsfirewall fungerer som et intelligent lag mellem brugeren og serveren og analyserer HTTP/HTTPS-trafik i realtid. I modsætning til en traditionel netværksfirewall, som overvåger porte og IP-adresser, går en WAF i dybden med: URL'er, parametre, anmodningstekster, headere, cookies, HTTP-metoder og mere.

Dens mission er at opdage og stoppe typiske Layer 7-angreb : SQL-injektion, XSS, LFI/RFI, angreb mod adgangskontrol, API-misbrug, aggressiv scraping, brute force og endda visse DDoS-mønstre på applikationsniveau. For at gøre dette er den afhængig af regelsæt, signaturer og sikkerhedspolitikker, der konstant opdateres.

Logføring er den anden side af medaljen. Enhver WAF-beslutning – tillad, bloker eller kun tæl – kan ledsages af en detaljeret hændelse i loggene . Disse logge tillader:

• Undersøg hændelserRekonstruer, hvad der skete, og hvordan der blev gjort et forsøg på at udnytte en sårbarhed.
• Juster regler: opdager falske positiver ved at se, hvilke legitime anmodninger WAF blokerer.
• Overhold reglernepåvise, at der findes aktive kontroller (PCI DSS, GDPR, interne revisioner osv.).
• Fodring af en SIEMKorreler applikationsangreb med netværks-, system-, identitets- osv. hændelser.

Problemet er, at en dårligt indstillet WAF kan fylde logs med tusindvis af irrelevante hændelser , hvilket gør det umuligt at finde det vigtige, og oven i købet forårsager uberettigede afvisninger af legitim trafik. Det er her, kunsten at lege med logging, optælling og blokeringstilstande kommer ind i billedet.

Sikkerhedsmodeller i WAF: blokeringslister, tilladelseslister og en hybrid tilgang

De fleste moderne WAF'er kombinerer adskillige filtreringsmetoder, hvilket direkte påvirker, hvordan anmodninger logges og blokeres . Overordnet set kan vi identificere to klassiske filosofier plus en meget almindelig hybridmodel.

En bloklistebaseret WAF følger en negativ sikkerhedsmodel. Dens kerneprincip er: "Jeg tillader alt undtagen det, jeg ved er skadeligt." Den fungerer ved at bruge signaturer fra kendte angreb (SQL-injektion, XSS, botmønstre osv.) og regler, der definerer, hvad der betragtes som mistænkeligt. Den er nemmere at implementere i starten, men hvis man udelukkende stoler på denne model, risikerer man, at nye angrebsvektorer eller varianter slipper igennem uopdaget.

En WAF med en tilladelsesliste fungerer på den modsatte måde: "bloker alt undtagen det, der er eksplicit tilladt." Den er baseret på en positiv sikkerhedsmodel. Kun trafik, der passer til den definerede legitime adfærd - ruter, metoder, parametre, formater, størrelser osv. - accepteres. Det er meget mere sikkert, men kræver betydelig finjustering og kan generere falske positiver i starten , hvis det ikke er ordentligt forberedt.

På grund af fordele og ulemper ved hver tilgang bliver en hybridmodel, der kombinerer tilladelseslister og blokeringslister, stadig mere almindelig . I dette scenarie defineres forventede trafikprofiler (for eksempel hvad der udgør et normalt login eller en betalingsanmodning), og signaturer og heuristikker anvendes samtidigt for at detektere typiske ondsindede mønstre. Til logføringsformål muliggør denne hybridtilgang:

• Markér som højrisikobegivenhed det, der overtræder listen over tilladte varer.
• Behandl som advarsler med mellem/lav prioritet generelle blokeringslistemønstre.
• Brug "tælle"-tilstanden til at se, hvad der ville bryde en regel, før du aktiverer blokken.

WAF i netværk, på vært og i skyen: indflydelse på logføring og låsning

WAF-implementeringsmodellen har stor indflydelse på, hvordan trafiklogning og -blokering håndteres. Logføring af anmodninger på en netværksenhed er ikke det samme som at logge dem på en agent på serveren eller på en administreret cloudtjeneste.

En netværksbaseret WAF implementeres typisk som en fysisk eller virtuel enhed i infrastrukturen, mellem internettet og applikationer. Dette er den klassiske tilgang, der anvendes af producenter som F5. Den tilbyder fordelen ved høj ydeevne og detaljeret kontrol , men konfiguration og administration kan være kompleks. Logføring sendes normalt til syslog eller en central SIEM, og det er vigtigt omhyggeligt at filtrere, hvad der gemmes, for at undgå overbelastning af lager- og analyseværktøjer og for at diagnosticere problemer i IP- og DNS-netværk.

Værtsbaserede WAF'er kører på de samme servere (eller containere), hvor applikationen befinder sig, typisk som et modul eller en agent (f.eks. ModSecurity integreret i Nginx eller Apache; kombinationen af ​​det med Linux-hærdning ved hjælp af SELinux forbedrer sikkerhedstilstanden). Denne model giver mulighed for bedre applikationskontekst og meget specifikke regler pr. tjeneste, på bekostning af et forbrug af lokale ressourcer og krav om mere distribueret logstyring. Logfiler kan gemmes i lokale filer og derefter videresendes eller integreres med centraliserede logtjenester.

Cloudbaserede WAF'er (Cloudflare, Akamai, Imperva Cloud, AWS WAF osv.) integreres med load balancers, CDN'er eller virtuelle netværk. Udbydere tilbyder typisk dashboards og log-eksport til S3, BigQuery, eksterne syslogs eller SIEM'er. De er generelt nemmere at konfigurere, men du skal tilpasse dine logpolitikker til udbyderens model: hændelsestyper, opbevaringsperioder, alvorlighedsfiltre osv.

At vælge den ene model er ikke kun en teknisk beslutning, men også et spørgsmål om, hvordan du vil balancere logging og låsning: en cloud-administreret tjeneste forenkler mange aspekter, men du ønsker måske absolut kontrol over, hvor logs gemmes på grund af compliance- eller fortrolighedspolitikker, hvilket skubber dig i retning af on-premise eller hybride modeller.

Vilkår, regler og web-ACL'er: hvordan WAF beslutter, om den skal blokere, tillade eller kun registrere

Uanset producenten er alle moderne WAF'er baseret på konceptet om adgangsbetingelser, regler og politikker . Forståelse af dette er nøglen til succesfuld brug af optællings-, logførings- og låsetilstande i produktionen.

Betingelserne beskriver , hvilken del af anmodningen der inspiceres: kilde-IP, specifikke HTTP-headere (Host, User-Agent, Accept, Content-Type…), forespørgselsparametre, anmodningstekst, cookies, HTTP-metode, oprindelsesland osv. For eksempel kan du i AWS WAF Classic definere en IP-betingelse med op til 10.000 adresser eller intervaller eller en strengmatchbetingelse på en del af URL'en.

Regler kombinerer en eller flere betingelser og tildeler en intention: at tillade, at blokere eller at tælle. Når en regel har flere betingelser, evalueres de typisk med et logisk OG : alle betingelser skal være opfyldt for at reglen kan udløses. En normal regel uden betingelser matcher i praksis ikke noget, og dens handling udløses aldrig.

Mange WAF'er, herunder AWS WAF, har også hastighedsbaserede regler . Disse regler tæller anmodninger, der ankommer fra en IP-adresse (eller et sæt IP-adresser, der opfylder bestemte betingelser) i løbet af et tidsvindue, for eksempel fem minutter. Hvis en tærskel overskrides – f.eks. 1.000 anmodninger på fem minutter – træder reglen i kraft: den blokerer eller tæller blot. Dette er meget nyttigt til:

• kontrol brute force på loginformularer.
• Begræns aggressiv scraping eller uhøflige bots.
• Afbødning af visse typer DDoS-angreb på applikationsniveau.

Det næste niveau er Web ACL (Access Control List) . Her grupperes reglerne, og en evalueringsrækkefølge og en standardhandling (ALLOW eller BLOCK) defineres. En anmodning passerer gennem reglerne i rækkefølge; hvis den matcher en, anvendes dens handling, og evalueringen af ​​resten stoppes. Hvis den ikke matcher nogen regler, anvendes den standardhandling, der er defineret i ACL'en.

Med hensyn til balancering af logføring og blokering er det i ACL'en, du bestemmer, om systemet som standard skal være tilladt (TILLADT og blokering kun efter specifikke regler) eller meget restriktivt (BLOKERING undtagen i særlige tilfælde). Derudover giver mange løsninger dig mulighed for at indstille regler i "tællingstilstand" i ACL'en, så de logger matches, men ikke blokerer trafik – ideelt til tuningfasen.

Hvidlister og støjreduktion i logfiler

Tilladelseslister er et grundlæggende værktøj til at reducere falske positiver og støj i loggen . Ideen er enkel: I visse sammenhænge fortæller du WAF'en, at den ikke må anvende et direktiv eller et sæt regler på specifik trafik, som du allerede har kategoriseret som betroet, eller som du ved er uden for normen, men legitim.

For eksempel kan du i AWS WAF oprette tilladelseslister, så visse signaturinspektioner ikke anvendes, hvis en anmodning kommer fra en bestemt IP-adresse eller et bestemt IP-interval , eller hvis den matcher et kendt URL-mønster og en kendt HTTP-metode. Dette hjælper med at:

• Forhindr interne API'er, der bruger "mærkelige" mønstre genererer konstante falske positiver.
• Reducer den latenstid, der introduceres af dybdegående inspektion i trafik, du allerede anser for at være troværdig.
• Reducer mængden af ​​unødvendige poster i WAF-loggene.

På platforme som ModSecurity er den anbefalede fremgangsmåde ikke at ændre standardregler (f.eks. OWASP Core Rule Set), men snarere at oprette specifikke undtagelser efter regel-ID for bestemte parametre, stier eller brugere. Dette giver dig mulighed for at opretholde den overordnede beskyttelse uden at skabe store sårbarheder ved at deaktivere hele regler på tværs af webstedet.

Nøglen er at gøre tilladelseslisterne kirurgiske , ikke en generel tilgang. Det er meget bedre at udelukke en specifik kombination (regel X + parameter Y i URL Z) end at deaktivere regel X globalt. På den måde forbliver logføringen nyttig, og du skaber ikke unødvendige blinde vinkler.

Protokolregler og begrænsninger: hvornår skal man blokere, hvornår skal man advare

Mange WAF'er inkorporerer et sæt HTTP-protokolrensningsregler, der fungerer som et første filter for misdannet eller mistænkelig trafik . Disse regler kontrollerer nødvendige headere, metoder, argumentstørrelser osv. og er en hyppig kilde til både god beskyttelse og falske positiver, hvis de ikke forstås korrekt.

Nogle meget almindelige eksempler:

• Manglende acceptheader (Mangler Accept-header): Dette er ikke strengt taget en RFC-overtrædelse, men mange anmodninger uden denne header kommer fra automatiserede værktøjer eller dårligt skrevne scripts. Det kan påvirke brugerdefinerede API'er eller klienter, der ikke sender den. I mange miljøer foretrækkes logføring og optælling frem for direkte blokering.
• Manglende værtsheaderIfølge HTTP/1.1-standarder er Host-headeren obligatorisk. WAF'er skal også bruge den til at bestemme, hvilken politik der skal anvendes. Blokering her er normalt rimelig, men det kan generere falske positiver under test eller på grund af forkert konfigureret intern trafik. Det anbefales at overvåge logfilerne, før streng blokering aktiveres.
• Manglende brugeragentheaderDenne regel forsøger at begrænse rudimentære bots og uidentificeret trafik. Problemet er, at mange legitime API'er muligvis ikke sender en brugeragent. Den mest fornuftige tilgang er normalt at logge, og hvis en konsistent og legitim API opdages, tilføj deres IP-adresse eller mønster til en tilladelsesliste.
• GET/HEAD-validering med brødtekstSelvom RFC ikke strengt forbyder at sende kroppen med GET- eller HEAD-anmodninger, er det ikke almindelig praksis og kan indikere forsøg på undvigelse. I mange tilfælde er et første skridt at logge alle disse anmodninger, og hvis de viser sig at være mistænkelige anomalier, fortsætte med at blokere dem.
• Manglende indholdstype med brødtekstHvis der er en brødtekst, men ingen Content-Type, er det en klar indikation af forkert protokolbrug eller et forsøg på at undgå analyse. I disse tilfælde giver en mere aggressiv blokeringsmetode normalt mening, især i internetvendte miljøer.

Ud over disse protokolregler findes argumentgrænser ofte for at beskytte mod oversvømmelser på applikationsniveau og DoS-angreb. For eksempel:

• Maksimalt antal argumenter pr. anmodning (som standard 255 i nogle WAF'er).
• Maksimal længde af et individuelt argument (for eksempel 400 tegn).
• Den samlede kombinerede størrelse af alle argumenter (f.eks. 64.000 bytes).

Disse værdier er rimelige for mange applikationer, men der er tilfælde – komplekse formularuploads, avancerede filtre, store JSON-indlæsninger – hvor falske positiver forekommer. I disse scenarier er den mest fornuftige tilgang at starte med at logge og tælle , gennemgå hvilke slutpunkter der overskrider grænserne, og kun justere for disse ruter i stedet for at ophæve alle grænser for hele webstedet.

Falske positiver: hvordan man opdager dem og ikke dør i forsøget

En falsk positiv er en legitim anmodning, som WAF identificerer som ondsindet og blokerer eller markerer som et angreb. De er uundgåelige, især når du har omfattende regelsæt som OWASP CRS aktiveret, men de kan administreres professionelt, så de ikke bliver en daglig hovedpine.

Opdagelse af falske positiver starter med en omhyggelig gennemgang af logfilerne . Dette involverer en undersøgelse af, hvilke anmodninger der blokeres, hvilken regel der udløser dem, og den kontekst, de forekommer i (URL, parametre, bruger, oprindelse osv.). Visuelle værktøjer og dashboards kan hjælpe med at identificere stigninger i 403-fejl eller usædvanlige mønstre.

En stærkt anbefalet tilgang, både af cloud-udbydere og ModSecurity-fællesskabet, er at bruge en simulerings- eller tælletilstand . I denne tilstand logger de regler, du vil teste, hvert match, men blokerer ikke. Dette giver dig mulighed for at se, for eksempel, hvor mange legitime anmodninger en ny SQLi-regel ville have blokeret, før du turde aktivere den i produktion.

Det er også en god idé at teste reglerne i et staging- eller præproduktionsmiljø , der modtager reel eller simuleret trafik. Værktøjer som OWASP ZAP eller trafikgengivelsesscripts kan hjælpe dig med at simulere legitime mønstre og kendte angreb for at teste WAF'ens adfærd.

Derudover er det afgørende at overveje den operationelle og omdømmemæssige indvirkning af falske positiver: betalingsafbrydelser, fejl i brugerregistreringen, kritiske API-kald, der fejler uden forklaring – alt sammen kan have en direkte omkostning i omsætning og brandimage. Et overskud af falske positiver overvælder også sikkerhedsteamet med advarsler, der ikke tilføjer værdi, hvilket gør det vanskeligt at identificere ægte hændelser.

Strategier til justering af regler og intelligent brug af registret

Håndtering af falske positiver handler ikke om at slå regler fra, indtil "alt fungerer", men om at finjustere WAF'en med kirurgisk præcision . Det er her, god praksis som følgende kommer i spil:

For det første skal du undgå at deaktivere regler globalt. Det er at foretrække at oprette meget specifikke undtagelser : udelukker kun regel-ID'et for en bestemt rute, for bestemte parametre eller for intern trafik. På denne måde forbliver du beskyttet i resten af ​​applikationen og vedligeholder nyttige logfiler.

For det andet, udnyt optællingstilstanden før blokering. Ved at aktivere nye regler i første omgang kun i logføringstilstand kan du måle, hvor mange legitime anmodninger der vil blive påvirket. Du kan supplere dette med advarsler i SIEM for hurtigt at opdage, om en regel genererer et unormalt antal matches.

For det tredje, integrer WAF'en med en SIEM eller centraliseret loggingplatform . Dette gør det nemmere at korrelere WAF-hændelser med andre indikatorer: usædvanlig systemaktivitet, massegodkendelsesfejl, mistænkelige konfigurationsændringer osv. Det hjælper også med at prioritere, hvilke regler der skal justeres først, baseret på hændelsernes alvorlighed og hyppighed.

For det fjerde skal du dokumentere alle ændringer: hvilken regel der blev finjusteret, for hvilket endpoint, under hvilken begrundelse og med hvilken dokumentation. Det kan være nyttigt at konsultere servermanualerne til dette. Denne dokumentation hjælper ikke kun med at opretholde intern kontrol, men den er også uvurderlig i sikkerhedsrevisioner og -gennemgange, hvor du vil demonstrere, at kontroller ikke deaktiveres let.

Automatisering, maskinlæring og adaptive regler i WAF

Efterhånden som applikationer vokser, og trafikken bliver mere kompleks, bliver det urealistisk at administrere WAF manuelt. Det er her, automatisering, avanceret loganalyse og i nogle tilfælde maskinlæring kommer i spil.

For det første giver integrationen med SIEM dig mulighed for at opbygge korrelationsregler og automatiserede svar : for eksempel, hvis et sæt IP'er gentagne gange udløser injektions- eller XSS-regler, kan du generere en automatisk handling for at tilføje disse IP'er til en midlertidig blokeringsliste eller styrke inspektionsniveauet.

For det andet inkorporerer nogle WAF'er maskinlæringstilstande , der observerer legitim trafik over en defineret periode. Baseret på disse data foreslår eller justerer de tærskler, mønstre og profiler af normal adfærd. Dette hjælper med at reducere falske positiver, når regler skifter til blokeringstilstand, og registrerer efterfølgende trafikafvigelser.

I forsknings- og laboratoriemiljøer er superviserede læringsteknikker blevet brugt til at træne modeller, der skelner mellem legitim og ondsindet trafik, og forfiner politikker, der derefter bruges i produktionen. Selvom det ikke er en mirakelkur, kan denne tilgang hjælpe med at afdække subtile mønstre , som klassiske signaturbaserede regler ikke let opdager.

Endelig giver kontinuerlig automatiseret testning (ved hjælp af værktøjer som OWASP ZAP, brugerdefinerede scripts eller CI/CD-pipelines) dig mulighed for at validere, at ændringer i WAF'en ikke ødelægger kritisk funktionalitet eller efterlader åbenlyse sårbarheder. Integration af disse tests i implementeringscyklussen gør sikkerhed til en naturlig del af udviklingsflowet snarere end en patch i sidste øjeblik.

Politikdesign pr. applikation og sortlister pr. tjeneste

I komplekse miljøer – for eksempel en hostingudbyder eller en internetudbyder – er en enkelt WAF-politik ikke nok, især når der er tale om skygge-IT . Det er almindeligt at have flere domæner eller applikationer bag den samme load balancer, hver med forskellige sikkerhedsbehov og trafikprofiler . Det er her, at design af tjenestespecifikke politikker og lister bliver afgørende.

Et illustrativt eksempel er en HTTP/S load balancing-funktion, der fungerer som en reverse proxy for flere websteder (f.eks. www.company1.com og www.company2.com) bag en enkelt virtuel IP-adresse. I dette scenarie kan WAF'en konfigureres til at evaluere værtsheaderen og kilde-IP-adressen, så snart anmodningen ankommer, selv før den når load balancing-modulet.

Logikken ville være nogenlunde sådan her: WAF'en kontrollerer, om kombinationen af ​​SERVER_NAME (Host) og klient-IP matcher en webstedsspecifik blackliste. Hvis IP'en er angivet som blokeret for www.company2.com, men ikke for www.company1.com, sendes et 403 Forbidden-svar kun i det første tilfælde. Den "rene" trafik sendes derefter til load balancing-modulet, som bestemmer, hvilken backend der betjener anmodningen.

Dette giver mulighed for at vedligeholde f.eks. domænespecifikke sortlister i stedet for en enkelt global liste for hele adgangspunktet. På logningsniveau registreres hver afvisning i syslog med detaljer som regel-ID, den matchede betingelse, URL'en, værten og klientens IP-adresse, hvilket letter efterfølgende analyse og udvidelse eller fejlfinding af disse lister.

Moralen i historien er, at jo mere segmenterede dine politikker er (efter applikation, efter miljø, efter brugertype), jo bedre kan du finde balancen mellem logføring og blokering: Du kan være meget streng på administrative portaler og noget mere fleksibel på informative websteder, for eksempel altid med beviser i loggene for, hvorfor hver beslutning blev truffet.

Ud over den klassiske WAF: WAAP- og API-beskyttelse

Trusselsbilledet har ikke stået stille. I dag er mange applikationer cloud-native, bruger mikroservicearkitekturer og eksponerer offentlige og private API'er , hvilket gør dem til primære mål for angribere. Traditionelle WAF'er har udviklet sig til bredere platforme kendt som WAAP (Web Application and API Protection) eller WAAS (Web Application & API Security).

Disse løsninger registrerer ikke kun automatisk webapplikationer, men identificerer også API-slutpunkter , accepterer specifikationer som OpenAPI eller Swagger og bruger denne definition til at kontrollere anmodningers overholdelse af regler: forventede datatyper, tilladte parametre, størrelsesgrænser osv. Afhængigt af slutpunktet (for eksempel et, der håndterer meget følsomme data) kan der anvendes et meget højere niveau af kontrol og blokering.

På logningsniveau har WAAP en tendens til at generere kontekstrige hændelser : hvilket præcist API-slutpunkt der blev angrebet, hvilken operation (GET, POST, PUT…), hvilken bruger eller token der var involveret, hvilken del af specifikationen der blev overtrådt osv. Dette giver mulighed for mere præcise blokeringsbeslutninger i stedet for udelukkende at stole på generiske nyttelastmønstre.

Derudover inkluderer mange WAAP-værktøjer applikations- og API-specifik DoS-beskyttelse, geoplaceringsfiltrering, IP-omdømmehåndtering, bot- og scraping-detektion samt muligheder for at tilpasse alarmniveauer pr. tjeneste. Igen handler det om at have fleksibiliteten til at beslutte, hvor du ønsker en mere robust tilgang, og hvor du vil prioritere problemfri drift , uden at ofre en solid logdatabase til undersøgelse af eventuelle hændelser.

Samlet set bliver en velafstemt WAF – uanset om den er klassisk, WAAP-baseret eller integreret i et cloud-økosystem – en essentiel komponent i moderne applikations- og API-forsvar, der er i stand til at kombinere detaljeret logging, intelligent blokering og kontinuerlig tilpasning til det skiftende trusselslandskab.