Vårt cyberförsvarscenter ansvarar för säkerheten för kundens webbinfrastruktur och avvisar attacker på klientwebbplatser. För att skydda mot attacker använder vi FortiWeb Web Application Firewalls (WAFs). Men även den coolaste WAF är inget universalmedel och skyddar inte "out of the box" från riktade attacker.
Därför använder vi, förutom WAF . Det hjälper till att samla alla händelser på ett ställe, samlar statistik, visualiserar det och låter oss se en riktad attack i tid.
Idag ska jag berätta mer i detalj hur vi korsade julgranen med WAF och vad som kom ut av det.
Historien om en attack: hur allt fungerade innan man bytte till ELK
I vårt moln har kunden implementerat applikationen bakom vår WAF. Från 10 000 till 100 000 användare anslutna till sajten per dag nådde antalet anslutningar 20 miljoner per dag. Av dessa var 3-5 användare inkräktare och försökte hacka sajten.
Den vanliga formen brute force från en IP-adress blockerades ganska enkelt av FortiWeb. Antalet träffar på webbplatsen per minut var högre än för legitima användare. Vi satte helt enkelt upp aktivitetströsklar från en adress och slog tillbaka attacken.
Det är mycket svårare att hantera "långsamma attacker", när angripare agerar långsamt och klär ut sig som vanliga klienter. De använder många unika IP-adresser. Sådan aktivitet såg inte ut som massiv brute force för WAF, det var svårare att spåra det automatiskt. Och det fanns också risken att blockera normala användare. Vi letade efter andra tecken på en attack och satte upp en policy för automatisk blockering av IP-adresser baserat på detta tecken. Till exempel hade många olagliga sessioner gemensamma fält i http-förfrågningshuvudena. Du var ofta tvungen att leta efter sådana fält manuellt i FortiWebs händelseloggar.
Det blev långt och obehagligt. I FortiWebs standardfunktioner registreras händelser i text i 3 olika loggar: upptäckta attacker, information om förfrågningar och systemmeddelanden om WAF-drift. Dussintals eller till och med hundratals attacker kan komma på en minut.
Inte så mycket, men du måste manuellt klättra genom flera stockar och iterera över många rader:
I attackloggen ser vi användaradresser och aktivitetens karaktär.
Det räcker inte att bara skanna loggtabellen. För att hitta det mest intressanta och användbara om attackens natur måste du titta in i en specifik händelse:
Markerade fält hjälper till att upptäcka "långsam attack". Källa: skärmdump från .
Tja, huvudproblemet är att bara en FortiWeb-specialist kan ta reda på det. Om vi under kontorstid fortfarande kunde spåra misstänkt aktivitet i realtid, kan utredningen av nattincidenter försenas. När FortiWeb-policyerna av någon anledning inte fungerade kunde nattskiftsingenjörerna i tjänst inte bedöma situationen utan tillgång till WAF och väckte FortiWeb-specialisten. Vi tittade igenom loggarna i flera timmar och fann ögonblicket för attacken.
Med sådana mängder information är det svårt att förstå helheten på ett ögonblick och agera proaktivt. Sedan bestämde vi oss för att samla in data på ett ställe för att analysera allt i en visuell form, hitta början på attacken, identifiera dess riktning och blockeringsmetod.
Vad valde du från
Först och främst tittade vi på lösningar som redan används, för att inte multiplicera enheter i onödan.
Ett av de första alternativen var Nagiossom vi använder för att övervaka , , nödlarm. Ordningsvakterna använder den också för att meddela skötarna vid misstänkt trafik, men den vet inte hur man samlar in spridda stockar och försvinner därför.
Det fanns ett alternativ att aggregera allt med MySQL och PostgreSQL eller annan relationsdatabas. Men för att ta fram data var det nödvändigt att skulptera din ansökan.
Som stocksamlare i vårt företag använder de också FortiAnalyzer från Fortinet. Men i det här fallet passade han inte heller. För det första är det mer skärpt att arbeta med en brandvägg FortiGate. För det andra saknades många inställningar och interaktion med det krävde utmärkta kunskaper om SQL-frågor. Och för det tredje skulle dess användning öka kostnaderna för tjänsten för kunden.
Det är så vi kom till öppen källkod i ansiktet ÄLG.
Varför välja ELK
ELK är en uppsättning program med öppen källkod:
- Elasticsearch - en databas med tidsserier, som just skapades för att arbeta med stora volymer text;
- Logstash – En datainsamlingsmekanism som kan konvertera loggar till önskat format;
- Kibana - en bra visualiserare, samt ett ganska vänligt gränssnitt för att hantera Elasticsearch. Du kan använda den för att bygga scheman som kan övervakas av tjänstgörande ingenjörer på natten.
Ingångströskeln för ELK är låg. Alla grundläggande funktioner är gratis. Vad mer behövs för lycka.
Hur fick du ihop det hela i ett system?
Skapade index och lämnade bara den nödvändiga informationen. Vi laddade in alla tre FortiWEB-loggarna i ELK - resultatet var index. Det här är filer med alla insamlade loggar för en period, till exempel en dag. Om vi visualiserade dem direkt skulle vi bara se dynamiken i attackerna. För detaljer måste du "falla igenom" i varje attack och titta på specifika fält.
Vi insåg att först måste vi ställa in analysen av ostrukturerad information. Vi tog långa fält som strängar, som "Meddelande" och "URL", och analyserade dem för att få mer information för beslutsfattande.
Till exempel, med hjälp av parsning, tog vi ut användarens plats separat. Detta hjälpte omedelbart att lyfta fram attacker från utlandet på webbplatser för ryska användare. Genom att blockera alla anslutningar från andra länder minskade vi antalet attacker med 2 gånger och kunde enkelt hantera attacker inne i Ryssland.
Efter att ha analyserat började de leta efter vilken information de skulle lagra och visualisera. Att lämna allt i loggen var olämpligt: storleken på ett index var stor - 7 GB. ELK tog lång tid att bearbeta filen. Men all information var inte användbar. Något duplicerades och tog extra utrymme – det var nödvändigt att optimera.
Till en början tittade vi helt enkelt igenom indexet och tog bort onödiga händelser. Detta visade sig vara ännu mer obekvämt och längre än att arbeta med loggar på själva FortiWeb. Det enda pluset från "julgranen" i detta skede är att vi kunde visualisera en stor tidsperiod på en skärm.
Vi misströstade inte, vi fortsatte att äta kaktusen och studera ELK och trodde att vi skulle kunna utvinna den nödvändiga informationen. Efter att ha rengjort indexen började vi visualisera vad som är. Så vi kom till stora instrumentpaneler. Vi petade widgets - visuellt och elegant, en riktig ЁLKa!
Fångade ögonblicket för attacken. Nu var det nödvändigt att förstå hur början av attacken ser ut på diagrammet. För att upptäcka det tittade vi på serverns svar till användaren (returkoder). Vi var intresserade av serversvar med sådana koder (rc):
Kod (rc)
namn
beskrivning
0
FALLA
Begäran till servern är blockerad
200
Ok
Begäran har bearbetats
400
Dålig förfrågan
Dålig förfrågan
403
Förbjudna
Auktorisering nekad
500
Internal Server Error
Tjänsten är inte tillgänglig
Om någon började attackera webbplatsen ändrades förhållandet mellan koderna:
- Om det fanns fler felaktiga förfrågningar med kod 400, och samma antal normala förfrågningar med kod 200, så försökte någon hacka sajten.
- Om samtidigt förfrågningar med kod 0 också växte, så "såg" även FortiWeb-politikerna attacken och applicerade block på den.
- Om antalet meddelanden med kod 500 ökade, så är sidan inte tillgänglig för dessa IP-adresser - också en sorts blockering.
Under den tredje månaden hade vi satt upp en instrumentpanel för att spåra denna aktivitet.
För att inte övervaka allt manuellt satte vi upp integration med Nagios, som frågade ELK med vissa intervall. Om den registrerade uppnåendet av tröskelvärden med koder, skickade den ett meddelande till tjänstemän om misstänkt aktivitet.
Kombinerade 4 sjökort i övervakningssystemet. Nu var det viktigt att se på graferna ögonblicket när attacken inte blockeras och ingripande av en ingenjör behövs. På 4 olika grafer var vårt öga suddigt. Därför kombinerade vi diagrammen och började observera allt på en skärm.
Vid övervakning såg vi hur grafer av olika färger förändras. Ett rött utbrott indikerade att attacken hade börjat, medan de orangea och blå graferna visade FortiWebs reaktion:
Allt är bra här: det var en uppsving av "röd" aktivitet, men FortiWeb klarade sig och attackschemat gick på intet.
Vi ritade också för oss själva ett exempel på en graf som kräver intervention:
Här kan vi se att FortiWeb har ökat aktiviteten, men den röda attackgrafen har inte minskat. Du måste ändra WAF-inställningarna.
Att utreda nattincidenter har också blivit lättare. Grafen visar omedelbart ögonblicket när det är dags att komma till försvaret av sajten.
Det är vad som händer ibland på natten. Röd graf - attacken har börjat. Blå - FortiWeb-aktivitet. Attacken var inte helt blockerad, vi var tvungna att ingripa.
Vart är vi på väg
Nu utbildar vi tjänstgöringsadministratörer att arbeta med ELK. Skötarna lär sig att bedöma situationen på instrumentpanelen och fatta ett beslut: det är dags att eskalera till en FortiWeb-specialist, annars räcker policyerna för WAF för att automatiskt avvärja attacken. Så vi minskar belastningen på informationssäkerhetsingenjörer på natten och delar upp rollerna i supporten på systemnivå. Tillgången till FortiWeb finns endast kvar hos cyberförsvarscentret, och endast de gör ändringar i WAF-inställningarna när det brådskande behövs.
Vi arbetar även med rapportering för kunder. Vi planerar att data om dynamiken i WAF-arbetet ska finnas tillgänglig på kundens personliga konto. ELK kommer att göra situationen tydligare utan att behöva hänvisa till själva WAF.
Om kunden vill övervaka sitt eget skydd i realtid kommer även ELK väl till pass. Vi kan inte ge bort tillgång till WAF, eftersom kundens ingripande i arbetet kan påverka resten. Men du kan plocka upp en separat ELK och ge den att "leka runt".
Det här är scenarierna för att använda julgranen som vi har samlat på oss på sistone. Dela dina tankar om detta och glöm inte för att undvika databasläckor.
Källa: will.com