Sådan implementeres WEB-applikation og API-beskyttelse med RELIANOID (WAAP)

Se kategorier

Sådan implementeres WEB-applikation og API-beskyttelse med RELIANOID (WAAP)

6 min læses

Hvad er en WEB-applikation og API-beskyttelse (WAAP) #

Webapplikationen og API-beskyttelsen (WAAP) er en progressiv udvikling af RELIANOID sikkerhedsprodukt, Web Application Firewall (WAF). WAAP tilbyder de samme funktioner som en traditionel WAF, men beskytter også API'er udover webapplikationer.

Med udviklingen af ​​cloud-tjenester og SaaS (Software as a Service) har behovet for at integrere forskellige miljøer fremmet brugen af ​​API'er, hvilket giver den bedste løsning til at orkestrere alle disse tjenester. Denne funktionalitet gør WAAP mere avanceret end WAF, da man kan implementere A WAAP på kanten af ​​et netværk, der indeholder offentlige tjenester eller konfigurere det i det samme miljø med en ADC.

Så det er her, hvor RELIANOID ADC og WAAP forenes for at arbejde sammen og tilbyde beskyttelse af webapplikationer og API'er før levering af en applikation.

Hvorfor en WAAP er påkrævet #

Da man nemt kan få adgang til API'er og webapplikationer på internettet, er sikkerhed en stor bekymring, fordi følsomme data er afsløret. En hacker kan forårsage et sikkerhedsbrud for at få private oplysninger. Så en WAAP er nødvendig, da traditionel websikkerhed ikke håndterer følgende opgaver:

Signaturmatchning er ikke nok til applikationssikkerhed:
Indholdet af webapplikationer og API'er ændrer sig løbende. Så indholdets signatur er svær at få. Da web-publiceret indhold og API'er bliver ved med at ændre sig, kræver systemet konstant læring.

Blokering af trafik baseret på kilde-IP eller destinationsport er ikke nok:
Traditionelle firewalls blokerer IP'er og porte, men disse oplysninger er normalt krypteret. En mekanisme til at dekryptere, analysere indholdet og genkryptere er afgørende. Vi bruger TLS-mekanismen, så WAAP kan tilbyde et dybere sikkerhedsniveau.

HTTP(S)-trafik er i øjeblikket den mest anvendte, og den kan tilbyde kompleksitet i analysen: Det meste webtrafik er rettet mod Layer 7-protokollen HTTP(S) i OSI-modellen, hvilket tilbyder kompleksitet i adfærden af ​​HTTP-protokollen defineret i 80'erne til moderne protokoller, der bruges i dag. Dette forpligter sikkerhedsløsningen til ikke kun at bruge IPS- eller IDS-mekanisme, men også være i stand til at beskytte mod angreb på det øverste lag i OSI-modellen, lag 7-protokoller som HTTP og HTTPS.

Hvilke funktioner en WAAP kan tilbyde, som en traditionel WAF ikke kan #

WAAP tilbyder enorme muligheder, som en traditionel WAF ikke kan tilbyde:

Automatisering og læring: WAAP er et levende element integreret i en ADC. Denne sikkerhedsfunktion modtager information og lærer konstant ved hjælp af mekanismer som DoS Detection, bot-detektion, protokolbeskyttelse og håndhævelse, blandt andre. WAAP-motoren kræver en kanal til at modtage INPUT-data, hvor WAAP-motoren konstant modtager ny information og sammenligner den modtagne information med de behandlede og inspicerede data.

Sikre API'er og mikrotjenester: På daglig basis bygger ingeniører API'er og mikrotjenester for at tilbyde offentlige tjenester. WAAP skal beskytte disse endepunkter under hensyntagen til de eksponerede oplysninger.

Hvordan Relianoid fungerer som en WAAP #

RELIANOID ADC inkluderer et Cybersikkerhedsmodul kaldet IPDS (Intrusion Prevention and Detection System). Dette modul tilbyder WAAP-funktioner, automatisering og læring til WEB'er og API'er. Relianoid inkluderer en pakke kaldet relianoid-ipds, og denne pakke opdateres dagligt. Denne pakke har mere end 4 mekanismer til webapplikationer og API-beskyttelse. Dens egenskaber er:

Bloklisteregler #

Blokeringslister er en del af en sikkerhedsmekanisme til at gruppere trafik baseret på geolokalisering og forskellige kilder, som beskrevet nedenfor:

geo_*: Disse blokeringslister inkluderer IP'er og netværk baseret på lande.
TOR_knudepunkter: Denne blokliste er hentet fra TOR-projektet. Her kan vi finde kilde-IP'erne, hvor TOR-trafik offentliggøres på internettet.
webexploit: Medlemmer af kildelisten er blevet identificeret som webudnyttere. Disse angribere forsøgte at udføre flere anmodninger mod webservere for at finde sårbarheder.
spyware: De inkluderede kilder er en liste over ondsindet spyware og adware IP-adresseområder.
proxy: indeholder TOR og andre åbne proxyer.
mail_spammer: Kilden inkluderet er en liste baseret på IP'er, der er registreret ved at sende spam.
bad_peers: Kilden inkluderet er en liste baseret på rapporter om dårlige gerninger i p2p.
CIArmy: De inkluderede kilder her tilbydes af CIArmy-projektet. Dette projekt giver datakilden opnået ved at analysere trafik baseret på en gruppe af vagtposter rundt på internettet.
bogon: Kilden inkluderet her hævder at være fra et område af IP-adresserummet, der er reserveret, men endnu ikke tildelt eller uddelegeret af internettet.

DOS regler #

Denial of Service-reduktion er et sæt regler, der har til formål at beskytte eller reducere virkningen af ​​angreb på en tjeneste, som gør den ubrugelig på grund af overvældende mængder af illegitime anmodninger. RELIANOID IPDS-motoren indeholder forskellige teknikker til at udføre DoS-beskyttelse til webapplikationer og API'er.

Disse regler er beskrevet nedenfor:

Falske TCP-flag:
I enhver TCP-trafik følger TCP-pakkerne et kendt flow. Et BOGUS TCP-angreb er et, hvor TCP-flowet ikke følger en forventet TCP-sti. For eksempel kan pakken følge en SYN-FIN-sti, som er uventet, i stedet for en SYN-ACK-sti. RELIANOID overvåger og styrer TCP flow. Hvis en uventet pakke modtages, RELIANOID vil droppe det.

Samlet forbindelsesgrænse pr. kilde-IP:
RELIANOID anvender en kildegrænse baseret på antallet af anmodninger pr. sekund, og når grænsen pr. kilde-IP er nået, RELIANOID vil droppe de indkommende pakker.

Begræns RST-pakke pr. sekund:
Dette er et almindeligt DoS-angreb, hvor angriberen forsøger at åbne en TCP-socket, og når først TCP-svarpakken er modtaget, sender angriberen en TCP RST-pakke til værten.

Forbindelsesgrænse pr. sekund:
RELIANOID anvender en destinationsgrænse baseret på antallet af anmodninger pr. sekund. Hvis grænsen pr. destinations-IP nås, RELIANOID vil droppe de indkommende pakker.

RBL regler #

En sorthulsliste i realtid er et sikkerhedssystem, der bruges af mailservere til at beskytte mod spammere. Hvis mailserveren modtager en forbindelse, fanger den kilde-IP'en og forsøger at løse den mod kendte DNS-servere. Hvis DNS-opløsningen virker, vil kildens IP-adresse blive registreret som en angriber.

RELIANOID har udviklet denne sikkerhedsmekanisme, hvilket gør det muligt at fange enhver kilde-IP i et bestemt flow og forsøge at løse kilde-IP'en mod en DNS-zone. Til dette formål er der udvalgt en samling af nogle af de mest robuste RBL-domæner.

WAF regler #

RELIANOID inspicerer HTTP(S)-trafik på to måder:

1 – Brug af foruddefinerede regler baseret på OWASP-regelsæt (Open Web Application Security Project). Regelsættet inkluderet i RELIANOID 6 er baseret på OWASP Core Rule Set version 4. Disse regler opdateres dagligt. Hvis der sker en ændring i OWASP-regelsættet, vil den næste IPDS-pakkeopdatering inkludere ændringerne.

2 – Brug af regler opnået fra tredjepartsleverandører eller brugerdefinerede regler designet af dig, vores kunde. RELIANOID bruger ModSecurity-motorstøtten til 3. parts regelsæt eller opretter dine egne regler baseret på dissektorens HTTP-sprog.

Som standard RELIANOID IPDS inkluderer sikkerhedspakker mod følgende angreb:

SQL Injection (SQLi)
Cross-site scripting (XSS)
Lokal filinkludering (LFI)
Remote File Inclusion (RFI)
PHP/Java/Ruby/Perl Code Injection
skalchok
Unix Shell Injection
Sessionfiksering
Scripting/scanner/botdetektion

Regelsættet findes i RELIANOID 6 Inkluder:

ANMODNING-905-FÆLLES-UNDTAGELSER
Disse regler bruges som undtagelsesmekanismer til at fjerne almindelige falske positiver, der kan opstå.
ANMODNING-911-METHODE-HANDHÆVELSE
Tilladte anmodningsmetoder.
REQUEST-913-SCANNER-DETECTION
Tjek for scannere som crawlere, bots, scripts osv.
REQUEST-920-PROTOCOL-HANDHÆVELSE
Validerer HTTP-anmodninger og eliminerer et stort antal applikationslagsangreb.
ANMODNING-921-PROTOKOL-ANgreb
Tjek for protokolangreb.
REQUEST-930-APPLICATION-ATTACK-LFI
Kontrollerer for applikationsangreb ved hjælp af Local File Inclusion (LFI).
REQUEST-931-APPLICATION-ATTACK-RFI
Kontrollerer for applikationsangreb ved hjælp af Remote File Inclusion (RFI).
REQUEST-932-APPLICATION-ATTACK-RCE
Kontrollerer for applikationsangreb ved hjælp af Remote Code Execution (RCE).
REQUEST-933-APPLICATION-ATTACK-PHP
Kontrollerer for applikationsangreb ved hjælp af PHP.
REQUEST-934-APPLICATION-ATTACK-GENERIC
Tjek for applikationsangreb ved hjælp af Node.js, Ruby og Perl.
REQUEST-941-APPLICATION-ATTACK-XSS
Kontrollerer for applikationsangreb ved hjælp af XSS.
REQUEST-942-APPLICATION-ATTACK-SQLI
Kontrollerer for applikationsangreb ved hjælp af Sql Injection.
ANMODNING-943-ANSØGNING-ANgreb-SESSION-FIKSERING
Kontrollerer for applikationsangreb ved hjælp af sessionsfiksering.
REQUEST-944-APPLICATION-ATTACK-JAVA.
Kontrollerer for applikationsangreb ved hjælp af Java.

IPDS-motoren er en trussel-intelligensmekanisme til webapplikationer og API-beskyttelse. Den opdateres dagligt gennem relianoid-ipds-pakken, som fungerer som kernen for motoren, og holder denne motor opdateret med RELIANOID regler og dem, der er tilpasset af kunden.

Dette relianoid-ipds kerneregelsæt bruger forskellige mekanismer til at skabe disse sikkerhedsregler, såsom at krydse tredjepartsdata, analysere sentinel-logfiler eller lave Big-data-analyse mod private oplysninger. Hvis du identificerer, at RELIANOID IPDS kerneregelsæt inkluderer nogle kilde-IP'er eller regler som falske positiver, kontakt os, og vi vil med glæde løse problemet så hurtigt som muligt.

📄 Download dette dokument i PDF-format #

    EMAIL: *

    drevet af BetterDocs