Check_MK monitoren der haproxy Backends

Kleines lokales Plugin für check_mk um die HAProxy Backends zu monitoren.

das Skript muss unter /usr/lib/check_mk_agent/local angelegt werden.
touch /usr/lib/check_mk_agent/local/haproxy-local.sh
Dort dann den nachfolgenden Code reinkopieren und Konfiguration anpassen.
#!/bin/bash
#
# checks haproxy
#

_awk_bin=$(which awk)
_status_url="http://localhost:9090/haproxy/"
_server_name="ha-cap-"
a=0

# $(curl -s ${_status_url}\;csv | grep "^${_server_name}" | grep -vE "(FRONTEND|BACKEND)")

for line in $(curl -s ${_status_url}\;csv | grep "^${_server_name}" | grep -vE "(FRONTEND|BACKEND)"); do
        _name=$(echo $line | ${_awk_bin} -F',' '{ print $1; }' )
        _host=$(echo $line | ${_awk_bin} -F',' '{ print $2; }' )
        _stat=$(echo $line | ${_awk_bin} -F',' '{ print $18; }')
        STATUSTXT="${_name}  ${_host}  ${_stat}"
        if [ ${_stat} == "UP" ]; then
                _check_response="0"
        else
                _check_response="2"
        fi
        if [ ${a} -lt 10 ]; then
                echo "${_check_response} BEHIND-HAPROXY-0${a} - ${STATUSTXT}"
        else
                echo "${_check_response} BEHIND-HAPROXY-${a} - ${STATUSTXT}"
        fi
        a=$((a+1))
done

Ergebnis sieht dann so aus
check_mk + haproxy
check_mk + haproxy

Natürlich muss auch der haproxy so konfiguriert sein das er die Statusseite ausliefert. Hier Auszug aus der haproxy.cfg
listen status
    bind *:9090
    mode http
    stats enable
    stats uri /haproxy
    acl localhost  src  127.0.0.1
    acl stats      path_beg  /haproxy
    http-request allow if stats localhost
    http-request deny  if stats !localhost

Debian 9 : Apache mit mod_qos und fail2ban absichern

Es kommt immer wieder vor das die Webserver unter Volllast geraten da jemand unsere API exzessiv anfragt. Da hier alle anderen Anfragen auch mit betroffen sind ist hier ein möglicher Weg einen Apache dagegen abzusichern. In meinem Fall handelt es sich um ein Debian 9 bei anderen Linux Derivaten sollte es ähnlich funktionieren.
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.5 (stretch)
Release:	9.5
Codename:	stretch
Natürlich kann man die Werte aus diesem Beispiel nicht einfach übernehmen, diese müssen der jeweiligen Anwendung angepasst werden, sie dienen lediglich als Beispiel

Erstmal installieren wir die benötigten Packete
apt install libapache2-mod-qos fail2ban
Dann machen wir die Konfiguration für mod_qos
vi /etc/apache2/conf-available/mod_qos.conf
dort tragen wir erstmal eine Grundkonfiguration ein
## QoS Settings
<IfModule mod_qos.c>
    # Gleichzeitige Verbindungen von 100000 IP Adressen zulassen 
    QS_ClientEntries 100000
    # maximal 20 Verbindungen pro IP Adresse
    QS_SrvMaxConnPerIP 20
    # maximale Anzahl der aktiven TCP Verbindungen hier 256
    MaxClients              256
    # QS_SrvMaxConnClose <Nummer> [%] definiert die maximale Anzahl der gleichzeitigen TCP-Verbindungen,
    # bis der Server Keep-Alive für diesen Server deaktiviert (die Verbindung wird nach jeder Anforderung geschlossen. 
    # Sie können die Anzahl der Verbindungen als Prozentsatz von MaxClients angeben, wenn Sie das Suffix hinzufügen '%' auf den angegebenen Wert.
    QS_SrvMaxConnClose      70%
    # minimum request/response speed (https://de.wikipedia.org/wiki/Slowloris Schutz):
    QS_SrvMinDataRate       150 1200
    # QS_SrvMinDataRate <bytes pro seconds> [<max bytes pro second> [<connections>]], definiert den minimalen Upload / Download-Durchsatz
    # QS_SrvMaxConnExcludeIP <addr>
    # QS_SrvMaxConnExcludeIP 192.168.x.xxx
    #
    # Quelle : https://www.mankier.com/1/mod_qos
</IfModule>
Jetzt geben wir noch die Statusseite für qos frei damit wir auch sehen was hier so passiert.
<Location /qos>
   SetHandler qos-viewer
   Require ip [Eigene IP Adresse oder IP Range (CIDR)]
   # z.B. Require ip 127.0.0.1
</Location>
Jetzt aktivieren wir noch das Modul und die Konfiguration
a2enmod qos
a2enconf mod_qos
dann der obligatorische Neustart des Apaches
systemctl restart apache2
nun kann man den ersten Test durchführen, von einem anderen Rechner die IP Adresse des Servers über das Apache Benchmark Tool einfach mal anfragen mit diesen Werten
ab -n 1500 -c 100 http://[IP des Webservers]/index.html
im Errorlog des Apaches sollten jetzt solche Meldungen erscheinen
[xxx] [:error] [xxx] mod_qos(034): access denied, QS_SrvMinDataRate rule (in): min=354, this connection=26, c=192.168.x.xxx
[xxx] [:error] [xxx] mod_qos(031): access denied, QS_SrvMaxConnPerIP rule: max=50, concurrent connections=51, c=192.168.x.xxx
Dann machen wir mit fail2ban weiter
vi /etc/fail2ban/jail.d/http-requests.conf
dort fügen wir diesen Inhalt ein
[http-requests]
enabled = true
port = http,https
filter = http-requests
logpath = /var/log/apache2/access.log
# maxretry bedeutet wieviele GET / POST wir im Log finden bevor wir die IP sperren
maxretry = 30
# findtime ist die Zeitperiode in der wir GET/POST zählen (10 Sekunden)
findtime = 10
# Wielange wird die IP gebannt in Sekunden (600 Sekunden = 10 Minuten)
bantime = 600
action = iptables[name=HTTP, port=http, protocol=tcp]
den Filter dazu erstellen
vi /etc/fail2ban/filter.d/http-requests.conf
und dort diesen Inhalt rein
# Fail2Ban configuration file
# http-requests.conf
#
[Definition]
# failregex = es wird gegen GET/POST im Logfile gematched
failregex = ^<HOST> -.*"(GET|POST).*
# ignoreregex = 
ignoreregex =
ein neustart von fail2ban aktiviert die Config
systemctl restart fail2ban
Jetzt kann wieder mit dem Apache Benchmark Tool getestet werden, bevor wir allerdings das Benchmark Tool von einem anderen Rechner aus starten öffnen wir lokal das Logfile von fail2ban damit wir sehen was passiert.
tail -f /var/log/fail2ban.log
jetzt den Benchmark starten wie oben angegeben. Im Log sollten jetzt solche Meldungen erscheinen
2018-07-20 00:25:27,998 fail2ban.filter         [6203]: INFO    [http-requests] Found 192.168.x.xxx
2018-07-20 00:25:27,998 fail2ban.filter         [6203]: INFO    [http-requests] Found 192.168.x.xxx
2018-07-20 00:25:28,096 fail2ban.actions        [6203]: NOTICE  [http-requests] 192.168.x.xxx already banned
2018-07-20 00:25:29,098 fail2ban.actions        [6203]: NOTICE  [http-requests] 192.168.x.xxx already banned
In fail2ban kann man sich jetzt den Status anzeigen lassen
root@ddev-01: fail2ban-client status http-requests
Status for the jail: http-requests
|- Filter
|  |- Currently failed:	1
|  |- Total failed:	1629
|  `- File list:	/var/log/apache2/access.log
`- Actions
   |- Currently banned:	1
   |- Total banned:	2
   `- Banned IP list:	192.168.x.xxx
möchte man die IP wieder entsperren genügt ein
fail2ban-client set http-requests unbanip 192.168.x.xxx
wenn eine bestimmte IP oder eine IP Range freigegeben werden muss ist das in der jail.conf zu erledigen
vi /etc/fail2ban/jail.conf
dort nach ignoreip = suchen und die eigene IP hinzufügen

Quellen :
http://mod-qos.sourceforge.net/#variables
https://de.wikipedia.org/wiki/Slowloris
https://www.fail2ban.org/wiki/index.php/Main_Page
https://sourceforge.net/p/mod-qos/discussion/
http://mod-qos.sourceforge.net/#statusviewer
http://mod-qos.sourceforge.net/glossary.html
http://mod-qos.sourceforge.net/dos.html

VIM Sonderzeichen ersetzen (hexadezimal)

Problem : In manchen Fällen bekommt man Dateien von Kunden geschickt die irgendein unbekanntes encoding enthalten. mit recode und iconv kam in meinem Fall auch nur Mist raus.

Lösung :
Die Datei mit vim öffnen und das encoding auf utf8 festnageln.
set fenc=utf8
dann können die unbekannten Zeichen ersetzt werden. Hier ein paar Beispiele.
:%s#\%x86#Ü#g
:%s#\%x9f#ü#g
:%s#\%x8a#ä#g
:%s#\%x9a#ö#g
:%s#§#ß#g

Check_MK Agent über SSH Verbindung

Wenn man das Check_MK Monitoring nicht über den Standardport (xinet) laufen lassen möchte / kann besteht dich Möglichkeit dies über eine SSH Verbindung zu realisieren. Hierfür muss nur einiges an Vorarbeit erledigt werden.

Auf jedem Host der zu monitoren ist legt man einen User für den Check_Mk Agents an.
useradd -d /home/monitor -c 'CHECK_MK User' -g monitor -m -s /bin/bash monitor
Auf dem Monitoring-Server einen SSH Key für das monitoring erstellen. Dazu logt ihr euch über ssh auf dem Server ein und wechselt mit su - sitename auf die Check_MK Site (User). Dort legt ihr ein SSH-Keypair an.
ssh-keygen -t monitor
dann zeigt ihr euch den schlüssel über cat an und pflegt diesen auf den zu monitorenden Hostsystemen unter dem User monitor ein ( /home/monitor/.ssh/authorized_keys )
cat ~/.ssh/id_monitor.pub
Eintrag auf den Hostsystemen :
command="sudo /usr/bin/check_mk_agent" ssh-rsa [SSH KEY DES SERVERS]
Jetzt muss noch die sudoers Config angepasst werden.
vi /etc/sudoers
Dort fügt man die folgenden Zeilen ein, trägt man den User monitor ein
# Allow User monitor to run check_mk_agent
monitor ALL=NOPASSWD: /usr/bin/check_mk_agent
Jetzt kann man das bis jetzt mal testen.Wenn ihr euch über ssh auf dem Host als User monitor anmeldet, oder den check_mk_agent lokal auf dem Host als User monitor ausführt, muss der selbe output zu sehen sein.

Ist das der Fall muss jetzt noch in der WATO eine Regel erstellt werden.
Unter Host & Service ParametersDatasource ProgramsIndividual program call instead of agent access eine Regel für die Umgebung erstellen
	ssh -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no monitor@$HOSTADDRESS$
dann sollten nach einem TabulaRasa alle Services zu sehen sein.
check_mk_agent über ssh
check_mk_agent über ssh


Mehr Info : Check_MK - Anleitung zu diesem Thema

InfluxDB - Aufbewahrung der Daten managen

Wenn eine Datenbank in Influx erstellt wird gibt es eine default RETENTION POLICY (Aufbewahrungsrichtlinie) mit den Namen "autogen" die DURATION ist dort auf Unendlich und die shardGroupDuration auf 7 Tage konfiguriert . Dies kann man auch bei der Erstellung einer Datenbank mitgeben (allerdings darf man das nicht vergessen ;-)) DATABASE MANAGMENT
>SHOW RETENTION POLICIES
name              duration  shardGroupDuration replicaN default
----              --------  ------------------ -------- -------
autogen           0s        168h0m0s           1        true
lässt man eine größere Umgebung mit diesen default Werten monitoren ist die Datenbank recht schnell voll und wächst und wächst .......

Um realistische Aufbewahrungsfristen zu realisieren kann man eine neue Policy schreiben, es kommt natürlich immer auf den jeweiligen Anwendungsfall an !
CREATE RETENTION POLICY "twelve_weeks_only" ON "collectd" DURATION 12w SHARD DURATION 1d DEFAULT
nun sieht die Retention Policy schon anders aus
>SHOW RETENTION POLICIES
name              duration  shardGroupDuration replicaN default
----              --------  ------------------ -------- -------
autogen           0s        168h0m0s           1        false
twelve_weeks_only 2016h0m0s 24h0m0s            2        true
die Werte müssen natürlich je nach Anwendungsfall angepasst werden.

Zur Erklärung :

Erstellt eine neue RETENTION POLICY in der Datenbank collectd mit den Namen twelve_weeks_only
CREATE RETENTION POLICY "twelve_weeks_only" ON "collectd"
Die Aufbewahrungsfrist der Daten beträgt hier 12 Wochen -> Duration units
DURATION 12w
In einer einzelnen Shard-Group können mehrere Shards vorhanden sein. Jeder Shard enthält eine bestimmte Reihe von Serien. Alle Punkte, die auf eine bestimmte Serie in einer bestimmten Shard-Gruppe fallen, werden im selben Shard (TSM-Datei) auf der Festplatte gespeichert.(auszug InfluxDB Doku)
SHARD / SHARD Groups / SHARD Duration
SHARD DURATION 1d
Setzt die neue Policy als DEFAULT für die Datenbank collectd
DEFAULT
Um mir wieder Platz zu schaffen habe ich danach die Policy "autogen" aus der InfluxDB gelöscht
DROP RETENTION POLICY "autogen" ON "collectd"

Nach der Erstellung der neuen RETENTION POLICY begann die Aufzeichnung der Messwerte wieder bei Null, sollte das nicht gewünscht werden kann man auch die RETENTION POLICY ändern. Der Weg ist aber ungetestet !!
ALTER RETENTION POLICY "autogen" ON "collectd" DURATION 12w SHARD DURATION 7d DEFAULT

“Sicher ist, dass nichts sicher ist. Selbst das nicht.”
Joachim Ringelnatz