In mijn laatste post die wij geïnstalleerd logwatch alsmede OSSEC. Het is nu tijd om logwatch OSSEC en samen spelen in dezelfde zandbak. In deze post zal ik bespreken hoe om logwatch aan de informatie die wordt gegenereerd door OSSEC samen te vatten.

Deployment Opties

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

1. Heb logwatch ontleden de OSSEC logs direct.
2. Heb OSSEC haar waarschuwingen worden verzonden naar een syslog-server type, vervolgens stormloop 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 lopen in gaat echter de OSSEC alert bestand. Log inzendingen krijgen niet genormaliseerd. Dit betekent dat de indeling kunnen per item te binnenkomst, en kan zelfs gespreid over meerdere lijnen. Het gaat om een echte nachtmerrie voor een script dat zal logwatch filter en een samenvatting van de gegevens alert te creëren.

Als we verder gaan met optie # 2, zullen wij verlangen dat een andere box op te treden als onze gecentraliseerde logging server. Met het oog op de server te accepteren OSSEC logboekvermeldingen van niet-agent systemen, heeft om op te luisteren UDP/514. Dit is dezelfde poort die wordt gebruikt door een gecentraliseerde logging server, en je kunt geen twee aanvragen dezelfde haven bevinden (behalve met Windows, maar socket toegang is zeer slordig). Aan de positieve kant, zal de signalering inzendingen krijgen genormaliseerd wanneer ze worden doorgegeven aan de Syslog-server, zodat het maken van een samenvatting logwatch script zal veel gemakkelijker zijn. Verder logwatch reeds weet over de standaard Syslog-bestanden, dus we zullen minder aanpassingen te doen hebben.

Tot slot ben ik al in een eerder bericht dat OSSEC niet is ontworpen om een SIM worden. Dit is omdat het niet neem alles op, alleen de gebeurtenissen die een waarschuwing genereren. Dus zijn we waarschijnlijk naar een centrale server toch wilt, en is het zinvol om het op te slaan hebben 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 gaan voor optie # 1 te dekken is een veel ingewikkelder.

Omgaan met Datum / Tijd Stamps

Neem een kijkje op de belangrijkste OSSEC logfile en je moet zien van de volgende strekking:

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

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

2010/02/18 14:27:06 ossec-syscheckd: INFO: Begin syscheck scan.

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

Let op de manier waarop de datum / tijd stempel is geformatteerd. Dit is anders dan de meeste toepassingen, dus het eerste wat we moeten doen is vertellen logwatch hoe om te gaan met dit formaat. We moeten een script dat we kunnen bellen wanneer dat nodig is, dat begrijpt bovenstaande opmaak te maken.

Begin met het verplaatsen in de gedeelde map scripts:

cd / usr / share / logwatch / scripts / shared

Gebruik je 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) (

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

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

)

while (gedefinieerd ($ ThisLine <STDIN> =)) (

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

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

print $ ThisLine;

)

)

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

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

chmod 755 applylongdate

Configureer de Logbestanden

Vervolgens moeten we logwatch vertellen waar de OSSEC log bestanden zich bevinden. Anytime u nieuwe log bestanden of het creëren van nieuwe diensten te controleren in logwatch, moet u uw wijzigingen onder de directory / etc / logwatch directory. We gaan twee configuratie bestanden te maken. De eerste zal behandelen OSSEC berichten, en de tweede zal behandelen OSSEC signaleringen en actieve reactie veranderingen.

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

cd / etc / logwatch / conf / logbestanden

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 de config file voor de resterende log bestanden:

VI-ossec alert.conf

De inhoud van dit bestand dient als volgt:

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

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

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

Eenmaal voltooid, opslaan en afsluiten. De standaard machtigingen moet aanvaardbaar zijn voor onze setup.

Configureren OSSEC Services

Vervolgens moeten we de OSSEC diensten te definiëren en wat we willen gebruiken als een titel bij de 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 eenvoudig:

Title = "Berichten OSSEC"

Logboek = ossec

Eenmaal voltooid is kan je opslaan en afsluiten. We moeten nog een bestand in deze map te maken:

VI-ossec alert.conf

De inhoud van dit bestand dient te worden:

Title = "OSSEC Alerts"

Logboek = ossec-alert

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

Het ontleden van de inzendingen

Vervolgens moeten we logwatch vertellen hoe de opmaak van de logboekvermeldingen in het verslag. We moeten een aanpassing script voor elke set van diensten te creëren. We gaan starten met een logwatch meegeleverde testscript, gewoon om te zorgen dat alles werkt te maken.

Begin met het verplaatsen in de juiste directory:

cd / etc / logwatch / scripts / services

Gebruik je favoriete editor waarmee u 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 lijnen die u zal

# Worden verwerking en rapportage over. Het zal de eerste expositie

# Standaard omgevingsvariabelen en dan duurt het STDIN en

# Dump het goed mee terug naar stdout.

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

# Meer in uw dienst config bestand (zie hierboven).

echo "Datumbereik: $ 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 bevatten exact dezelfde inhoud:

#! / Bin / bash

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

# Worden verwerking en rapportage over. Het zal de eerste expositie

# Standaard omgevingsvariabelen en dan duurt het STDIN en

# Dump het goed mee terug naar stdout.

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

# Meer in uw dienst config bestand (zie hierboven).

echo "Datumbereik: $ 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

Ten slotte moeten we de juiste machtigingen instellen:

chmod 755 * ossec

Testen De Setup

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

logwatch | less

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

logwatch-service ossec | less

logwatch-service-alert ossec | less

Verdere aanpassing

Zodra je al het bovenstaande werkt, kunt u zich richten op het verkrijgen van logwatch te filteren en de logboekvermeldingen samen te vatten. Logwatch is vrij flexibel, en je kunt de output op elke gewenste manier. Een van de leuke dingen over de hierboven genoemde test script van hierboven is dat u precies laat zien wat je hebt om mee te werken. Dus met een beetje magie reguliere expressie kun je een samenvatting van de items opgeven als u dat nodig achten. Voor een aantal ideeën, check out de bestanden te vinden onder:

/ Usr / share / logwatch / scripts / services

Dit zijn de standaard scripts samenvatting opgenomen met logwatch. In het bijzonder zijn een kijkje op de bestanden "pam" en "sshd". Ze zijn goede voorbeelden van zowel een eenvoudige en een complexe set van filters samenvatting.

Zoals de ontwikkeling van je scripts, aandacht besteden aan de $ LOGWATCH_DETAIL_LEVEL "variabele. Dit zal u toelaten om het uitgangsniveau van het verslag aan te passen, afhankelijk van hoeveel verbosity de gebruiker op zoek is. Bijvoorbeeld, terwijl je nog in de bovenstaande directory services, voer het volgende commando:

minder sshd

Toen 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 tekst string. In dit geval zijn we op zoek naar het woord "detail". Zodra u op Enter drukt de zoektocht loopt door het bestand totdat hij vindt het eerste exemplaar van de tekst string. Ook wordt aandacht besteed de zoekstring. In de eerste wedstrijd, zult u 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 gevolgd door de Enter-toets. Dit zal springen door het bestand naar het volgende voorbeeld van 'Detail'. Je moet zien:

if ($ Detail> = 20) (

Gebruikers $ ($ user) () ($ Host $ methode) + +;

Else ()

if ($ host! ~ / $ IgnoreHost /) (

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

Noot van de auteur vindt u 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 u dient deze verklaring te zien:

if (keys% OtherList) (

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

print "$ _: $ _ $ OtherList () tijd (s) \ n" foreach toetsen OtherList%;

)

Deze sectie is uiterst belangrijk, want het is een definitieve catchall. Denk aan een firewall-beleid voor een moment. De meesten van ons een definitieve regel die zegt: "Als ik niet toestaan dat een specifiek patroon door het verkeer, ontkennen". Met andere woorden, als er iets onverwachts gebeurt, dit is hoe ik wil dat je dit af te handelen.

De bovenstaande verklaring dient hetzelfde doel bij het ontleden van het logbestand. Alle van de vorige "if" verklaringen poging om een specifieke tekenreeks in de log entry om af te stemmen op het goed formaat. Dit item zegt: "Als u nog niet op elkaar afgestemd en drukte een specifieke logboekvermelding nog, het afdrukken in een sectie met de titel" Ongeëvenaarde ** Inzendingen ** ". Deze stap is uiterst belangrijk, omdat zonder dat wij nooit zullen zien onverwachte items. Het is de onverwachte items die waarschijnlijk de belangrijkste en meest interessante.

Samenvatting Exec

Zowel OSSEC logwatch en zijn uitstekende gratis tools. OSSEC excelleert op waarschuw je als een bekende aanvalsvectoren patroon plaatsvindt. Logwatch is een geweldig hulpmiddel voor het samenvatten van een tijd brok van logs, zodat mensen kunnen eigenlijk maken gevoel van wat er gaande is. Door het combineren van de twee tools die je kunt een veel robuuster verdediging in de diepte-houding. Het geheel wordt meer dan de som van de delen.

In mijn laatste twee posts heb ik overlegd en logwatch OSSEC, alsook hoe zij kunnen benutten om uw veiligheid te vergroten zijn houding. In deze tranche zal ik bespreken hoe de beide tools te installeren.

Installeren logwatch

Logwatch is eenvoudig te installeren. In feite is het standaard geïnstalleerd op een groot aantal Linux-distributies, zodat u wellicht al een kopie op uw systeem. Om te controleren, aanmelden als root en probeer logwatch met de "-v" schakelaar. Als je 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, dan kunt u deze uit de grijper logwatch download pagina .

Er zijn drie smaken van logwatch die kunnen worden gedownload; binaries in RPM formaat, bron in RPM formaat of een bron in een tar bal. If your system supports RPM package management, the binary RPM is your best choice. It is simple to install and RPM will automatically update the software when new versions are available.

Installing Logwatch From RPM

To install the binary version of the RPM, simply logon as root and navigate to the directory where you downloaded the RPM file. Now execute the command:

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

Don't forget you can use the tab key to auto-complete the file name rather than having to type in the whole thing.

Installing Logwatch From Source

Installing from source is a bit more time consuming. Remember that in order to install source code you must already have a compiler (like gcc) installed on your system. Logon as root and navigate to the directory where you downloaded the Tar ball. To extract the archive, execute the command:

tar xvzf logwatch-7.3.6.tar.gz

You will see a directory structure below your current location get created and lots of files being copied in. We now need to move into the top most directory that was created:

cd logwatch-7.3.6

In order for Logwatch to run, there are a bunch of directories that need to be created on your system. These are documented in the README in the current directory. Luckily, Logwatch includes an install script that can do all the work for you. Unfortunately, the script has the wrong permissions set so it will not run by default. This is pretty easy to fix however with the chmod command:

chmod 500 install_logwatch.sh

Now we can run the script to setup our system:

./install_logwatch.sh

Don't forget the period at the beginning of the line.

Testing Logwatch

To test your Logwatch setup, execute the command:

logwatch | less

You will see your terminal screen go blank, but that is normal. You will eventually see a Logwatch report get printed to the screen that you can navigate through using the “Page Up” and “Page Down” keys. How log it takes for the report to show up on the screen will depend on how much log information needs to get parsed. It could take a few seconds or a couple of minutes. Either way, it will give you a chance to familiarize yourself with the report format.

Installing OSSEC

As I mentioned in my last post, you have two installation options with OSSEC, local or client/server. In this post I'm going to focus on the client/server setup, as it is a bit more complex. If you are performing a local install, simply select the “local” option during the install process and skip the section on setting up a secure channel between the agent and the server.

Start With The Server

OSSEC uses Blowfish encryption to secure communication between the client and the server. Blowfish is symmetrical key based, so both sides must know what key value to use in order to communicate. The server is responsible for generating the symmetrical key, so we have to install the server software first. During the client install we will be prompted for a key value so obviously we will need to have that handy ahead of time.

Here's a time saving tip. The key value is long and nearly impossible to remember. The easiest way to move the key value from the server system to the agent system is to use SSH. Create a secure connection to the OSSEC server, and extract the appropriate key (directions provided below). In a second terminal window, create an SSH session to the system where you will be installing the agent. When the client install prompts you for the key value, you can simply copy/paste between the two terminals.

Installing The OSSEC Server

The server software is available as a Tar ball, so you can grab a copy of the latest version from the OSSEC download page . You will then need to extract the contents of the Tar ball:

tar xvzf ossec-hids-2.3.tar.gz

Next, move into the directory structure you just created:

cd ossec-hids-2.3

OSSEC provides an install script to walk you through the process of installing the server. To start the script, type:

./install.sh

Don't forget the period at the beginning of the command. You will now be prompted through a number of install options:

• Language – The default is English. Change as needed.
• Confirmation of installation – Press Enter once you have read the screen.
• Install type – Type in “server” without the quotes and press Enter.
• Install location – Accept the default.
• E-mail notification – Default is yes, select if you want e-mail alerts. If you select yes, you will be prompted for a valid e-mail address and mail server.
• Integrity check – Default is yes. Select if you want the local system periodically checked for intrusions.
• Root kit detection – Default is yes. Good option since we need to maintain a high level of integrity on this system.
• Active response – Default is yes. Select this option if you wish to be able to respond to events.
• Firewall drop – Permits the OSSEC server to defend it self if a direct attack is detected.
• White list – This will permit you to add IP addresses from which possible attacks will be ignored. Be careful with this option. If you will not have console access to the OSSEC server, it might be wise to identify one IP address that can always get in. Just ensure the source IP is a trustworthy system.
• Enable Syslog – Default is yes. Select this option if you wish to collect logs from system that cannot run an OSSEC agent (like firewalls, switches, routers, access points, etc.).
• Log files to be monitored – This screen identifies all of the local log files OSSEC will monitor. It is purely information, so all you can do is press Enter to move past it. If you notice one or more log files missing from the list, you can add them later to the ossec.conf file.

At this point OSSEC will access the local complier and install all needed files onto the system. Once complete, you can start the OSSEC server by executing the command:

/var/ossec/bin/ossec-control start

Defining OSSEC Agents

We are not done with the OSSEC server just yet. Next, we need to pre-define any systems that will be running the OSSEC agent (client) software. This is performed using the manage_agents command. First however, we need to do a bit of homework. Make a list of all of the systems that will be running the OSSEC agent software. For each system, you will need a descriptive name as well as that system's IP address.

Now, execute the following from the command line:

/var/ossec/bin/manage_agents

Dit levert 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 systeem IP-adres. Maak je geen zorgen over de agent ID-nummer. Gewoon accepteren de standaard en OSSEC zal automatisch toekennen van de eerstvolgende beschikbare ID-nummer. Zodra u de informatie te bevestigen die u hebt ingevoerd, keert u terug naar de Agent Manager hoofdmenu. Herhaal de bovenstaande procedure voor elk systeem dat zal worden uitgevoerd OSSEC een agent.

Het genereren van Keys

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 het gereedschap gesloten na de laatste stap gemaakt, nu het weer op gang brengen.

Druk op de toets "E" gevolgd door Enter om het als "uittreksel sleutel voor een agent" menuoptie te selecteren. Vervolgens wordt u gevraagd om het ID-nummer van de toets die u wilt uitpakken. 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 software te installeren op agent eerst.

OSSEC Agent Installatie op Linux

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

installeren van de client heeft veel van dezelfde vragen als de server te installeren. Gebruik de info hierboven om u te begeleiden door het proces. De melding dat echter zal variëren is dat u wordt gevraagd om het IP-adres van de server OSSEC bieden. Na voltooiing zal OSSEC toegang tot de lokale compiler en installeert alle benodigde bestanden op het systeem.

Vervolgens moeten we het Blowfish-toets te importeren vanuit het OSSEC server. Hoewel nog steeds aan de agent-systeem, het volgende commando:

/ Var / ossec / bin / manage_agents

Wanneer de Agent Manager-menu verschijnt, selecteer "I" om het Blowfish-toets te importeren.

Toen de volgende prompt verschijnt, moet u handmatig de juiste Blowfish-toets. Nogmaals, als u werkt met SSH om beide systemen op hetzelfde moment, je kunt gewoon copy / paste tussen de twee terminals. Zorg ervoor dat de sleutel lijkt correct, drukt u op de Enter-toets, en kies vervolgens "y" om te bevestigen dat de sleutel juiste looks. U gaat terug naar de Agent Manager menu. Selecteer "q" om terug te keren naar de command line.

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

/ Var / ossec / bin / ossec-controle start

U ziet alle OSSEC agent onderdelen te starten, gevolgd door een 'voltooid' wordt weergegeven.

OSSEC Agent installeren op Windows

OSSEC heeft een zelfuitpakkend uitvoerbaar bestand dat zal u toelaten om de agent-software installeren op een Windows-systeem. Door te dubbelklikken op het uitvoerbare om te beginnen met de installatie. U wordt gevraagd akkoord te gaan met de licentie alsmede welke onderdelen u wilt installeren. Volg gewoon de aanwijzingen tot aan de OSSEC Agent Manager-venster verschijnt.

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

Selecteer vervolgens "Beheer" uit de OSSEC Agent Manager menu, gevolgd door "Start OSSEC". Je moet nu de "Status zie:" indicator te veranderen in "Running ...".

Testen OSSEC

Zodra u de server en agent-software geïnstalleerd, gestart en de passende sleutels geconfigureerd, is het nu tijd om onze setup te testen. Voer de volgende opdracht op de OSSEC server:

cd / var / ossec / logs

En check out de ossec.log bestand:

minder ossec.log

Controleer het logboekbestand voor eventuele fouten. Een veelgemaakte fout is dat OSSEC rapporten kan sturen geen e-mail. Zorg ervoor dat de e-mail server wordt uitgevoerd en dat het verbindingen accepteren. Zodra u tevreden bent met de server setup, is het nu tijd om te controleren of de agenten. Omlaag om de "waarschuwingen" directory:

cd alerts

En check out de alerts.log bestand:

minder alerts.log

Concreet bent u op zoek naar inzendingen van de volgende strekking:

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

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

Src IP: (geen)

Gebruiker: (geen)

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

U ziet nu een item voor elk systeem waarop u de installatie van de Agent-software.

Meer te komen

Whow! Dat is meer dan genoeg voor een post! In mijn volgende post zal ik je in hefboomwerking logwatch om alle informatie van de signalering parse wordt opgewekt door OSSEC.

In my last post I described how Logwatch could be used to simplify the log review process. In this post we'll look at OSSEC and what it brings to the table.

What Is OSSEC?

OSSEC , short for “Open Source SECurity”, is a host based intrusion detection system (HIDS). In other words, it is designed to detect attacks or policy violations if and when they occur. While it does not have the ability to protect against unknown or 0-Day attacks (that would be host based intrusion prevention), it does include a wide range of tools which can help you identify an intrusion when it occurs, as well as the extent of the damage that has been caused.

Supported Platforms

To take advantage of all of the features OSSEC has to offer, you have to run an agent on the system being protected. OSSEC agents can run on Windows, Mac OS X, Linux, and a wide range of UNIX systems. If you are just interested in the log analysis portion however, an even wider range of systems can be supported. This includes hardware from both Cisco and Juniper. A number of specific products are also supported like Checkpoint firewalls, Symantec Anti-Virus, Snort, Squid, and Arpwatch, just to name a few.

When you install OSSEC you have two configuration options, local or client/server. A local install is used when you need to run everything on a single system. The client/server installation lets you run a distributed environment protecting multiple systems at the same time. While most deployments are client/server based, if you want to give OSSEC a spin you can easily run everything on a single test system using a local install.

Log Analysis

OSSEC includes a Log-based Intrusion Detection System (LIDS). This has the ability to review log files in near real time, while scrutinizing them for known attack patterns. When a log is generated on a protected system, the agent takes care of securely transmitting the log (Blowfish encryption using a pre-shared secret) back to the server. The server then takes care of performing the analysis.

Most log analysis tools process their rules in a linear format. By that I mean if we have 500 rules, rule one is checked, then rule two, then rule three and so on till a match is found or we reach the end of the rule set.  OSSEC works a bit differently as it implements a hieratical structure to the rules. Log entries are first classified and then checked only against whichever rules are appropriate. The result is that rather than needing to process all 500 rules, most events will get checked against 10 rules or less. This dramatically reduces the amount of overhead required to process the rule set.

Integrity Checking

OSSEC includes a tool called Syscheck for performing file and directory integrity checking. If you are running a Windows agent, you can also include specific keys within the Windows registry to be monitored as well. File changes can be detected using both MD-5 and SHA-1 hash algorithms. The system is extremely customizable. You can include or exclude single files, or entire directory structures. You can even set a flag to detect new file creation.

The agent software is designed to use a minimal amount of CPU during the integrity check. While this means the check will take longer, it also helps to minimize the performance hit to the system. Hash information is transmitted back to the server. The server then takes care of performing the hash comparison to see if any of the system's critical files have been changed. The server also stores a copy of the integrity check policy, so that if policy changes are made on the agent, they can be detected and reported as well.

Anomaly detection

OSSEC goes far beyond log checking to verify system integrity. Usage policies can be centrally managed from the server, and then pushed out to the appropriate agents. For example you could define a policy regarding which Windows applications are acceptable (Office, Firefox, etc.) and which ones are not (IM client, Skype, etc.). You can even define acceptable configuration options like verifying that NT hashes are being used for password stored but not LanMan hashes.

OSSEC includes a number of other goodies in order to help verify a system's integrity. For example OSSEC has the ability to execute commands from the agent and monitor the output that gets generated. For example you could have the Linux agent execute the “df” command at regular intervals and generate an alert if disk usage exceeds 90%. A Windows example may be to have OSSEC generate an alert whenever file information is written to the alternate data streams area of NTFS.

Active Response

Finally, OSSEC includes the ability to respond when suspicious activity is detected. Responses can be generated from the server or the agent, which ever you specify. Responses can be as benign as generating an e-mail alert, to being as proactive as blocking a remote IP address for a limited amount of time. There are a number of included active response scripts you can draw on, or you can easily write your own.

Secure Architecture

The OSSEC authors have gone to great lengths to secure all of the components within the product. Tasks such as integrity checking are performed on the server, rather than the agent, so the trustworthiness of the hashes cannot be compromised during an attack. Processes are run with the lowest level of permissions possible, and different accounts are used to run each OSSEC component. This means that a compromise of a single application within OSSEC will not immediately lead to a compromise of the full package. Further, most components are run within a chrooted jail so their access to the system is even further restricted.

Final Words

While OSSEC is a powerful tool, it is important to remember that it is a HIDS and not a log management solution. OSSEC can review log entries looking for suspicious patterns, but it will only save alert information. So while OSSEC will not replace your Security Information Management (SIM) solution, it can most certainly augment it. You can easily setup OSSEC to forward all alerts it generates to a central logging server .

While OSSEC is open source software, Trend Micro is primarily developing it. If you need commercial support, you can purchase a support contract through them at a reasonable fee.

More To Come

In my next installment we'll look at installing OSSEC and Logwatch. After that, we'll move into integrating the two together.

I recently had a student ask me a question regarding the integration of Logwatch with OSSEC. I felt like this was a complex and yet cool enough idea that it warranted a series of posts to cover it in full. So over the next few days I'll talk about each of these tools, how to integrate them together, as well as what additional security visibility can be gained once the process is complete.

What Is Logwatch?

Logwatch is an excellent open source tool for generating daily human readable log reports. Log entries tend to fall into one of three categories:

• Stuff you know is evil
• Stuff you know is normal and can be safely ignored
• Everything else

It is that “everything else” category where Logwatch really shines. For the stuff we know is evil, we will setup some form of alerting system. For example we may write an alert signature that warns the security analyst when an account is being brute forced. But what about the attacks we don't know about or are not sure what they look like? This would be a clear example of that “everything else” category. The traffic is not normal, but we have not seen it before to have a signature waiting to generate an alert. Since we will be unable to catch the attack in real time, we will need to catch it during a daily log review.

Of course the problem with doing daily log reviews is that it is tedious and time consuming. I mean let's be honest, who really wants to spend their day reviewing one million plus log entries? Even if you did, are you sure you would actually catch the out of the ordinary traffic?

How It Works

What Logwatch does very well is permit you to reorganize your data into a format that is easier for humans to follow. Its real strength is that it permits you to move the stuff you understand out of the way (normal or evil), so that the unexpected log entries stand out like a sore thumb. In other words, Logwatch lets you summarize your log entries so the unusual stuff is easier to spot.

What I really love about Logwatch is that you don't lose anything. Many log review tools will only show you the stuff that has been pre-defined as being evil. The problem they all share is that when something evil but unexpected happens, it flies right under the wire. Because Logwatch lets you see everything, you no longer miss the unexpected.

Logwatch In Action

Lets discuss how Logwatch works using the SSH server service as an example. The scripts to deal with SSH have already been defined within Logwatch, so you do not need to do any tweaking to receive the features we are going to discuss.

When reviewing a log file, the first thing Logwatch does is reorganize log entries based on their message types. For example all Successful SSH logons are grouped together, as well as too many logon failures, refused connections, locked accounts, accounts without a proper shell, protocol mis-matches, etc. etc. etc. Once all the SSH messages are grouped by their type, the data is then summarized to reduce the amount of information being reported.

For example, the default is to summarize failed logon attempts by account and source IP. So a typical failed logon report section might look like this:

Failed logins from these:

bsmith/password from 1.2.3.4: 637 time(s)

jsmith/password from 1.2.3.5: 2 time(s)

So rather than having to review 639 log entries reporting a bad logon attempt, we have all the pertinent information summarized into three lines (if you include the title). Continue this process for all of the other SSH messages, and we have dramatically reduced the amount of time required to review our logs.

But what if something happens that Logwatch is not pre-programmed to recognize? When an unexpected log entry is found, Logwatch adds a section to the end of the service report called “Unmatched Entries”. So if we see this title in the SSH server section, we know some event has occurred that is either abnormal or unexpected for the SSH service. This could very well be some form of attack that we are not aware is making the rounds.

By focusing in on the unmatched entries section, we can quickly identify unexpected activity. As I stated earlier, this is really the main goal of doing daily log reviews. To find the stuff we don't expect which will sneak past our alerting system. Logwatch makes this process as quick and as painless as possible.

Feature Summary

In the above example I talked about doing daily log reviews, but to be honest Logwatch is highly customizable. You can specify any range you wish to use down to an interval of one second. For example let's say I'm investigating an intrusion rather than performing a daily log review. I could specify a range such as “2010/02/14 17:05:00 for that hour” to focus right in on the information that interest me. I can also focus in on one specific log file or service.

The detail level of the report is also customizable. Typically when you deal with security you get in the habit of always wanting the highest detail level of reporting. To be honest, with Logwatch a high level of detail is probably more than you will ever need. Personally I typically stick with “med” for medium and that works out nicely. You can also specify the reporting level as “low” or “high” or use a numeric range of 0-10 for a higher level of granularity (low =0, med=5, high=10).

Logwatch can be run automatically or as a manual process. Typically you will want to set it up to run automatically each day and summarize one day's worth of log entries. If you ever need to expand or focus the report, you can always run Logwatch from the command line while specifying exactly what you want to see. You can then use the “–save” option to specify a report name and directory location for storage.

More To Come

The above should give you a good idea as to the features Logwatch can bring to the table. In the next post I'll discuss OSSEC in the same level of detail. After that, I'll get into how to install each tool as well as how to integrate them together.