I mitt förra inlägg installerade vi logwatch samt OSSEC. Det är nu dags att få logwatch och OSSEC spela tillsammans i samma sandlåda. I detta inlägg ska jag diskutera hur man kan få logwatch att sammanfatta den information som genereras av OSSEC.

Distribution Alternativ

Vi har två vägar vi kan följa för att ställa upp detta:

1. Har logwatch tolka OSSEC stockar direkt.
2. Har OSSEC skicka sina meddelanden till en Syslog typ server, kör sedan logwatch om syslog-server.

Förmånen för alternativ 1 är att vi bara behöver ett system. Logwatch kommer att köras på systemet värd för OSSEC servern. Det problem vi kommer att rinna ut innebär dock OSSEC registreringen filen. Loggposter inte får normaliseras. Detta innebär att formatet kan ändras från tillträde till inresa, och kan även spridas över flera rader. Det kommer att bli en riktig mardröm att skapa en logwatch skript som filter och sammanfattning av varningsinformation.

Om vi går med alternativ # 2 kommer vi att kräva en annan låda som skall fungera som vår centraliserad loggning server. För att få OSSEC servern accepterar loggposter från icke-agent, är den att lyssna på UDP/514. Det är samma port som används av en centraliserad loggning server, och du kan inte ha två ansökningar har samma hamn (utom med Windows, men uttaget är extremt rörigt). På den positiva sidan, kommer registreringen poster blir normaliserat när de överförs till syslog-servern så att skapa en logwatch sammanfattning skript kommer att bli mycket lättare. Vidare logwatch redan känner till standarden Syslog-filer, så vi kommer att ha mindre anpassning att göra.

Slutligen nämnde jag i ett tidigare inlägg som OSSEC inte är utformad för att ett SIM. Detta eftersom det inte anteckna allt, bara de händelser som leder till en anmälan. Så vi förmodligen kommer att vilja ha en central server i alla fall, och det är vettigt att ha det lagra information som genereras av OSSEC.

Så om det låter som jag styr dig mot alternativ # 2, du är helt riktig. Med det sagt, jag ska faktiskt till att omfatta alternativ 1 eftersom det är ett mycket mer komplicerat setup.

Hantering av datum / tid Frimärken

Ta en titt på de viktigaste OSSEC loggfilen och du bör se ut ungefär så här:

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

2010/02/18 00:32:05 ossec-rootcheck: INFO: Slutdatum rootcheck scan.

2010/02/18 14:27:06 ossec-syscheckd: INFO: Från syscheck scan.

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

Notera hur datum-/tidstämpel formateras. Detta är annorlunda än de flesta tillämpningar, så det första vi behöver göra är att berätta logwatch hur man skall hantera detta format. Vi behöver skapa ett manus som vi kan kalla när det behövs som förstår det format som anges ovan.

Börja med att inflyttningen till delad skript katalogen:

cd / usr / share / logwatch / scripts / delade

Använd din favorit editor, skapa en fil med namnet "applylongdate":

VI applylongdate

Här är vad du behöver insidan av den filen. Känn dig fri att kopiera och klistra in från denna sida:

användning logwatch ": datum";

min $ 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: Söker:". $ SearchDate. "\ N";

)

medan (definierade ($ ThisLine = <STDIN>)) (

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

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

print $ ThisLine;

)

)

# VI: shiftwidth = 3 syntax = perl Tabbstopp = 3 et

När du sparar filen måste vi nu ställa in rätt behörighet:

chmod 755 applylongdate

Konfigurera loggfilerna

Nästa vi måste berätta logwatch där OSSEC loggfiler finns. Varje gång du lägger loggfiler eller skapa nya tjänster för att övervaka i logwatch bör du placera dina ändringar under / etc / logwatch katalogen. Vi kommer att skapa två konfigurationsfiler. Den första kommer att hantera OSSEC meddelanden, och den andra kommer att hantera OSSEC varningar och aktiva förändringar svar.

Låt oss börja med att skapa konfigurationsfilen för de viktigaste OSSEC loggfilen:

cd / etc / logwatch / conf / loggfiler

VI ossec.conf

Innehållet i filen ska vara så följas:

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

* ApplyLongDate =

Du kan nu spara och stäng filen. Därefter kommer vi att skapa konfigurationsfilen för återstående loggfilerna:

vi ossec-alert.conf

Innehållet i detta ärende bör vara så följas:

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

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

Logfile = / var / ossec / logs / brandvägg / firewall.log

När du är klar spara och avsluta. Standardbehörigheterna torde vara godtagbart för vår inställning.

Konfigurera OSSEC Tjänster

Sedan behöver vi också fastställa OSSEC tjänster och identifiera vad vi vill använda som en rubrik när rapporterna genereras. Här skapar du den första filen:

cd / etc / logwatch / conf / tjänster

VI ossec.conf

Innehållet i detta ärende är ganska enkelt:

Titel = "OSSEC Meddelanden"

Logfile = ossec

När du är klar kan du spara och avsluta. Vi måste skapa en mer filen i den katalogen:

vi ossec-alert.conf

Innehållet i denna fil bör vara:

Titel = "OSSEC alarm"

Logfile = ossec-alert

När du är klar spara och avsluta som vanligt.

Analysera Inlägg

Sedan behöver vi berätta logwatch hur du formaterar loggposter i betänkandet. Vi behöver skapa en anpassning skript för varje uppsättning av tjänster. Vi kommer att börja med att använda en logwatch medföljande testunderlag, bara se till att allt fungerar.

Börja med att inflyttningen till lämplig katalog:

cd / etc / logwatch / scripts / tjänster

Använd din favorit editor för att skapa ditt första skript:

VI ossec

Innehållet i skriften ska vara så följas:

#! / Bin / bash

# Det är så trevligt script som visar dig de linjer du

# Vara bearbetning och rapportering om. Det kommer först att visa

# Standard miljövariabler och det tar STDIN och

# Dumpa det rätt ut igen till standard ut.

# Detta är de vanliga miljövariabler. Du kan definiera

# Mer i din config-fil (se ovan).

echo "Datumintervall: $ LOGWATCH_DATE_RANGE"

echo "Detaljnivå: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Dir: $ LOGWATCH_TEMP_DIR"

echo "Debug Nivå: $ LOGWATCH_DEBUG"

# Ta Nu STDIN och dumpa det på standard ut

katt

Now create your second script:

vi ossec-alert

and include the exact same contents:

#!/bin/bash

# This is as nice script that will show you the lines you will

# be processing and reporting on.  It will first display the

# standard environment variables and then it takes STDIN and

# dump it right back out to STDOUT.

# These are the standard environment variables.  You can define

# more in your service config file (see above).

echo “Date Range: $LOGWATCH_DATE_RANGE”

echo “Detail Level: $LOGWATCH_DETAIL_LEVEL”

echo “Temp Dir: $LOGWATCH_TEMP_DIR”

echo “Debug Level: $LOGWATCH_DEBUG”

# Now take STDIN and dump it to STDOUT

cat

Finally, we need to set the appropriate permissions:

chmod 755 ossec*

Testing The Setup

The easiest way to test our new setup is to run the command:

logwatch | less

If you only want to see your changes, you can run a report on each service, one at a time:

logwatch –service ossec | less

logwatch –service ossec-alert | less

Further Customization

Once you get all of the above working, you can focus on getting Logwatch to filter and summarize the log entries. Logwatch is pretty flexible, and you can customize the output any way you want. One of the nice things about the above test script above is that it shows you exactly what you have to work with. So with a little regular expression magic you can summarize the entries as you deem appropriate. For some ideas, check out the files located under:

/usr/share/logwatch/scripts/services

These are the default summary scripts included with Logwatch. Specifically, have a look at the files “pam” and “sshd”. They are great examples of both a simple and a complex set of summary filters.

As you develop your scripts, pay close attention to the $LOGWATCH_DETAIL_LEVEL” variable. This will permit you to customize the output level of the report depending on how much verbosity the user is looking for. For example, while you are still in the above services directory, run the following command:

less sshd

When the first page of the file's contents is displayed, type in:

/Detail<Enter Key>

The backslash lets us search the file for a particular text string. In this case we are searching for the word “Detail”. Once you press Enter the search will skip through the file till it finds the first instance of the text string. It will also highlight the search string. In the first match you will notice that the author assigned the variable “$Detail” to be the same as the variable $LOGWATCH_DETAIL_LEVEL”. This is to save them some typing.

Now press the backslash key again followed by the Enter key. This will jump through the file to the next instance of “Detail”. You should see:

if ($Detail >= 20) {

$Users{$User}{$Host}{$Method}++;

} else {

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

$Users{$User}{$Host}{“(all)”}++;

Note the author provides more information if the detail level is set to 20 (half way between low and medium) or higher. Keep jumping through the file and you will see other examples where the author leveraged this technique.

Now page down to the end of the file and you should see this statement:

if (keys %OtherList) {

print “\n**Unmatched Entries**\n”;

print “$_ : $OtherList{$_} time(s)\n” foreach keys %OtherList;

)

This section is extremely important, as it is a final catchall. Think of a firewall policy for a moment. Most of us create a final rule that says, “If I did not specifically permit a traffic pattern through, deny it”. In other words, if something unexpected happens, this is how I want you to handle it.

The above statement serves the same purpose when parsing the logfile. All of the previous “if” statements attempt to match a specific text string in the log entry in order to format it properly. This entry says “If you have not matched and printed a specific log entry yet, print it out in a section titled “**Unmatched Entries**”. This step is extremely important because without it we will never see unexpected entries. It is the unexpected entries that are probably the most important and most interesting.

Exec Sammanfattning

Both OSSEC and Logwatch are excellent complimentary tools. OSSEC excels at warning you when a known attack pattern takes place. Logwatch is a terrific tool for summarizing a time chunk of logs so humans can actually make sense of what is going on. By combining the two tools you can create a far more robust defense in-depth posture. The whole becomes greater than the sum of the parts.

In my last two posts I discussed Logwatch and OSSEC, as well as how they can be leverage to augment your security posture. In this installment I'll discuss how to install both of these tools.

Installing Logwatch

Logwatch is pretty easy to install. In fact, it is installed by default on many Linux distributions so you may already have a copy on your system. To check, logon as root and try running Logwatch with the “-v” switch. If you see:

[root@fubar logwatch]# logwatch -v

Logwatch 7.3.6 (released 05/19/07)

Logwatch is installed and you have a copy of the latest version. If you do not have the latest version, you can grab it from the Logwatch download page .

There are three flavors of Logwatch which can be downloaded; Binaries in RPM format, source in RPM format, or source in a Tar ball. 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

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.

Mer att komma

Usch! 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.

I mitt senaste inlägg beskrev jag hur logwatch skulle kunna användas för att förenkla översynen loggen. I detta inlägg kommer vi att titta på OSSEC och vad det innebär för bordet.

Vad är OSSEC?

OSSEC , kort för "Open Source Security", är en värdbaserad Intrusion Detection System (HIDS). Med andra ord är det utformat för att upptäcka angrepp eller kränkningar politik om och när de uppstår. 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.

Plattformar som stöds

För att kunna utnyttja alla funktioner OSSEC har att erbjuda, måste du köra en agent på systemet som skyddas. OSSEC agenter kan köras på Windows, Mac OS X, Linux och ett brett utbud av UNIX-system. If you are just interested in the log analysis portion however, an even wider range of systems can be supported. Detta inkluderar hårdvara från både Cisco och Juniper. A number of specific products are also supported like Checkpoint firewalls, Symantec Anti-Virus, Snort, Squid, and Arpwatch, just to name a few.

När du installerar OSSEC du har två inställningsalternativ, lokala eller klient / server. En lokal installation används när du behöver köra allt på ett enda system. I klient / server installation kan du köra en distribuerad miljö skydda flera system samtidigt. Även om de flesta installationer är klient / server-baserat, om du vill ge OSSEC en spin du lätt kan köra allt på ett enda test som använder en lokal installation.

Log Analysis

OSSEC ingår ett Log-baserad Intrusion Detection System (lock). Detta har förmågan att granska loggfiler i nära realtid, medan granska dem för kända angrepp mönster. När en stock genereras på ett skyddat system, tar agenten hand om säkert översändande loggen (Blowfish kryptering med en i förväg delad hemlighet) tillbaka till servern. Servern tar sedan hand om att utföra analysen.

De flesta log analysverktyg bearbetar sina regler på ett linjärt format. Med det menar jag om vi har 500 regler, regel ett är markerad, så i regel två, sedan regel tre och så vidare tills en matchning hittas eller att vi kommer till slutet för regeln. OSSEC fungerar lite annorlunda då det genomför en hieratical struktur med reglerna. Loggposterna först klassificeras och kontrolleras enbart mot beroende på reglerna är lämpliga. Resultatet är att istället för att behöva bearbeta alla 500 regler, kommer de flesta evenemang får kontrolleras mot 10 regler eller mindre. Detta dramatiskt reducerar overhead krävs för att behandla den regel som.

Integritetskontroll

OSSEC innehåller ett verktyg som heter Syscheck för att utföra fil och katalog integritet kontroll. Om du kör en Windows-agent, kan du även inkludera specifika tangenter i Windows-registret som skall övervakas också. Arkiv förändringar kan spåras med både MD-5 och SHA-1 algoritmer hash. Systemet är mycket anpassningsbart. Du kan inkludera eller utesluta enskilda filer eller hela strukturer katalog. Du kan även ställa in en flagga för att upptäcka nya filen skapas.

Agenten programvara är att använda minimalt med CPU under integritet kontroll. Även om detta innebär att kontrollen kommer att dröja längre, den bidrar till att minimera utförande slå till systemet. Hash information skickas tillbaka till servern. Servern tar sedan hand om att utföra de hash jämförelse för att se om någon av systemets viktiga filer har ändrats. Servern lagrar också en kopia av hederligheten check politik, så att om politiska förändringar görs på ombudet, kan de påvisas och rapporteras också.

Att upptäcka avvikelser

OSSEC goes far beyond log checking to verify system integrity. Riktlinjer för användning kan hanteras centralt från servern, och sedan sköt ut till lämpliga medel. Till exempel kan du definiera en policy om vilka Windows-program är acceptabla (Office, Firefox, etc.) och vilka som inte är (IM-klient, Skype, etc.). Du kan även ange acceptabelt konfigurationsalternativ vilja kontrollera att NT hashar används för lösenord lagras men inte Lanman hashar.

OSSEC innehåller ett antal andra godsaker för att bidra till att verifiera systemets integritet. Till exempel OSSEC har möjligheten att köra kommandon från agenten och övervaka produktionen som får genereras. Till exempel kan du få Linux-agenten utföra "df"-kommandot med jämna mellanrum och leder till en anmälan om diskanvändning överstiger 90%. En Windows exempel kan vara att ha OSSEC generera en varning när filen är skriven för Alternate Data Streams område med NTFS.

Aktiv respons

Slutligen innehåller OSSEC förmågan att reagera när misstänkt aktivitet upptäcks. Svaren kan genereras från servern eller dennes ombud, som någonsin du anger. Svaren kan vara så tillmötesgående som genererar ett e-postmeddelande, att vara så aktiv som blockerar en IP-adressen för en begränsad tid. Det finns ett antal av de ingående aktiv respons skript du kan dra på, eller så kan du enkelt skriva en egen.

Säker Arkitektur

De OSSEC Författarna har gjort stora ansträngningar för att säkra alla delar i produkten. Uppgifter som att integritetskontroll utförs på servern, snarare än agenten, så trovärdigheten i hashar inte kan äventyras under en attack. Processer körs med den lägsta nivån av behörigheter möjligt och olika konton används för att köra varje OSSEC komponent. Detta innebär att ett röjande av en enda ansökan inom OSSEC inte omedelbart kommer att leda till en kompromiss av hela paketet. Ytterligare komponenter, de flesta körs i en chrootade fängelse så deras tillgång till systemet är ännu mer begränsad.

Slutord

Medan OSSEC är ett kraftfullt verktyg är det viktigt att komma ihåg att det är en HIDS och inte en stock management-lösning. OSSEC kan granska loggposter söker efter misstänkta mönster, men det kommer bara spara varningsinformation. So while OSSEC will not replace your Security Information Management (SIM) solution, it can most certainly augment it. Du kan enkelt setup OSSEC att vidarebefordra alla registreringar som skapas för att en central loggning server .

Medan OSSEC är öppen källkod, Trend Micro utvecklas i första hand det. Om du behöver kommersiell support kan du köpa ett supportavtal genom dem till en rimlig kostnad.

Mer att komma

I mitt nästa delbetalning vi titta på installation OSSEC och logwatch. Efter det kommer vi att flytta in i att integrera de två tillsammans.

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.

Mer att komma

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.