Balance mellem optagelse og blokering i WAF

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

Find balancen mellem registrering og låsning i en WAF Det 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 på AWS WAF, ModSecurity, cloud WAF og on-premise løsningerDu vil se, hvordan du begrænser falske positiver uden at sænke beskyttelsesniveauet, hvordan du organiserer politikker efter applikation, og hvordan du bruger registreringsdatabasen som en allieret, ikke som en konstant, uhåndterlig støj.

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

En webapplikationsfirewall fungerer som en intelligent lag mellem brugeren og serverenAnalyse af HTTP/HTTPS-trafik i realtid. I modsætning til en traditionel netværksfirewall, som kun ser på porte og IP-adresser, går en WAF i detaljer: URL'er, parametre, anmodningstekster, headere, cookies, HTTP-metoder osv.

Deres mission er opdage og stoppe typiske lag 7-angrebSQL-injektion, XSS, LFI/RFI, adgangskontrolangreb, API-misbrug, aggressiv scraping, brute force og endda visse DDoS-mønstre på applikationsniveau er alle beskyttet mod disse angreb. Dette opnås gennem konstant opdaterede sæt af regler, signaturer og sikkerhedspolitikker.

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 logfilerneDisse optegnelser 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 loggene med tusindvis af irrelevante begivenhederhvilket gør det umuligt at finde det vigtige, og oven i købet forårsager det uberettigede afvisninger af legitim trafik. Det er her, kunsten at manipulere registrerings-, optællings- og blokeringsmetoder kommer ind i billedet.

Sikkerhedsmodeller i WAF: blokeringslister, tilladelseslister og en hybrid tilgang

De fleste moderne WAF'er kombinerer flere filtreringsmetoder, hvilket har direkte indflydelse på hvordan anmodninger logges og blokeresGenerelt kan vi tale om to klassiske filosofier plus en meget almindelig blandet model.

En WAF baseret på blokliste Den følger en negativ sikkerhedsmodel. Dens idé er: "Jeg tillader alt undtagen det, jeg ved er dårligt." Den fungerer baseret på 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 du udelukkende stoler på denne model, risikerer du nye vektorer eller varianter af angreb glide ind uopdaget.

En WAF af tilladelsesliste Det er det stik modsatte: "bloker alt undtagen det, der er eksplicit tilladt." Det 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 begyndelsen hvis den ikke er ordentligt tilberedt.

På grund af fordele og ulemper ved hver tilgang bliver en enkelt model mere og mere almindelig. hybrid af tilladelsesliste + blokeringslisteI dette scenarie defineres forventede trafikprofiler (for eksempel hvad der udgør et normalt login eller en betalingsanmodning), og samtidig anvendes signaturer og heuristikker for at detektere typiske ondsindede mønstre. Til logføringsformål tillader den hybride tilgang:

• 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 WAF netværksbaseret Det implementeres typisk som en fysisk eller virtuel enhed i infrastrukturen, mellem internettet og applikationer. Dette er den klassiske tilgang hos producenter som F5. Det har den fordel, at det tilbyder høj ydeevne og granulær kontrolKonfiguration og administration kan dog være kompleks. Logfiler sendes typisk til syslog eller en central SIEM, og det er vigtigt omhyggeligt at filtrere, hvad der gemmes, for at undgå overbelastning af lagerplads, analyseværktøjer og diagnosticering. IP- og DNS-netværksproblemer.

WAF værtsbaseret Den kører på de samme servere (eller containere), hvor applikationen befinder sig, normalt som et modul eller en agent (for eksempel ModSecurity integreret i Nginx eller Apache; kombineret med Linux-hærdning med SELinux (forbedrer sikkerhedsstillingen). Denne model giver dig mulighed for at have Mere applikationskontekst og meget specifikke regler pr. tjeneste, på bekostning af et forbrug af lokale ressourcer og krav om mere distribueret logstyring. De kan gemmes i lokale filer og derefter videresendes eller integreres med centraliserede logtjenester.

WAF i skyen (Cloudflare, Akamai, Imperva Cloud, AWS WAF osv.) integrerer med load balancers, CDN'er eller virtuelle netværk. Her tilbyder udbyderen typisk paneler, dashboards og logeksport til S3, BigQuery, fjernsystemlog eller SIEM. Det er normalt nemmere at aktivere, men du skal tilpasse dine logføringspolitikker til udbyderens model: hændelsestyper, opbevaring, alvorlighedsfiltre osv.

At vælge én model frem for en anden er ikke kun en teknisk beslutning; det afhænger også af, hvordan du vil balancere logning og blokering. En cloud-administreret tjeneste forenkler mange aspekter, men du vil måske... absolut kontrol over, hvor logfilerne gemmes på grund af compliance- eller fortrolighedspolitikker, hvilket skubber hen imod 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å ideen om betingelser, regler og adgangspolitikkerAt forstå dette er nøglen til at eksperimentere med optællings-, logførings- og låsetilstande uden at ødelægge tingene i produktionen.

den condiciones De 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.

den regler De kombinerer en eller flere betingelser og tildeler en intention: tillad, bloker eller tæl. Når en regel har flere betingelser, evalueres de normalt med en logisk OGAlle betingelser skal være opfyldt for at reglen kan aktiveres. En normal regel uden betingelser matcher i praksis ikke noget, og dens handling udløses aldrig.

Mange WAF'er, herunder AWS WAF, har også satsbaserede reglerDisse regler tæller anmodninger, der kommer fra en IP-adresse (eller et sæt af 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 simpelthen. 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 (adgangskontrolliste)Her grupperes reglerne, og en evalueringsrækkefølge og en standardhandling (TILLAD eller BLOKER) defineres. En anmodning gennemgår reglerne i rækkefølge; hvis den matcher en, anvendes dens handling, og evalueringen af ​​resten stoppes. Hvis den ikke matcher nogen, anvendes den standardhandling, der er defineret i ACL'en.

Med hensyn til balancen mellem logføring og låsning, er ACL'en der, hvor du bestemmer, om systemet som standard skal bruge logføring. være tilladende (tillad og bloker kun ved specifikke regler) eller meget restriktive (BLOKER undtagen i visse tilfælde). Derudover giver mange løsninger dig mulighed for at indstille regler i "tællingstilstand" i ACL'en, så de registrerer matches, men ikke blokerer trafik, ideelt til tuningfasen.

Hvidlister og støjreduktion i logfiler

Tilladelseslister er et grundlæggende værktøj til reducere falske positiver og støj i optagelsenIdeen 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 som er legitim.

For eksempel kan du i AWS WAF oprette regler for tilladelseslister, så hvis anmodningen kommer fra en IP-adresse eller specifikt intervalEller, hvis det matcher et kendt URL-mønster og HTTP-metode, anvendes visse signaturinspektioner ikke. 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 standardreglerne (f.eks. OWASP Core Rule Set), men at oprette specifikke udelukkelser efter regel-ID for specifikke parametre, ruter eller brugere. Dette giver mulighed for at opretholde den overordnede beskyttelse uden at skabe store sårbarheder ved at deaktivere alle regler for hele webstedet.

Nøglen er, at de tilladte lister er kirurgiskIkke en drastisk foranstaltning. 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 første misdannede eller mistænkelige trafikfilterDisse regler gennemgår obligatoriske overskrifter, metoder, argumentstørrelser osv., og er en hyppig kilde til både god beskyttelse og falske positiver, hvis de ikke er godt forstået.

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 er det almindeligt at finde grænser for argumenter 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 start med at registrere og tælleGennemgå hvilke slutpunkter der overskrider grænserne, og juster kun 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 om, at WAF identificerer sig som ondsindet og blokerer eller markerer som et angreb. De er uundgåelige, især når du aktiverer brede regelsæt som OWASP CRS, men de kan håndteres professionelt, så de ikke bliver en daglig hovedpine.

Opdagelsen af ​​falske positiver starter med en omhyggelig observation af logfilerneGennemgå hvilke anmodninger der blokeres, hvilken regel der udløser dem, og i hvilken kontekst (URL, parametre, bruger, oprindelse osv.). Visuelle værktøjer og dashboards hjælper 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 simuleringstilstand eller tælletilstandI denne tilstand logger de regler, du vil teste, hvert match, men blokerer ikke. Dette giver dig mulighed for at se, 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 afprøve reglerne i en 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 Finjuster WAF'en med en skalpelDet er her, at gode fremgangsmåder som følgende kommer i spil:

Først og fremmest skal du undgå at deaktivere regler globalt. Det er at foretrække at oprette meget specifikke undtagelserUdeluk 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 modo de conteo Før blokering kan du måle, hvor mange legitime anmodninger der vil blive påvirket, hvis du aktiverer nye regler i logføringstilstand. Du kan supplere dette med SIEM-advarsler for hurtigt at opdage, om en regel genererer et unormalt antal matches.

For det tredje, integrer WAF'en med en SIEM eller centraliseret loggingplatformDette 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, dokumenter hver ændring: hvilken regel der er blevet forfinet, for hvilket effektpunkt, under hvilken begrundelse, og med hvilken dokumentation. Se i den forbindelse server manualer guide Denne dokumentation kan være nyttig. Den hjælper ikke kun med at opretholde intern kontrol, men den er også uvurderlig i forbindelse med revisioner og sikkerhedsgennemgange, hvor du vil demonstrere, at... Kontrollerne deaktiveres ikke let.

Automatisering, maskinlæring og adaptive regler i WAF

Efterhånden som applikationerne vokser, og trafikken bliver mere kompleks, bliver det urealistisk at administrere WAF manuelt. Det er her, Automatisering, avanceret loganalyse og i nogle tilfælde brugen af ​​maskinlæring.

For det første muliggør integration med SIEM opbygning af korrelationsregler og automatiserede svarHvis et sæt IP-adresser f.eks. gentagne gange udløser injektions- eller XSS-regler, kan der genereres en automatiseret handling for at tilføje disse IP-adresser til en midlertidig blokeringsliste eller styrke inspektionsniveauet.

For det andet inkorporerer nogle WAF'er maskinlæringstilstande (læringstilstand), der observerer legitim trafik over en defineret periode. Baseret på disse data foreslår eller justerer den 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 til at skelne mellem legitim og ondsindet trafik og forfine politikker, der derefter bruges i produktionen. Selvom det ikke er en magisk løsning, kan denne tilgang hjælpe. opdage subtile mønstre som klassiske signaturbaserede regler ikke let opdager.

Endelig kontinuerlig automatiseret testning (Ved hjælp af værktøjer som OWASP ZAP, brugerdefinerede scripts eller CI/CD-pipelines) kan du 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, der passer til alle, ikke tilstrækkelig, især når der er IT i skyggerneDet er almindeligt at have flere domæner eller applikationer bag den samme load balancer, hver med forskellige sikkerhedsbehov og trafikprofilerDet er her, at det giver mening at designe servicespecifikke politikker og lister.

Et illustrativt eksempel er en HTTP/S load balancer, der fungerer som omvendt proxy til flere websteder (for eksempel www.company1.com og www.company2.com) bag en enkelt virtuel IP-adresse. I dette scenarie er det muligt at konfigurere WAF'en, så snart anmodningen ankommer, evalueres værtsheaderen og kilde-IP'en, selv før de indtastes i load balancing-modulet.

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

Dette giver dig mulighed for at vedligeholde f.eks. sortlister efter domæneI stedet for en global liste for hele adgangspunktet logges 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 været statisk. I dag er mange applikationer cloud-native, bruger mikroservicearkitekturer og eksponerer Offentlige og private API'er som bliver det primære mål for angribere. Den traditionelle WAF har udviklet sig til bredere platforme kendt som WAAP (Web Application and API Protection) eller WAAS (Web Application & API Security).

Disse løsninger opdager ikke kun automatisk webapplikationer, men også Identificér API-slutpunkterDe 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 endpointen (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 begivenheder mere kontekstrigDette giver mulighed for mere præcise blokeringsbeslutninger i stedet for udelukkende at stole på generiske nyttelastmønstre. Disse oplysninger kan bruges til at bestemme det nøjagtige API-slutpunkt, der blev angrebet, den specifikke involverede operation (GET, POST, PUT osv.), den involverede bruger eller token, den del af specifikationen, der blev overtrådt, og så videre.

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 bestemme. hvor du ønsker en fast hånd, og hvor du ønsker at prioritere flydendeuden at ofre et godt register til at undersøge enhver hændelse.

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 optagelse, intelligent låsning og kontinuerlig tilpasning til det skiftende trusselsbillede.