Vores cyberforsvarscenter er ansvarlig for sikkerheden af kundens webinfrastruktur og afviser angreb på klientwebsteder. For at beskytte mod angreb bruger vi FortiWeb Web Application Firewalls (WAF'er). Men selv den sejeste WAF er ikke et vidundermiddel og beskytter ikke "ud af boksen" mod målrettede angreb.
Derfor bruger vi udover WAF . Det hjælper med at samle alle hændelser ét sted, akkumulerer statistik, visualiserer det og giver os mulighed for at se et målrettet angreb i tide.
I dag vil jeg fortælle dig mere detaljeret, hvordan vi krydsede juletræet med WAF, og hvad der kom ud af det.
Historien om et angreb: hvordan alt fungerede før skiftet til ELK
I vores sky har kunden implementeret applikationen bag vores WAF. Fra 10 til 000 brugere forbundet til siden om dagen nåede antallet af forbindelser op på 100 millioner om dagen. Heraf var 000-20 brugere ubudne gæster og forsøgte at hacke siden.
Den sædvanlige form for brute force fra én IP-adresse blev blokeret af FortiWeb ganske nemt. Antallet af hits til webstedet pr. minut var højere end for legitime brugere. Vi satte simpelthen aktivitetstærskler fra én adresse og afviste angrebet.
Det er meget sværere at håndtere "langsomme angreb", når angriberne handler langsomt og forklæder sig som almindelige klienter. De bruger mange unikke IP-adresser. En sådan aktivitet lignede ikke massiv brute force for WAF, det var sværere at spore det automatisk. Og der var også risiko for at blokere normale brugere. Vi ledte efter andre tegn på et angreb og opsatte en politik for automatisk blokering af IP-adresser baseret på dette tegn. For eksempel havde mange illegitime sessioner fælles felter i http-anmodningsoverskrifterne. Du skulle ofte lede efter sådanne felter manuelt i FortiWebs hændelseslogfiler.
Det blev langt og ubehageligt. I FortiWebs standardfunktionalitet registreres hændelser i tekst i 3 forskellige logfiler: opdagede angreb, information om anmodninger og systemmeddelelser om WAF-drift. Dusinvis eller endda hundredvis af angrebsbegivenheder kan komme på et minut.
Ikke så meget, men du skal manuelt klatre gennem flere logs og iterere over mange linjer:
I angrebsloggen ser vi brugeradresser og arten af aktiviteten.
Det er ikke nok blot at scanne logtabellen. For at finde det mest interessante og nyttige om angrebets art, skal du kigge ind i en bestemt begivenhed:
Fremhævede felter hjælper med at opdage "langsomt angreb". Kilde: skærmbillede fra .
Nå, hovedproblemet er, at kun en FortiWeb-specialist kan finde ud af det. Hvis vi i åbningstiden stadig kunne spore mistænkelig aktivitet i realtid, kan undersøgelsen af nathændelser blive forsinket. Da FortiWeb-politikkerne af en eller anden grund ikke virkede, kunne de vagthavende nattevagtingeniører ikke vurdere situationen uden adgang til WAF og vækkede FortiWeb-specialisten. Vi kiggede loggene igennem i flere timer og fandt tidspunktet for angrebet.
Med sådanne mængder af information er det svært at forstå det store billede på et øjeblik og handle proaktivt. Så besluttede vi at indsamle data ét sted for at analysere alt i en visuel form, finde begyndelsen af angrebet, identificere dets retning og metode til blokering.
Hvad har du valgt fra
Først og fremmest så vi på løsninger, der allerede er i brug, for ikke at multiplicere enheder unødigt.
En af de første muligheder var Nagiossom vi bruger til at overvåge , , nødalarmer. Sikkerhedsvagterne bruger den også til at underrette vagterne i tilfælde af mistænkelig trafik, men den ved ikke, hvordan den skal indsamle spredte logs og forsvinder derfor.
Der var en mulighed for at samle alt med MySQL og PostgreSQL eller en anden relationsdatabase. Men for at trække dataene ud, var det nødvendigt at forme din ansøgning.
Som logopsamler i vores virksomhed bruger de også FortiAnalyzer fra Fortinet. Men i dette tilfælde passede han heller ikke. For det første er det mere skærpet at arbejde med en firewall FortiGate. For det andet manglede mange indstillinger, og interaktion med det krævede fremragende kendskab til SQL-forespørgsler. Og for det tredje ville brugen heraf øge omkostningerne ved tjenesten for kunden.
Sådan kom vi til open source i ansigtet ELK.
Hvorfor vælge ELK
ELK er et sæt open source-programmer:
- Elasticsearch - en database med tidsserier, som netop er skabt til at arbejde med store mængder tekst;
- Logstash – en dataindsamlingsmekanisme, der kan konvertere logfiler til det ønskede format;
- Kibana - en god visualizer, samt en ret venlig grænseflade til styring af Elasticsearch. Du kan bruge det til at bygge tidsplaner, der kan overvåges af vagthavende ingeniører om natten.
Indgangstærsklen for ELK er lav. Alle grundlæggende funktioner er gratis. Hvad skal der ellers til for lykke.
Hvordan satte du det hele sammen i ét system?
Oprettede indekser og efterlod kun de nødvendige oplysninger. Vi indlæste alle tre FortiWEB-logfiler i ELK - outputtet var indekser. Det er filer med alle indsamlede logfiler for en periode, for eksempel en dag. Hvis vi visualiserede dem med det samme, ville vi kun se dynamikken i angrebene. For detaljer skal du "falde igennem" i hvert angreb og se på specifikke felter.
Vi indså, at vi først skal opsætte parsing af ustruktureret information. Vi tog lange felter som strenge, såsom "Besked" og "URL", og analyserede dem for at få mere information til beslutningstagning.
For eksempel ved hjælp af parsing fjernede vi brugerens placering separat. Dette hjalp med det samme at fremhæve angreb fra udlandet på websteder for russiske brugere. Ved at blokere alle forbindelser fra andre lande reducerede vi antallet af angreb med 2 gange og kunne nemt håndtere angreb inde i Rusland.
Efter parsing begyndte de at lede efter, hvilken information de skulle gemme og visualisere. At forlade alt i loggen var upassende: størrelsen på et indeks var stor - 7 GB. ELK tog lang tid at behandle filen. Men ikke alle oplysninger var nyttige. Noget blev duplikeret og optog ekstra plads – det var nødvendigt at optimere.
Først kiggede vi blot indekset igennem og fjernede unødvendige begivenheder. Dette viste sig at være endnu mere ubelejligt og længere end at arbejde med logs på selve FortiWeb. Det eneste plus fra "juletræet" på dette tidspunkt er, at vi var i stand til at visualisere et stort tidsrum på én skærm.
Vi fortvivlede ikke, vi fortsatte med at spise kaktus og studere ELK og troede på, at vi ville være i stand til at udtrække den nødvendige information. Efter at have renset indekserne, begyndte vi at visualisere, hvad der er. Så vi kom til store dashboards. Vi satte widgets - visuelt og elegant, en rigtig ЁLKa!
Fangede øjeblikket for angrebet. Nu var det nødvendigt at forstå, hvordan begyndelsen af angrebet ser ud på diagrammet. For at opdage det, så vi på serverens svar til brugeren (returkoder). Vi var interesserede i serversvar med sådanne koder (rc):
Kode (rc)
Navn
beskrivelse
0
DROP
Anmodningen til serveren er blokeret
200
Ok
Anmodningen blev behandlet
400
Dårlig anmodning
Dårlig anmodning
403
Forbudt
Godkendelse nægtet
500
Internal Server Error
Tjenesten er ikke tilgængelig
Hvis nogen begyndte at angribe webstedet, ændredes forholdet mellem koder:
- Hvis der var flere fejlagtige anmodninger med kode 400, og det samme antal normale anmodninger med kode 200, så var der nogen, der forsøgte at hacke siden.
- Hvis der samtidig også voksede anmodninger med kode 0, så "så" FortiWeb-politikerne også angrebet og lagde blokeringer på det.
- Hvis antallet af beskeder med kode 500 steg, så er siden ikke tilgængelig for disse IP-adresser - også en slags blokering.
Inden den tredje måned havde vi oprettet et dashboard til at spore denne aktivitet.
For ikke at overvåge alt manuelt, satte vi integration op med Nagios, som med bestemte intervaller spurgte ELK. Hvis det registrerede opnåelsen af tærskelværdier ved hjælp af koder, sendte det en meddelelse til vagtcheferne om mistænkelig aktivitet.
Kombineret 4 diagrammer i overvågningssystemet. Nu var det vigtigt at se på graferne det øjeblik, hvor angrebet ikke er blokeret, og der er behov for en ingeniørs indgriben. På 4 forskellige grafer var vores øje sløret. Derfor kombinerede vi diagrammerne og begyndte at observere alt på én skærm.
Ved overvågning så vi, hvordan grafer med forskellige farver ændrede sig. Et rødt udbrud indikerede, at angrebet var begyndt, mens de orange og blå grafer viste FortiWebs reaktion:
Alt er fint her: der var en bølge af "rød" aktivitet, men FortiWeb klarede sig, og angrebsplanen blev til intet.
Vi tegnede også selv et eksempel på en graf, der kræver indgriben:
Her kan vi se, at FortiWeb har øget aktiviteten, men den røde angrebsgraf er ikke faldet. Du skal ændre WAF-indstillingerne.
Det er også blevet lettere at undersøge nathændelser. Grafen viser øjeblikkeligt det øjeblik, hvor det er tid til at komme til forsvar af webstedet.
Det er, hvad der nogle gange sker om natten. Rød graf - angrebet er begyndt. Blå - FortiWeb aktivitet. Angrebet var ikke helt blokeret, vi måtte gribe ind.
Hvor er vi på vej hen
Nu uddanner vi vagtadministratorer til at arbejde med ELK. Lederne lærer at vurdere situationen på dashboardet og træffe en beslutning: Det er tid til at eskalere til en FortiWeb-specialist, ellers vil politikkerne på WAF være nok til automatisk at afvise angrebet. Så vi reducerer belastningen af informationssikkerhedsingeniører om natten og opdeler rollerne i support på systemniveau. Adgang til FortiWeb forbliver kun hos cyberforsvarscentret, og kun de foretager ændringer i WAF-indstillingerne, når det er et presserende behov.
Vi arbejder også på rapportering til kunder. Vi planlægger, at data om dynamikken i WAF-arbejdet vil være tilgængelige på kundens personlige konto. ELK vil gøre situationen klarere uden at skulle henvise til selve WAF.
Hvis kunden ønsker at overvåge sin egen beskyttelse i realtid, vil ELK også komme godt med. Vi kan ikke give væk adgang til WAF, da kundens indgriben i arbejdet kan påvirke resten. Men du kan hente en separat ELK og give den til at "lege rundt".
Dette er scenarierne for brug af juletræet, som vi har samlet på det seneste. Del dine tanker om dette og glem det ikke for at undgå databaselækager.
Kilde: www.habr.com