Balanse mellom opptak og blokkering i WAF

Informatec Digital » Ressurser » Balanse mellom opptak og blokkering i WAF

Å finne den rette balansen mellom logging og blokkering i en WAF har blitt en av de vanligste hodepinene for sikkerhets- og driftsteam. En brannmur for nettapplikasjoner kan stoppe svært alvorlige angrep, men hvis den konfigureres for aggressivt, kan den blokkere legitime kjøp, tilgang eller API-kall. Hvis den konfigureres for løst, ender den opp med å være nesten utelukkende dekorativ. Nøkkelen er å nøye justere når man skal logge, når man skal telle, når man skal tillate og når man skal blokkere.

I denne artikkelen skal vi dykke ned i hvordan man oppnår denne balansen ved hjelp av moderne WAF-funksjoner (tillatelseslister, frekvensbaserte regler, læringsmoduser, SIEM-integrasjon, maskinlæring osv.), støttet av konkrete eksempler fra AWS WAF, ModSecurity, skybaserte WAF-er og lokale løsninger . Du vil se hvordan du begrenser falske positiver uten å senke beskyttelsesnivået, hvordan du organiserer policyer etter applikasjon, og hvordan du bruker logging som en alliert, ikke som en konstant, uhåndterlig kilde til støy.

Hva er en WAF, og hvorfor er registrering så viktig?

En brannmur for webapplikasjoner fungerer som et intelligent lag mellom brukeren og serveren , og analyserer HTTP/HTTPS-trafikk i sanntid. I motsetning til en tradisjonell nettverksbrannmur, som overvåker porter og IP-adresser, går en WAF dypere inn i: URL-er, parametere, forespørselstekster, overskrifter, informasjonskapsler, HTTP-metoder og mer.

Dens oppgave er å oppdage og stoppe typiske lag 7-angrep : SQL-injeksjon, XSS, LFI/RFI, angrep mot tilgangskontroll, API-misbruk, aggressiv skraping, brute force og til og med visse DDoS-mønstre på applikasjonsnivå. For å gjøre dette er den avhengig av sett med regler, signaturer og sikkerhetspolicyer som kontinuerlig oppdateres.

Logging er den andre siden av saken. Hver WAF-beslutning – tillat, blokker eller bare tell – kan ledsages av en detaljert hendelse i loggene . Disse loggene tillater:

• Undersøk hendelserrekonstruere hva som skjedde og hvordan det ble gjort et forsøk på å utnytte en sårbarhet.
• Juster reglerOppdag falske positiver ved å se hvilke legitime forespørsler WAF blokkerer.
• Overhold regelverketdemonstrer at det finnes aktive kontroller (PCI DSS, GDPR, interne revisjoner osv.).
• Mating av en SIEMKorreler applikasjonsangrep med nettverks-, system-, identitets- osv. hendelser.

Problemet er at en dårlig innstilt WAF kan fylle logger med tusenvis av irrelevante hendelser , noe som gjør det umulig å finne det som er viktig, og i tillegg forårsaker det uberettigede avvisninger av legitim trafikk. Det er her kunsten å leke med logging, telling og blokkeringsmoduser kommer inn i bildet.

Sikkerhetsmodeller i WAF: blokkeringslister, tillatelseslister og en hybrid tilnærming

De fleste moderne WAF-er kombinerer flere filtreringsmetoder, noe som direkte påvirker hvordan forespørsler logges og blokkeres . Grovt sett kan vi identifisere to klassiske filosofier, pluss en veldig vanlig hybridmodell.

En blokkeringslistebasert WAF følger en negativ sikkerhetsmodell. Kjerneprinsippet er: «Jeg tillater alt unntatt det jeg vet er skadelig.» Den fungerer ved å bruke signaturer fra kjente angrep (SQL-injeksjon, XSS, botmønstre osv.) og regler som definerer hva som anses som mistenkelig. Den er enklere å distribuere i utgangspunktet, men å stole utelukkende på denne modellen risikerer å la nye angrepsvektorer eller varianter slippe gjennom uoppdaget.

En WAF med en tillatelsesliste fungerer på motsatt måte: «blokker alt unntatt det som er eksplisitt tillatt». Den er basert på en positiv sikkerhetsmodell. Bare trafikk som passer til den definerte legitime oppførselen – ruter, metoder, parametere, formater, størrelser osv. – aksepteres. Den er mye sikrere, men krever betydelig finjustering og kan generere falske positiver i utgangspunktet hvis den ikke er riktig forberedt.

På grunn av fordelene og ulempene med hver tilnærming blir en hybridmodell som kombinerer tillatelseslister og blokkeringslister stadig mer vanlig . I dette scenariet defineres forventede trafikkprofiler (for eksempel hva som utgjør en vanlig pålogging eller betalingsforespørsel), og signaturer og heuristikker brukes samtidig for å oppdage typiske ondsinnede mønstre. For loggingsformål tillater denne hybridtilnærmingen:

• Merk som høyrisikohendelse det som bryter med listen over tillatte varer.
• Behandle som varsler med middels/lav prioritet generelle blokkeringslistemønstre.
• Bruk «telle»-modusen for å se hva som ville bryte en regel før du aktiverer blokken.

WAF i nettverket, på verten og i skyen: innvirkning på logging og låsing

WAF-distribusjonsmodellen påvirker i stor grad hvordan trafikklogging og -blokkering håndteres. Logging av forespørsler på en nettverksenhet er ikke det samme som å logge dem på en agent i serveren eller på en administrert skytjeneste.

En nettverksbasert WAF distribueres vanligvis som en fysisk eller virtuell enhet i infrastrukturen, mellom internett og applikasjoner. Dette er den klassiske tilnærmingen som brukes av produsenter som F5. Den tilbyr fordelen med høy ytelse og detaljert kontroll , men konfigurasjon og administrasjon kan være kompleks. Logging sendes vanligvis til syslog eller en sentral SIEM, og det er viktig å filtrere nøye hva som lagres for å unngå overbelastning av lagrings- og analyseverktøy, og for å diagnostisere problemer i IP- og DNS-nettverk.

Vertsbaserte WAF- er kjører på de samme serverne (eller containerne) der applikasjonen befinner seg, vanligvis som en modul eller agent (for eksempel ModSecurity integrert i Nginx eller Apache; å kombinere det med Linux-herding ved hjelp av SELinux forbedrer sikkerhetstilstanden). Denne modellen gir mulighet for bedre applikasjonskontekst og svært spesifikke regler per tjeneste, på bekostning av å forbruke lokale ressurser og kreve mer distribuert logghåndtering. Logger kan lagres i lokale filer og deretter videresendes, eller integreres med sentraliserte loggføringstjenester.

Skybaserte WAF-er (Cloudflare, Akamai, Imperva Cloud, AWS WAF osv.) integreres med lastbalanserere, CDN-er eller virtuelle nettverk. Leverandører tilbyr vanligvis dashbord og loggeksport til S3, BigQuery, eksterne syslogger eller SIEM-er. De er generelt enklere å sette opp, men du må tilpasse loggføringsreglene dine til leverandørens modell: hendelsestyper, oppbevaringsperioder, alvorlighetsfiltre osv.

Å velge den ene eller den andre modellen er ikke bare en teknisk avgjørelse, men også et spørsmål om hvordan du vil balansere logging og låsing: en skybasert tjeneste forenkler mange aspekter, men du ønsker kanskje absolutt kontroll over hvor logger lagres på grunn av samsvars- eller konfidensialitetspolicyer, noe som presser deg mot lokale eller hybride modeller.

Vilkår, regler og web-ACL-er: hvordan WAF bestemmer om den skal blokkere, tillate eller bare registrere

Uavhengig av produsent er alle moderne WAF-er basert på konseptet med tilgangsbetingelser, regler og retningslinjer . Å forstå dette er nøkkelen til å kunne bruke telle-, loggførings- og låsemoduser i produksjonen.

Betingelsene beskriver hvilken del av forespørselen som inspiseres: kilde-IP, spesifikke HTTP - overskrifter (Host, User-Agent, Accept, Content-Type…), spørreparametere, forespørselstekst, informasjonskapsler, HTTP-metode, opprinnelsesland osv. I AWS WAF Classic kan du for eksempel definere en IP-betingelse med opptil 10 000 adresser eller områder, eller en strengsamsvarsbetingelse på en del av URL-en.

Regler kombinerer én eller flere betingelser og tilordner en intensjon: å tillate, blokkere eller telle. Når en regel har flere betingelser, evalueres de vanligvis med et logisk OG : alle betingelser må være oppfylt for at regelen skal aktiveres. En vanlig regel uten betingelser samsvarer i praksis ikke med noe, og handlingen utløses aldri.

Mange WAF-er, inkludert AWS WAF, har også hastighetsbaserte regler . Disse reglene teller forespørslene som kommer fra en IP-adresse (eller et sett med IP-adresser som oppfyller visse betingelser) i løpet av et tidsvindu, for eksempel fem minutter. Hvis en terskel overskrides – for eksempel 1.000 forespørsler på fem minutter – trer regelen i kraft: blokkering eller rett og slett telling. Dette er veldig nyttig for:

• kontroll brute force på innloggingsskjemaer.
• Begrens aggressiv skraping eller frekke roboter.
• Begrense visse typer DDoS-angrep på applikasjonsnivå.

Det neste nivået er Web ACL (Access Control List) . Her grupperes reglene, og en evalueringsrekkefølge og en standardhandling (TILLAT eller BLOKKER) defineres. En forespørsel går gjennom reglene i rekkefølge; hvis den samsvarer med én, brukes handlingen, og evalueringen av resten stoppes. Hvis den ikke samsvarer med noen regler, brukes standardhandlingen som er definert i ACL-en.

Når det gjelder å balansere logging og blokkering, er det i tilgangskontrollisten (ACL) du bestemmer om du vil at systemet skal være tillatende som standard (TILLATE og blokkering kun etter spesifikke regler) eller svært restriktivt (BLOKKERE unntatt i unntakstilfeller). Videre lar mange løsninger deg angi regler i "tellemodus" i tilgangskontrollisten, slik at de logger treff, men ikke blokkerer trafikk – ideelt for finjusteringsfasen.

Hvitelister og støyreduksjon i logger

Tillatelseslister er et grunnleggende verktøy for å redusere falske positiver og støy i loggen . Ideen er enkel: i visse sammenhenger ber du WAF om ikke å bruke et direktiv eller et sett med regler på spesifikk trafikk som du allerede har kategorisert som klarert, eller som du vet er utenfor normen, men legitim.

I AWS WAF kan du for eksempel opprette tillatelseslisteregler slik at visse signaturinspeksjoner ikke brukes hvis en forespørsel kommer fra en bestemt IP-adresse eller et bestemt IP-område , eller hvis den samsvarer med et kjent URL-mønster og HTTP-metode. Dette bidrar til å:

• Forhindre interne API-er som bruker «rare» mønstre genererer konstante falske positiver.
• Reduser latensen som introduseres av dyp inspeksjon i trafikk du allerede anser som pålitelig.
• Reduser volumet av unødvendige poster i WAF-loggene.

På plattformer som ModSecurity er den anbefalte tilnærmingen ikke å endre standardregler (f.eks. OWASP Core Rule Set), men snarere å opprette spesifikke ekskluderinger etter regel-ID for bestemte parametere, stier eller brukere. Dette lar deg opprettholde generell beskyttelse uten å skape store sårbarheter ved å deaktivere hele regler på tvers av nettstedet.

Nøkkelen er å gjøre tillatelseslistene kirurgiske , ikke en generell tilnærming. Det er mye bedre å ekskludere en spesifikk kombinasjon (regel X + parameter Y i URL Z) enn å deaktivere regel X globalt. På den måten forblir loggføringen nyttig, og du skaper ikke unødvendige blindsoner.

Protokollregler og grenser: når man skal blokkere, når man skal advare

Mange WAF-er inneholder et sett med HTTP-protokollsaneringsregler som fungerer som et første filter for feilformet eller mistenkelig trafikk . Disse reglene sjekker nødvendige overskrifter, metoder, argumentstørrelser osv., og er en hyppig kilde til både god beskyttelse og falske positiver hvis de ikke forstås riktig.

Noen veldig vanlige eksempler:

• Mangler Godta-overskrift (Mangler Godta-header): Dette er ikke strengt tatt et RFC-brudd, men mange forespørsler uten denne headeren kommer fra automatiserte verktøy eller dårlig skrevne skript. Det kan påvirke tilpassede API-er eller klienter som ikke sender den. I mange miljøer foretrekkes logging og telling fremfor direkte blokkering.
• Manglende vertsoverskriftI henhold til HTTP/1.1-standarder er Host-headeren obligatorisk. WAF-er trenger den også for å bestemme hvilken policy som skal brukes. Blokkering her er vanligvis rimelig, men det kan generere falske positiver under testing eller på grunn av feilkonfigurert intern trafikk. Det anbefales å overvåke loggene før streng blokkering aktiveres.
• Manglende brukeragent-headerDenne regelen forsøker å begrense rudimentære roboter og uidentifisert trafikk. Problemet er at mange legitime API-er kanskje ikke sender en brukeragent. Den mest fornuftige tilnærmingen er vanligvis å logge, og hvis et konsistent og legitimt API oppdages, legge til IP-adressen eller mønsteret deres i en tillatelsesliste.
• GET/HEAD-validering med brødtekstSelv om RFC ikke strengt forbyr å sende innholdet med GET- eller HEAD-forespørsler, er det ikke vanlig praksis og kan tyde på unnvikelsesforsøk. I mange tilfeller er et første trinn å logge alle disse forespørslene, og hvis de viser seg å være mistenkelige avvik, fortsette å blokkere dem.
• Mangler innholdstype med brødtekstHvis det finnes en brødtekst, men ingen Content-Type, er det en klar indikasjon på feil protokollbruk eller et forsøk på å unngå analyse. I slike tilfeller er det vanligvis fornuftig med en mer aggressiv blokkeringsmetode, spesielt i internettvendte miljøer.

I tillegg til disse protokollreglene, finnes det ofte argumentgrenser som beskytter mot oversvømmelser på applikasjonsnivå og DoS-angrep. For eksempel:

• Maksimalt antall argumenter per forespørsel (som standard 255 i noen WAF-er).
• Maksimal lengde på et enkelt argument (for eksempel 400 tegn).
• Total kombinert størrelse for alle argumenter (for eksempel 64 000 byte).

Disse verdiene er rimelige for mange applikasjoner, men det finnes tilfeller – komplekse skjemaopplastinger, avanserte filtre, store JSON-innlastinger – der falske positiver oppstår. I slike scenarier er den mest fornuftige tilnærmingen å starte med å logge og telle , gjennomgå hvilke endepunkter som bryter grensene, og justere bare for disse rutene, i stedet for å oppheve alle grensene for hele nettstedet.

Falske positiver: hvordan oppdage dem og ikke dø i forsøket

En falsk positiv er en legitim forespørsel som WAF identifiserer som ondsinnet og blokkerer eller flagger som et angrep. De er uunngåelige, spesielt når du har omfattende regelsett som OWASP CRS aktivert, men de kan håndteres profesjonelt slik at de ikke blir en daglig hodepine.

Å oppdage falske positiver starter med en nøye gjennomgang av loggene . Dette innebærer å undersøke hvilke forespørsler som blokkeres, hvilken regel som utløser dem, og konteksten de oppstår i (URL, parametere, bruker, opprinnelse osv.). Visuelle verktøy og dashbord kan bidra til å identifisere topper i 403-feil eller uvanlige mønstre.

En sterkt anbefalt tilnærming, både av skyleverandører og ModSecurity-fellesskapet, er å bruke en simulerings- eller tellemodus . I denne modusen logger reglene du vil teste hvert treff, men blokkerer ikke. Dette lar deg for eksempel se hvor mange legitime forespørsler en ny SQLi-regel ville blokkere før du tør å aktivere den i produksjon.

Det er også lurt å teste reglene i et oppsetnings- eller preproduksjonsmiljø som mottar ekte eller simulert trafikk. Verktøy som OWASP ZAP eller trafikkavspillingsskript kan hjelpe deg med å simulere legitime mønstre og kjente angrep for å teste WAF-ens oppførsel.

Videre er det avgjørende å vurdere den driftsmessige og omdømmemessige effekten av falske positiver: betalingsavbrudd, feil i brukerregistreringen, kritiske API-kall som mislykkes uten forklaring – alt dette kan ha en direkte kostnad i inntekter og merkevareimage. Et overskudd av falske positiver overvelder også sikkerhetsteamet med varsler som ikke tilfører verdi, noe som gjør det vanskelig å identifisere ekte hendelser.

Strategier for å justere regler og intelligent bruk av registeret

Å håndtere falske positiver handler ikke om å slå av regler før «alt fungerer», men om å finjustere WAF med kirurgisk presisjon . Det er her gode fremgangsmåter som følgende kommer inn i bildet:

Først bør du unngå å deaktivere regler globalt. Det er å foretrekke å opprette svært spesifikke unntak : ekskluder regel-ID-en bare for en bestemt rute, for visse parametere eller for intern trafikk. På denne måten forblir du beskyttet i resten av applikasjonen og vedlikeholder nyttige logger.

For det andre, dra nytte av tellemodus før blokkering. Ved å aktivere nye regler i utgangspunktet bare i loggmodus kan du måle hvor mange legitime forespørsler som vil bli påvirket. Du kan supplere dette med varsler i SIEM for raskt å oppdage om en regel genererer et unormalt antall treff.

For det tredje, integrer WAF med en SIEM eller sentralisert loggføringsplattform . Dette gjør det enklere å korrelere WAF-hendelser med andre indikatorer: uvanlig systemaktivitet, massegodkjenningsfeil, mistenkelige konfigurasjonsendringer osv. Det hjelper også med å prioritere hvilke regler som skal justeres først basert på alvorlighetsgraden og hyppigheten av hendelsene.

For det fjerde, dokumenter alle endringer: hvilken regel som ble finjustert, for hvilket endepunkt, under hvilken begrunnelse og med hvilke bevis. Det kan være nyttig å konsultere serverhåndbøkene for dette. Denne dokumentasjonen bidrar ikke bare til å opprettholde intern kontroll, men den er også uvurderlig i sikkerhetsrevisjoner og -gjennomganger, der du vil demonstrere at kontroller ikke deaktiveres lettvint.

Automatisering, maskinlæring og adaptive regler i WAF

Etter hvert som applikasjoner vokser og trafikken blir mer kompleks, blir det urealistisk å administrere WAF manuelt. Det er her automatisering, avansert logganalyse og i noen tilfeller maskinlæring kommer inn i bildet.

For det første lar integrasjonen med SIEM deg bygge korrelasjonsregler og automatiserte svar : for eksempel, hvis et sett med IP-er gjentatte ganger utløser injeksjons- eller XSS-regler, kan du generere en automatisk handling for å legge til disse IP-ene i en midlertidig blokkeringsliste eller styrke inspeksjonsnivået.

For det andre bruker noen WAF-er maskinlæringsmoduser som observerer legitim trafikk over en definert periode. Basert på disse dataene foreslår eller justerer de terskler, mønstre og profiler av normal atferd. Dette bidrar til å redusere falske positiver når regler settes i blokkeringsmodus og oppdager påfølgende trafikkavvik.

I forsknings- og laboratoriesammenheng har veiledede læringsteknikker blitt brukt til å trene modeller som skiller mellom legitim og ondsinnet trafikk, og forbedrer retningslinjer som deretter brukes i produksjon. Selv om det ikke er en magisk løsning, kan denne tilnærmingen bidra til å avdekke subtile mønstre som klassiske signaturbaserte regler ikke lett oppdager.

Til slutt lar kontinuerlig automatisert testing (ved hjelp av verktøy som OWASP ZAP, tilpassede skript eller CI/CD-pipelines) deg validere at endringer i WAF ikke ødelegger kritisk funksjonalitet eller etterlater åpenbare sårbarheter. Integrering av disse testene i distribusjonssyklusen gjør sikkerhet til en naturlig del av utviklingsflyten, snarere enn en oppdatering i siste liten.

Policydesign per applikasjon og svartelister per tjeneste

I komplekse miljøer – for eksempel en hostingleverandør eller en internettleverandør – er ikke én WAF-policy nok, spesielt når skygge-IT er involvert . Det er vanlig å ha flere domener eller applikasjoner bak samme lastfordeler, hver med forskjellige sikkerhetsbehov og trafikkprofiler . Det er her det blir viktig å utforme tjenestespesifikke policyer og lister.

Et illustrerende eksempel er en HTTP/S-lastbalanserer som fungerer som en omvendt proxy for flere nettsteder (f.eks. www.company1.com og www.company2.com) bak én virtuell IP-adresse. I dette scenariet kan WAF konfigureres til å evaluere vertsheaderen og kilde-IP-adressen så snart forespørselen kommer, selv før den når lastbalanseringsmodulen.

Logikken ville være omtrent slik: WAF sjekker om kombinasjonen av SERVER_NAME (vert) og klient-IP samsvarer med en nettstedsspesifikk svarteliste. Hvis IP-adressen er oppført som blokkert for www.company2.com, men ikke for www.company1.com, sendes et 403 Forbidden-svar bare i det første tilfellet. Den "rene" trafikken sendes deretter til lastbalanseringsmodulen, som bestemmer hvilken backend som betjener forespørselen.

Dette gjør det mulig å vedlikeholde for eksempel domenespesifikke svartelister , i stedet for én global liste for hele tilgangspunktet. På loggføringsnivå registreres hver avvisning i sysloggen med detaljer som regel-ID, samsvarende betingelse, URL-adresse, vert og klientens IP-adresse, noe som letter senere analyse og utvidelse eller feilsøking av disse listene.

Moralen i historien er at jo mer segmenterte retningslinjene dine er (etter applikasjon, miljø, brukertype), desto bedre kan du finne balansen mellom logging og blokkering: du kan være veldig streng på administrative portaler og noe mer fleksibel på informasjonsnettsteder, for eksempel, alltid med bevis i loggene for hvorfor hver beslutning ble tatt.

Utover den klassiske WAF: WAAP- og API-beskyttelse

Trussellandskapet har ikke stått stille. I dag er mange applikasjoner skybaserte, bruker mikrotjenestearkitekturer og eksponerer offentlige og private API-er , noe som gjør dem til primære mål for angripere. Tradisjonelle WAF-er har utviklet seg til bredere plattformer kjent som WAAP (Web Application and API Protection) eller WAAS (Web Application & API Security).

Disse løsningene oppdager ikke bare webapplikasjoner automatisk, men identifiserer også API-endepunkter , godtar spesifikasjoner som OpenAPI eller Swagger, og bruker denne definisjonen til å kontrollere samsvar med forespørsler: forventede datatyper, tillatte parametere, størrelsesgrenser osv. Avhengig av endepunktet (for eksempel et som håndterer svært sensitive data), kan et mye høyere nivå av gransking og blokkering brukes.

På loggføringsnivået har WAAP en tendens til å generere kontekstrike hendelser : hvilket nøyaktig API-endepunkt som ble angrepet, hvilken operasjon (GET, POST, PUT…), hvilken bruker eller token som var involvert, hvilken del av spesifikasjonen som ble brutt, osv. Dette gir mulighet for mer presise blokkeringsbeslutninger, i stedet for å bare stole på generiske nyttelastmønstre.

Videre inkluderer mange WAAP-verktøy applikasjons- og API-spesifikk DoS-beskyttelse, geolokasjonsfiltrering, IP-omdømmehåndtering, bot- og skrapingsdeteksjon og alternativer for å tilpasse varslingsnivåer per tjeneste. Igjen handler det om å ha fleksibiliteten til å bestemme hvor du ønsker en mer robust tilnærming og hvor du vil prioritere problemfri drift , uten å ofre en solid loggdatabase for å undersøke eventuelle hendelser.

Samlet sett blir en godt innstilt WAF – enten klassisk, WAAP-basert eller integrert i et skyøkosystem – en essensiell komponent i moderne applikasjons- og API-forsvar, i stand til å kombinere detaljert logging, intelligent blokkering og kontinuerlig tilpasning til det skiftende trussellandskapet.