Ons cyberdefensiecentrum is verantwoordelijk voor de beveiliging van de webinfrastructuur van klanten en weert aanvallen op sites van klanten af. Ter bescherming tegen aanvallen gebruiken we FortiWeb Web Application Firewalls (WAF's). Maar zelfs de coolste WAF is geen wondermiddel en beschermt niet "out of the box" tegen gerichte aanvallen.
Daarom gebruiken we naast WAF . Het helpt om alle gebeurtenissen op één plek te verzamelen, verzamelt statistieken, visualiseert deze en stelt ons in staat een gerichte aanval op tijd te zien.
Vandaag zal ik je in meer detail vertellen hoe we met WAF de “kerstboom” zijn overgestoken en wat eruit is voortgekomen.
Het verhaal van één aanval: hoe alles werkte voordat er werd overgestapt op ELK
In onze cloud heeft de klant de applicatie achter onze WAF ingezet. Van 10 tot 000 gebruikers die per dag verbinding maakten met de site, bereikte het aantal verbindingen 100 miljoen per dag. Hiervan waren 000 tot 20 gebruikers indringers en probeerden de site te hacken.
De gebruikelijke vorm van brute kracht vanaf één IP-adres werd vrij eenvoudig door FortiWeb geblokkeerd. Het aantal hits per minuut op de site was hoger dan dat van legitieme gebruikers. We hebben eenvoudigweg activiteitsdrempels vanaf één adres ingesteld en de aanval afgeslagen.
Het is veel moeilijker om ‘langzame aanvallen’ te bestrijden, wanneer aanvallers langzaam handelen en zich vermommen als gewone klanten. Ze gebruiken veel unieke IP-adressen. Dergelijke activiteiten leken voor de WAF niet op een enorme brute kracht; het was moeilijker om ze automatisch te volgen. Er bestond ook een risico dat normale gebruikers werden geblokkeerd. We hebben gezocht naar andere tekenen van een aanval en hebben een beleid geconfigureerd om IP-adressen automatisch te blokkeren op basis van dit teken. Veel onwettige sessies hadden bijvoorbeeld gemeenschappelijke velden in de HTTP-verzoekheaders. Deze velden moesten vaak handmatig worden doorzocht in FortiWeb-gebeurtenislogboeken.
Het werd lang en ongemakkelijk. In de standaard FortiWeb-functionaliteit worden gebeurtenissen in tekst vastgelegd in 3 verschillende logboeken: gedetecteerde aanvallen, verzoekinformatie en systeemberichten over WAF-werking. Binnen een minuut kunnen tientallen of zelfs honderden aanvalsgebeurtenissen plaatsvinden.
Niet zozeer, maar je moet handmatig door verschillende logboeken klimmen en een groot aantal regels doorlopen:
In het aanvalslogboek zien we gebruikersadressen en de aard van de activiteit.
Het is niet voldoende om eenvoudigweg de logboektabel te scannen. Om de meest interessante en nuttige informatie over de aard van de aanval te vinden, moet je naar een specifieke gebeurtenis kijken:
Gemarkeerde velden helpen bij het detecteren van "langzame aanvallen". Bron: screenshot van .
Het belangrijkste probleem is dat alleen een FortiWeb-specialist dit kan achterhalen. Terwijl we tijdens kantooruren verdachte activiteiten nog steeds in realtime konden volgen, kon het onderzoek naar nachtelijke incidenten langer duren. Toen het FortiWeb-beleid om de een of andere reden niet werkte, konden de dienstdoende nachtploegingenieurs de situatie niet beoordelen zonder toegang tot de WAF en maakten ze de FortiWeb-specialist wakker. We hebben een aantal uren door de logboeken gekeken en het moment van de aanval gevonden.
Met zulke hoeveelheden informatie is het moeilijk om op het eerste gezicht het grote geheel te begrijpen en proactief te handelen. Toen besloten we om gegevens op één plek te verzamelen om alles in visuele vorm te analyseren, het begin van de aanval te vinden, de richting en de blokkeringsmethode te identificeren.
Waar heb je uit gekozen?
Allereerst hebben we gekeken naar de oplossingen die al in gebruik zijn om entiteiten niet onnodig te vermenigvuldigen.
Eén van de eerste opties was Nagiosdie we gebruiken voor monitoring , , noodwaarschuwingen. Bewakers gebruiken het ook om dienstdoende agenten op de hoogte te stellen bij verdacht verkeer, maar het weet niet hoe het verspreide logboeken moet verzamelen en is daarom niet langer nodig.
Er was een optie om alles samen te voegen MySQL en PostgreSQL of een andere relationele database. Maar om gegevens eruit te halen, moest je je eigen applicatie maken.
Ons bedrijf gebruikt ook FortiAnalyzer van Fortinet. Maar ook in dit geval paste het niet. Ten eerste is het meer afgestemd op het werken met een firewall FortiGate. Ten tweede ontbraken veel instellingen en voor de interactie ermee was een uitstekende kennis van SQL-query's vereist. En ten derde zou het gebruik ervan de kosten van de dienst voor de klant verhogen.
Zo kwamen we in het gezicht bij open source terecht ELK.
Waarom kiezen voor ELK
ELK is een reeks open source-programma's:
- Elasticsearch – een tijdreeksdatabase, die speciaal is gemaakt om met grote hoeveelheden tekst te werken;
- Logstash – een mechanisme voor gegevensverzameling dat logs naar het gewenste formaat kan converteren;
- Kibana – een goede visualisator, evenals een redelijk vriendelijke interface voor het beheren van Elasticsearch. U kunt het gebruiken om grafieken te maken die dienstdoende technici 's nachts kunnen controleren.
De instapdrempel voor ELK is laag. Alle basisfuncties zijn gratis. Wat is er nog meer nodig voor geluk?
Hoe hebben we dit allemaal in één systeem samengevoegd?
We hebben indexen gemaakt en alleen de noodzakelijke informatie achtergelaten. We hebben alle drie de FortiWEB-logboeken in ELK geladen - de uitvoer was indexen. Dit zijn bestanden met alle verzamelde logs voor een periode, bijvoorbeeld een dag. Als we ze meteen zouden visualiseren, zouden we alleen de dynamiek van de aanvallen zien. Voor details moet je in elke aanval ‘invallen’ en naar specifieke velden kijken.
We realiseerden ons dat we eerst de analyse van ongestructureerde informatie moesten opzetten. We hebben lange velden in de vorm van tekenreeksen genomen, zoals 'Bericht' en 'URL', en deze geparseerd om meer informatie te verkrijgen voor de besluitvorming.
Met behulp van parseren hebben we bijvoorbeeld afzonderlijk de locatie van de gebruiker geïdentificeerd. Dit hielp om aanvallen vanuit het buitenland op sites voor Russische gebruikers onmiddellijk onder de aandacht te brengen. Door alle verbindingen vanuit andere landen te blokkeren, hebben we het aantal aanvallen met de helft teruggebracht en konden we aanvallen binnen Rusland rustig afhandelen.
Na het parseren gingen ze op zoek naar welke informatie ze moesten opslaan en visualiseren. Het was onpraktisch om alles in het dagboek achter te laten: de grootte van één index was groot: 7 GB. Het duurde lang voordat ELK het bestand verwerkte. Niet alle informatie was echter nuttig. Er werd iets gedupliceerd en nam extra ruimte in beslag - het was noodzakelijk om te optimaliseren.
In eerste instantie hebben we eenvoudigweg de index gescand en onnodige gebeurtenissen verwijderd. Dit bleek nog lastiger en langer dan het werken met logs op FortiWeb zelf. Het enige voordeel van de ‘kerstboom’ in dit stadium is dat we een grote tijdsperiode op één scherm konden visualiseren.
We wanhoopten niet, bleven cactussen eten, ELK bestuderen en geloofden dat we de nodige informatie zouden kunnen verkrijgen. Nadat we de indexen hadden schoongemaakt, begonnen we te visualiseren wat er is. Zo kwamen we bij grote dashboards. We hebben widgets geprikt - visueel en elegant, een echte ЁLKa!
Het moment van de aanval vastgelegd. Nu was het nodig om te begrijpen hoe het begin van de aanval er op de kaart uitziet. Om dit te detecteren, hebben we gekeken naar de reacties van de server op de gebruiker (retourcodes). We waren geïnteresseerd in serverreacties met dergelijke codes (rc):
Code (rc)
Naam
beschrijving
0
DROP
Het verzoek aan de server is geblokkeerd
200
Ok
Aanvraag succesvol verwerkt
400
Bad Request
Foute aanvraag
403
verboden
Autorisatie geweigerd
500
Internal Server Error
Dienst is niet beschikbaar
Als iemand de site begon aan te vallen, veranderde de verhouding van de codes:
- Als er meer foutieve verzoeken waren met code 400 en hetzelfde aantal normale verzoeken met code 200, dan probeerde iemand de site te hacken.
- Als tegelijkertijd de verzoeken met code 0 ook toenamen, ‘zagen’ politici van FortiWeb de aanval ook en pasten er blokkeringen op toe.
- Als het aantal berichten met code 500 toeneemt, betekent dit dat de site niet beschikbaar is voor deze IP-adressen - ook een vorm van blokkering.
Tegen de derde maand hadden we een dashboard opgezet om deze activiteit bij te houden.
Om niet alles handmatig te monitoren, hebben we de integratie met Nagios opgezet, die met bepaalde tussenpozen ELK ondervroeg. Als ik drempelwaarden constateerde die door codes werden bereikt, stuurde ik een melding naar de dienstdoende agenten over verdachte activiteiten.
Gecombineerde 4 kaarten in het monitoringsysteem. Nu was het belangrijk om in de grafieken het moment te zien waarop de aanval niet werd geblokkeerd en de tussenkomst van een ingenieur nodig was. Op 4 verschillende grafieken was ons oog wazig. Daarom combineerden we de kaarten en begonnen alles op één scherm te observeren.
Bij het monitoren hebben we gekeken hoe grafieken van verschillende kleuren veranderen. Een vleugje rood liet zien dat de aanval was begonnen, terwijl de oranje en blauwe grafieken de reactie van FortiWeb lieten zien:
Hier is alles in orde: er was een golf van ‘rode’ activiteit, maar FortiWeb ging ermee om en het aanvalsplan liep op niets uit.
We hebben ook voor onszelf een voorbeeld getekend van een grafiek die tussenkomst vereist:
Hier zien we dat FortiWeb de activiteit heeft vergroot, maar de rode aanvalsgrafiek is niet afgenomen. U moet uw WAF-instellingen wijzigen.
Ook het onderzoeken van nachtelijke incidenten is eenvoudiger geworden. De grafiek toont meteen het moment waarop het tijd is om het terrein te komen beschermen.
Dat gebeurt soms 's nachts. Rode grafiek - de aanval is begonnen. Blauw – FortiWeb-activiteit. De aanval werd niet volledig geblokkeerd, we moesten ingrijpen.
Waar gaan we naartoe?
Momenteel trainen we dienstdoende beheerders om met ELK te werken. Degenen die dienst hebben, leren de situatie op het dashboard in te schatten en een beslissing te nemen: het is tijd om te escaleren naar een FortiWeb-specialist, of het beleid op de WAF is voldoende om de aanval automatisch af te slaan. Op deze manier verminderen we de belasting van informatiebeveiligingsingenieurs 's nachts en verdelen we ondersteunende rollen op systeemniveau. Toegang tot FortiWeb blijft alleen voorbehouden aan het cyberdefensiecentrum, en alleen zij brengen wijzigingen aan in de WAF-instellingen wanneer dit absoluut noodzakelijk is.
Ook zijn wij bezig met rapportage voor klanten. We zijn van plan dat gegevens over de dynamiek van de WAF-operatie beschikbaar zullen zijn in het persoonlijke account van de klant. ELK zal de situatie duidelijker maken zonder de noodzaak om naar de WAF zelf te verwijzen.
Als de klant zijn bescherming in realtime wil monitoren, komt ELK ook van pas. We kunnen de toegang tot WAF niet weggeven, omdat inmenging van klanten in het werk gevolgen kan hebben voor anderen. Maar je kunt een aparte ELK pakken en deze geven om te "spelen".
Dit zijn de scenario's voor het gebruik van de kerstboom die we de laatste tijd hebben verzameld. Deel uw mening hierover en vergeet het niet om databaselekken te voorkomen.
Bron: www.habr.com