home » search tags
Die Suche tag = logstash ergab 5 Treffer:

Mai
2
Mittels facets lassen sich bestimmte Felder anhand ihres vorkommens suchen und zusammenfassen.

Wie man losgstash beibringen kann die GeoIP-Daten zu nutzen, habe ich hier bereits geschrieben.

Wer z.B. die logfiles seines Mailservers in Elasticsearch sammelt, kann z.B. eine Statistik der Top SPAM Länder erstellen. Da ich Einträge von Postfix mit _type = postfix und SPAM mit tag = msg_spam versehe, sieht das passende query/facets wie folgt aus:

{
"fields" : ["geoip.country_code2"],
"query" :{
"bool" : {
"must" : {
"term" : {
"type" : "postfix"
}
},
"must" : {
"term" : {
"tags" : "msg_spam"
}
}
}
},
"facets" : {
"laender" : {
"terms" : {
"field" : "country_code2",
"size" : 10
}
}
}
}



Die dazu passende Ausgabe wäre dann:

{u'count': 69, u'term': u'ru'}
{u'count': 48, u'term': u'gb'}
{u'count': 37, u'term': u'us'}
{u'count': 34, u'term': u'ar'}
{u'count': 30, u'term': u'es'}
{u'count': 28, u'term': u'vn'}
{u'count': 24, u'term': u've'}
{u'count': 24, u'term': u'sa'}
{u'count': 22, u'term': u'tw'}
{u'count': 18, u'term': u'ua'}

April
25
Mittels fail2ban lassen sich (mehr oder weniger) wirksam und automatisiert, unerwünschte Zugriff auf einen Server verhinden und protokollieren.

Um die Daten (z.B. wer hat wann, wie und auf welche Art versucht sich unlauter am System anzumelden) zu visualisieren gibt es verschiedene Ansätze.
Aktuell nutze ich auf div. Systemen eine Mischung aus Logstash, Elasticsearch und Kibana.

Ich gehe davon aus, das bereits eine Umgebung der genannten Komponenten läuft und gehe daher nicht auf die Installation ein.

Die von mir genutzte Konfiguration von fail2ban sieht wie folgt aus

loglevel = 3
logtarget = /var/log/fail2ban.log
socket = /var/run/fail2ban/fail2ban.sock



Wichtig für die weitere Konfiguration ist der Pfad zum Logfile (logtarget), in diesem Beispiel /var/log/fail2ban.log

Die Einträge im Logfile haben folgendes Muster (wobei www.xxx.yyy.zzz die IP darstellt):

2014-04-24 03:43:11,315 fail2ban.actions: WARNING [ssh] Ban www.xxx.yyy.zzz
2014-04-24 05:17:38,490 fail2ban.actions: WARNING [ssh] Ban www.xxx.yyy.zzz
2014-04-24 10:51:26,914 fail2ban.actions: WARNING [ssh] Ban www.xxx.yyy.zzz
2014-04-24 16:20:17,831 fail2ban.actions: WARNING [postfix] Ban www.xxx.yyy.zzz
2014-04-24 18:40:26,777 fail2ban.actions: WARNING [ssh] Ban www.xxx.yyy.zzz
2014-04-24 23:23:48,630 fail2ban.actions: WARNING [sasl] Unban www.xxx.yyy.zzz
2014-04-25 03:43:11,729 fail2ban.actions: WARNING [ssh] Unban www.xxx.yyy.zzz



Um das Logfile korrekt von Logstash verarbeiten zu lassen, benötigen wir passende Filter:

FAIL2BAN %{GREEDYDATA:timer} fail2ban.actions: %{GREEDYDATA:severity} \
[%{GREEDYDATA:service}\] %{FAIL2BAN_ACTION:action} %{IPV4:remoteaddr}



Nun kann man das Logfile von fail2ban in Logstash einbinden:

input {
file {
path => "/var/log/fail2ban.log"
type => "fail2ban"
tags => "fail2ban,system,security"
}
}

filter {
if [type] == "fail2ban" {
grok {
patterns_dir => ["/opt/logstash/patterns"]
match => ["message", "%{FAIL2BAN}"]
add_tag => [ "fail2ban_action" ]
}
}
if [remoteaddr] {
geoip {
source => "remoteaddr"
target => "geoip"
database => "/opt/logstash/GeoLiteCity.dat"
add_field => [ "[geoip][coordinates]", "%{[geoip][longitude]}" ]
add_field => [ "[geoip][coordinates]", "%{[geoip][latitude]}" ]
}
mutate {
convert => [ "[geoip][coordinates]", "float" ]
}
}

}



Nach einem restart/reload von Logstash muss man nur warten (was meist nicht sonderlich lange dauert) bis die ersten Zugriffe von fail2ban geloggt wurden.

Anschließend kann man innerhalb von Kibana (über den Tag fail2ban) die anfallenden Daten visualisieren:

Im folgenden Beispiel sind die Aktionen wie folgt eingefärbt:

Ban = grün
Unban = gelb

April
2
Wie hier bereits beschrieben kann man Logstash (und Kibana) nutzen um z.B. die Besucher einer Webseite geographisch darzustellen, das ganze sieht dann z.B. so aus

März
26
Wer einen Webserver betreibt will gerne wissen aus welcher Region der Welt seine Besucher kommen.
Da ich die Logfiles von div. Webservern mit Logstash verarbeite lag es nahe diese Funktion direkt beim indexieren zu erledigen, somit entfällt zukünftig das manuelle Nachschlagen der Geodaten (z.B. via utrace.de.

Das anpassen von Logstash ist schnell geschehen

Zuerst besorgt man sich eine passende GeoIP-Datenbank, z.B. die Opensource Version von MaxMind
wget -N http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz



Nach dem entpacken

gunzip GeoLiteCity.dat.gz && cp GeoLiteCity.dat /opt/logstash/



kann man mit der Konfiguration von Logstash beginnen. Als Basis dient ein System das nach folgender Anleitung "Elasticsearch - Basisinstallation/Testsystem" installiert wurde.

Die zentrale Konfigurationsdatei (in meinem Falle logstash.conf) muss mit folgenden Filter erweitert werden

filter {
if [remoteaddr] {
geoip {
source => "remoteaddr"
target => "geoip"
database => "/opt/logstash/GeoLiteCity.dat"
add_field => [ "[geoip][coordinates]", "%{[geoip][longitude]}" ]
add_field => [ "[geoip][coordinates]", "%{[geoip][latitude]}" ]
}
mutate {
convert => [ "[geoip][coordinates]", "float" ]
}
}
}



Nach einem restart/reload von Logstash kann man nun die folgenden neuen Felder finden:


März
26
Ich komme kaum mit dem Updates von elasticsearch hinterher, denn kaum habe ich eine Anleitung für 1.0.1 geschrieben, ist Version 1.1.0 raus. Den passenden Download gibt's hier

Da mich die laaange Liste der breaking changes, new features, enhancements und bugfixes überzeugt hat, sind nun alle meine ES-Systeme aktualisiert.

Bei dieser Gelegenheit habe ich auch gleich Logstash von 0.9.0 auf die passende Version 1.4.0 aktualisiert.