chrisbrenton.org

Uw bron voor onzichtbare beveiliging bug spray

Het opzetten van een Security Information Management System-Part 6

20 augustus 2009 door Chris Verlaat een antwoord »

Tot nu toe in deze serie hebben we aan bod:

Het definiëren van een scope en focus voor uw SIM-
Belang van de opbouw in plaats van het kopen van uw eerste systeem
Architectuur en capaciteitsplanning
Aanbevolen fasen van implementatie
Het selecteren van een centrale logging server platform
Hoe kan ik op afstand inloggen Vermelding
Facility, ernst en prioriteit
Hoe in te loggen berichten te sorteren
Configureren van apparaten en besturingssystemen om in te loggen inzendingen in te dienen

Cool. Dus hebben we logboekgegevens voor een aantal systemen wordt verzameld op een centrale server. Nu komt de belangrijkste taak, gebruik te maken van die informatie. Log inzendingen worden ingedeeld in twee categorieën; kritische berichten willen we weten meteen, en log-items die zal komen te zitten, als onderdeel van een regelmatige evaluatie proces.

Blacklisting Vs. Whitelisting

Bij de evaluatie van log-berichten, hebben we twee mogelijke houdingen die we kunnen gebruiken. De eerste is bedoeld als blacklisting. Met de zwarte lijst methode definiëren we wat een evenement interessant genoeg is om rapportage te rechtvaardigen. Dit is vergelijkbaar met hoe de anti-virus software malware of het proces dat we gebruiken voor het filteren van spam detecteert.

Zoals de meeste dingen in het leven, de zwarte lijst heeft een aantal goede en slechte aspecten. Aan de positieve kant, is het meestal vrij eenvoudig om een handtekening te schrijven als we weten wat we willen zoeken. Handtekeningen nauwkeurig kunnen worden gedefinieerd om te helpen minimaliseren van het aantal false positives die we tegenkomen. Het probleem met zwarte lijst is dat we weten wat we zoeken. Als er een nieuwe aanval genereert een unieke handtekening we nog nooit zijn tegengekomen in het verleden, zal een zwarte lijst systeem waarschijnlijk missen evenement omdat er geen handtekening is gedefinieerd.

Met whitelisting definiëren we de evenementen die we begrijpen, en dan onze aandacht richten op de nieuwe en unieke log berichten die worden aangetroffen. Aan de positieve kant zijn we veel meer kans op te vangen cutting edge aanvallen. Whitelisting meestal echter relatief luidruchtig, omdat we gebonden zijn aan een unieke loggen berichten die niet indicatief zijn voor een security event ontmoeting.

Dus die moeten we gebruiken? Goede verdediging in de diepte-praktijken vertellen ons beide te gebruiken.

Real time waarschuwingen

We kunnen gebruik maken van zwarte lijsten in real-time waarschuwingen van het evenement willen we bewust worden gemaakt van zodra ze zich voordoen uit te voeren. Zwarte lijst mag alleen worden gebruikt voor een laag geluidsniveau soorten evenementen. Met andere woorden, we willen aan de stok met het schrijven van handtekeningen voor gebeurtenissen die een grote kans om een echte beveiligingsprobleem hebben. Goede voorbeelden zijn:

Andere aanmeldingsnaam mislukkingen allemaal uit hetzelfde IP-adres in een korte tijd
Meerdere HTTP 403 fouten worden gegenereerd door een enkel IP in een korte tijd
Interne systemen het ontvangen van vele ICMP fouten of TCP-resets in een korte tijd

Om de real-time waarschuwingen uit te voeren, moeten we software die de logs zal toezien op in real time. De logboekvermeldingen moet getoetst worden gedefinieerd handtekeningen, die ook aangeven wat te doen wanneer de gebeurtenis plaatsvindt.

Swatch

Een van de gemakkelijkste tools die u kunt gebruiken voor monitoring logboekvermeldingen is Swatch . Swatch is gebaseerd op Perl. Dit betekent dat, hoewel het is ontworpen voor UNIX-en Linux-systemen, kun je het krijgen draait op Windows als je Perl is geïnstalleerd. Eenvoud is zowel Swatch grootste kracht en zwakte. Terwijl de Swatch is relatief eenvoudig te implementeren, is het ook enigszins beperkt in zijn functionaliteit. Toch, als je nieuw bent bij houtkap, Swatch is een uitstekend eerste hulpmiddel voor real-time waarschuwingen.

Voor de implementatie van Swatch, moet u een unieke configuratiebestand maken voor elke log-bestand dat u wilt controleren. In het configuratiebestand zullen we vertellen Swatch wat te zoeken in die bepaalde log-bestand, en wat te doen wanneer de gebeurtenis wordt gedetecteerd.

Bijvoorbeeld, laten we zeggen dat we zullen moeten Swatch toezicht op de Web server error log. Wij kunnen wensen om een soortgelijke vermelding van de volgende in de configuratie van de Swatch-bestand voor de error log te maken:

# Kijk uit voor buffer overflows
watchfor / client-server configuratie ontkend door | Bestandsnaam te lang /
mail = noc@fubar.org: webmaster@fubar.org, subject = Web server overflow poging

De regel die begint met een "#" is gewoon commentaar op de handtekening. De watchfor lijn geeft aan welke tekenreeks (s) willen we definiëren als zijnde interessant. In dit specifieke regel die we hebben gedefinieerd twee verschillende strings, 'client ontkend door server configuratie "en" File name too long "zo interessant. De pijp karakter tussen de snaren fungeert als een logische "of". Als een van beide string is aangetroffen, de e-mail parameter definieert twee verschillende e-mail adressen die we moeten contact opnemen. De onderwerpregel van de e-mail zal worden "Web server overflow poging", terwijl het lichaam van de e-mail zal de werkelijke logboekvermelding worden.

Als er andere patronen die we wensen op te sporen, kunnen voegen we extra watchfor en mail verklaringen. Als we meer willen dan stuur een e-mail te doen, kan de exec parameter gebruikt worden voor elke toepassing op het lokale systeem uit te voeren. De drempel parameter kan ook worden gebruikt om te beoordelen beperking van de rapportage van de gebeurtenissen.

Simple Event Coordinator (SEC)

SEC is een geweldig hulpmiddel waarschuwt u kunt downloaden van de belangrijkste website . Het ondersteunt BSD en Linux, en wordt geleverd met een aantal populaire Linux-smaken. SEC biedt volledige ondersteuning voor reguliere expressies en maakt het mogelijk om uiterst granulaire handtekeningen.

De regel indeling is als volgt:

type = Detectiemethode
ptype = Patroon type (reguliere expressie, string match)
patroon = Wat te zoeken naar
desc = Beschrijving (kan een variabele zijn)
action = Wat te doen bij detectie

Er is een uitstekend archief van pre-geschreven regels die u kunt gebruiken, dat is de moeite waard om te kijken naar. U kunt de match op meerdere patronen, definiëren meerdere drempels, alle tijdens het verwerken van honderden van log berichten per seconde. Over het enige nadeel van de SEC is dat je een nodig hebt goed begrip van reguliere expressies om de tool te effectief te gebruiken. Toch kan het instrument worden veel krachtiger en flexibeler dan Swatch.

Waar kan ik meer te waarschuwen ideeën?

Ik was betrokken bij de oprichting van de originele SANS Top 5 Log Reports . Voor april 2009 Log Summit Ik bijgewerkt mijn presentatie op te breken rapport voorbeelden in een laag geluidsniveau en een hoge ruis categorieën. Alles wat aan de lage ruis lijst zou een goede kandidaat voor het alarmeren. Alles wat in de hoge ruis sectie is beter bewaakt door dagelijkse rapporten.

Dagelijkse rapporten

Dus we leveraged zwarte lijst op onze real-time waarschuwingen te genereren. We zullen leverage whitelisting nu te markeren onbekende maar interessante patronen te helpen binnen onze dagelijkse rapporten.

Als het gaat om dagelijkse rapporten, hebben we de neiging om te neigen naar de grote getallen. Wat zijn de top 5 IPs de overdracht van gegevens? Welke e-mail adres verzonden meeste berichten? Terwijl de grote getallen zijn zeker belangrijk, is mijn ervaring dat de veiligheid gebeurtenissen die u zorgen hoeft te maken over de meest de minste logboekvermeldingen te genereren. De slimme aanvallers doen hun uiterste best te blijven verborgen in de ruis. Dus de enige manier om ze te vinden is om het signaal te verlagen tot ruis verhouding.

Ik heb de auteur van het Perimeter Security baan voor SANS. Een van de labs heb ik mijn leerlingen uit te voeren is naar een parse 200.000 lijn logbestand. Het doel is om de interessante patronen plek evenals de herziening te formuleren in een geautomatiseerd proces. De meeste mensen vinden de haven scanner zoals het is behoorlijk lawaaierig. Sommigen zelfs ter plaatse van de IP-adres het uitvoeren van de applicatielaag aanvallen op de webserver. Wat de meeste mensen wel missen, zijn de zes lijnen die een vrij duidelijke aanwijzing dat een intern systeem wordt gecompromitteerd en naar huis bellen voor de marsorders. Hoe vind je die zes lijnen? Door whitelisting alles wat je te begrijpen en zich te concentreren op wat ooit is gelaten.

Dus het is OK voor onze dagelijkse rapporten om ons mooie grafieken met grote getallen. Een van de rapporten is echter in staat om alle crud te verplaatsen naar de zijkant, zodat we beter kunnen ter plaatse de interessante patronen.

Logwatch

Een van de beste tools voor het doen van een dagelijks een logboek bij beoordeling is logwatch . Logwatch vat alle van de log patronen begrijpt, terwijl de nadruk iets zonder een vooraf gedefinieerde handtekening. De beste manier om deze functie te begrijpen is om te kijken naar een voorbeeld.

Gedood SSHD: 2 Time (s)
SSHD gestart: 1 Time (s)
Aansluitingen:
Mislukte logins van deze:
msmith / wachtwoord van 1.3.247.11: 6 tijd (s)
jsmith / wachtwoord van 1.3.247.11: 5 keer (s)
psmith / wachtwoord van 1.3.247.11: 4 tijd (s)
Gebruikers loggen in via sshd:
jjones aangemeld van zonsondergang (1.3.247.9) met behulp van publieke sleutels: 146 Times (s)
jsmith aangemeld uit dialup5533.wnskvtao.sover.net (216.114.181.200) using password: 1 Times (s)
jsmith aangemeld uit dialup984.wnskvtao.sover.net (216.114.163.223) using password: 1 Times (s)
bjones aangemeld van Charlie (1.3.247.11) met behulp van publieke sleutels: 444 Times (s)
jsmith aangemeld vanaf 192.168.1.173 using password: 2 Times (s)
djones aangemeld van Charlie (1.3.247.11) using password: 47 Times (s)
** Ongeëvenaarde Inzendingen **
Ontvangen loskoppelen van 148.64.147.168: 3: Key uitwisseling mislukt.
Ontvangen loskoppelen van 216.114.160.132: 11: Alle open kanalen gesloten
gescand uit 146.87.114.150 met SSH-1.0-SSH_Version_Mapper. Raak niet in paniek.
gescand van 211.184.226.99 met SSH-1.0-SSH_Version_Mapper. Raak niet in paniek.

In het bovenstaande voorbeeld logwatch wordt gebruikt om SSH-activiteit samen te vatten. Begrijpt de dienst die wordt gestopt en gestart, mislukte aanmeldingspogingen als geslaagde aanmelding. Al deze informatie wordt weergegeven in beknopte vorm zodat het makkelijker te verteren. Bijvoorbeeld weten we niet precies wanneer msmith incorrect hun wachtwoord hebt ingevoerd, maar we zien het gebeurde zes keer al, vanaf IP-adres 1.3.247.11. Dus in plaats van zes lijnen te verteren, hoeven we alleen te kijken naar een. Als we willen elke specifieke log entry zien, kunnen we altijd terug verwijzen naar de originele logs.

Kijk nu naar de "Ongeëvenaarde Entries" sectie. Elk van deze is een gebeurtenis die logwatch niet een handtekening voor. In plaats van te negeren, wat zou er gebeuren met een zwarte lijst op basis van het systeem, zijn ze hier samengevat voor ons om. We hebben dan de mogelijkheid om een handtekening voor een specifieke vermelding te genereren, zodat het zal je ingedeeld op een soortgelijke wijze als het proces en aanmelding secties.

Het is duidelijk dat dit geeft ons het beste van twee werelden. Het bovenstaande verslag is een beetje meer dan 650 lijnen ter waarde van logboekvermeldingen, samengevat naar beneden in een gemakkelijk te lezen rapport. Het belangrijkste is dat geen van de logboekvermeldingen moesten worden genegeerd om deze samenvatting te produceren.

Beyond dagelijkse rapportage

U kunt ook het nuttig vinden om op lange termijn trend analyses en datamining uitvoeren op uw log gegevens. Dit kan helpen om patronen die normaal onopgemerkt blijven bij het logboek voor een kleine momentopname in de tijd (net als 24 uur) is beoordeeld onthullen. Ongetwijfeld een van de beste tools beschikbaar zijn voor het omgaan met veel data is splunk .

Splunk

Splunk is beschikbaar als een gratis versie die beperkt is tot de verwerking van 500 MB per dag, of u kunt investeren in de commerciële versie die onbeperkt data-verwerking ondersteunt. Splunk is uiterst flexibel op de aanvaarding van gegevens. Het kan fungeren als een centrale logging server, of u kunt bestanden via een aantal methoden, inclusief FTP en HTTP. Zodra de gegevens zijn ontvangen, elk veld splunk indexen in elk logbestand. Dit geeft u ongeëvenaarde sorteren en zoeken mogelijkheden.

De volledige functies zijn splunk zijn te talrijk om in in dit bericht. Check hun site voor een volledige lijst van ondersteunde functies. Wat splunk is erg goed in zijn is het manipuleren van en rapporteren over een groot aantal logboekvermeldingen. Het kan indexeren, zoeken en rapporteren over miljarden logboekvermeldingen per seconde. Dit maakt het uiterst nuttig voor het genereren van langdurige trend rapporten of hardlopen opgeslagen zoekopdrachten voor data mining doeleinden.

Exec Samenvatting

We zullen we aan het einde van het parcours. Hopelijk bent u het gevoel dat je een betere greep op hoe je een centrale logging oplossing, en hoe als hefboom te gebruiken om betere beveiliging van uw omgeving te implementeren. Als u vragen heeft, aarzel dan niet om een reactie te laten vallen.