RELIANOID Web Application Firewall #

Web Application Firewall (WAF) fungerer som et afgørende værktøj til at identificere og forhindre ondsindet HTTP-trafik inden for HTTP(S)-farme. Ved at analysere mønstre håndhæver den avancerede sikkerhedspolitikker på organiserede regelsæt, som derefter anvendes på HTTP-farme. Efter dekryptering af SSL-pakker granskes WAF-reglerne, hvilket muliggør anvendelse af mønstre på HTTP-indholdet i SSL-trafikken.

RELIANOID IPDS pakken indeholder OWASP ModSecurity Core-regelsæt, forudinstalleret og klar til brug, mens brugerne bevarer fleksibiliteten til at oprette brugerdefinerede regelsæt for omfattende systembeskyttelse mod forskellige angreb. For at udforske yderligere detaljer om OWASP-regler kan brugerne henvise til OWASP Modsecurity Project. Derudover er det værd at bemærke, at RELIANOID WAF-modulet udvider sin funktionalitet ud over HTTP-beskyttelse til at omfatte avanceret HTTP-indholdsmanipulation, herunder omdirigeringer og omskriver.

Visning af WAF-regelsæt #

WAF-regelsætvisningen viser en oversigt over de tilgængelige regelsæt og de tildelte farm-tjenester:

NavnEt beskrivende navn til at identificere et regelsæt. Klik på det for at åbne redigeringsformularen.
GårdeDe gårde, som reglen gælder for. Du kan udvide listen over gårde ved hjælp af en pil opad, der er placeret ved siden af GÅRDE kolonneoverskriften til højre. Som standard er den begrænset til 20 tegn.
STATUSRegelsættets status er repræsenteret af følgende statusfarvekoder:

• Grøn. Midler AKTIVERETRegelsættet bliver kontrolleret for de gårde, der bruger det.
• Rød. Midler DEAKTIVERETRegelsættet er ikke aktiveret, og har derfor ingen effekt på gården.

Handlinger . Tilladte handlinger for status for WAF-reglerne:

• RedigereRediger regelsætindstillingerne, eller tildel en farm-tjeneste, hvis det er nødvendigt.
• GenstartGeninitialiser en WAF-regel.
• StartenAnvend WAF-regelsættet.
• SletteFjern et regelsæt.

Forståelse af OWASP CRS-regelsættet #

OWASP CRS- regelsættene omfatter generiske angrebsdetektionsregler, der tilbyder et grundlæggende beskyttelsesniveau for enhver webapplikation.

Driftsformer #

De forudindlæste OWASP CRS-regelsæt fungerer i to tilstande:

Anomaliscoringstilstand (standard): Denne tilstand anbefales på grund af dens nøjagtige logoplysninger og fleksible blokeringspolitikker. Den kaldes også "samarbejdsbaseret detektionstilstand" og tildeler en "anomaliscore" til hver matchende regel. Ved afslutningen af ​​evalueringer af indgående og udgående regler udløser anomaliscoren blokeringshandlinger, hvilket typisk resulterer i en standard 403-fejl.

Selvstændig tilstand : Denne tilstand anvender handlinger øjeblikkeligt. Samtidig med at den reducerer ressourceforbruget, ofrer den fleksibiliteten i blokeringspolitikker og detaljerede revisionslogfiler (kun den første registrerede trussel logges). Regler følger den forstyrrende handling, du angiver (f.eks. afvis, slip). Den første matchende regel udfører denne handling, hvilket ofte fører til ophør af evaluering efter det første match, svarende til mange IDS'er.

Grundlæggende OWASP CRS-regelsæt #

Disse forudindlæste beskyttelsesregler er arrangeret baseret på præferencer. Hvis du vælger at bruge dem, bedes du overveje og anvende dem på følgende måde:

ANMODNING-90-KONFIGURATION ANMODNING-901-INITIALISERING
# Anvend ethvert andet OWASP-regelsæt baseret på, hvad du vil beskytte
ANMODNING-949-BLOKERING-EVALUERING SVAR-959-BLOKERING-EVALUERING SVAR-980-KORRELATION # Til logføringsformål, aktiver kun dette til fejlfinding.

Inden for OWASP Core Rule Set fungerer REQUEST-901-INITIALIZATION -regelsættet som et grundlæggende element og tilbyder en bred vifte af muligheder for at konfigurere sikkerhedsreglernes overordnede funktionsmåde. Det giver brugerne fleksibilitet til at finjustere indstillingerne, så de passer til specifikke sikkerhedsbehov, og danner dermed rygraden i regelkonfigurationsprocessen. Regelsættene REQUEST-949-BLOCKING-EVALUATION og RESPONSE-959-BLOCKING-EVALUATION spiller en afgørende rolle i den proaktive sikkerhedstilstand ved at evaluere og udføre blokeringshandlinger baseret på anomaliscorer. De bidrager væsentligt til OWASP Core Rule Sets evne til at identificere og forhindre potentielle trusler i realtid. Som supplement til disse fokuserer RESPONSE-980-CORRELATION- regelsættet på at korrelere og analysere svar, hvilket forbedrer OWASP Core Rule Sets samlede evne til at opdage og reagere effektivt på udviklende sikkerhedsudfordringer. Sammen giver disse regelsæt brugerne mulighed for at implementere en robust og tilpasningsdygtig sikkerhedsramme til deres webapplikationer.

Forståelse af paranoianiveauer, stikprøvetagning og anomaliscore #

Indstillingen Paranoia-niveau giver dig mulighed for at angive intensiteten af ​​regelkontroller, hvilket påvirker anomaliscorer. Højere paranoia-niveauer forbedrer sikkerheden ved at aktivere flere regler, men kan øge risikoen for at blokere legitim trafik på grund af falske positiver. Anbefalinger for hvert niveau:

Paranoia niveau 1 (standard): Velegnet til begyndere, forskellige installationer og standard sikkerhedsopsætninger, med sjældne falske positiver.
Paranoia niveau 2Anbefales til moderate til erfarne brugere, der søger omfattende dækning og øget sikkerhed. Forvent nogle falske positiver.
Paranoia niveau 3Rettet mod erfarne brugere, der håndterer falske positiver, til installationer med høje sikkerhedsbehov.
Paranoia niveau 4Anbefales til erfarne brugere, der beskytter installationer med meget høje sikkerhedskrav, men som sandsynligvis vil producere et stort antal falske positiver, der kræver en løsning, før de går live.

For at hæve niveauet for blokering af paranoia skal du navigere til regelsættet REQUEST-901-INITIALIZATION , derefter redigere i rå tilstand og ændre regel-ID 901120. Erstat setvar:'tx.blocking_paranoia_level=1′ med dit foretrukne niveau.

Ved at anvende niveauet for detektionsparanoia kan man køre regler fra et højere paranoianiveau uden at tage dem i betragtning i anomaliscoringen. Denne fleksibilitet muliggør inkorporering af regler fra paranoianiveau 2 i et finjusteret system på paranoianiveau 1, hvilket mindsker bekymringer om potentielle falske positiver, der kan eskalere scoren ud over den etablerede tærskel. Som standardkonfiguration justeres niveauet for detektionsparanoia med niveauet for blokerende paranoia. For at øge niveauet for detektionsparanoia skal du navigere til regelsættet REQUEST-901-INITIALIZATION , derefter redigere i rå tilstand og ændre regel-ID 901125. Erstat setvar:'tx.detection_paranoia_level=%{TX.blocking_paranoia_level}' med dit foretrukne niveau (f.eks. setvar:'tx.detection_paranoia_level=2′ ).

Hver regel i CRS er tildelt et alvorlighedsniveau, hvor standardpoint angiver effekten på anomaliscoren, når en regel matcher. Alvorlighedsniveauerne og deres tilsvarende scorer er som følger:

KRITISKAnomalyscore på 5, primært fra programangrebsregler (93x- og 94x-filer).
FEJLAnomalyscore på 4, primært genereret af udgående lækageregler (95x filer).
ADVARSELAnomalyscore på 3, primært udløst af ondsindede klientregler (91x filer).
MEDDELELSEAnomalyscore på 2, primært som følge af protokolregler (92x filer).

I anomalitilstand akkumuleres disse scorer, hvilket gør det muligt for en enkelt anmodning at udløse flere regler. Justeringer af disse standardpunkter er generelt unødvendige, men kan tilpasses baseret på specifikke krav.

Den kumulative anomaliscore, hvor en indgående anmodning eller et udgående svar vil blive blokeret, kan defineres . Som standard får de fleste registrerede indgående trusler en kritisk score på 5, mens mindre overtrædelser har lavere scorer. Ved standardblokeringstærsklerne opfører CRS sig på samme måde som tidligere versioner og blokerer og logger anmodninger med et enkelt kritisk regelmatch. Justering af blokeringstærsklerne til højere værdier, f.eks. 7 eller 10, kan gøre CRS mindre følsomt og kræve flere regelmatch før blokering. Forsigtighed anbefales dog, da hævning af tærskler kan give nogle angreb mulighed for at omgå regler eller politikker. Alternativt involverer en anbefalet implementeringsstrategi i første omgang at fastsætte høje anomaliscoringstærskler (>100) og gradvist at sænke dem, efterhånden som tilliden til systemet vokser, hvilket tilbyder en proaktiv tilgang til at forbedre sikkerheden over tid.

Som standard er tærsklen for indgående anomali-score indstillet til 5, og tærsklen for udgående anomali-score er indstillet til 4. For at ændre tærsklen for indgående anomali-score skal du navigere til regelsættet REQUEST-901-INITIALIZATION , derefter redigere i rå tilstand og ændre regel-ID 901100. Erstat setvar:'tx.inbound_anomaly_score_threshold=5′ med dit foretrukne niveau (f.eks. setvar:'tx.inbound_anomaly_score_threshold=4′ ). Gør på samme måde for tærsklen for udgående anomali-score, hvor regel-ID 901110 erstatter setvar:'tx.outbound_anomaly_score_threshold=4′.

Blokering af tidlig anomaliscoring muliggør en tidlig vurdering af anomaliscorer for anmodninger og svar ved afslutningen af ​​henholdsvis fase 1 og fase 3 i stedet for at vente til slutningen af ​​fase 2 og fase 4. Aktivering af denne tilstand tillader øjeblikkelig blokering, hvis anomaltærsklen nås under den tidlige evaluering, hvilket omgår udførelsen af ​​fase 2 (og henholdsvis fase 4). For at aktivere tidlig blokering skal du aktivere regel-ID 901115 i REQUEST-901-INITIALIZATION- regelsættet, som sætter variablen tx.early_blocking til 1 (deaktiveret som standard). Det er vigtigt at bemærke, at tidlig blokering kan skjule potentielle advarsler, da nyttelast, der udløser fase 2- (eller fase 4-) advarsler, ikke vil blive evalueret, hvis tidlig blokering er aktiveret. Deaktivering af tidlig blokering i fremtiden kan afsløre nye advarsler fra fase 2.

Funktionen Easing In / Sampling Percentage er designet til at afbøde potentielle problemer ved integration af CRS i et eksisterende live-websted, såsom falske positiver og uventede påvirkninger af ydeevnen. For forsigtigt at introducere CRS kan du i første omgang aktivere det for et begrænset antal anmodninger. Når eventuelle problemer er løst, og der er etableret tillid til opsætningen, kan du gradvist øge andelen af ​​anmodninger, der er underlagt regelsættet. Juster procentdelen af ​​anmodninger, der behandles af kernereglerne, ved at indstille tx.sampling_percentage som regel-ID 901130 i REQUEST-901-INITIALIZATION -regelsættet; standardværdien er 100, hvilket betyder, at hver anmodning gennemgår CRS-kontroller. Udvælgelsen af ​​kontrollerede anmodninger er baseret på et pseudo-tilfældigt tal genereret af ModSecurity. Hvis en anmodning får lov til at bestå uden CRS-kontrol, vil den ikke have en post i revisionsloggen af ​​ydeevneårsager, men der registreres en fejllogpost. For at deaktivere fejllogposten skal du udstede den angivne direktiv efter at have inkluderet CRS.