Hittills i denna serie har vi täckt:
- Definiera en omfattning och inriktning för ditt SIM-
- Vikten av att bygga istället för att köpa din första systemet
- Arkitektur och kapacitetsplanering
- Rekommenderad faser av utbyggnaden
- Välja en centraliserad plattform för loggning server
- Hur man acceptera avlägsna loggposter
- Facility, svårighetsgrad och prioritering
- Så här sorterar loggmeddelanden
- Konfigurera apparater och operativsystem lämna loggposter
Cool. Så vi har loggposter för ett antal system som samlas på en central server. Nu kommer den viktigaste uppgiften, att utnyttja denna information. Logga poster kommer att grupperas i två kategorier; kritiska meddelanden vill vi veta om direkt, och loggposter som får fångas som del av en regelbunden översyn.
Svartlistning Vs. Vitlistning
När du granskar loggmeddelanden har vi två möjliga ställningar vi kan använda. Den första kallas för svartlistning. Med svartlistning metod vi definiera vad som gör en händelse intressant nog för att motivera rapportering. Detta liknar hur antivirusprogram upptäcker Malware eller processen vi använder för att filtrera bort spam.
Liksom det mesta i livet, har svartlistning några bra och dåliga aspekter. På plussidan är det oftast ganska lätt att skriva en signatur om vi vet vad vi vill leta efter. Signaturer kan väl definieras för att minimera antalet falska positiva vi möter. Problemet med svartlistning är att vi måste veta vad vi letar efter. Om en ny attack genererar en unik signatur vi har aldrig stött på tidigare kommer en svartlistning systemet missar troligen den händelsen eftersom ingen signatur har definierats.
Med vitlistning vi definierar de händelser vi förstår, och sedan fokusera vår uppmärksamhet på den nya och unika loggmeddelanden som påträffas. På plussidan vi är långt mer benägna att fånga framkant attacker. Vitlistning tenderar att vara relativt högljudd men eftersom vi är bundna att stöta unika logga meddelanden som inte vittnar om en säkerhet händelse.
Så vilka ska vi använda? Bra försvar på djupet praxis berätta att använda båda. 
Realtid larma
Vi kan dra nytta av svartlistning för att utföra realtid varna för händelsen vill vi vara medvetna om att så snart de uppstår. Svartlistning bör endast användas för låg ljudnivå typer av evenemang. Med andra ord vill vi hålla fast vid att skriva signaturer för händelser som har en hög sannolikhet för att vara en sann säkerhetsproblem. Bra exempel är:
- Olika inloggningsnamn misslyckanden allt från samma IP-adress i en kort tid
- Flera HTTP 403 fel som genereras av en enda IP på kort tid
- Interna system tar emot många ICMP fel eller TCP återställs på kort tid
För att kunna utföra realtid larma behöver vi program som kommer att övervaka loggar i realtid. Loggposterna bör kontrolleras mot definierade signaturer, som också ange vad de ska göra när händelsen inträffar.
Swatch
Ett av de enklaste verktyg du kan använda för poster övervakning logg är Swatch . Swatch är baserad på Perl. Detta innebär att medan den är avsedd för UNIX-och Linux-system, kan du få det körs på Windows om du har Perl installerat. Enkelhet är både Swatch största styrka och svaghet. Medan Swatch är relativt lätt att installera, det är också något begränsad i sin funktionalitet. Men ändå, om du är ny på loggning, gör Swatch en utmärkt första verktyg för att i realtid varna.
Om du vill distribuera Swatch, måste du skapa en unik konfigurationsfil för varje loggfil du vill bevaka. I konfigurationsfilen så berättar vi Swatch vad man ska leta efter i just loggfil, och vad man ska göra när händelsen upptäcks.
Till exempel, låt oss säga att vi kommer att ha Swatch följa webbserverns felloggen. Vi kanske vill skapa en post av följande slag i Swatch: s konfigurationsfil för felloggen:
# Håll utkik efter buffertspill
watchfor / klient förnekas av serverkonfigurationen | Filnamn för lång tid /
mail = noc@fubar.org: webmaster@fubar.org, Ämne = webbserver overflow försök
Den rad som börjar med ett "#" är helt enkelt kommentar på signaturen. Den watchfor raden identifierar vilken teckensträng (s) vill vi definiera som intressant. I denna regel har vi definierat två olika strängar, "klient förnekas av server konfiguration" och "Filnamn för lång" så intressant. Röret karaktär mellan strängarna fungerar som en logisk "eller". Om någon sträng påträffas definierar post parametern två olika e-postadresser vi ska kontakta. Ämnesraden på e-mail kommer att "Webbserver overflow försök", medan kroppen av e-post kommer att vara den faktiska loggpost.
Om det finns andra mönster vi vill upptäcka, kan vi lägga till ytterligare watchfor och uttalanden post. Om vi vill göra mer än att skicka e-post kan exec parametern användas för att köra alla program ligger på det lokala systemet. Tröskeln parameter kan också användas för att betygsätta begränsa rapportering av händelser.
Enkel Event Coordinator (SEK)
SEC är en otrolig varnar verktyg som du kan ladda ner från den huvudsakliga webbplatsen . Den stöder BSD och Linux, och levereras med ett antal populära Linux-smaker. SEC stöder fullt reguljära uttryck och gör att du kan skapa extremt korniga signaturer.
Regeln formatet är som följer:
type = metod för spårning
ptype = Mönster typ (reguljärt uttryck, sträng match)
mönster = Vad du ska söka efter
desc = Beskrivning (kan vara en variabel)
action = Vad gör när de upptäcks
Det finns ett utmärkt arkiv av redan skrivna regler som du kan använda som är väl värt att titta på. Du kan matcha på flera mönster, definiera flera trösklar, allt medan bearbetning hundratals loggmeddelanden per sekund. Om enda nackdelen av SEC är att du behöver en god förståelse för reguljära uttryck att använda verktyget effektivt. Ändå kan verktyget vara mycket mer kraftfulla och flexibla än Swatch.
Var kan jag få fler varningar idéer?
Jag var involverad i skapandet av den ursprungliga SANS Top 5 Logga rapporter . För april 2009 Logga toppmötet Jag uppdaterade min presentation för att bryta upp rapporten exempel på låg ljudnivå och hög kategorier buller. Något på låg ljudnivå listan skulle göra en bra kandidat för att varna. Allt i det höga bullret avsnittet är bättre monitoreras genom dagliga rapporter.
Dagliga rapporter
Så vi belånade svartlistning att generera vår realtid varningar. Vi kommer nu dra nytta av vitlistning för att lyfta fram okända men intressant trafikmönster i våra dagliga rapporter.
När det gäller dagliga rapporter, tenderar vi att dras mot de stora siffrorna. Vilka är de 5 IPs överföra data? Vilken e-postadress skickas de meddelanden? Medan de stora siffrorna är visserligen viktiga, har det varit min erfarenhet att säkerheten händelser du behöver oroa dig för de mest genererar minst antal loggposter. Den smarta Angriparna försöker väldigt hårt att vara gömda i bruset. Så det enda sättet att hitta dem är att sänka signal-brus-förhållande.
Jag författaren banan Områdesskydd för SAN. En av labben har jag mina elever gör är att tolka en 200.000 linje loggfil. Målet är att upptäcka intressanta mönster samt formulera en översyn i en automatiserad process. Mest folk hittar portskanner eftersom det är ganska bullrigt. Vissa plats ens IP-adress att utföra attacker applikationslagret mot webbservern. Vad de flesta människor missar dock är de sex linjer som är en ganska klar indikation på att ett internt system som redan äventyras och ringer hem för marschorder. Hur hittar man de 6 rader? Genom vitlistning allt du förstår och fokusera på vad som någonsin är kvar.
Så det är OK för vårt dagliga rapporter ger oss rätt diagram med stora siffror. En av rapporterna har dock kunna flytta alla crud åt sidan så att vi kan bättre upptäcka intressanta mönster.
Logwatch
Ett av de bästa verktygen för att göra en daglig logg översyn logwatch . Logwatch sammanfattar alla log mönster den förstår och framhävt något utan en fördefinierad signatur. Bästa sättet att förstå denna funktion är att titta på ett exempel.
SSHD Dödade: 2 Tid (s)
SSHD startat: 1 Tid (s)
Anslutningar:
Misslyckades inloggningar från dessa:
msmith / lösenord från 1.3.247.11: 6 (s)
jsmith / lösenord från 1.3.247.11: 5 (s)
psmith / lösenord från 1.3.247.11: 4 (s)
Användare loggar in via sshd:
jjones loggade in från solnedgången (1.3.247.9) med PublicKey: 146 Times (s)
jsmith loggade in från dialup5533.wnskvtao.sover.net (216.114.181.200) med lösenord: 1 gånger (s)
jsmith loggade in från dialup984.wnskvtao.sover.net (216.114.163.223) med lösenord: 1 gånger (s)
Bjones loggade in från Charlie (1.3.247.11) med PublicKey: 444 Times (s)
jsmith loggade in från 192.168.1.173 använda lösenord: 2 gånger (s)
djones loggade in från Charlie (1.3.247.11) med hjälp av lösenord: 47 gånger (s)
** Oöverträffad Inlägg **
Fick koppla från 148.64.147.168: 3: Key utbyte misslyckades.
Fick koppla från 216.114.160.132: 11: Alla öppna kanaler stängt
skannats från 146.87.114.150 med SSH-1.0-SSH_Version_Mapper. Få inte panik.
skannats från 211.184.226.99 med SSH-1.0-SSH_Version_Mapper. Få inte panik.
I exemplet ovan logwatch används för att sammanfatta SSH aktivitet. Det förstår den service som startas och stoppas, misslyckade inloggningsförsök och inloggningarna som lyckas. All denna information visas i sammandrag-format så det är lättare att smälta. Till exempel vet vi inte exakt när msmith felaktigt in sitt lösenord, men vi ser det hänt sex gånger, allt från IP-adress 1.3.247.11. Så istället för att ha sex linjer för att smälta, behöver vi bara titta på en. Om vi vill se varje enskild loggpost, kan vi hänvisa alltid tillbaka till den ursprungliga stockarna.
Nu titta på "Oöverträffad Entries"-avsnittet. Alla dessa är en händelse som logwatch inte har en signatur för. Hellre än att ignorera dem, vilket skulle hända med en svartlista baserat system, de sammanfattas här för oss att granska. Vi har då möjlighet att skapa en signatur för en specifik post, så det får kategoriseras på ett liknande sätt till processen och sektioner inloggning.
Tydligt detta ger oss det bästa av båda världar. Ovanstående rapport är lite över 650 linjer till ett värde av loggposter, sammanfattas ner i en lättläst rapport. Viktigast av allt, hade ingen av loggposterna som ska ignoreras för att producera denna sammanfattande rapport.
Förutom daglig rapportering
Du kan också vara bra att utföra långsiktiga trenden analys och data mining på dina loggdata. Detta kan bidra till att avslöja mönster som normalt inte upptäcks när de loggar för en liten ögonblicksbild i tid (som 24 timmar) ses över. Förmodligen en av de bästa verktyg som finns tillgängliga för att hantera stora mängder data är Splunk .
Splunk
Splunk är tillgänglig som en gratis version som är begränsad till behandling 500 MB per dag, eller så kan du investera i den kommersiella versionen som stöder obegränsad databehandling. Splunk är mycket flexibel i att acceptera data. Den kan fungera som en centraliserad loggning server, eller så kan du överföra filer via ett antal metoder, inklusive FTP och HTTP. När data tas emot, varje område Splunk index i varje loggfil. Detta ger dig oöverträffad sortering och sökning kapacitet.
Den fullständiga funktioner är Splunk är för många att komma in i det här inlägget. Kolla deras hemsida för en fullständig lista över funktioner som stöds. Vad Splunk är extremt bra på är att manipulera och rapportera om ett stort antal loggposter. Det kan indexera, söka och rapportera om miljarder loggposter per sekund. Detta gör det mycket användbart för att generera långsiktiga trenden rapporter eller köra sparade sökningar för datautvinning.
Exec Sammanfattning
Vi har vi kommit till slutet av spåret. Förhoppningsvis du tycker att du har ett bättre grepp om hur du distribuerar en centraliserad loggning lösning, samt hur du kan utnyttja den för att bättre säkra din omgivning. Om du har några frågor är du välkommen att släppa en kommentar. 
Relaterade inlägg:
