I mitt siste innlegg installerte vi Logwatch samt OSSEC. Det er nå tid for å få Logwatch og OSSEC spille sammen i den samme sandkassen. I dette innlegget vil jeg diskutere hvordan du får Logwatch å oppsummere den informasjonen som blir generert av OSSEC.

Distribusjon Alternativer

Vi har to veier vi kan følge for å sette dette opp:

1. Har Logwatch analysere OSSEC loggene direkte.
2. Har OSSEC sende sin varsler til en Syslog type server, så løpe Logwatch på Syslog serveren.

Fordelen til opsjonsavtaler # 1 er at vi kun trenger ett system. Logwatch skal kjøres på systemet vert for OSSEC serveren. Problemet skal vi kjøre inn innebærer imidlertid OSSEC varselet filen. Loggoppføringer ikke får normalisert. Dette betyr at formatet kan endre seg fra oppføring til oppføring, og kan også spres over flere linjer. Det kommer til å være et reelt mareritt å opprette en Logwatch skript som vil filtrere og oppsummere varselet informasjon.

Hvis vi går med alternativ # 2, vil vi kreve en annen boks for å opptre som vår sentralisert logging server. For å få OSSEC serveren godtar loggoppføringer fra ikke-agent systemer, har det å høre på UDP/514. Dette er den samme port som brukes av en sentralisert logging server, og du kan ikke ha to programmer dele de samme port (unntatt med Windows, men socket-tilgang er ekstremt rotete). På pluss-siden, vil den varsle oppføringene blir normalisert når de er overført til syslog serveren slik skape en Logwatch sammendrag skript vil bli langt enklere. Videre Logwatch allerede vet om den vanlige Syslog filene, så vi vil ha mindre tilpasning arbeid å gjøre.

Til slutt, nevnte jeg i et tidligere innlegg at OSSEC ikke er designet for å være et SIM. Dette er fordi den ikke opp alt, bare de hendelser som genererer et varsel. Så vi er trolig kommer til å ha en sentralisert server uansett, og det er fornuftig å ha den lagre den informasjonen som blir generert av OSSEC.

Så hvis det høres ut som jeg er styringsgruppe du mot alternativ # 2, du er helt korrekt. Med det sagt, jeg er faktisk skal dekke alternativ # 1 som det er et langt mer komplisert oppsett.

Takle dato / klokkeslett stempler

Ta en titt på de viktigste OSSEC logfile og du bør se omtrent slik ut:

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

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

2010/02/18 14:27:06 ossec-syscheckd: INFO: Fra og syscheck skanne.

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

Legg merke til måten dato / tidsstempel er formatert. Dette er annerledes enn de fleste applikasjoner, så det første vi trenger å gjøre er å fortelle Logwatch hvordan man skal håndtere dette formatet. Vi må lage et skript som vi kan ringe ved behov som forstår formatet som vises ovenfor.

Start med å flytte inn i felles scripts katalogen:

cd / usr / share / logwatch / scripts / delt

Ved hjelp av et redigeringsprogram, oppretter du en fil som heter "applylongdate":

vi applylongdate

Her er hva du trenger på innsiden av denne filen. Føl deg fri til å kopiere / lime inn fra denne siden:

Bruk Logwatch ': datoer';

min $ Debug = $ ENV ('LOGWATCH_DEBUG') | | 0;

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

if ($ Debug> 5) (

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

print standardfeil "DEBUG: Looking for:". $ SearchDate. "\ N";

)

mens (definert ($ ThisLine = <STDIN>)) (

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

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

print $ ThisLine;

)

)

# VI: shiftwidth = 3 syntaks = perl tabstop = 3 et

Når du lagrer filen, vi nå må stille de nødvendige tillatelsene:

chmod 755 applylongdate

Konfigurer loggfilene

Neste vi trenger å fortelle Logwatch hvor OSSEC loggen filene ligger. Når du legger til nye loggfiler eller lage nye tjenester til skjermen i Logwatch, bør du plassere endringene under / etc / logwatch katalogen. Vi kommer til å lage to konfigurasjonsfiler. Den første vil håndtere OSSEC meldinger, og den andre skal håndtere OSSEC varsler og aktiv respons endringer.

La oss starte med å opprette konfigurasjonsfilen for de viktigste OSSEC loggfil:

cd / etc / logwatch / conf / loggfiler

vi ossec.conf

Innholdet i filen skal være som følger:

Logfile = / var / ossec / logs / ossec.log

* ApplyLongDate =

Nå kan du lagre og lukke filen. Deretter vil vi lage config-filen for resten av loggfiler:

VI ossec-alert.conf

Innholdet i denne filen skal være som følger:

Logfile = / var / ossec / logs / aktiv-responses.log

Logfile = / var / ossec / logger / varsler / alerts.log

Logfile = / var / ossec / logger / brannmur / firewall.log

Når den er ferdig, lagre og avslutte. Standardtillatelsene bør være akseptabelt for setup vår.

Konfigurere OSSEC Tjenester

Deretter må vi definere OSSEC tjenester og finne ut hva vi ønsker å bruke som tittel når rapportene er generert. Slik oppretter du den første filen:

cd / etc / logwatch / conf / tjenester

vi ossec.conf

Innholdet i denne filen er ganske enkelt:

Title = "OSSEC Meldinger"

Logfile = ossec

Når du har gjort kan du lagre og avslutte. Vi må lage enda en fil i denne katalogen:

VI ossec-alert.conf

Innholdet i denne filen skal være:

Title = "OSSEC Alerts"

Logfile = ossec-varsel

Når den er ferdig, lagre og avslutte som vanlig.

Analysere Entries

Deretter må vi fortelle Logwatch hvordan du formaterer loggen oppføringer i rapporten. Vi må opprette en tilpasning skript for hvert sett av tjenester. Vi kommer til å starte med å bruke en Logwatch medfølgende testskriptet, bare for å sørge for at alt fungerer.

Start med å flytte inn i den aktuelle katalogen:

cd / etc / logwatch / scripts / tjenester

Bruk din favoritt editor for å lage din første skriptet:

vi ossec

Innholdet i manuskriptet skal være som følger:

#! / Bin / bash

# Dette er like fin skript som vil vise deg de linjene du vil

# Være behandling og rapportering. Det vil først vise

# Standard miljøvariabler, og så tar det STDIN og

# Dumpe det rett ut igjen til stdout.

# Dette er standard miljøvariabler. Du kan angi

# Mer i ditt config-filen (se over).

echo "Date Range: $ LOGWATCH_DATE_RANGE"

echo "Detaljnivå: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Reg: $ LOGWATCH_TEMP_DIR"

echo "Debug Nivå: $ LOGWATCH_DEBUG"

# Nå tar STDIN og dumpe det å STDOUT

cat

Nå oppretter andre skriptet:

VI ossec-varsel

og ta med nøyaktig samme innhold:

#! / Bin / bash

# Dette er like fin skript som vil vise deg de linjene du vil

# Være behandling og rapportering. Det vil først vise

# Standard miljøvariabler, og så tar det STDIN og

# Dumpe det rett ut igjen til stdout.

# Dette er standard miljøvariabler. Du kan angi

# Mer i ditt config-filen (se over).

echo "Date Range: $ LOGWATCH_DATE_RANGE"

echo "Detaljnivå: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Reg: $ LOGWATCH_TEMP_DIR"

echo "Debug Nivå: $ LOGWATCH_DEBUG"

# Nå tar STDIN og dumpe det å STDOUT

cat

Til slutt må vi stille de riktige tillatelsene:

chmod 755 ossec *

Testing av installasjonen

Den enkleste måten å teste vårt nye oppsett er å kjøre kommandoen:

logwatch | mindre

Hvis du bare vil se endringene, kan du kjøre en rapport på hver service, en om gangen:

logwatch-tjenesten ossec | mindre

logwatch-tjeneste ossec-varsling | mindre

Ytterligere tilpassing

Når du får alle de ovennevnte arbeider, kan du fokusere på å få Logwatch å filtrere og oppsummere loggoppføringene. Logwatch er ganske fleksibel, og du kan tilpasse resultatet akkurat slik du vil. En av de fine ting om det over testskriptet ovenfor, er at den viser deg nøyaktig hva du har å jobbe med. Så med litt vanlig uttrykk magi du kan oppsummere oppføringene som du finner hensiktsmessig. For noen ideer, sjekk ut filene som ligger under:

/ Usr / share / logwatch / scripts / tjenester

Disse er standard sammendraget skriptene følger med Logwatch. Nærmere bestemt, ta en titt på filene "Pam" og "sshd". De er gode eksempler på både en enkel og et komplekst sett av sammendrag filtre.

Etter hvert som du utvikler din skript være oppmerksom på $ LOGWATCH_DETAIL_LEVEL "variabel. Dette vil tillate deg å tilpasse utgangsnivået av rapporten avhengig av hvor mye detaljnivå brukeren er ute etter. For eksempel mens du fortsatt er i tjenestene ovenfor katalog, kjører du følgende kommando:

mindre sshd

Når den første siden av innholdet i filene vises, skriver du følgende:

/ Detalj <Skriv Key>

Den omvendte skråstreken lar oss søke i filen for et bestemt tekststreng. I dette tilfellet er vi søker etter ordet "Detail". Når du trykker Enter søket hoppe gjennom filen til den finner første forekomsten av tekststreng. Det vil også markere søkestrengen. I den første kampen vil du legge merke til at forfatteren tildelt variabelen "$ Detalj" for å være den samme som den variable $ LOGWATCH_DETAIL_LEVEL ". Dette er å spare dem litt å skrive.

Nå trykker du på tasten igjen backslash etterfulgt av Enter-tasten. Dette vil hoppe gjennom filen til neste forekomst av "Detail". Du bør se:

if ($ Detail> = 20) (

$ Brukere ($ Bruker) ($ Host) ($ Metode) + +;

) Else (

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

$ Brukere ($ Bruker) ($ Host) ("(alle )"}++;

Merk at forfatteren er mer informasjon om detaljnivået er satt til 20 (midt mellom lav og medium) eller høyere. Hold hoppe gjennom filen og du vil se andre eksempler der forfatteren utnyttes denne teknikken.

Nå side ned til slutten av filen og du burde se denne uttalelsen:

if (nøkler% OtherList) (

print "\ n ** Uslåelig Entries ** \ n";

print "$ _: $ OtherList ($ _) gang (er) \ n" foreach nøkler% OtherList;

)

Denne delen er svært viktig, ettersom det er en avsluttende oppsamlingsadresse. Tenk på en brannmur politikk for et øyeblikk. De fleste av oss lage en endelig regel som sier, "Hvis jeg ikke spesifikt tillater en trafikk mønster gjennom, nekte for det". Med andre ord, hvis noe uventet skjer, dette er hvordan jeg vil at du skal håndtere det.

Ovennevnte uttalelse tjener samme formål under analyse av loggfilen. Alle de tidligere "hvis" utsagn forsøker å matche en bestemt tekststreng i loggen for å formatere den riktig. Denne oppføringen sier "Hvis du ikke har matchet og trykte en bestemt logg posten ennå, skrive den ut i et avsnitt med tittelen" ** Uslåelig Entries ** ". Dette trinnet er svært viktig fordi uten den vil vi aldri se uventede oppføringer. Det er den uventede innganger som sannsynligvis er den viktigste og mest interessante.

Exec Summary

Både OSSEC og Logwatch er utmerket gratis verktøy. OSSEC utmerket til advarsel når et kjent mønster angrep finner sted. Logwatch er et veldig bra verktøy for oppsummering av en tid blings av logger, slik at mennesker faktisk kan gjøre følelse av hva som skjer. Ved å kombinere de to verktøyene kan du lage en langt mer robust forsvar i dybden stilling. Hele blir større enn summen av delene.

I mine siste to innlegg drøftet jeg Logwatch og OSSEC, samt hvordan de kan dra nytte av å øke din sikkerhet holdning. I denne avbetaling vil jeg diskutere hvordan du installerer begge disse verktøyene.

Installere Logwatch

Logwatch er ganske enkel å installere. Faktisk er det installert som standard på mange Linux-distribusjoner, slik at du kanskje allerede har en kopi på systemet. Hvis du vil kontrollere, pålogging som root og prøv å kjøre Logwatch med "-v" bryter. Hvis du ser:

[Root @ Fubar logwatch] # logwatch-v

Logwatch 7.3.6 (utgitt 05/19/07)

Logwatch er installert og du har en kopi av den nyeste versjonen. Hvis du ikke har den nyeste versjonen, kan du hente det fra Logwatch nedlastingssiden .

Det er tre varianter av Logwatch som kan lastes ned; Binærfiler i RPM-format, kilde i RPM-format, eller kilde i et Tar ball. Hvis systemet ditt støtter RPM pakkesystem, den binære RPM er ditt beste valg. Det er enkelt å installere og RPM vil automatisk oppdatere programvaren når nye versjoner er tilgjengelige.

Installere Logwatch Fra RPM

Hvis du vil installere den binære versjonen av RPM, bare pålogging som root og navigere til katalogen der du har lastet ned RPM filen. Nå utføre kommandoen:

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

Glem ikke at du kan bruke TAB for å auto-fullføre filnavn i stedet for å måtte skrive inn hele greia.

Installere Logwatch fra Kilde

Installere fra source er litt mer tidkrevende. Husk at for å installere kildekoden må du allerede har en kompilator (som gcc) installert på systemet ditt. Pålogging som root og navigere til katalogen der du har lastet ned Tar ballen. For å pakke ut arkivet, utføre kommandoen:

tar xvzf logwatch-7.3.6.tar.gz

Du vil se en katalogstruktur under stedet der du befinner få laget og masse filer som kopieres i. Vi må nå flytte inn i den øverste katalogen som ble laget:

cd logwatch-7.3.6

For Logwatch å kjøre, er det en haug med kataloger som må opprettes på systemet ditt. Dette er dokumentert i README i gjeldende katalog. Heldigvis inneholder Logwatch en installerer skript som kan gjøre alt arbeidet for deg. Dessverre har skriptet feil tillatelser satt slik at den ikke vil kjøre som standard. Dette er ganske enkelt å fikse men med chmod kommandoen:

chmod 500 install_logwatch.sh

Nå kan vi kjøre skriptet å sette opp systemet vårt:

. / Install_logwatch.sh

Ikke glem den perioden på begynnelsen av linjen.

Testing Logwatch

For å teste Logwatch oppsettet, utføre kommandoen:

logwatch | mindre

Du vil se din terminal skjermen gå tom, men det er normalt. Du vil etter hvert se en Logwatch rapport får skrevet ut til skjermen som du kan navigere gjennom ved hjelp av "Page Up" og "Page Down"-tastene. Hvordan logger det tar for rapporten skal vises på skjermen vil avhenge av hvor mye logginformasjonen trenger å få analysert. Det kan ta noen sekunder eller et par minutter. Uansett vil det gi deg en sjanse til å gjøre deg kjent med rapporten format.

Installere OSSEC

Som jeg nevnte i mitt siste innlegg, har du to alternativer installasjon med OSSEC, lokale eller klient / server. I dette innlegget skal jeg fokusere på klient / server setup, som det er litt mer komplisert. Hvis du utfører en lokal installasjon, velger du bare "lokale" valget under installasjonen, og hoppe over den delen om å sette opp en sikker kanal mellom agent og serveren.

Start med tjeneren

OSSEC bruker Blowfish kryptering for å sikre kommunikasjon mellom klienten og serveren. Blowfish er symmetrisk nøkkel basert, slik at begge sider må vite hva nøkkelen verdi som skal brukes for å kommunisere. Serveren er ansvarlig for å generere den symmetriske nøkkelen, så vi må installere serverprogramvaren først. Under kunden installerer vi vil bli spurt om en nøkkel verdi så åpenbart vi trenger å ha det praktiske forut for sin tid.

Her er et tidsbesparende tips. Nøkkelen verdien er lang og nesten umulig å huske. Den enkleste måten å flytte nøkkelen verdien fra serveren systemet til agent systemet er å bruke SSH. Opprette en sikker forbindelse til OSSEC serveren, og pakke den aktuelle tasten (veibeskrivelse nedenfor). I et annet terminalvindu, opprette en SSH sesjon til systemet hvor du skal installere agenten. Når klienten installerer ber deg om nøkkelen verdien, kan du bare kopiere / lime mellom de to terminalene.

Installere OSSEC Server

Serverprogramvaren er tilgjengelig som en Tar ball, slik at du kan ta en kopi av den nyeste versjonen fra OSSEC nedlastingssiden . Du må da pakke ut innholdet i Tar ballen:

tar xvzf ossec-hids-2.3.tar.gz

Deretter flytter inn i katalogstrukturen du nettopp opprettet:

cd ossec-hids-2.3

OSSEC gir en installerer skript for å lede deg gjennom prosessen med å installere serveren. For å starte skriptet, type:

. / Install.sh

Ikke glem perioden på begynnelsen av kommandoen. Du vil nå bli bedt om gjennom en rekke installasjonsalternativer:

• Språk - Standard er engelsk. Endre etter behov.
• Stadfesting av installasjon - Trykk Enter når du har lest skjermen.
• Installere type - Skriv inn "server" uten anførselstegn, og trykk Enter.
• Installere beliggenhet - Godta standard.
• E-post varsling - Standard er ja, velge om du vil e-postvarsler. Hvis du velger ja, vil du bli bedt om en gyldig e-postadresse og e-postserveren.
• Integritet sjekk - Standard er ja. Velg om du vil at lokale systemet regelmessig kontrolleres for inntrenging.
• Root kit gjenkjenning - Standard er ja. Godt alternativ siden vi trenger for å opprettholde en høy grad av integritet på dette systemet.
• Aktiv respons - Standard er ja. Velg dette alternativet hvis du ønsker å være i stand til å reagere på hendelser.
• Brannmur drop - tillater OSSEC serveren til å forsvare seg selv om et direkte angrep blir oppdaget.
• 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

This will produce the Agent Manager main menu. Press “A” followed by the Enter key to define your first system. Enter a descriptive name for the first system, followed by the system's IP address. Don't worry about the agent ID number. Simply accept the default and OSSEC will auto-assign the next available ID number. Once you confirm the information you entered, you will be returned to the Agent Manager main menu. Repeat the above process for each system that will be running an OSSEC agent.

Generating Keys

Once you have added in all of your systems, it is time to generate encryption keys. This step is also performed with the manage_agents utility. If you closed the tool after the last step, relaunch it now.

Press the “E” key followed by Enter to select the “Extract key for an agent” menu option. You will then be prompted for the ID number of the key you wish to extract. The descriptive names and IP addresses are listed with each ID number, so it should be trivial to identify which one you want. Start with the system you plan to install the agent software onto first.

OSSEC Agent Install On Linux

When installing the agent software on a Linux or UNIX client, you use the exact same Tar ball we used to install the server software. Run the same install script, but this time when you are prompted for the type of install you wish to perform, type in “agent” followed by the Enter key.

The client install has many of the same prompts as the server install. Use the info above to guide you through the process. The prompt that will vary however is that you will be asked to provide the IP address of the OSSEC server. Once complete, OSSEC will access the local complier and install all required files onto the system.

Next we need to import the Blowfish key from the OSSEC server. While still on the agent system, run the command:

/var/ossec/bin/manage_agents

When the Agent Manager menu appears, select “I” to import the Blowfish key.

When the next prompt appears, you need to manually enter the appropriate Blowfish key. Again, if you are running SSH to both systems at the same time, you can simply copy/paste between the two terminals. Make sure the key looks correct, press the Enter key, and then select “y” to confirm that the key looks correct. You will be returned to the Agent Manager menu. Select “q” in order to return to the command line.

Now we simply need to start the OSSEC agent. You can do so by executing the following command:

/var/ossec/bin/ossec-control start

You should see all of the OSSEC agent components start up, followed by a “Completed” message.

OSSEC Agent Install On Windows

OSSEC has a self-extracting executable that will permit you to install the agent software on a Windows system. Simply double click the executable to start the install process. You will be prompted to agree to the license as well as which components you wish to install. Simply follow the prompts till the OSSEC Agent Manager window appears.

The OSSEC Agent Manager window will prompt you for the IP address of the OSSEC server. It will also prompt you for the Blowfish key value to use, so extract the appropriate key on the server and enter the value in this field. Make sure you delete the prompt within this field before you paste in the Blowfish key. Otherwise communication with the server may fail.

Next, select “Manage” from the OSSEC Agent Manager menu, followed by “Start OSSEC”. You should now see the “Status:” indicator change to “Running…”.

Testing OSSEC

Once you have the server and agent software installed, started and the appropriate keys configured, it is now time to check our setup. Execute the following command on the OSSEC server:

cd /var/ossec/logs

And check out the ossec.log file:

less ossec.log

Check the log file for any errors. A common error is that OSSEC reports it cannot send e-mail. Make sure the mail server is running and that it is accepting connections. Once you are happy with the server setup, it is now time to check out the agents. Move down to the “alerts” directory:

cd alerts

And check out the alerts.log file:

less alerts.log

Specifically, you are looking for entries similar to the following:

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

Rule: 501 (level 3) -> 'New ossec agent connected.'

Src IP: (none)

User: (none)

ossec: Agent started: 'test_system->192.168.1.10′.

You should see an entry for every system on which you installed the agent software.

More To Come

Whew! That's more than enough for one post! In my next post I'll get into leveraging Logwatch to parse all of the alert information being generated by 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.