Taggat med: rsyslog

Så upptäckte säkerhetsloggning med OSSEC ett intrång

Detta är en historia om hur min säkerhetsloggning som bl.a. bygger på OSSEC identifierade ett intrång på en av mina webbservrar.

OSSEC är öppen källkod och går under licensen GNU GPLv2 och utvecklades från början av Daniel Cid och företaget Third Brigade som sedermera blev uppköpta av Trend Micro. Dock så lovade Trend Micro att fortsätta hålla OSSEC som öppen källkod, vilket det fortfarande är.

OSSEC är en mjukvara som går under kategorin HIDS (host-based intrusion detection system) och har bl.a. funktioner för att analysera loggfiler efter suspekta mönster, detektera rootkits och utföra aktiva åtgärder såsom att blockera i brandvägg.


Det går att installera OSSEC som fristående installationer på varje server och sedan skicka vidare larm med hjälp av rsyslog, syslog-ng eller filebeat (föredetta logstash-forwarder) eller använda OSSEC:s inbyggda funktionalitet för att skicka loggar krypterat. Det finns även Windows-klienter till OSSEC.

Jag har konfigurerat OSSEC som en tripwire-funktionalitet, dvs att OSSEC kontrollerar checksummor på viktiga filer. Eftersom många webbattacker går ut på att modifiera webbsidor så har jag även lagt in så att OSSEC-larmar på förändringar i filer som ligger under webbkataloger. Standard så kontrollerar OSSEC enbart integritet på ett antal viktiga systemfiler, därför är det viktigt att lägga till ytterligare filer som du vill hålla koll på.

Jag brukar lägga till ungefär följande rad i /var/ossec/etc/ossec.conf filen:

 <directories realtime="yes" report_changes="yes" restrict=".htaccess|.php|.html|.js">/var/www/domän.se/</directories>

Och även följande rad om du vill larma på nya filer:

<alert_new_files>yes</alert_new_files>

Skulle du få många nya larm om temporära filer som skapas i någon katalog så kan du alltid lägga ignore på den katalogen enligt följande:

<ignore>/var/www/katalognamn</ignore>

Men observera dock vilken katalog du ignorerar så inte det går att utnyttja av en angripare.

Vidare bör du ställa ner intervallet då övriga filer kontrolleras som är standard på 22h. Du gör det med följande rad i ossec.conf:

<frequency>14400</frequency>

Även så måste du ändra följande fil: /var/ossec/rules/local_rules.xml och lägga till följande rad för att få larm om nya filer:

<rule id=”554″ level=”7″ overwrite=”yes”>
<category>ossec</category>
<decoded_as>syscheck_new_entry</decoded_as>
<description>File added to the system.</description>
<group>syscheck</group>
</rule>

Det är för att regeln med id 554 standard är satt som level=”0″ vilket betyder att du inte får några larm.

Intrånget

Det larm som dök upp från OSSEC som fick mig att höja på ögonbrynen är följande:

Den som är observant på ovan larm ser att includ_once() är en felstavning av PHP-funktionen include_once(). Givetvis så kontrollerade jag filen manuellt och upptäckte då att någon hade manuellt modifierat footer.php. Detta är ett vanligt förekommande förfarande när det gäller hackade WordPress-installationer.

Efter vidare undersökning så identifierade jag Filesman-phpbakdörren men även en till bakdörr. Denna bakdörr la jag in min egen bakdörr i så att den loggade alla försök att utnyttja bakdörren samt att lösenordet till bakdörren loggades. Om du är intresserad av bakdörrar till php så kan du kolla in min samling på Github Gist här.

Du kan med fördel även importera larm från OSSEC till Splunk eller ELK-stacken (Elasticsearch, Logstash och Kibana).

Filesman PHP-bakdörr