Vårt cyberforsvarssenter er ansvarlig for sikkerheten til klientens nettinfrastruktur og avviser angrep på klientnettsteder. For å beskytte mot angrep bruker vi FortiWeb Web Application Firewalls (WAFs). Men selv den kuleste WAF er ikke et universalmiddel og beskytter ikke «ut av boksen» mot målrettede angrep.
Derfor bruker vi i tillegg til WAF . Det hjelper å samle alle hendelser på ett sted, samler statistikk, visualiserer det og lar oss se et målrettet angrep i tide.
I dag skal jeg fortelle deg mer detaljert hvordan vi krysset juletreet med WAF og hva som kom ut av det.
Historien om ett angrep: hvordan alt fungerte før du byttet til ELK
I skyen vår har kunden distribuert applikasjonen bak vår WAF. Fra 10 000 til 100 000 brukere koblet til siden per dag, nådde antallet tilkoblinger 20 millioner per dag. Av disse var 3-5 brukere inntrengere og forsøkte å hacke nettstedet.
Den vanlige formen brute force fra én IP-adresse ble blokkert av FortiWeb ganske enkelt. Antall treff på nettstedet per minutt var høyere enn for legitime brukere. Vi satte rett og slett opp aktivitetsterskler fra én adresse og avviste angrepet.
Det er mye vanskeligere å håndtere «langsomme angrep», når angripere opptrer sakte og forkler seg som vanlige klienter. De bruker mange unike IP-adresser. Slik aktivitet så ikke ut som massiv brute force for WAF, det var vanskeligere å spore det automatisk. Og det var også risiko for å blokkere vanlige brukere. Vi så etter andre tegn på et angrep og satte opp en policy for automatisk blokkering av IP-adresser basert på dette skiltet. For eksempel hadde mange illegitime økter vanlige felt i http-forespørselshodene. Du måtte ofte lete etter slike felt manuelt i FortiWeb-hendelsesloggene.
Det ble langt og ubehagelig. I standardfunksjonaliteten til FortiWeb registreres hendelser i tekst i 3 forskjellige logger: oppdagede angrep, informasjon om forespørsler og systemmeldinger om WAF-drift. Dusinvis eller til og med hundrevis av angrepshendelser kan komme i løpet av et minutt.
Ikke så mye, men du må manuelt klatre gjennom flere logger og iterere over mange linjer:
I angrepsloggen ser vi brukeradresser og aktivitetens art.
Det er ikke nok å bare skanne loggtabellen. For å finne det mest interessante og nyttige om angrepets natur, må du se inn i en spesifikk hendelse:
Uthevede felt hjelper til med å oppdage "sakte angrep". Kilde: skjermbilde fra .
Vel, hovedproblemet er at bare en FortiWeb-spesialist kan finne ut av det. Hvis vi i løpet av arbeidstiden fortsatt kunne spore mistenkelig aktivitet i sanntid, kan etterforskningen av natthendelser bli forsinket. Da FortiWeb-retningslinjene av en eller annen grunn ikke fungerte, kunne ikke nattskiftingeniørene på vakt vurdere situasjonen uten tilgang til WAF og vekket FortiWeb-spesialisten. Vi så gjennom loggene i flere timer og fant angrepsøyeblikket.
Med slike mengder informasjon er det vanskelig å forstå det store bildet på et øyeblikk og handle proaktivt. Så bestemte vi oss for å samle data på ett sted for å analysere alt i en visuell form, finne begynnelsen av angrepet, identifisere retningen og metoden for blokkering.
Hva ble valgt
Først av alt så vi på løsningene som allerede er i bruk, for ikke å multiplisere enheter unødvendig.
Et av de første alternativene var Nagiossom vi bruker til å overvåke , , nødvarsler. Sikkerhetsvaktene bruker den også til å varsle ledsagerne ved mistenkelig trafikk, men den vet ikke hvordan den skal samle inn spredte tømmerstokker og forsvinner derfor.
Det var et alternativ å samle alt med MySQL og PostgreSQL eller en annen relasjonsdatabase. Men for å trekke ut dataene, var det nødvendig å forme søknaden din.
Som tømmeroppsamler i vårt firma bruker de også FortiAnalyzer fra Fortinet. Men i dette tilfellet passet han heller ikke. For det første er det mer skjerpet å jobbe med en brannmur FortiGate. For det andre manglet mange innstillinger, og interaksjon med det krevde utmerket kunnskap om SQL-spørringer. Og for det tredje vil bruken øke kostnadene for tjenesten for kunden.
Dette er hvordan vi kom til åpen kildekode i ansiktet ELK.
Hvorfor velge ELK
ELK er et sett med åpen kildekode-programmer:
- Elasticsearch - en database med tidsserier, som nettopp ble opprettet for å jobbe med store tekstvolumer;
- Logstash – en datainnsamlingsmekanisme som kan konvertere logger til ønsket format;
- Kibana - en god visualisator, samt et ganske vennlig grensesnitt for å administrere Elasticsearch. Du kan bruke den til å lage tidsplaner som kan overvåkes av vakthavende ingeniører om natten.
Inngangsterskelen for ELK er lav. Alle grunnleggende funksjoner er gratis. Hva annet trengs for lykke.
Hvordan satte du alt sammen i ett system?
Laget indekser og la bare den nødvendige informasjonen. Vi lastet inn alle de tre FortiWEB-loggene i ELK - utgangen var indekser. Dette er filer med alle innsamlede logger for en periode, for eksempel en dag. Hvis vi visualiserte dem med en gang, ville vi bare se dynamikken i angrepene. For detaljer må du "falle gjennom" i hvert angrep og se på spesifikke felt.
Vi innså at først må vi sette opp parsing av ustrukturert informasjon. Vi tok lange felt som strenger, for eksempel "Message" og "URL", og analyserte dem for å få mer informasjon for beslutningstaking.
For eksempel, ved å bruke parsing, tok vi ut brukerens plassering separat. Dette bidro til umiddelbart å fremheve angrep fra utlandet på nettsteder for russiske brukere. Ved å blokkere alle forbindelser fra andre land reduserte vi antallet angrep med 2 ganger og kunne enkelt håndtere angrep inne i Russland.
Etter parsing begynte de å se etter hvilken informasjon de skulle lagre og visualisere. Å forlate alt i loggen var upassende: størrelsen på en indeks var stor - 7 GB. ELK brukte lang tid på å behandle filen. Imidlertid var ikke all informasjon nyttig. Noe ble duplisert og tok ekstra plass – det var nødvendig å optimalisere.
Først så vi ganske enkelt gjennom indeksen og fjernet unødvendige hendelser. Dette viste seg å være enda mer upraktisk og lengre enn å jobbe med logger på selve FortiWeb. Det eneste plusset fra «juletreet» på dette stadiet er at vi klarte å visualisere et stort tidsrom på én skjerm.
Vi fortvilte ikke, vi fortsatte å spise kaktusen og studere ELK og trodde at vi ville klare å hente ut nødvendig informasjon. Etter å ha renset indeksene, begynte vi å visualisere hva som er. Så vi kom til store dashboards. Vi pirket widgets - visuelt og elegant, en ekte ЁLKa!
Fang øyeblikket av angrepet. Nå var det nødvendig å forstå hvordan begynnelsen av angrepet ser ut på kartet. For å oppdage det, så vi på serverens svar til brukeren (returkoder). Vi var interessert i serversvar med slike koder (rc):
Kode (rc)
Navn
beskrivelse
0
DROP
Forespørselen til serveren er blokkert
200
Ok
Forespørselen ble behandlet
400
Dårlig forespørsel
Dårlig forespørsel
403
Forbidden
Autorisasjon nektet
500
Internal Server Error
Tjenesten er utilgjengelig
Hvis noen begynte å angripe nettstedet, endret forholdet mellom kodene seg:
- Hvis det var flere feilaktige forespørsler med kode 400, og samme antall normale forespørsler med kode 200, så var det noen som prøvde å hacke nettstedet.
- Hvis forespørsler med kode 0 samtidig vokste, så «så» også FortiWeb-politikerne angrepet og satte blokkeringer på det.
- Hvis antall meldinger med kode 500 økte, er siden ikke tilgjengelig for disse IP-adressene - også en slags blokkering.
Innen den tredje måneden hadde vi satt opp et dashbord for å spore denne aktiviteten.
For ikke å overvåke alt manuelt, satte vi opp integrasjon med Nagios, som spurte ELK med visse intervaller. Hvis den registrerte oppnåelsen av terskelverdier ved hjelp av koder, sendte den en melding til tjenestevaktene om mistenkelig aktivitet.
Kombinert 4 kart i overvåkingssystemet. Nå var det viktig å se på grafene øyeblikket når angrepet ikke er blokkert og det er nødvendig med inngripen fra en ingeniør. På 4 forskjellige grafer var øyet vårt uskarpt. Derfor kombinerte vi diagrammene og begynte å observere alt på én skjerm.
På overvåking så vi hvordan grafer med forskjellige farger endres. Et rødt utbrudd indikerte at angrepet hadde begynt, mens de oransje og blå grafene viste FortiWebs reaksjon:
Alt er bra her: det var en bølge av "rød" aktivitet, men FortiWeb taklet det og angrepsplanen ble til intet.
Vi tegnet også for oss selv et eksempel på en graf som krever intervensjon:
Her kan vi se at FortiWeb har økt aktivitet, men den røde angrepsgrafen har ikke blitt mindre. Du må endre WAF-innstillingene.
Det er også blitt enklere å etterforske natthendelser. Grafen viser umiddelbart øyeblikket når det er på tide å komme til forsvar av nettstedet.
Det er det som noen ganger skjer om natten. Rød graf - angrepet har begynt. Blå - FortiWeb-aktivitet. Angrepet ble ikke helt blokkert, vi måtte gripe inn.
Hvor skal vi
Nå utdanner vi vaktadministratorer til å jobbe med ELK. Deltakerne lærer å vurdere situasjonen på dashbordet og ta en avgjørelse: det er på tide å eskalere til en FortiWeb-spesialist, ellers vil retningslinjene på WAF være nok til å automatisk avvise angrepet. Så vi reduserer belastningen på informasjonssikkerhetsingeniører om natten og deler rollene i støtte på systemnivå. Tilgang til FortiWeb forblir kun hos cyberforsvarssenteret, og bare de gjør endringer i WAF-innstillingene når det haster.
Vi jobber også med rapportering for kunder. Vi planlegger at data om dynamikken i WAF-arbeid skal være tilgjengelig på kundens personlige konto. ELK vil gjøre situasjonen klarere uten å måtte henvise til selve WAF.
Dersom kunden ønsker å overvåke sin egen beskyttelse i sanntid, vil også ELK komme godt med. Vi kan ikke gi bort tilgang til WAF, siden kundens inngripen i arbeidet kan påvirke resten. Men du kan plukke opp en egen ELK og gi den til å "leke rundt".
Dette er scenariene for bruk av juletreet som vi har samlet i det siste. Del dine tanker om dette og ikke glem for å unngå databaselekkasjer.
Kilde: www.habr.com