ExpireDate von Zertifikat überwachen.

Wer, wie ich, eine eigene (private) CA betreibt, wird irgendwann mal überrascht feststellen, dass auch das Root-Zertifikat ausläuft. Standardmäßig nach 4 Jahren. Wenn plötzlich der Radius keine Clients mehr ins Netz lässt, wenn jede interne HTTPS-Verbindung auf Warnung läuft und man sich plötzlich wieder mit Notfall-Passwörtern anmelden muss, weiß man, dass man vergessen hat, sein Root-Zertifikat rechtzeitig zu erneuern.

Was bei einzelnen Clients noch mit vertretbaren Aufwand zu beheben ist, nervt beim Zwangs erneuern der CA doch ziemlich, besonders wenn man gerade etwas anderes vor hatte.

Für diesen Zweck hab ich mir ein kleines Script gebastelt, das via Munin alle Cert-Restlaufzeiten ermittelt und rechtzeitig Alarm schlägt.

wie immer unter GPL hier zu beziehen: Check Expire Date

Linux Bandbreiten-Monitor/Traffic-Accounting

Wenn man unter Linux einen Rechner betreibt findet man einen Haufen an Möglichkeiten den Bandbreitenverbrauch zu ermitteln. Betreibt man hingegen einen Router und will nicht nur den eigenen Verbrauch, sondern den Transfer-Traffic aufgeschlüsselt nach gewissen Attributen, wird es dünn im Lösungsumfeld. Soll das ganze dann noch auf einem handelsüblichen SOHO-Router laufen, wird es richtig kniffelig.

Das erste Problem ist, dass man wissen muss nach,nach was man sucht. Unter „Bandbreiten-Monitor“ verstehen die meisten Lösungsvorschläge das Monitoring des eigenen Verbrauchs/Traffic oder nur das „Gesamtaufkommen“ an einem Interface. Kurzum: Werte die sich leicht ermitteln lassen. Das aufschlüsseln des Transfertraffics bezeichnet man häufig als IP-Accounting. Danach teilt sich das Feld in folgende Lösungen auf:

  • Promiscuous Mode Basiert: Hierbei wird ein Interface in den Promiscuous-Mode geschaltet und der komplette Netzwerktraffic mitgeschnitten. Die Lösungen unterscheiden sich dann darin, wo und wie die Daten ausgewertet werden. Im einfachsten Fall werden die Pakete vorverarbeitet und an eine Sammelstelle weiter geleitet. Bekannteste Vertreter sind NTop, NProbe und bandwidthd.
  • IPTables/NetFilter Basiert: Hierbei wird ausgenutzt, dass IPTables mit protokolliert wie viele Pakete/Bytes über eine Filter-Regel gelaufen sind. Dies kann man dann asyncron über Bash-Befehle auslesen.

Der Promiscuous Mode basierten Lösungen sind die allumfassenden Lösungen. Sie schneiden alles mit und können die detailliertesten Auswertungen bieten. Sie haben jedoch immer zwei massive Nachteile. Erstens ist die benötigte CPU-Leistung enorm. Selbst die schlanke NPrope schaffte bei einem 600MHz Prozessor nicht mal Ansatzweise den zu erwartenden Transfertraffic (100Mbit/s). Auch wird das Analyseziel stark belastet. Sowohl was die Bandbreite als auch die CPU-Last betrifft. Das ist für eine einfache Bandbreitenanalyse ein wenig übertrieben. Des weiteren ist es mehr als fraglich ob das ganze rechtlich überhaupt zulässig ist. Immerhin handelt es sich hierbei um eine DPI,  jeh nach Ausführung sogar mit ungesicherter Ausleitung.

Die IPTables -Variante hat den Vorteil, dass die Pakete sowieso durch IPTables verarbeitet werden müssen. Der Overhead für das zusätzliche Monitoring hält sich in Grenzen. Auf besagtem 600 MHz Prozessor war keine Leistungsabfall durch Zu- oder Abschalten der Filter-Regeln zu messen, noch gab es eine nennenswerte CPU-Last. Der Nachteil ist jedoch, dass man wissen muss was man Monitoren will. Wenn man nur wissen will, wie viel Traffic auf ein Netzsegment entfällt, ist das einfach umsetzbar. Will man jedoch wissen auf welchen Client im Netzsegment der Traffic aufgelaufen ist, wird es schwierig. Besonders wenn es sich um ein Netzsegment mit ständig wechselnden Clients handelt wird es nahezu unmöglich das mit IPTables alleine zu bewerkstelligen.

Abhilfe schafft ein die NFLog Schnittstelle und ein Daemon aus dem pmacct.net-Project. IPTables führt das Decoding und Vorfilterung durch und leitet das Paket dann an den uacctd weiter. Dieser filtert, aggregiert und verarbeitet die Daten oder leitet sie an ein Sammelstelle weiter.

Das Ganze ist denkbar einfach zu konfigurieren. Als erstes braucht es nur IPTables-Regeln die die interessanten Pakete ausleiten.

iptables -I FORWARD -d 192.168.0.0/16 -j NFLOG --nflog-nlgroup 1
iptables -I FORWARD -s 192.168.0.0/16 -j NFLOG --nflog-nlgroup 1

Durch diese Regeln werden alle Pakete die das 192.168-Netz betreffen an die ULog-Schnittstelle weitergeleitet. Die weiteren Parameter bewirken, dass immer gewartet wird bis sich 50 Pakete gesammelt haben und nur die ersten 48 Bytes weitergeleitet werden. Die Group-Angabe ist später für die Auswertung wichtig.

Der entsprechende uacctd ist wie folgt konfiguriert:

daemonize: true
pidfile: /var/run/uacctd.pid
syslog: daemon

uacctd_group : 1
plugins: memory[host_in], memory[host_out]

aggregate[host_in]: dst_host
aggregate[host_out]: src_host

aggregate_filter[host_in]: dst net 192.168.0.0/16
aggregate_filter[host_out]: src net 192.168.0.0/16

imt_path[host_in]: /tmp/pmacct_host_in.pipe
imt_path[host_out]: /tmp/pmacct_host_out.pipe

Durch diese Konfiguration werden zwei Endpunkte angelegt, jeweils einen für ein- und ausgehendem Traffic und nach internem Client aggregiert. Der Speicherverbrauch und die Prozessorlast ist in meinem Einsatzgebiet zu vernachlässigen (selten mehr als 20 Clients gleichzeitig) kann jedoch je nach Einsatzart stark ansteigen. Ob das ganze bei 10k Clients und „portgenauem“ Monitoring noch skaliert habe ich nicht ausprobiert.

Auswerten kann man das ganze wie folgt:

pmactt -s -p /tmp/pmacct_host_in.pipe

Mit der eigenen Wunsch-Skriptsprache kann man nun die wildesten Skriptes zum überwachen des Traffics basteln.
Hier mein Beispiel für einen Perl-Skript/Munin-Plugin: munin-bandwidth.perl

Munin – „unknown warning“ unterdrücken

Ich nutzte Munin seitdem ich meine Serverstruktur am laufen habe und es hat mir gute Dienste geleistet.

Eine Sache hat mich doch immer ein wenig gestört. Ich besitze Geräte/Nodes die nicht 24/7 online sind, jedoch auch überwacht werden wollen, da sie keine direkte Interaktion mit dem Nutzer zulassen (oder der Nutzer es nicht will). Kurz: mein HTPC soll meckern, wenn was ist, aber bitte nicht während man gerade genüsslich einen Film schaut!

Bis „vor kurzem“ kam es dabei auf Seiten Munin immer zu Fehlermeldungen wie „WARNING <node>.<value> unknown“. Eine Mail mit solchen Zusammenfassung gab es am Tag mindestens 2 Mal. Einmal mit „Unknown“ und einmal mit „OK“ wenn der Rechner wieder da war. Unter den ganzen Unknown/OK Meldungen gingen die wirklich wichtigen Meldungen wie WARNING/ERROR/NOTICE leider unter, so dass ich einmal wöchentlich die Statistik aufrufen musste und nachschauen durfte…

es gibt Abhilfe. Man kann in der Munin-(Server)-Konfiguration bei der Node folgendes angeben:

 df._sdb1.unknown_limit 300

In dem oben angebenen Fall würde für das Plugin df Fieldname sdb1 erst nach 300 „Unknown“ Meldung wirklich eine Mail ausgelöst werden. Bei 5 Minuten pro Prüfungen macht das 25 Stunden, die der Rechner offline sein kann, ohne dass es eine Warnmeldung gibt.

Nachteil an der Sache, man muss das für jeden Plugin/Feldwert machen. Das führt in jedem Fall zur Plugin-Hygiene!

Munin SMART-Daten zusammengefasst

Ich betreibe schon eine geraume Zeit einen Munin-Tracker um meine Heim-Hardware zu überwachen. (Router, Server, HTPC, usw). Leider hat sich gerade beim Server gezeigt, wie schnell Munin unübersichtlich werden kann. Bei aktuell 10 HDDs ist man schon eine weile beschäftigt um die Smart-Tables zu „überscrollen“. Das hat mich so generft, dass ich nach eine Lösung gesucht habe, die lautet „multigraph“. Dabei werden von „Plugin“ gleich mehrere Graphen geliefert (inkl Übersichts-Graph) und anschießend wird dieser Übersichtsgraph dargestellt und erst beim Öffnen wird dann jeder Graph einzeln dargestellt.

Das ganze lässt sich schnell implementieren, bis auf den Haken, dass sowohl die SMART Abfrage als auch das scannen eines 3Ware-Controllers zu lange braucht. Munin hat immer die Abfrage abgebrochen.  Daher musste ich den auslesenden Teil auslagern und alles in state-Files schreiben. Diese werden von dem munin-Plugin dann eingelesen und ausgewertet.

smart-Scriptes

Munin und 3Ware

Hinter Munin versteckt sich ein sehr puristisches aber brauchbares Monitoring-Tool um ein ganzes Netzwerk zu überwachen. Munin besteht dabei aus zwei Teilen. Der Node und einem Crawler, der zyklisch (5 Minuten) alle bekannten Nodes abfragt. Danach werden Graphen von den gesammelten Daten über die Zeiträume Tag, Woche, Monat und Jahr erzeugt. Damit lassen sich gut Trends und Ungereimtheiten ablesen. Dazu wird noch rudimentäres „Alerting“ geboten. Über/Unter-schreitet ein „getrackter“ Wert ein vorgegebenes Limit, wird eine Warnmail ausgesendet. Zudem wird der Wert Farblich zusätzlich markiert, so das man beim Kontrollieren der Status-Webseite sofort sieht, das was im Argen liegt.

Die Node bietet dabei von Start weg überhaupt keine Funktionalität. Alles was man angezeigt bekommen will, muss via Plugins geliefert werden. Die Communitie bietet hier jedoch ein extrem umfangreiches Repertoire an schon vorhanden Plugins. Darunter auch Plugins die SNMP Quellen abfragen.

Nun bieten 3Ware einen SNMP Zugang zu allen RAID-Daten. Nur ist dies leider sehr umständlich. Da sich Plugins sehr einfach schreiben lassen, hab ich einfach drei Plugins geschrieben, die mir die wichtigsten Daten extrahieren und in Munin zur Verfügung stellen. Ich benutzte dazu „tw_cli“ welches von 3Ware mitgeliefert wird. Anschließend wird dessen Output ausgewertet und dargestellt.

die Sources gibt es hier:

  • RAID-Status: Liefert den Status aller im System bekannten RAID-Units
  • RAID-Unit-Status: Listet den Status aller physikalisch Einheiten einer RAID-Unit.
  • BBU – Status: Liefert den Status der installierten BBUs