Så langt i denne serien har vi dekket:
- Definere et omfang og fokus for SIM-kortet
- Viktigheten av å bygge stedet for å kjøpe ditt første system
- Arkitektur-og kapasitetsplanlegging
- Anbefalt faser av utplassering
- Velge en sentralisert logging serverplattform
- Hvordan godta eksterne loggoppføringer
- Facility, alvorlighetsgrad og prioritet
- Hvordan sortere loggmeldinger
- Konfigurere apparater og operativsystemer til å sende inn loggoppføringer
Cool. Så vi har loggoppføringene for en rekke systemer som blir samlet på en sentralisert server. Nå kommer den viktigste oppgaven, å utnytte denne informasjonen. Loggoppføringer vil bli gruppert i to kategorier; kritiske meldinger vi ønsker å vite om en gang, og oppføringer som vil bli fanget som en del av en regelmessig gjennomgang prosess.
Svartelisting Vs. Hvitlisting
Ved gjennomgang loggmeldinger, har vi to mulige positurer vi kan bruke. Den første kalles svartelisting. Med svartelisting metoden definerer vi hva som gjør en hendelse interessant nok til å rettferdiggjøre rapportering. Dette ligner på hvordan anti-virus programvare oppdager Malware eller prosessen vi bruke til å filtrere ut spam.
Som de fleste ting i livet, har svartelistet noen gode og dårlige sider. På pluss-siden, er det vanligvis ganske enkelt å skrive en signatur hvis vi vet hva vi ønsker å se etter. Signaturer kan bli tett definert til å bidra til å minimere antall falske positiver vi møter. Problemet med svartelisting er at vi må vite hva vi leter etter. Dersom et nytt angrep genererer en unik signatur vi aldri har møtt i det siste, vil en svartelisting system trolig glipp av hendelsen fordi ingen signatur har blitt definert.
Med hvitlisting definerer vi hendelsene vi forstår, og deretter fokusere på de nye og unike loggmeldinger som er oppstått. På plussiden er vi langt mer sannsynlig å fange cutting edge angrep. Hvitlisting tendens til å være relativt bråkete men siden vi er bundet til å møte unike loggmeldinger som ikke indikerer en sikkerhets hendelse.
Så hvilken skal vi bruke? Godt forsvar i dybden praksis si at vi skal bruke begge. 
Sanntids alarmering
Vi kan utnytte svartelistet å utføre sanntid varsling av hendelsen vi ønsker å bli gjort oppmerksom på så snart de oppstår. Svartelisting bør bare brukes for støysvake typer arrangementer. Med andre ord, ønsker vi å holde fast med å skrive signaturer for hendelser som har en høy sannsynlighet for å være en sann sikkerhetsproblem. Gode eksempler er:
- Ulike påloggingsnavnet svikt alt fra samme IP-adresse i løpet av kort tid
- Flere HTTP 403 feil som blir generert av en enkelt IP i løpet av kort tid
- Interne systemer får mange ICMP feil eller TCP nullstiller i løpet av kort tid
For å utføre sanntid varsling, må vi programvare som skal overvåke loggene i sanntid. Loggoppføringene bør kontrolleres opp mot definerte signaturer, noe som også indikerer hva man skal gjøre når hendelsen oppstår.
Swatch
En av de enkleste verktøy du kan bruke for overvåking loggoppføringene er Swatch . Swatch er basert på Perl. Dette betyr at mens det er konstruert for UNIX-og Linux-systemer, kan du få det kjører på Windows hvis du har Perl installert. Enkelhet er både Swatch største styrke og svakhet. Mens Swatch er relativt enkel å distribuere, det er også noe begrenset i sin funksjonalitet. Likevel, hvis du er ny til hogst, gjør Swatch en utmerket første verktøy for sanntids varsling.
Hvis du vil distribuere Swatch, må du lage en unik konfigurasjonsfil for hver loggfil du ønsker å overvåke. I konfigurasjonsfilen vil vi fortelle Swatch hva du skal se etter i den aktuelle loggfilen, og hva du skal gjøre når hendelsen er oppdaget.
For eksempel, la oss si at vi kommer til å ha Swatch overvåke webserveren feilloggen. Vi kan ønske å skape en oppføring som ligner på følgende i Swatch sin konfigurasjonsfil feilloggen:
# Se opp for bufferoverflyter
watchfor / klient avvist av server konfigurasjon | Filnavn for lang tid /
post = noc@fubar.org: webmaster@fubar.org, emne = webserver overløp forsøk
Linjen som begynner med en "#" er rett og slett kommentar til signaturen. Den watchfor linjen identifiserer hvilke tegnstreng (e) vi vil definere som å være interessant. I denne spesielle regelen har vi definert to forskjellige strenger, "klient avvist av server konfigurasjon" og "File name for lang" som interessant. Røret karakter mellom strengene virker som en logisk "eller". Hvis enten string er oppstått, definerer mail parameteren to forskjellige e-postadresser vi bør kontakte. Emnefeltet i e-posten skal være "Web server overflow forsøk», mens hoveddelen av e-posten skal være selve loggoppføringen.
Hvis det er andre mønstre vi ønsker å oppdage, kan vi legge til ytterligere watchfor og mail uttalelser. Hvis vi ønsker å gjøre mer enn å sende en e-post, kan exec parameteren brukes til å utføre alle programmer ligger på det lokale systemet. Terskelen parameteren kan også brukes til å rangere begrense rapportering av hendelser.
Enkelt hendelse koordinator (SEC)
SEC er en fantastisk varsler verktøy du kan laste ned fra hovedsiden nettstedet . Den støtter BSD og Linux, og leveres med en rekke populære Linux smaker. SEC støtter fullt regulære uttrykk og lar deg lage ekstremt detaljerte signaturer.
Regelen formatet er som følger:
type = Metode for påvisning
ptype = Mønster type (vanlig uttrykk, streng kamp)
mønster = Hva vil søke etter
desc = Beskrivelse (kan være en variabel)
action = Hva gjør du når oppdaget
Det er en utmerket arkiv over forhåndsskrevne reglene du kan bruke som er vel verdt å se på. Du kan matche på flere mønstre, definere flere terskler, alt mens behandling hundrevis av loggmeldinger per sekund. Om den eneste ulempen med SEC er at du trenger en god forståelse av regulære uttrykk for å bruke verktøyet effektivt. Likevel kan verktøyet være langt mer kraftig og fleksibel enn Swatch.
Hvor kan jeg få flere varslingstjenester ideer?
Jeg var involvert med etableringen av de opprinnelige SANS Topp 5 Logg rapporter . For i april, oppdatert 2009 Log toppmøtet jeg min presentasjon for å bryte opp rapporten eksempler på lav støy og høy støy kategorier. Noe på lav støy listen ville gjøre en god kandidat for varsling. Alt i den høye støyen delen er bedre overvåket gjennom daglige rapporter.
Daglige rapporter
Så vi utnyttet svartelistet å generere våre sanntid varsler. Vi vil nå utnytte hvitlisting å hjelpe fremheve ukjente men interessant trafikkmønsteret innenfor våre daglige rapporter.
Når det gjelder daglige rapporter, har vi en tendens til å bevege seg mot de store tallene. Hva er de 5 beste IP overføre data? Hvilken e-postadresse sendte flest meldinger? Mens de store tallene er absolutt viktig, har det vært min erfaring at sikkerhetshendelser du trenger å bekymre deg mest generere færrest loggoppføringene. De smarte Angriperne prøver veldig hardt å holde seg skjult i støy. Så den eneste måten å finne dem, er å senke signal til støyforhold.
Jeg forfatteren Perimeter Security banen for SANS. En av de labs jeg har mine elever utføre er å analysere en 200 000 linje loggfil. Målet er å oppdage interessante mønstre samt formulere gjennomgangen inn en automatisert prosess. De fleste folk finner havnen skanner som det er ganske bråkete. Noen selv spot IP-adressen utfører applikasjonslaget angrep mot webserveren. Hva folk flest savner imidlertid, er de seks linjene som er en ganske klar indikasjon på at et internt system er allerede kompromittert og ringer hjem for marsjordre. Hvordan finner du disse 6 linjer? Ved hvitlisting alt forstå deg og fokusere på hva noensinne som er igjen.
Så det er OK for våre daglige rapporter til å gi oss pene diagrammer med store tall. En av rapportene har imidlertid å kunne flytte alle crud til siden slik at vi kan bedre se de interessante patters.
Logwatch
En av de beste verktøyene for å gjøre en daglig logg vurdering er Logwatch . Logwatch vil oppsummere alle de log mønstre det forstår, mens fremhever noe uten en forhåndsdefinert signatur. Beste måten å forstå denne funksjonen er å se på et eksempel.
SSHD Drept: 2 Tid (s)
SSHD Startet: 1 Tid (s)
Tilkoblinger:
Mislykkede pålogginger fra disse:
msmith / passord fra 1.3.247.11: 6 time (s)
jsmith / passord fra 1.3.247.11: 5 time (s)
psmith / passord fra 1.3.247.11: 4 time (s)
Brukere logger inn gjennom sshd:
jjones logget inn fra solnedgang (1.3.247.9) med publickey: 146 Times (s)
jsmith logget inn fra dialup5533.wnskvtao.sover.net (216.114.181.200) ved hjelp av passord: 1 Times (s)
jsmith logget inn fra dialup984.wnskvtao.sover.net (216.114.163.223) ved hjelp av passord: 1 Times (s)
Bjones logget inn fra Charlie (1.3.247.11) bruker publickey: 444 ganger (s)
jsmith logget inn fra 192.168.1.173 bruke passordet: 2 ganger (s)
djones logget inn fra Charlie (1.3.247.11) ved hjelp av passord: 47 ganger (s)
** Umatchede Entries **
Mottatt koble fra 148.64.147.168: 3: Nøkkel utveksling mislyktes.
Mottatt disconnect fra 216.114.160.132: 11: Alle åpne kanaler stengt
scannet fra 146.87.114.150 med SSH-1.0-SSH_Version_Mapper. Ikke få panikk.
scannet fra 211.184.226.99 med SSH-1.0-SSH_Version_Mapper. Ikke få panikk.
I eksempelet ovenfor Logwatch brukes til å oppsummere SSH aktivitet. Det forstår tjenesten bli stoppet og startet, klarte påloggingsforsøk samt vellykkede pålogginger. All denne informasjonen vises i sammendraget format slik at det er lettere å fordøye. For eksempel vet vi ikke nøyaktig når msmith angitt feil passordet sitt, men vi ser det skjedd seks ganger, alt fra IP-adressen 1.3.247.11. Så i stedet for å måtte seks linjer å fordøye, vi trenger bare å se på en. Hvis vi ønsker å se hvert enkelt loggoppføringen, kan vi alltid se tilbake til den opprinnelige loggene.
Nå se på "Umatchede Entries"-delen. Hver av disse er en hendelse som Logwatch ikke har en signatur for. Snarere enn ignorere dem, som ville skje med en svarteliste-basert system, de er oppsummert her for oss å vurdere. Vi får deretter muligheten til å generere en signatur for en bestemt oppføring, så det vil bli kategorisert i en lignende måte til prosessen og pålogging seksjoner.
Klart dette gir oss det beste fra begge verdener. Rapporten ovenfor representerer litt over 650 linjer verdt loggoppføringene, oppsummeres ned i en lettlest rapport. Viktigst, hadde ingen av de loggoppføringene å bli ignorert for å produsere denne sammendragsrapport.
Utover daglig rapportering
Du kan også finne det nyttig å utføre langsiktig trend analyse og data mining på loggdata. Dette kan bidra til å avdekke mønstre som normalt gå ubemerket når logger for en liten øyeblikksbilde i tid (som 24 timer) er anmeldt. Uten tvil en av de beste verktøyene som er tilgjengelige for å håndtere mye data blir Splunk .
Splunk
Splunk er tilgjengelig som en gratis versjon som er begrenset til å behandle 500 MB per dag, eller du kan investere i den kommersielle versjonen som støtter ubegrenset databehandling. Splunk er ekstremt fleksibel til å akseptere data. Det kan fungere som en sentralisert logging server, eller du kan overføre filer via en rekke metoder, inkludert FTP og HTTP. Når dataene er mottatt, alle felt Splunk indekser i hver loggfil. Dette gir deg enestående sortering og søking evne.
Den fullstendige funksjoner Splunk er for mange å komme inn i dette innlegget. Sjekk deres nettsted for en full liste over støttede funksjoner. Hva Splunk er ekstremt god på er å manipulere og rapportering på et stort antall oppføringer. Det kan indeksere, søke og rapportere om milliarder av loggoppføringene per sekund. Dette gjør det ekstremt nyttig for å generere langsiktig trend rapporter eller kjører lagrede søk for data mining formål.
Exec Oppsummering
Vi har vi nådd slutten av stien. Forhåpentligvis du føler at du har en bedre håndtak på hvordan du distribuerer en sentralisert logging løsning, samt hvordan å utnytte til det bedre sikre ditt miljø. Hvis du har spørsmål, kan du gjerne droppe en kommentar. 
Relaterte innlegg:
