Archief voor de 'Logging' categorie

De combinatie van logwatch en OSSEC - Deel 4

18 februari 2010

In mijn laatste bericht installeerden we logwatch als OSSEC. Het is nu tijd om logwatch en OSSEC samen spelen in dezelfde zandbak. In deze post zal ik bespreken hoe om te logwatch naar de informatie die wordt gegenereerd door OSSEC samen te vatten.

Deployment Options

We hebben twee paden die we kunnen volgen om dit op te zetten:

  1. Hebben logwatch direct ontleden de OSSEC logs.
  2. Hebben OSSEC haar waarschuwingen worden verzonden naar een Syslog-server typen, ren dan logwatch op de Syslog-server.

Het voordeel voor optie # 1 is dat we slechts een systeem nodig hebben. Logwatch zal worden uitgevoerd op het systeem als gastheer van de OSSEC server. Het probleem dat we gaan tegenkomen maar heeft betrekking op de OSSEC alert bestand. Logboekvermeldingen niet krijgen genormaliseerd. Dit betekent dat het formaat kan je veranderen van de toegang tot entry, en kan zelfs verspreid over meerdere regels. Het wordt een echte nachtmerrie voor een logwatch script dat zal filteren en een overzicht van de alert informatie te creëren.

Als we met optie # 2, zullen we nodig hebben nog een box op te treden als onze centrale logging server. Met het oog op de OSSEC server log Vermelding van niet-agent systemen, heeft het te luisteren op UDP/514. Dit is dezelfde poort die wordt gebruikt door een centrale logging server, en je kunt geen twee applicaties dezelfde poort (behalve met Windows, maar socket toegang is erg rommelig). Aan de positieve kant, verschijnt de melding inzendingen krijgen genormaliseerd als ze worden doorgegeven aan de Syslog-server, zodat het maken van een samenvatting logwatch script zal veel gemakkelijker. Verder logwatch weet nu al over de standaard Syslog-bestanden, dus we hebben minder aanpassingen werk te doen.

Ten slotte heb ik vermeld in een eerder bericht dat OSSEC niet is ontworpen om een ​​SIM-kaart te zijn. Dit komt omdat het niet alles op, alleen de gebeurtenissen die een waarschuwing genereren. Dus we gaan waarschijnlijk naar een centrale server toch wilt, en is het zinvol om te slaan van de informatie die wordt gegenereerd door OSSEC.

Dus als het klinkt alsof ik stuur je naar optie # 2, bent u absoluut correct. Met dat gezegd, ben ik eigenlijk ga optie # 1 te dekken omdat het een veel ingewikkelder.

Omgaan met datum / tijd stempels

Neem een ​​kijkje op de belangrijkste OSSEC logfile en je ziet de volgende strekking:

[Root @ Fubar logs] # tail -3 / var / ossec / logs / ossec.log

2010/02/18 12:32:05 ossec-rootcheck: INFO: Ending rootcheck scannen.

2010/02/18 14:27:06 ossec-syscheckd: INFO: Starten syscheck scannen.

2010/02/18 14:39:21 ossec-syscheckd: INFO: Ending syscheck scannen.

Let op de manier waarop de datum / tijd stempel is opgemaakt. Dit is anders dan de meeste toepassingen, dus het eerste wat we zullen moeten doen is vertellen logwatch hoe om te gaan met dit formaat. Moeten we een script dat we kunnen bellen wanneer dat nodig is, dat begrijpt het formaat hierboven te creëren.

Begin met het verhuizen naar de gedeelde scripts directory:

cd / usr / share / logwatch / scripts / shared

Gebruik uw favoriete editor, maak een bestand met de naam "applylongdate":

vi applylongdate

Hier is wat je nodig hebt binnenkant van dat bestand. Voel je vrij om te kopiëren / plakken van deze pagina:

gebruik logwatch ': data ";

my $ Debug = $ ENV {'LOGWATCH_DEBUG'} | | 0;

$ SearchDate = TimeFilter ('% Y /% m /% d% H:% M:% S');

if ($ Debug> 5) {

afdrukken STDERR "DEBUG: Inside ApplyLongDate ... \ n";

afdrukken STDERR "DEBUG: Op zoek naar:". $ SearchDate. "\ N";

}

while (defined ($ ThisLine = <STDIN>)) {

if ($ ThisLine = ~ m / ^ $ SearchDate / o) {

print $ ThisLine = ~ s / ^ .... \ / .. \ / .. ..:..:.. / /;

print $ ThisLine;

}

}

# Vi: shiftwidth = 3 syntax = perl tabstop = 3 et

Zodra u het bestand opslaat, we moeten nu de juiste machtigingen in te stellen:

chmod 755 applylongdate

Configureren The Log Files

Vervolgens moeten we logwatch vertellen waar de OSSEC log bestanden zich bevinden. Keer dat je nieuwe log bestanden of creëren van nieuwe services te monitoren in logwatch, moet u uw wijzigingen onder de / etc / logwatch directory. We gaan twee configuratie bestanden te maken. De eerste behandelt OSSEC boodschappen, en de tweede zal behandelen OSSEC waarschuwingen en actieve respons veranderingen.

Laten we beginnen met het maken van het configuratiebestand voor de belangrijkste OSSEC logbestand:

cd / etc / logwatch / conf / logfiles

vi ossec.conf

De inhoud van het bestand moet worden als volgt:

Logboek = / var / ossec / logs / ossec.log

* ApplyLongDate =

U kunt nu te slaan en het bestand. Vervolgens maken we het configuratiebestand voor de overige logbestanden:

vi ossec-alert.conf

De inhoud van dit bestand moet worden als volgt:

Logboek = / var / ossec / logs / actief-responses.log

Logboek = / var / ossec / logs / alerts / alerts.log

Logboek = / var / ossec / logs / firewall / firewall.log

Eenmaal voltooid, op te slaan en af ​​te sluiten. De standaard permissies moet aanvaardbaar zijn voor onze setup.

Configureren van OSSEC Services

Vervolgens moeten we de OSSEC diensten te definiëren en wat we willen gebruiken als een titel wanneer rapporten worden gegenereerd identificeren. Hier is hoe u het eerste bestand:

cd / etc / logwatch / conf / services

vi ossec.conf

De inhoud van dit bestand is vrij simpel:

Title = "OSSEC Berichten"

Logboek = ossec

Eenmaal voltooid, kunt u opslaan en af ​​te sluiten. We moeten nog een bestand aan te maken in deze directory:

vi ossec-alert.conf

De inhoud van dit bestand moet zijn:

Title = "OSSEC Alerts"

Logboek = ossec-alert

Eenmaal voltooid, op te slaan en af ​​te sluiten zoals gebruikelijk.

Ontleden van de inzendingen

Vervolgens moeten we logwatch vertellen hoe de logboekvermeldingen format in het rapport. We zullen een maatwerk script voor elke set van diensten te creëren. We gaan starten met een logwatch meegeleverde testscript, gewoon om er zeker alles werkt te maken.

Begin met het verplaatsen naar de juiste directory:

cd / etc / logwatch / scripts / services

Gebruik je favoriete editor om uw eerste script te maken:

vi ossec

De inhoud van het script moet worden als volgt:

#! / Bin / bash

# Dit is zo mooi script dat zal u tonen de regels die u zult

# Te verwerken en rapporteren over. Het zal eerst geeft de

# Standaard omgevingsvariabelen en dan duurt het STDIN en

# Dump het goed terug naar STDOUT.

# Dit zijn de standaard omgevingsvariabelen. U kunt definiëren

# Meer in uw dienst config-bestand (zie boven).

echo "Date Range: $ LOGWATCH_DATE_RANGE"

echo "Detail Level: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Dir: $ LOGWATCH_TEMP_DIR"

echo "Debug Level: $ LOGWATCH_DEBUG"

# Neem nu STDIN en dump het naar STDOUT

kat

Maak nu uw tweede script:

vi ossec-alert

en omvatten de exact dezelfde inhoud:

#! / Bin / bash

# Dit is zo mooi script dat zal u tonen de regels die u zult

# Te verwerken en rapporteren over. Het zal eerst geeft de

# Standaard omgevingsvariabelen en dan duurt het STDIN en

# Dump het goed terug naar STDOUT.

# Dit zijn de standaard omgevingsvariabelen. U kunt definiëren

# Meer in uw dienst config-bestand (zie boven).

echo "Date Range: $ LOGWATCH_DATE_RANGE"

echo "Detail Level: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Dir: $ LOGWATCH_TEMP_DIR"

echo "Debug Level: $ LOGWATCH_DEBUG"

# Neem nu STDIN en dump het naar STDOUT

kat

Tot slot moeten we de juiste machtigingen in te stellen:

chmod 755 ossec *

De installatie testen

De eenvoudigste manier om onze nieuwe setup te testen is het uitvoeren van de opdracht:

logwatch | less

Als u alleen uw wijzigingen wilt zien, kunt u een verslag uit over elke dienst, een voor een:

logwatch-service ossec | less

logwatch-service ossec-alert | less

Verdere Customization

Zodra je al het bovenstaande werkend te krijgen, kunt u zich concentreren op het verkrijgen van logwatch te filteren en samen te vatten van de logboekvermeldingen. Logwatch is vrij flexibel, en je kunt de output aanpassen op elke gewenste manier. Een van de leuke dingen over de bovenstaande test script is vooral dat het laat zien u precies wat u moet werken. Dus met een beetje regular expression magie kun je samenvatten van de vermeldingen als u dat nodig acht. Voor een aantal ideeën, check out de bestanden zich onder:

/ Usr / share / logwatch / scripts / services

Dit zijn de standaard samenvatting van scripts die bij logwatch. In het bijzonder, hebben een blik op de bestanden "PAM" en "sshd". Ze zijn goede voorbeelden van zowel een eenvoudige en een complexe set van samenvatting filters.

Als je de ontwikkeling van uw scripts, bijzondere aandacht schenken aan de $ LOGWATCH_DETAIL_LEVEL "variabele. Dit zal u toelaten om het uitgangsniveau van het rapport afhankelijk van hoeveel breedsprakigheid van de gebruiker is op zoek naar aan te passen. Bijvoorbeeld, terwijl u nog steeds in de bovenstaande diensten directory, voer het volgende commando:

minder sshd

Als de eerste pagina van de inhoud van het bestand wordt weergegeven, typt u in:

/ Detail <Voer key>

De backslash laat ons het bestand zoeken naar een bepaalde tekststring. In dit geval zijn we op zoek naar het woord "Detail". Zodra u op Enter drukt het zoeken slaat door het bestand tot hij vindt het eerste exemplaar van de tekenreeks. Het zal ook wijzen op de zoekterm. In de eerste wedstrijd zal je merken dat de auteur de variabele "$ Detail" toegewezen aan hetzelfde te zijn als de variabele $ LOGWATCH_DETAIL_LEVEL ". Dit is hen te redden wat typwerk.

Druk nu op de backslash toets te drukken, gevolgd door de Enter-toets. Dit zal springen door het bestand naar de volgende instantie van "Detail". Je moet zien:

if ($ Detail> = 20) {

Gebruikers $ {$ user} {$ Host} {$ Methode} + +;

} Else {

if ($ Host! ~ / $ IgnoreHost /) {

Gebruikers $ {$ user} {$ Host} {"(alle )"}++;

Let op de auteur geeft meer informatie als het detail niveau is ingesteld op 20 (halverwege tussen laag-en medium) of hoger. Blijf springen door het bestand en je ziet andere voorbeelden waar de auteur leveraged deze techniek.

Nu page down aan het einde van het bestand en je ziet deze verklaring:

if (keys% OtherList) {

print "\ n ** Ongeëvenaarde Inzendingen ** \ n";

print "$ _: $ OtherList {$ _} tijd (s) \ n" foreach keys% OtherList;

}

Dit gedeelte is uiterst belangrijk, want het is een laatste catchall. Denk aan een firewall beleid voor een moment. De meesten van ons een definitieve regel die zegt: "Als ik niet specifiek een verkeerspatroon vergunning door, ontkennen". Met andere woorden, als er iets onverwachts gebeurt, dit is hoe ik wil dat je om te gaan.

De bovenstaande verklaring dient hetzelfde doel bij het parseren van het logbestand. Alle vorige "als" statements poging om een ​​bepaalde tekst reeks wedstrijd in de logboekvermelding om naar behoren te formatteren. Dit bericht zegt: "Als u nog niet op elkaar afgestemd en drukte een specifieke log entry yet, print het uit in een hoofdstuk getiteld" ** Ongeëvenaarde Inzendingen ** ". Deze stap is zeer belangrijk, want zonder dat zullen we nooit te zien onverwacht inzendingen. Het is de onverwachte items die waarschijnlijk de belangrijkste en meest interessante.

Exec Samenvatting

Zowel OSSEC en logwatch zijn uitstekende gratis tools. OSSEC blinkt uit in het waarschuwen wanneer een bekende aanvalsvectoren patroon plaatsvindt. Logwatch is een geweldig hulpmiddel voor het samenvatten van een tijd stuk van logs, zodat mensen ook daadwerkelijk zinvol zijn van wat er gebeurt. Door het combineren van de twee tools die u kunt een veel robuuster verdediging in de diepte-houding. Het geheel wordt meer dan de som der delen.

De combinatie van logwatch en OSSEC - Deel 3

17 februari 2010

In mijn laatste twee posten besprak ik logwatch en OSSEC, en hoe ze kunnen benutten om uw veiligheid te vergroten zijn houding. In deze aflevering bespreek ik hoe beide van deze tools te installeren.

Het installeren van logwatch

Logwatch is vrij eenvoudig te installeren. In feite is het standaard geïnstalleerd op een groot aantal Linux-distributies, zodat je misschien al een kopie op uw systeem. Om te controleren, moet u inloggen als root en probeer logwatch met de "-v" schakelaar. Als u ziet:

[Root @ Fubar logwatch] # logwatch-v

Logwatch 7.3.6 (uitgebracht 05/19/07)

Logwatch is geïnstalleerd en je hebt een kopie van de laatste versie. Als u niet beschikt over de nieuwste versie, kunt u het grijpen van de logwatch download pagina .

Er zijn drie smaken logwatch die kunnen worden gedownload; Binaries in RPM-formaat, bron in de RPM-formaat, of bron in een Tar bal. Als uw systeem ondersteunt RPM package management, de binaire RPM is uw beste keuze. Het is eenvoudig te installeren en RPM zal automatisch updaten van de software als er nieuwe versies beschikbaar zijn.

Het installeren van logwatch Van RPM

Voor het installeren van de binaire versie van de RPM, gewoon inloggen als root en ga naar de map waar u het gedownloade RPM-bestand. Voer nu het commando:

rpm-U logwatch-7.3.6-1.noarch.rpm

Vergeet niet dat je kan de TAB-toets te gebruiken om automatisch aan te vullen de bestandsnaam in plaats van te typen in het hele ding.

Het installeren van logwatch van de Bron

Het installeren van de broncode is een beetje meer tijd in beslag. Vergeet niet dat, om de broncode te installeren moet je al een compiler (zoals gcc) op uw systeem geïnstalleerd te hebben. Aanmelden als root en ga naar de map waar u het gedownloade Tar bal. Voor het extraheren van het archief, het commando:

tar xvzf logwatch-7.3.6.tar.gz

U ziet een directory-structuur onder de huidige locatie worden aangemaakt en veel bestanden worden gekopieerd inch We moeten nu verhuizen naar de hoofddirectory dat is gemaakt:

cd logwatch-7.3.6

Om logwatch uit te voeren, zijn er een heleboel mappen die moeten worden gemaakt op uw systeem. Deze zijn gedocumenteerd in de README in de huidige directory. Gelukkig, logwatch bevat een install script dat al het werk voor u kan doen. Helaas, het script heeft de verkeerde rechten zo ingesteld dat deze niet standaard uitgevoerd. Dit is vrij makkelijk om maar vast met het chmod commando:

chmod 500 install_logwatch.sh

Nu kunnen we het script uitvoeren om ons systeem setup:

. / Install_logwatch.sh

Vergeet niet de periode aan het begin van de regel.

Testen logwatch

Voor het testen van uw logwatch setup, het commando:

logwatch | less

U ziet uw terminal scherm leeg te gaan, maar dat is normaal. Je zult uiteindelijk zien een logwatch rapport te krijgen naar het scherm dat je kunt navigeren door het gebruik van de "Page Up" en "Page Down" toetsen. Hoe log het duurt voor het rapport te laten zien op het scherm is afhankelijk van hoe veel log-informatie nodig heeft om verwerkt. Het kan een paar seconden of een paar minuten. Hoe dan ook, het geeft je een kans om vertrouwd te raken met het rapport-formaat.

Het installeren van OSSEC

Zoals ik in mijn laatste post, heb je twee installatie-opties met OSSEC, lokale of client / server. In deze post ga ik focussen op de client / server setup, want het is een beetje ingewikkelder. Als u het uitvoeren van een lokaal te installeren, selecteert u de "lokale" optie tijdens het installatieproces en sla het gedeelte over het opzetten van een beveiligd kanaal tussen de agent en de server.

Begin met de server

OSSEC maakt gebruik van Blowfish-encryptie om de communicatie veilig tussen de client en de server. Blowfish is symmetrische sleutel gebaseerd, zodat aan beide zijden moet weten wat de belangrijkste waarde om te gebruiken om te communiceren. De server is verantwoordelijk voor het genereren van de symmetrische sleutel, dus we moeten de server software eerst installeren. Tijdens de client te installeren zullen wij gevraagd worden om een ​​belangrijke waarde zo duidelijk we zullen moeten die handig hebben van tevoren.

Hier is een tijdsbesparende tip. De sleutel waarde is lang en bijna onmogelijk om te onthouden. De eenvoudigste manier om de belangrijkste waarde te verplaatsen van de server-systeem aan de agent-systeem is het gebruik van SSH. Maak een veilige verbinding met de server OSSEC, en haal de juiste toets (aanwijzingen hieronder). In een tweede terminal venster, maak een SSH-sessie aan het systeem waar u de installatie van de agent. Wanneer de client te installeren die u vraagt ​​om de sleutel waarde, kun je gewoon copy / paste tussen de twee terminals.

Het installeren van de OSSEC Server

De server software is beschikbaar als een Tar bal, dus je kunt een exemplaar van de laatste versie te pakken vanaf de OSSEC download pagina . U moet dan om de inhoud van de Tar bal uit te pakken:

tar xvzf ossec-HIDS-2.3.tar.gz

Vervolgens verplaatsen naar de directory-structuur die u zojuist hebt gemaakt:

cd ossec-HIDS-2.3

OSSEC biedt een install script die u stapsgewijs door het proces van het installeren van de server. Het script, type start:

. / Install.sh

Vergeet niet de periode aan het begin van de opdracht. U wordt nu gevraagd door een aantal installatie opties:

  • Taal - De standaard is Engels. Veranderen als dat nodig is.
  • Bevestiging van de installatie - Druk op Enter als je eenmaal hebt gelezen op het scherm.
  • Installeer type - Type in "server" zonder de aanhalingstekens en druk op Enter.
  • Installeer locatie - Accepteer de standaard.
  • E-mail - standaard is ja, selecteren als u wilt e-mail alerts. Als u Ja selecteert, wordt u gevraagd om een ​​geldig e-mail adres en e-mail server.
  • Integriteitscontrole - Standaard is ja. Selecteer deze optie als u wilt dat het lokale systeem periodiek gecontroleerd op indringers.
  • Root kit detectie - Standaard is ja. Goede optie, aangezien we nodig hebben om een ​​hoog niveau van integriteit te behouden op dit systeem.
  • Actieve reactie - Standaard is ja. Selecteer deze optie als u wenst om te kunnen reageren op gebeurtenissen.
  • Firewall neerzetten - Vergunningen de OSSEC server te verdedigen zichzelf als een directe aanval wordt gedetecteerd.
  • Witte lijst - Dit zal u toelaten om IP-adressen van waaruit mogelijke aanvallen worden genegeerd toe te voegen. Wees voorzichtig met deze optie. Als je geen console toegang tot de OSSEC server, is het misschien verstandig om een ​​IP-adres dat altijd kan krijgen inch Gewoon zorgen voor de bron-IP is een betrouwbaar systeem te identificeren.
  • Enable Syslog - Standaard is ja. Selecteer deze optie als u wilt logs van systeem dat niet kan draaien een OSSEC agent (zoals firewalls, switches, routers, access points, etc.) te verzamelen.
  • Log files worden gecontroleerd - In dit scherm identificeert alle van de lokale logbestanden OSSEC monitor. Het is puur informatie, zodat alles wat je kunt doen is druk op Enter om over heen te stappen. Als u merkt dat een of meerdere log files ontbreken in de lijst, kunt u later toevoegen aan de ossec.conf bestand.

Op dit punt OSSEC zal de toegang van de lokale compiler en installeer alle benodigde bestanden naar het systeem. Eenmaal voltooid, kunt u de OSSEC server starten door het uitvoeren van het commando:

/ Var / ossec / bin / ossec-control start

Het definiëren van OSSEC Agents

We zijn nog niet klaar met de OSSEC server gewoon nog niet. Vervolgens moeten we vooraf bepalen alle systemen die zullen worden uitgevoerd de OSSEC agent (client) software. Dit is uitgevoerd met behulp van de manage_agents commando. Eerst echter moeten we een beetje huiswerk te maken. Maak een lijst van alle systemen die worden uitgevoerd de OSSEC agent software. Voor elk systeem, hebt u een beschrijvende naam als dat systeem het IP-adres.

Nu, voert u de volgende vanaf de opdrachtregel:

/ Var / ossec / bin / manage_agents

Dit zal de Agent Manager hoofdmenu. Druk op "A", gevolgd door de Enter-toets om uw eerste systeem te definiëren. Voer een beschrijvende naam voor het eerste systeem, gevolgd door het IP adres van het systeem. Maak je geen zorgen over de agent-ID-nummer. Gewoon accepteren de standaard en OSSEC zal automatisch toekennen van de volgende beschikbare ID-nummer. Zodra u de informatie die u hebt ingevoerd te bevestigen, keert u terug naar de Agent Manager hoofdmenu. Herhaal het bovenstaande proces voor elk systeem dat wordt het runnen van een OSSEC agent.

Het genereren van sleutels

Zodra u hebt toegevoegd in al uw systemen, is het tijd om encryptiesleutels te genereren. Deze stap is ook uitgevoerd met de manage_agents utility. Als u sloot het gereedschap na de laatste stap gemaakt, nu herstart het.

Druk op de "E" toets gevolgd door Enter om de "Extract toets voor een agent" te kiezen menu-optie. U wordt dan gevraagd naar het ID-nummer van de toets die u wenst te halen. De beschrijvende namen en IP-adressen worden vermeld met elk ID-nummer, dus het moet triviaal om te bepalen welke u wilt. Begin met het systeem dat u van plan om de agent software te installeren op de eerste plaats.

OSSEC Agent op Linux te installeren

Bij het installeren van de agent software op een Linux-of UNIX-client, gebruikt u exact dezelfde Tar bal hebben we gebruikt om de server software te installeren. Rijden op de zelfde installatie script, maar deze keer wanneer u wordt gevraagd voor het type installatie u wilt uitvoeren, type in "agent", gevolgd door de Enter-toets.

De client te installeren heeft veel van dezelfde aanwijzingen als de server te installeren. Gebruik maken van de info hierboven om u te begeleiden door het proces. De vraag die echter zal variëren is dat u wordt gevraagd om het IP-adres van de OSSEC server. Eenmaal voltooid, zal OSSEC toegang tot de lokale compiler en installeert alle benodigde bestanden naar het systeem.

Vervolgens moeten we de Blowfish sleutel te importeren uit de OSSEC server. Hoewel nog steeds over de agent-systeem, het volgende commando:

/ Var / ossec / bin / manage_agents

Toen de agent Manager menu verschijnt, selecteer "ik" aan de Blowfish sleutel te importeren.

Wanneer het volgende bericht verschijnt, moet u handmatig de juiste sleutel Blowfish. Nogmaals, als u SSH rennen om beide systemen op hetzelfde moment, kun je gewoon copy / paste tussen de twee terminals. Zorg ervoor dat de sleutel juiste looks, drukt u op de Enter-toets, en kies vervolgens "y" om te bevestigen dat de sleutel juiste looks. Keert u terug naar de Agent Manager menu. Selecteer "q" om terug te keren naar de opdrachtregel.

Nu hebben we gewoon nodig om de OSSEC-agent te starten. U kunt dit doen door het volgende commando:

/ Var / ossec / bin / ossec-control start

Je moet alle van de OSSEC middel onderdelen starten, gevolgd door een bericht 'Completed'.

OSSEC Agent installeren op Windows

OSSEC is een zelfuitpakkend uitvoerbaar, dat zal u toelaten om de agent software te installeren op een Windows-systeem. Gewoon dubbelklikken op het uitvoerbare bestand om de installatie te starten. U wordt gevraagd in te stemmen met de licentie en welke onderdelen u wilt installeren. Volg gewoon de aanwijzingen tot aan de OSSEC Agent Manager venster.

De OSSEC Agent Manager venster vraagt ​​u om het IP-adres van de OSSEC server. Het zal u ook vragen om de sleutel Blowfish waarde te gebruiken, dus haalt de juiste toets op de server en voer de waarde in dit veld. Zorg ervoor dat u wordt gevraagd te wissen binnen dit veld voordat je plakken in de Blowfish sleutel. Anders communicatie met de server kan mislukken.

Selecteer vervolgens "Beheren" van de OSSEC Agent Manager menu, gevolgd door "Start OSSEC". U ziet nu de "Status:" indicator te veranderen in "Running ...".

Testen OSSEC

Zodra u de server en agent-software geïnstalleerd, gestart en de geconfigureerde betreffende toetsen, is het nu tijd om onze installatie te controleren. Voer de volgende opdracht op de OSSEC server:

cd / var / ossec / logs

En bekijk het ossec.log bestand:

minder ossec.log

Controleer het logbestand voor eventuele fouten. Een veel voorkomende fout is dat OSSEC rapporten die het niet kunnen e-mail. Zorg ervoor dat de mail server wordt uitgevoerd en dat het accepteren van verbindingen. Als u tevreden bent met de server setup, is het nu tijd om te controleren of de agenten. Naar beneden naar de "waarschuwingen" directory:

cd waarschuwingen

En bekijk het alerts.log bestand:

minder alerts.log

In het bijzonder, bent u op zoek naar inzendingen lijkt op het volgende:

17 februari 2010 16:09:16 (desktop) 192.168.1.10-> ossec

Regel: 501 (niveau 3) -> 'Nieuwe ossec-agent is aangesloten. "

Src IP: (geen)

Gebruiker: (geen)

ossec: Agent gestart: 'test_system-> 192.168.1.10 ".

U ziet een vermelding voor elk systeem waarop u de installatie van de agent software.

Meer To Come

Whew! Dat is meer dan genoeg voor een post! In mijn volgende post zal ik krijgen in gebruik te maken van logwatch aan alle van de signalering informatie wordt gegenereerd door OSSEC ontleden.

De combinatie van logwatch en OSSEC - Deel 2

16 februari 2010

In mijn laatste bericht heb ik beschreven hoe logwatch kan worden gebruikt om de log review proces te vereenvoudigen. In dit bericht zullen we kijken naar OSSEC en wat het brengt aan de tafel.

Wat is OSSEC?

OSSEC , kort voor "Open Source Security", is een host based intrusion detectie systeem (HIDS). Met andere woorden, is het ontworpen om aanvallen of schendingen van het beleid als en wanneer ze zich voordoen op te sporen. Hoewel het niet de mogelijkheid hebben om te beschermen tegen onbekende of 0-day aanvallen (dat zou host-based intrusion prevention worden), maar bevat wel een breed scala aan hulpmiddelen die u kunnen helpen identificeren een inbraak als het optreedt, evenals de mate van de schade die is veroorzaakt.

Ondersteunde platformen

Om te profiteren van alle functies OSSEC te bieden heeft, moet je een agent te laten draaien op het systeem beschermd. OSSEC agenten kunnen draaien op Windows, Mac OS X, Linux, en een breed scala van UNIX-systemen. Als je gewoon geïnteresseerd in de log analyse gedeelte kan echter een nog groter aantal systemen worden ondersteund. Dit omvat zowel de hardware van Cisco en Juniper. Een aantal specifieke producten worden ook ondersteund, zoals Checkpoint firewalls, Symantec Anti-Virus, Snort, Squid, en arpwatch, om er maar een paar te noemen.

Wanneer u OSSEC installeert heb je twee configuratie-opties, lokaal of client / server. Een lokale installatie wordt gebruikt wanneer u nodig hebt om alles te draaien op een enkel systeem. De client / server-installatie kunt u een gedistribueerde omgeving te beschermen meerdere systemen tegelijk. Terwijl de meeste implementaties zijn client / server-gebaseerde, als u wilt geven OSSEC een spin kun je gemakkelijk draaien alles op een enkele test systeem met behulp van een lokaal te installeren.

Log Analyse

OSSEC omvat een Log-based Intrusion Detection System (deksels). Dit heeft de mogelijkheid om logbestanden herzien in de buurt van real-time, terwijl de loep ze voor bekende aanvalspatronen. Wanneer een logboek is gegenereerd op een beveiligd systeem, de agent zorgt voor veilig verzenden van de log (Blowfish encryptie met behulp van een pre-shared secret) terug naar de server. De server neemt dan zorg voor het uitvoeren van de analyse.

De meeste log analyse tools proces hun regels in een lineaire indeling. Daarmee bedoel ik dat als we 500 regels, regel een is aangevinkt, dan is de regel twee, dan regel drie en ga zo maar door totdat een match is gevonden of bereiken we het einde van de regel in te stellen. OSSEC werkt een beetje anders omdat het implementeert een hieratical structuur aan de regels. Log inzendingen worden eerst geclassificeerd en vervolgens gecontroleerd alleen tegen welke regels geschikt zijn. Het resultaat is dat in plaats van te hoeven aan alle 500 regels proces, de meeste gebeurtenissen krijgen vergeleken met 10 regels of minder. Dit vermindert drastisch de hoeveelheid overhead nodig is om de regel te stellen proces.

Integriteit Controle

OSSEC is voorzien van een tool genaamd Syscheck voor het uitvoeren van bestanden en mappen de integriteit te controleren. Als u werkt met een Windows-agent, kunt u ook specifieke toetsen binnen het Windows-register te worden gecontroleerd ook. Bestand veranderingen kunnen worden gedetecteerd met behulp van zowel MD-5 en SHA-1 hash algoritmen. Het systeem is uiterst aanpasbaar. U kunt opnemen of uitsluiten enkele bestanden, of hele directory structuren. U kunt zelfs een vlag om nieuw bestand maken te detecteren.

De agent software is ontworpen om een ​​minimale hoeveelheid CPU-gebruik tijdens de integriteit te controleren. Hoewel dit betekent dat de controle zal langer duren, helpt het ook om het minimaliseren van de performance hit op het systeem. Hash informatie wordt teruggestuurd naar de server. De server neemt dan zorg voor het uitvoeren van de hash vergelijking om te zien of een van kritieke het systeem bestanden zijn veranderd. De server slaat ook een kopie van de integriteit te controleren beleid, zodat als het beleid wijzigingen worden aangebracht op de agent, ze kunnen worden opgespoord en gemeld.

Anomaliedetectie

OSSEC gaat veel verder dan inloggen om te controleren integriteit van het systeem te controleren. Gebruik beleid kan centraal worden beheerd vanuit de server, en dan naar buiten geduwd om de juiste middelen. U kunt bijvoorbeeld definiëren van een beleid ten aanzien van die Windows-toepassingen aanvaardbaar zijn (Office, Firefox, etc.) en welke niet (IM-client, Skype, etc.). U kunt zelfs aanvaardbaar configuratie-opties, zoals na te gaan of NT hashes worden gebruikt voor het wachtwoord opgeslagen, maar niet LanMan hashes.

OSSEC omvat een aantal andere goodies om te helpen controleren of een systeem integriteit. Bijvoorbeeld OSSEC heeft de mogelijkheid om opdrachten uit te voeren van de agent en toezicht op de output die wordt gegenereerd. U kunt bijvoorbeeld de Linux-agent van de "df" commando uit te voeren op regelmatige tijdstippen en het genereren van een melding als schijfgebruik meer dan 90%. Een Windows voorbeeld kan worden te hebben OSSEC het genereren van een alarm als bestand informatie is geschreven naar het alternatieve gegevensstromen gebied van NTFS.

Actieve reactie

Tot slot, OSSEC omvat de mogelijkheid om te reageren bij verdachte activiteit wordt gedetecteerd. Reacties kunnen worden gegenereerd op basis van de server of de agent, die ooit die u opgeeft. Reacties kunnen worden als goedaardig als het genereren van een e-mail alert, naar wezen als pro-actief als het blokkeren van een extern IP-adres voor een beperkte hoeveelheid tijd. Er zijn een aantal van de opgenomen actieve reactie scripts die je kan putten uit, of je kunt makkelijk schrijf uw eigen.

Secure Architecture

De OSSEC auteurs hebben veel moeite gedaan om alle componenten veilig in het product. Taken zoals het controleren van de integriteit worden uitgevoerd op de server, in plaats van de agent, dus de betrouwbaarheid van de hashes kan niet worden aangetast tijdens een aanval. Processen zijn uitgevoerd met de laagste niveau van permissies mogelijk en verschillende accounts worden gebruikt om elke OSSEC component uit te voeren. Dit betekent dat een compromis van een enkele aanvraag binnen OSSEC niet direct leiden tot een compromis van het volledige pakket. Verder zijn de meeste componenten draaien binnen een chroot gevangenis , zodat hun toegang tot het systeem is nog verder beperkt.

Laatste woorden

Terwijl OSSEC is een krachtig hulpmiddel, is het belangrijk om te onthouden dat het een HIDS en niet een log management oplossing. OSSEC kunt bekijken logboekgegevens op zoek naar verdachte patronen, maar het zal alleen redden alert informatie. Dus terwijl OSSEC is geen vervanging voor uw Security Information Management (SIM)-oplossing, kan het zeer zeker vergroten het. U kunt eenvoudig instellen OSSEC om alle waarschuwingen genereert naar een centrale server logging naar voren .

Terwijl OSSEC is open source software, is Trend Micro in de eerste plaats de ontwikkeling ervan. Als u commerciële ondersteuning, kunt u een support contract de aankoop door hen tegen een redelijke vergoeding.

Meer To Come

In mijn volgende aflevering zullen we kijken naar de installatie van OSSEC en logwatch. Daarna gaan we verhuizen naar de integratie van de twee samen.

De combinatie van logwatch en OSSEC

15 februari 2010

Ik had onlangs een student vragen mij een vraag over de integratie van logwatch met OSSEC. Ik had het gevoel dat dit een complex en toch koel genoeg idee dat het gerechtvaardigd is een reeks van functies om het te dekken volledig. Dus de komende dagen zal ik spreken over elk van deze tools, hoe ze te integreren bij elkaar, en wat extra beveiliging zicht kan worden verkregen nadat het proces is voltooid.

Wat is logwatch?

Logwatch is een uitstekende open source tool voor het genereren van de dagelijkse menselijke leesbare log rapporten. Logboekvermeldingen hebben de neiging om te vallen in een van de drie categorieën:

  • Dingen die je weet is het kwaad
  • Dingen die je weet, is normaal en veilig kan worden genegeerd
  • Al het andere

Het is dat "alles anders" categorie waar logwatch echt schijnt. Voor de dingen die we weten het kwaad is, zullen we setup of andere vorm van alarmering systeem. Zo kunnen we schrijven een waarschuwing handtekening die de veiligheid analist waarschuwt wanneer een rekening wordt bruut geforceerd. Maar hoe zit het met aanvallen die we niet kennen of niet zeker weet wat ze eruit? Dit zou een duidelijk voorbeeld van dat 'alles anders "categorie. Het verkeer is niet normaal, maar we hebben niet eerder gezien om een ​​handtekening te wachten om een ​​alarm te genereren. Aangezien wij niet in staat om de aanval te vangen in real time, zullen we nodig hebben om hem te vangen tijdens een dagelijks een logboek bij te herzien.

Natuurlijk is het probleem met het doen van dagelijks een logboek bij reviews is dat het vervelend en tijdrovend. Ik bedoel, laten we eerlijk zijn, wie wil echt hun dag door te brengen review miljoen plus logboekvermeldingen? Zelfs als je dat deed, weet je zeker dat je eigenlijk zou het uit pakken van de gewone verkeer?

Hoe het werkt

Wat logwatch doet het erg goed is u toelaten om uw gegevens te reorganiseren in een formaat dat is makkelijker voor mensen om te volgen. Zijn grote kracht is dat het u toelaat om de dingen die je begrijpt uit de weg (normaal of slecht) te verplaatsen, zodat de onverwachte logboekvermeldingen zich onderscheiden als een zere duim. Met andere woorden, logwatch kunt u een samenvatting van uw log entries zodat het ongewone materiaal is makkelijker te herkennen.

Wat ik echt leuk vindt logwatch is dat je niet iets te verliezen. Veel loggen evaluatie tools alleen laten zien van de dingen die vooraf is gedefinieerd als het kwaad. Het probleem dat zij allen delen is dat wanneer er iets onverwachts gebeurt, maar het kwaad, vliegt hij recht onder de draad. Omdat logwatch laat je alles zien, je niet langer missen het onverwachte.

Logwatch In Actie

Laten we bespreken hoe logwatch werkt het gebruik van de SSH- server dienst als een voorbeeld. De scripts om te gaan met SSH reeds is gedefinieerd binnen logwatch, zodat u geen behoefte aan een tweaken aan de functies die we gaan bespreken te ontvangen.

Bij de herziening van een log-bestand, is het eerste wat logwatch doet is reorganiseren logboekvermeldingen op basis van hun boodschap typen. Bijvoorbeeld alle Succesvolle SSH aanmeldingen zijn gegroepeerd, evenals teveel aanmeldingen mislukten, weigerde verbindingen, afgesloten rekeningen, rekeningen zonder een behoorlijke shell, protocol mis-wedstrijden, enz. enz. enz. Als alle SSH-berichten zijn gegroepeerd volgens hun type, worden de gegevens vervolgens samengevat om de hoeveelheid informatie die wordt gemeld te verminderen.

Bijvoorbeeld, de standaard is om mislukte aanmeldingspogingen samen te vatten door de rekening en bron IP. Dus een typisch mislukte aanmelding rapport sectie ziet er als volgt uit:

Mislukte logins van deze:

BSmith / wachtwoord van 1.2.3.4: 637 keer (s)

jsmith / wachtwoord van 1.2.3.5: 2 keer (s)

Dus in plaats van tot 639 logboekvermeldingen het rapporteren van een slechte aanmelding poging herzien, hebben we alle relevante informatie samengevat in drie lijnen (als u de titel ook). Herhaal dit proces voor alle andere SSH berichten, en we hebben drastisch verminderd de hoeveelheid tijd die nodig is om onze logs.

Maar wat als er iets gebeurt dat logwatch niet is voorgeprogrammeerd te herkennen? Wanneer een onverwachte logboekvermelding is gevonden, logwatch voegt een sectie aan het eind van de dienst rapport genaamd "Ongeëvenaarde Entries". Dus als we zien deze titel in de SSH-server gedeelte, we weten dat een of andere gebeurtenis heeft plaatsgevonden die hetzij abnormale of onverwacht voor de SSH-service. Dit zou heel goed een bepaalde vorm van aanval die we ons niet bewust is het maken van de rondes.

Door te focussen in op de ongeëvenaarde inzendingen gedeelte, kunnen we snel te identificeren onverwachte activiteit. Zoals ik al eerder aangaf, dit is echt het belangrijkste doel van het doen van dagelijks een logboek bij reviews. Om de dingen die we verwachten niet dat dat zal sluipen langs ons waarschuwingssysteem. Logwatch maakt dit proces zo snel en zo pijnloos mogelijk te maken.

Samenvatting functie

In het bovenstaande voorbeeld heb ik gesproken over het doen van dagelijks een logboek bij recensies, maar om eerlijk te zijn logwatch is in hoge mate aanpasbaar. U kunt een bereik dat u wilt gebruiken om naar beneden een interval van een seconde. Laten we het bijvoorbeeld zeggen dat ik een inbraak in plaats van het uitvoeren van dagelijks een logboek bij evaluatie onderzoeken. Ik kon een bereik zoals "2010/02/14 17:05:00 voor dat uur" te richten rechts in op de informatie die mij interesseren. Ook kan ik focus in op een specifiek log-bestand of dienst.

Het detailniveau van het rapport is eveneens aanpasbaar. Normaal gesproken als je met de beveiliging krijg je in de gewoonte van altijd willen het hoogste detailniveau van de rapportage. Om eerlijk te zijn, met logwatch een hoge mate van detail is waarschijnlijk meer dan je ooit nodig zult hebben. Persoonlijk vind ik typisch stok met "med" voor middelgrote en dat werkt goed. U kunt ook de rapportage niveau als "laag" of "hoog" of gebruik een numeriek bereik van 0-10 voor een hoger niveau van granulariteit (laag = 0, med = 5, high = 10).

Logwatch kan automatisch of als een handmatig proces worden uitgevoerd. Normaal gesproken wil je het op te zetten om automatisch lopen per dag en een dag de moeite waard van het logboekvermeldingen samen te vatten. Als je ooit nodig hebt om uit te breiden of de focus het rapport, dan kunt u altijd draaien logwatch vanaf de command line en specificeert precies wat je wilt zien. U kunt dan gebruik maken van de "-save" optie om een ​​rapport naam en directory locatie voor opslag te geven.

Meer To Come

Het bovenstaande geeft je een goed idee om de functies logwatch kan brengen naar de tafel. In de volgende post bespreek ik OSSEC in dezelfde mate van detail. Daarna zal ik krijgen in hoe elk instrument en hoe ze te integreren bij elkaar te installeren.

Het opzetten van een Security Information Management System-Part 6

20 augustus 2009

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. :)

Het opzetten van een Security Information Management System-Deel 5

14 augustus 2009

In mijn laatste bericht ik besproken hoe een logging server een bericht de prioriteit van de waarde gebruikt om te sorteren binnenkomende berichten te loggen. In deze aflevering zal ik praten over het testen van connectiviteit, en hoe de verschillende tandwiel op de draad te krijgen om hun logboekvermeldingen te leggen aan een centrale server.

Eisen

Om een ​​systeem om in te loggen inzendingen in te dienen, het moet ondersteuning hebben voor Syslog. Logboekvermeldingen moeten worden doorgegeven in duidelijke tekst poort UDP/514 op de logging server. Als u gebruik maakt rsyslog op de server, TCP/514 is acceptabel ook.

Ingezonden lange ingangen moeten de volgende info:

  • Een van de prioriteiten waarde (in <PRI> formaat) aan het begin van de lading
  • De naam van de applicatie het indienen van de log entry
  • Het proces ID worden gebruikt door de toepassing
  • Het lichaam van de log berichten

Maar om eerlijk te zijn, Syslog is niet erg kieskeurig. Er zal getracht worden alles naar haar luisteren haven als een lang item record. Als er een prioriteit waarde is niet aanwezig is, zal het opnemen van de toegang tot alles wat-bestand wordt gebruikt voor facilitaire 1. Normaal gesproken is dit / var / log / messages.

Testen Connectiviteit

Bij het implementeren van een nieuwe setup, ik wil om de connectiviteit te controleren tussen de eerste paar cliënten en de logging server. Als het logbestand is niet werkt, wil je in staat zijn om het probleem te isoleren. Typische problemen zijn:

  • Client verkeerd geconfigureerd
  • Firewall in de weg (op de client, de draad, of de logging server)
  • Server niet goed geconfigureerd

U wilt de berichten bestand monitor op de logging server om ervoor te zorgen de test logboekvermelding is ontvangen. Op de logging server, voert u het volgende commando:

tail-f / var / log / messages

Staart opent het log-bestand read-only en print de laatste vijf regels. Als nieuwe logboekvermeldingen worden ontvangen, krijgen ze afgedrukt op het scherm ook.

Voor het genereren van een test logboekvermelding, ik wil gebruiken Netcat . Netcat kan gebruikt worden vanaf elke Windows-, Linux-of UNIX-systeem. Van het testsysteem, het volgende commando:

echo 'Dit is een UDP-test log entry' | nc-u-w 1 <IP-adres van logging server> 514

You should see the echoed portion of the command show up in the /var/log/messages file on the logging server. If not, launch a packet sniffer and see if you can determine where the failure is occurring. If you wish to test TCP connectivity as well, simply run the command again leaving out the Netcat “-u” switch:

echo 'this is a TCP test log entry' | nc -w 1 <IP address of logging server> 514

If both entries are received, we are ready to start pointing devices at our logging server.

Network hardware

Most network hardware supports Syslog via UDP/514. It is just a matter of going through the documentation and determining the proper command set for sending log entries to a remote server.

If you are using Cisco IOS, run the following from global configuration mode:

logging <IP address of logging server>

If you wish to change the logging facility from “local use 7” to something else, the command is:

logging facility <facility short name>

So to change logging facility to “local use 3”, the command would be:

logging facility local3

Linux and UNIX systems

There are a number of Syslog alternatives available for Linux and UNIX. In this section I'll cover how to get Syslog and rsyslog to forward their log messages to a remote server.

Syslog

If the client is running Syslog, you will need to edit the /etc/syslog.conf file. Add the following line to the bottom of the file:

*.* @<IP address of logging server>

So an example would be:

*.* @192.168.1.150

Note the white space between the wild card match and the remote IP address MUST BE TAB CHARACTERS . If you use spaces, Sysylog will not be able to parse the file. Save and exit the file, then restart Syslog to activate the changes.

rsyslog

With rsyslog we have the option of forwarding our log messages via UDP or TCP. In either case we will need to edit the /etc/rsyslog.conf file. To forward long entries using UDP, add the following line to the end of the file:

*.* @<IP address of logging server>:<port>

So an example would be:

*.* @192.168.1.150:514

If we wish to use TCP instead, we simply use two “@” symbols:

*.* @@192.168.1.150:514

Once complete save and exit the file. You will need to restart rsyslog to activate your changes.

Windows systems

As mentioned in a previous post, Windows does not include support for Syslog. This means you will need third party software to convert your logs in real time and submit them to a logging server. The Loganalysis Web site has a list of possible solutions.

For the purposes of this post, I'll cover Snare . It is free for use, can be commercially licensed, and have a very simple deployment process.

Once you download the software, you need to configure it for the system. Dit is weergegeven in figuur # 1. Snare needs to know the location of the logging server as well as what facility and severity level to use. Once complete, click the “Latest Events” menu potion to see which specific Event Viewer log entries Snare is forwarding to the logging server.

snare-config

Exec Samenvatting

In this post I discussed testing connectivity to a logging server, as well as how to configure clients to centralize their logs. In the next post I'll talk about what to look for in a daily reporting tool, as well as real time alerting.

Setting Up A Security Information Management System-Part4

12 augustus 2009

In the last post I talked about how to setup a logging server that will accept remote log entries. In this installment I'll talk about how to sort log entries into specific files.

Facility, severity and priority

Let's talk about how logging servers figure out which file to store a log entry in when it gets received. Log messages contain two descriptive parameters, facility and severity. When these two parameters are combined, the value is referred to as the priority of the log message.

Faciliteit

Facility defines the type of process that generated the log entry. For example all mail servers are expected to identify that their log entries are part of the “mail” facility. FTP processes should use the FTP facility, NTP processes should use the NTP facility, and so on. RFC 3164 defines the valid facilities, but here's the list:

Numerical Facility

Code

0 kernel messages (kern)

1 user-level messages (user) – default if not specified

2 mail system (mail)

3 system daemons (daemon)

4 security/authorization messages (auth)

5 internal syslogd (syslog)

6 line printer subsystem (lpr)

7 network news subsystem (news)

8 UUCP subsystem (uucp)

9 clock daemon

10 security/authorization messages (authpriv)

11 FTP daemon (ftp)

12 NTP subsystem (ntp)

13 log audit

14 log alert

15 clock daemon (cron)

16 local use 0 (local0)

17 local use 1 (local1)

18 local use 2 (local2)

19 local use 3 (local3)

20 local use 4 (local4)

21 local use 5 (local5)

22 local use 6 (local6)

23 local use 7 (local7)

The “local use” facilities are similar to private addresses in the IP world. These facilities are not reserved, and are available for anyone to use as they see fit.

Facility problems

There are a couple of problems here. To start, where is the Web server facility? This list was generated back in 1987 before Web servers (or Gopher for that matter) existed. So some of the services we use today (VoIP, SQL, etc.) are missing. Also, some of the listed services typically go unused in a corporate environment. UUCP and Network News (NNTP) are excellent examples.

The lack of current services has caused many vendors to rely heavily of the local use facilities. This can cause potential conflicts when we get into sorting our log entries. For example Linux uses local use 7 to identify its boot time log entries. Apache also uses local use 7 for Web server errors. So down the road it may be difficult for us to sort Web errors and boot messages into different log files.

Another problem is that there is no verbose description about each of these facilities. This can make it a bit difficult for a programmer to identify which one to use. For example, let's say we've written a program that authenticates a user for network access. Which facility should we use? Facility 4 and 10 seem the most likely, but their descriptions are identical. How do we choose? If our program runs as a background process should we actually choose facility 3 instead?

Je krijgt het idee. The list is not as clear-cut as it could be. It is not uncommon to see vendors use a different facility than you would expect. For example I've seen VPN vendors undecided as to the differences between facilities 4 and 10, so they simply send some percentage of log entries to each.

Strengheid

Severity defines the importance of the log entry. The same RFC 3164 defines the severity levels as:

Numerical Severity

Code

0 Emergency: system is unusable (emerg)

1 Alert: action must be taken immediately (alert)

2 Critical: critical conditions (crit)

3 Error: error conditions (error)

4 Warning: warning conditions (warn)

5 Notice: normal but significant condition (notice)

6 Informational: informational messages (info)

7 Debug: debug-level messages (debug)

Luckily the severity levels are far less vague than the facility descriptions. This means they are much less confusing to work with. The higher numbered severity levels tend to be very verbose. This means saying you want to send debug level messages to your logging server could easily flood the network. Use the higher numbered severity levels with caution.

Priority

When a log entry gets transmitted to a log server, the first value contained within it is the priority of the message. The priority is the facility and severity values combined per the following math formula:

( Facility x 8 ) + Severity = Priority

So lets say our mail server needs to send a warning message. What would the priority be? The mail facility has a value of 2, while warnings have a severity of 4. So the math would be:

( 2 x 8 ) + 4 = 20

If a print server (facility 6) needed to send a log entry saying it is currently on fire (severity 0), the priority value in the message would be:

( 6 x 8 ) + 0 = 48

When a log entry gets transmitted, the priority value needs to be encapsulated in less than and greater than signs. So the priority value in the above mail server message would be “<20>” while the print server would use “<48>”. Again, this needs to be the first piece of information transmitted in the log message.

Sorting log entries

The priority value is used by logging servers to sort the incoming messages. For example if we wanted all mail messages to go to the same file, we would tell our logging server that all messages with a priority of 16 (2×8+0) through 23 (2×8+7) should go to the “maillog” file. Most logging servers (like rsyslog) will let you do this numerically or by using the short description names.

rsyslog.conf example

Here are two lines out of the rsyslog.conf file that ships with Fedora. Let's talk about what they are actually doing:

authpriv.* /var/log/secure

*.info;mail.none;authpriv.none;cron.none /var/log/messages

These lines define two of the rules for determining which log entries should go to which log files. The syntax for sorting is:

facility.severity

So the first line says all facility 10 (authpriv) log entries, regardless of severity (“*” is a wild card match) should be sent to the file /var/log/secure.

The second line is a bit more complex as it has multiple conditions separated by semi-colons. These conditions state:

  • *.info = All facilities, so long as the severity level is info
  • mail.none = No mail facility log entries, regardless of severity
  • authpriv.none = No authprive facility log entries, regardless of severity
  • cron.none = No cron facility log entries, , regardless of severity

Of, om dit te vertalen naar het Engels, de regel zegt info "-berichten naar / var / log / messages, met uitzondering van degenen die een faciliteit van bevatten" "alle ernst Send" mail "," authPriv "of" cron ".

Dus met deze regels kunnen we definiëren elke combinatie van faciliteiten en de ernst waarden en die log file willen wij het direct. Wanneer u voor het eerst dit op te zetten, stok met de standaardinstellingen. Zoals u beginnen met het verzamelen logboekvermeldingen kunt u tweak de regels als het je past.

Het buigen van de RFC's

In een ideale wereld, zou de RFC's zijn een perfecte pasvorm voor de behoeften van iedereen. Helaas is dit niet altijd het geval. Een goed voorbeeld is de logging-faciliteiten. Zoals gezegd zijn we missen vergemakkelijkt voor moderne dag diensten, terwijl op hetzelfde moment hebben faciliteert dat we nooit zullen gebruiken. Een voor de hand liggende antwoord is op de verouderde faciliteiten recyclen om moderne diensten te ondersteunen.

Bijvoorbeeld, is UUCP (facility 8) ook niet ondersteund door moderne besturingssystemen. Met dit in gedachten, ik wil het te gebruiken als mijn Windows faciliteit. Op die manier kan ik sorteren alle Windows-log entries in hun eigen dossier. Voor de netwerkhardware, ik gebruik van het netwerk nieuws faciliteit (facility 7). Als u niet zeker weet of een faciliteit is op dit moment in gebruik is, wijzig dan je logging server configuratie bestand om alle logboekgegevens voor die mogelijkheid om een ​​uniek bestand te verzenden:

ftp .* / var / log / facility-test

Als er geen inzendingen komen, bent u in goede vorm. Houd in gedachten dat een legitieme dienst kan gebruiken op een later tijdstip. Bijvoorbeeld als drie maanden vanaf nu iemand zet een FTP-server, kunnen wij problemen hebben als we al gebruik van de FTP-faciliteit (facility 11). Als u niet zeker bent kunt u altijd stok met de lokale gebruik maken van faciliteiten, want dat is wat ze zijn bedoeld. Lokaal gebruik 0 en 7 lijken de meest intensief gebruikte, dus vermijd deze indien mogelijk.

Andere opties sorteer

Terwijl zijn geen onderdeel van de RFC, een logging-servers geven u de mogelijkheid om in te loggen entries sorteren op basis van patronen in het bericht. Een goed voorbeeld is Syslog-NG . Syslog-NG zal sorteren op basis van faciliteiten en de ernst, maar u kunt ook sorteren op basis van bron IP, de toepassing die de logboekvermelding gegenereerd, enz. Dit geeft je veel flexibeler sorteer-opties en het kan iets om te overwegen als facility / ernst is niet korrelig genoeg is voor uw behoeften.

Exec Samenvatting

In deze aflevering hebben we gesproken over hoe de voorziening en de ernst wordt gebruikt om in te loggen entries sorteren. In mijn volgende post zal ik vertellen hoe voor elk van onze systemen te krijgen om in te loggen berichten te versturen naar onze centrale server.

Het opzetten van een Security Information Management System-Deel 3

11 augustus 2009

In de laatste post Ik bedekte deel van de architectuur zorgen met het uitrollen van een gecentraliseerde beveiliging informatiesysteem. In deze post zal ik dekken de inzet van een standaard log-server, en controleren dat het klaar is om in te loggen inzendingen te accepteren.

Het selecteren van een logging server

Het eerste wat we moeten doen is het selecteren van een platform voor onze logging server. Als we alleen maar het opzetten van een testlab, zal Windows, UNIX-of Linux maken allemaal grote keuzes. Het kiezen van Windows zou nuttig kunnen zijn voor een Windows-beheerder, omdat ze niet zal hebben om de curve te bezuinigen op een nieuw besturingssysteem tijdens een poging om uit te testen houtkap. Hoewel Windows ondersteunt geen Syslog uit de doos, zijn er enkele uitstekende pakketten als Kiwi Syslog-server en WinSyslog dat de Syslog-ondersteuning zal toevoegen. Beide hebben de evaluatie-versies en zijn relatief goedkoop een licentie.

Als we praten over het opzetten van een productie-server zal echter willen we weg te blijven van Windows. Windows is berucht voor het feit dat een afschuwelijke IP-stack. Als feite vorige "patches" hebben verminkt het nog verder in het belang van vertragen verspreiding van de worm en het verhogen van de snelheid van de GUI. Terwijl veel van deze beperkingen zijn verwijderd in 2008 server en Windows 7, het IP-performance is nog steeds ondermaats in vergelijking met een Linux-of UNIX-systeem ingezet op identieke hardware.

Dus dat laat Linux-en UNIX-als keuzes voor een productie-systeem. Waaruit u kunt kiezen hangt af van persoonlijke keuze. Sommige, zoals de stabiliteit van de BSD, terwijl anderen, zoals de flexibiliteit van Linux. Voor de toepassing van dit document zal ik werken met een Fedora gebaseerde Linux-systeem. Installatie en configuratie van het besturingssysteem is relatief intuïtief en eenvoudig.

Het accepteren van externe logbestanden

Om in te loggen inzendingen uit externe systemen te aanvaarden, oudere versies van Fedora vereist is om de Syslog daemon (syslogd) initialiseren met de "-r" optie. Dit werd gedaan door het toevoegen van "-r" om de syslogd_options lijn van / etc / sysconfig / syslog file. Sommige versies van Linux nog steeds ondersteuning van legacy Syslog, en vereisen dat u "-r" toe te voegen aan de Syslog-RC initialisatie file. Controleer de docs voor uw specifieke distributie.

Nieuwe Fedora systemen echter wel ondersteunen "Betrouwbaar Syslog" of rsyslog. De uitvoering is redelijk vergelijkbaar met gewone oude Syslog, behalve rsyslog ondersteunt communicatie via TCP/514 als UDP/514. In de laatste post beschreef ik dat de uitvoering van logboekvermeldingen via TCP kunnen sommige van de redenen waarom we verliezen logboekvermeldingen te repareren, maar niet alle van hen. Als je wilt spelen met TCP-ondersteuning, ga je gang en open beide poorten op de logging server.

Om rsyslog op afstand logboekvermeldingen accepteren, moeten we het bestand / etc / rsyslog.conf bestand. Tegen het begin van het bestand moet u het volgende zien:

# Biedt UDP syslog-ontvangst

# $ MODLOAD imudp.so

# $ UDPServerRun 514

# Biedt TCP syslog-ontvangst

# $ MODLOAD imtcp.so

# $ InputTCPServerRun 514

Het "#" (hekje) symbool aan het begin van de regel vertelt het systeem niet naar de rest van de line proces. Wij gebruiken deze techniek voor commentaar als "commentaar out"-commando 'we willen niet te hebben verwerkt. Door commentaar van de MODLOAD en poort specificatie lijnen, voorkomen we rsyslog van het openen van een luisterende socket. Het helpt om het systeem te houden in een meer veilige toestand.

Aangezien we het opzetten van een centrale server logging, zullen we nodig hebben om deze sockets openen naar afgelegen logboekvermeldingen te accepteren. Wijzig het bestand / etc / rsyslog.conf bestand naar de juiste pond symbolen te verwijderen. Het bestand ziet er nu als volgt uit:

# Biedt UDP syslog-ontvangst

$ MODLOAD imudp.so

$ 514 UDPServerRun

# Biedt TCP syslog-ontvangst

$ MODLOAD imtcp.so

$ InputTCPServerRun 514

Als je weet dat je nooit zal TCP gebruiken, kunt u verlaat de laatste twee regels commentaar uit. Eenmaal voltooid sla uw wijzigingen op en sluit het bestand.

We moeten nu opnieuw inloggen zodat onze veranderingen worden doorgevoerd. Dit gebeurt op Fedora door het uitvoeren van het volgende commando:

dienst rsyslog opnieuw te starten

Wanneer u de opdracht uitvoert, ziet u rsyslog stoppen en beginnen met de status "OK". Als de shutdown is mislukt, is dat omdat rsyslog niet wordt geïnitialiseerd bij het opstarten. Vanaf de command line, voer het commando "setup" en selecteer "Systeem-diensten" in het hoofdmenu. Wanneer de diensten menu verschijnt, scroll naar beneden in de lijst tot je vinden rsyslog. Vink het vakje aan de linkerkant en selecteer vervolgens "OK". Sluit de setup utility en rsyslog zal nu initialiseren wanneer het systeem wordt opgestart.

Het verifiëren van de luisterende poort

Vervolgens moeten we zorgen dat onze logging proces op afstand logboekvermeldingen te accepteren. Vanaf de command line, type "netstat-an | grep: 514". De uitvoer ziet er ongeveer als volgt:

[Root @ Fubar ~] # netstat-an | grep: 514

tcp 0 0 0.0.0.0:514 0.0.0.0: * LISTEN

tcp 0 0::: 514::: * LUISTER

udp 0 0 0.0.0.0:514 0.0.0.0: *

udp 0 0::: 514::: *

De eerste regel vertelt ons dat TCP/514 luistert via IPv4 worden gebruikt op alle netwerkinterfaces. Regel twee vertelt ons dat de TCP-poort is ook luisteren op een interface met een IPv6-adres. Lijnen drie en vier zijn de dezelfde informatie, behalve voor UDP. Als een van de inzendingen staat "127.0.0.1:514" in plaats van "0.0.0.0:514", dan de poort is slechts gebonden aan de loopback interface. Alleen het lokale systeem in staat zal zijn om het te bereiken. Dit kan gebeuren met legacy-systemen Syslog als je vergeten bent om ze te draaien met de "-r" schakelaar.

U moet nu een logging server die in staat is het ontvangen van inkomende logboekvermeldingen. In de volgende post zal ik vertellen hoe deze logboekvermeldingen krijgen gesorteerd in specifieke bestanden.

Het opzetten van een Security Information Management System-Part2

10 augustus 2009

In mijn laatste bericht hebben we gesproken over het bepalen van uw doelen voor een Security Information Management (SIM)-systeem. In dit bericht zullen we praten over architectuur betreft als capaciteitsplanning.

Netwerkcommunicatie

Het doel zal zijn om een ​​of meerdere SIM-servers die logboekvermeldingen zullen verzamelen van andere systemen. Dit zal uiteraard een impact hebben op netwerkgebruik. Hoeveel van een impact zal afhangen van de hoeveelheid en soort van de systemen die we logboekvermeldingen verzamelen.

UDP/514

Zowat alle systemen ondersteunen de originele Syslog-communicatie-uitvoering die helemaal teruggaat tot het jaar 1988. De laatste beschrijving van deze spec verscheen in RFC 3164 . Hoewel deze RFC volledig ontleed zijn van RFC 5424 , RFC 3164 vertegenwoordigt nog steeds de uitvoering ondersteund door de meeste leveranciers. Windows is een opvallende uitzondering (eigen, geen Syslog-ondersteuning), maar er is 3rd party software om dit recht te zetten.

Zowel RFC's schrijven het gebruik van het UDP-protocol bij het overbrengen van logboekvermeldingen. De bekende poort te gebruiken is UDP/514. Waar RFC 3164 en 5424 verschillen is in het formaat van de log bericht. Ik zal ingaan op deze verschillen in een latere post.

De haat / liefde van het gebruik van UDP

Aan de positieve kant, UDP is verbindingsloze. Dit betekent dat het minder verkeer dan wanneer we gebruik TCP genereert. Ook, log transmissies zijn een one-way-proces. De gastheer het genereren van een log entry stuurt een pakket naar de logging server, maar de logging server nooit antwoorden. Dit betekent dat we het verkeer flow control met statische filtering plaats van stateful filtering die zal minder overhead op het verkeer controle-inrichting. Ook de UDP-header is meestal 1 / 3 - 1 / 4 van de grootte van een TCP-header, die kleinere transmissie pakketten, dus minder overhead betekent.

Aan de negatieve kant, UDP is verbindingsloze. ;) Dit betekent dat het een minimale fout rapportagemogelijkheden heeft. Bijvoorbeeld als we uitzenden een log entry en het frame vermist (bijvoorbeeld een botsing of een firewall laten vallen van de packet), heeft UDP niet de mogelijkheid om te detecteren dat een doorgifte is vereist. Dit betekent dat het mogelijk voor logboekvermeldingen te gaan missen als we overlopen het netwerk. Verder UDP heeft geen flow control vermogen. Als de SIM-server herkent het is de capaciteit te bereiken heeft het geen enkele manier te vertragen de binnenkomende transmissie van logboekvermeldingen. Enige optie de SIM-server is om weg te gooien de pakketjes zonder verwerking hen.

Onnodig te zeggen, moeten we ervoor zorgen dat we de juiste capaciteit te geven. Als het netwerk of de SIM-server overbelast raakt, gaan we logboekvermeldingen verliezen. Een goede capaciteitsplanning begint met het begrijpen van de impact van houtkap op het netwerk.

Netwerk impact van de logging

De maximale grootte van een UDP Syslog-pakket heeft andere specificaties in verschillende RFC's. De verouderde RFC 3164 definieert de maximale berichtgrootte als 1.024 bytes. RFC 5426 zakt dit maximum grootte 480 bytes. Als een verkoper nog steeds de oude spec, is het mogelijk ze kan nog steeds denken dat de 1024 byte grootte legitiem is. Het is mijn ervaring echter dat de meeste logboekvermelding pakketten variëren in grootte 75 tot 225 bytes, zodat de maxima zijn een non-issue.

Windows-systemen, firewalls en intrusion detection systemen hebben de neiging om de grootste berichten te genereren. Netwerkhardware heeft de neiging om het genereren van de kleinste berichten. Als we een 100 Mb Ethernet-netwerk, zou het theoretisch maximum worden ergens rond de 50.000 tot 130.000 beelden per seconde. Hierbij wordt uitgegaan van nul overige verkeer, wat zelden het geval is. For the purposes of capacity planning, assume you will be limited to 5,000 log entries per second. This number might even be less if you have a busy network. Taking some utilization measurements during the planning process is key.

Syslog over TCP

As mentioned above, UDP introduces the problem that log entries can become lost without us even knowing it. There are ways to validate capacity, which I will cover in a later post. Some feel running Syslog over TCP can rectify this problem. TCP can be leveraged for its reliability to insurie our log entries are properly received.

Helaas is ondersteuning voor TCP Syslog is geen buurt waren gestandaardiseerd. Sommige leveranciers ondersteunen TCP door simpelweg te luisteren op TCP/514. RFC 3195 definieert Betrouwbare Syslog als via poort TCP/601, maar de vaststelling ervan is zeer beperkt. RFC 5425 definieert het gebruik van TLS om Syslog-transmissie te beveiligen. Deze RFC specificeert het gebruik van de haven TCP/6514. Dit is een gloednieuw specificatie en ik ben niet bewust van iedereen steunen het gewoon nog niet.

Dus ondersteuning voor TCP is over het hele bord. Verder heeft TCP niet helemaal het probleem oplossen. Terwijl de TCP zal ons flow control en betrouwbaarheid op de draad, kan het niet goedmaken voor het feit dat Syslog op de applicatielaag niet de ontvangst van logboekvermeldingen erkennen. Dit werd door het ontwerp, omdat het lagere overhead. Het probleem is dat zelfs door het gebruik van TCP kunnen we nog steeds berichten verliezen binnen de IP-stack en nooit weten dat het zich voordoet.

So if you want to try and transmit logs via TCP, its only going to work between a specific vendor's client and server software. For example you may need to run Syslog-NG on both ends of the connection to leverage it's support for TCP. This is not always practical, as you cannot run the software client on appliances like access points, switches, routers, etc.

Where to place the logging server

When deciding where to place the logging server, we have to keep both network capacity and security in mind. Take a look at Figure #1. This is an ideal situation where the logging server has been isolated to a dedicated network operations network. This isolates it from the other security zones and makes it much easier to leverage the firewall to restrict access to the logging server.

sim-placement

The drawing assumes we only need one logging server for our entire environment. What if we have 100,000 nodes to keep track of? Large networks may need to look at aggregating the data. For example if I have 10 field offices, I may need to have a logging server located at each of them collecting local log info. Each of these logging servers would then relay summary information back to the corporate office for network wide trend reports. This way we maintain a high level of visibility while reducing network load. I'll cover some possible aggregation options in a later post.

How many systems can log to a single logging server?

There is no single answer to this question as each network is different. It is going to depend on how much capacity is available on your network and how many log entries each of these systems generate. For example I could probably point 50,000 switches at a single logging server, as switches tend to generate very few messages. Firewalls on the other hand are extremely chatty, so I might max out the network or SIM server with only 20-50 firewalls. So to answer the question we need to look at two metrics:

  • How much free capacity is there on the wire?
  • How many log entries will each host generate?

The second question is not as straightforward as it may seem. For example the average desktop may only generate 40-100 log entries per day. If we can push 1,000 log entries per second, the math says we should be able to point 86 million desktops at a single logging server. The problem is about 80% of those messages are generated at initial boot time. If everyone typically powers around 9:00 AM, the math changes to a more realistic 750 desktops (again, assuming we can push 1,000 log entries per second over the wire).

So we can't just look at quantity of long entries. We need to take time of day into account as well. This will identify the actual number of log entries per second we can expect under worse case conditions. Worse case is the capacity level we need to plan for.

Deploy centralized logging in phases

If you have tens of thousands of systems to deal with, it is easy to get overwhelmed with the work involved with deploying centralized logging. Rolling out the solution in phases makes it easier to wrap your brain around the whole process.

First, start with a single logging server. You may not be able to cover your whole network, but we have to start somewhere. Large networks should consider a deployment at the corporate office first, moving out to field offices once the corporate system is fully vetted and functional.

You will also want to phase in which devices you are collecting information from. I usually go with the following order:

  1. Network intrusion detection systems
  2. Firewalls
  3. Network hardware (routers, switches, access points, print servers, etc.)
  4. Internet facing servers
  5. Internal servers
  6. Internal desktops

Obviously you can tweak this list to fit your needs. For example if you do not plan on collecting info from desktops, simply leave that step out. I like to start with network intrusion systems first as their log entries are well suited for vetting both daily reports and real time alerting. Once we have a handle on alerting and reporting, adding additional devices becomes far easier.

Exec Samenvatting

In this post I covered all the things you need to consider when initially deploying a centralized logging solution. We covered how to predict the impact it will have on network utilization, how to calculate the number of hosts per logging server, and why it is important to deploy the solution in phases. In the next post we'll start talking about configuring the centralized logging server. Specifically, we'll look at how we are going to sort log entries.

Het opzetten van een Security Information Management (SIM) Systeem - Deel 1

August 8th, 2009

I get a lot of logging related questions. So much so that I decided to do a series on how to deploy log management. There are some excellent logging resources on the Internet, but they are fragmented in scope and/or vendor specific (usually written by the vendors). I wanted to create something vendor neutral that holds your hand through the entire process of deploying a log management solution.

Why should I deploy a security information management system?

Let's be candid, deploying log management is hard and painful. This is the reason why so many administrators avoid it like the plague. Het is moeilijk te implementeren en een wilde bok voor het uitvoeren van langdurige toediening. Weekly trips to the dentist would probably be more pleasurable.

With all that said, log management is probably the single most effective security solution you can deploy. You can't drop it and forget it like a firewall, but log management can give you unrivaled visibility into the inner workings of your network. When its not providing insight into security events you might otherwise miss, it is doing double duty helping you troubleshoot communication and system issues. A logging system can be resource intensive, but it can also provide a very high rate of return.

Why do you want a SIM?

Before we begin, the first question you have to ask yourself is why do you want a SIM solution . Do you want to improve security or is there a compliance specification you need to adhere to? It might seem odd to want to distinguish between the two, but the requirements are drastically different. Standards are far easier (and cheaper) to meet than true security.

Standards such as PCI-DSS require you to log user, application and network activity. However they tend to be very vague in how that information gets processed. You can usually get away with dropping in a black box, generating some colorful management reports, and be considered “compliant”. It may not help you find that backdoored system that's calling home, but you've met the standard.

Standards tend to focus on the lowest common denominator. They need to be applicable for a wide range of audiences, including businesses without a lot of resources. Rather than evaluating a specific organization's risk and basing the requirements on that, we set the bar low so it is achievable by small and large organizations alike.

Also, to simplify the process, we tend to focus on checklists. Checklists are cool because they tell you exactly what needs to be done to be complaint. Indien een auditor kan een vinkje naast alle items zetten, u passeert het testen. The problem is checklists tend to focus on symptoms, not the actual problem.

I'll give you a great example. Ik had een klant te brengen in een Qualified Security Assessor om ze te certificeren voor de PCI-DSS. This was one of my clients running a strict implementation of application control, so they could show a year and a half history of zero Malware infections. While they certainly received Malware over that time, we could prove that there were zero instances of actual infection as every Malware attack was immediately contained and eliminated. Not many businesses can claim a year+ with zero Malware infections.

The auditor failed them. PCI-DSS requirement #5 states: “anti-virus software must be used on all systems commonly effected by Malware”. Since they ran application control, not anti-virus, they were deemed non-compliant. If requirement 5 had been written to identify an acceptable threshold for Malware containment, they certainly would have met the specification. However risk evaluation and metrics do not make for easy checklist items.

So if you want to deploy a SIM to actually augment security in your environment, it is going to take longer and require more work than simply meeting a specification.

Should you build your own SIM?

I'ma firm believer that anyone considering a SIM solution should start by building his or her own. While there are some decent commercial SIM solutions out there, they isolate you from the inner works of the logging process. This can be a good thing in that it saves you time. The problem is you will not learn as much.

Also, log management deployment is a journey. You will find in the course of a rollout that your requirements may change. Information you initially thought was important, all of a sudden is not. Reports you didn't even think of, all of a sudden jump to the top of the list. By building your own system you will have more flexibility to make changes on the fly. If you later decide you want a commercial solution, you are now better informed of your requirements and can do a better job evaluating a potential purchase. This is important, as many log solutions are expensive. You don't want to drop a lot of money on a solution that will not meet your long-term needs.

I'll give you a good example. Most of the sites I've worked with initially think failed logons are important and want to see the reports. It does not take them long to figure out seeing all failed logons is a complete waste of time as everyone fat fingers the keyboard on occasion. They then realize they want some thresholds around the data. For example they only want to see failed logons if three or more failures are seen in five seconds (indicating an automated attack). Or only show failed logons when multiple logon names are used from the same source IP (indicating a password guessing attack). So by dealing with some information overload, they become better skilled at defining exactly what they wish to see.

Overzicht

OK, so we've covered defining a focus (security Vs. standards requirement) as well as the importance of initially building your own system. In de volgende aflevering zal ik krijgen in de architectuur en capaciteitsplanning.