Web Application Firewall (WAF) er et vigtigt værktøj til at identificere og forhindre ondsindet HTTP-trafik inden for HTTP(S)-farme. Det analyserer trafikmønstre og håndhæver avancerede sikkerhedspolitikker gennem organiserede sæt af regler, der anvendes på disse farme. Efter dekryptering af SSL-pakker gransker WAF reglerne, hvilket gør det muligt at anvende mønstre på HTTP-indholdet i SSL-trafikken.
RELIANOID IPDS pakken inkluderer OWASP ModSecurity Core-regelsæt, som leveres præinstalleret og klar til brug. Brugere har også fleksibiliteten til at oprette brugerdefinerede regelsæt for omfattende systembeskyttelse mod forskellige angreb. For flere detaljer om OWASP-regler henvises til OWASP ModSecurity Project. Derudover RELIANOID WAF-modulet udvider sin funktionalitet ud over HTTP-beskyttelse til også at omfatte avanceret HTTP-indholdshåndtering funktioner, såsom omdirigeringer og omskrivninger.
Visning af WAF-regelsæt #
WAF-regelsætvisningen giver et overblik over de tilgængelige regelsæt og deres tildelte farm-tjenester:
NavnEn beskrivende identifikator for et regelsæt. Klik for at få adgang til redigeringsformularen.
GårdeDe gårde, som reglen gælder for. Udvid listen over gårde ved hjælp af pilen opad ved siden af GÅRDE kolonneoverskrift. Begrænset til 20 tegn som standard.
StatusRegelsættets status, angivet med farvekoder:
- Grøn. AktiveretRegelsættet er aktivt og kontrolleres for de tildelte gårde.
- Rød. handicappetRegelsættet er inaktivt og påvirker ikke gårdene.
handlingerTilgængelige handlinger for WAF-regelsættets status:
- 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ættet omfatter generiske regler for angrebsdetektion, der tilbyder et grundlæggende beskyttelsesniveau for enhver webapplikation.
Driftsformer #
De forudindlæste OWASP CRS-regelsæt fungerer i to tilstande:
Anomali-scoringstilstand (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 tilstandDenne 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-kerneregelsættet, ANMODNING-901-INITIALISERING Regelsættet fungerer 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. ANMODNING-949-BLOKERING-EVALUERING og SVAR-959-BLOKERING-EVALUERING Regelsæt 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 forebygge potentielle trusler i realtid. Som supplement til disse, SVAR-980-KORRELATION Regelsættet fokuserer 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 et robust og tilpasningsdygtigt sikkerhedsrammeværk 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.
At hæve blokerende paranoia niveau, navigere til ANMODNING-901-INITIALISERING Regelsæt derefter Rediger i rå tilstand og rediger regel-ID'et 901120. Erstatte sætvar:'tx.blokerende_paranoia_niveau=1' med dit foretrukne niveau.
Ved at ansætte detektion paranoia niveau, kan man køre regler fra et højere paranoia-niveau uden at tage dem i betragtning i anomaliscoringen. Denne fleksibilitet muliggør inkorporering af regler fra paranoia-niveau 2 i et finjusteret system på paranoia-niveau 1, hvilket mindsker bekymringer om potentielle falske positiver, der kan eskalere scoren ud over den etablerede tærskel. Som standardkonfiguration justeres detektionsparanoia-niveauet med det blokerende paranoia-niveau. For at øge detektion paranoia niveau, navigere til ANMODNING-901-INITIALISERING Regelsæt derefter Rediger i rå tilstand og rediger regel-ID'et 901125. Erstatte sætvar:'tx.detection_paranoia_level=%{TX.blocking_paranoia_level}' med dit foretrukne niveau (f.eks. sætvar:'tx.detection_paranoia_level=2').
Hver regel i CRS er tildelt et alvorlighedsniveau, med standard score point angiver virkningen på anomalscore 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).
In anomalitilstand, akkumuleres disse scorer, hvilket gør det muligt for en enkelt anmodning at udløse flere regler. Justeringer af disse standardpoint er generelt unødvendige, men kan tilpasses baseret på specifikke krav.
Det kan defineres kumulativ anomalscore hvor en indgående anmodning or udgående svar vil blive blokeret. 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 anomaliescoringstæ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ærskel for indgående anomali-score, navigere til ANMODNING-901-INITIALISERING Regelsæt derefter Rediger i rå tilstand og rediger regel-ID'et 901100. Erstatte sætvar:'tx.inbound_anomaly_score_threshold=5′ med dit foretrukne niveau (f.eks. sætvar:'tx.inbound_anomaly_score_threshold=4′). På samme måde for tærskel for udgående anomali-score med regel-ID'et 901110 udskiftning sætvar:'tx.outbound_anomaly_score_threshold=4′.
Blokering af tidlig anomali-scoringstilstand muliggør en tidlig vurdering af anomalscorer 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, og omgår dermed udførelsen af fase 2 (og fase 4). For at aktivere tidlig blokering skal du aktivere regel-ID. 901115 inden for ANMODNING-901-INITIALISERING regelsæt, 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.
Lettelse i / stikprøveprocent Funktionen er designet til at afbøde potentielle problemer ved integration af CRS'en i et eksisterende live-websted, såsom falske positiver og uventede påvirkninger af ydeevnen. For forsigtigt at introducere CRS'en kan du i første omgang aktivere den 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 ved regel-ID'et 901130 inden for ANMODNING-901-INITIALISERING regelsæt; standardværdien er 100, hvilket betyder, at alle anmodninger gennemgår CRS-tjek. 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-tjek, 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'en.
