Zabbix Web-GUI brute force Sicherheit verbessern

Im Standard lässt Zabbix (Version 3.4) 5 Loginversuche zu bevor weitere Logins für 30 Sekunden gesperrt werden.

Wer die entsprechenden Einstellungen in den Konfigurationsdateien sucht wird enttäuscht, man muss an den Sourcecode der WebGUI ran.

Hierzu öffnet man mit einem beliebigen Editor die Datei include/defines.inc.php im WebGUI Verzeichnis, bei mir ist das /usr/share/zabbix/include/defines.inc.php .

Neben vielen anderen interessanten Einträgen die man sich unbedingt mal anschauen sollte interessieren uns hier folgende 2:

define('ZBX_LOGIN_ATTEMPTS', 5);
define('ZBX_LOGIN_BLOCK', 30); // sec

ZBX_LOGIN_ATTEMPTS gibt an wie viele Loginversuche man hat und ZBX_LOGIN_BLOCK wie lange man gesperrt wird.

Nach der Sperrzeit kann man direkt die nächsten 5 Versuche starten ohne das die Sperrzeit z.B. exponential wächst, das sind bei schneller Leitung für ein Script ca. 8 Versuche pro Minute, immerhin fast 500 Versuche pro Stunde und über 11500 pro Tag. Bei einem guten Passwort reicht das um sicher zu sein, aber mir ist das zuviel.

Ich habe bei mir die Werte auf

define('ZBX_LOGIN_ATTEMPTS', 3);
define('ZBX_LOGIN_BLOCK', 3600); // sec

geändert. Das reduziert die Anzahl der Versuche auf 72 pro Tag ohne das ich in der Praxis ein Problem habe (wenn mir beim dritten mal das Passwort nicht eingefallen ist dann weis ich es auch beim fünften mal nicht).

Für den Fall das man sich tatsächlich ausgesperrt hat, aber noch über einen Shellzugang mit Datenbankzugriff verfügt so kann man die Sperre in der Datenbank natürlich wieder löschen.

Beispiel (Zabbix 3.4, postgresql, User Admin):

update users set attempt_ip='',attempt_failed=0,attempt_clock=0 where alias like 'Admin';

 

logfile voller Meldungen „rsyslogd … action 17“ ….

Auf der Suche nach Performancebremsen habe ich heute gesehen das mein /var/log/messages voller Meldungen war:

Jan 26 05:55:01 camserver rsyslogd-2007: action 'action 17' suspended, next retry is Thu Jan 26 05:56:31 2017 [try http://www.rsyslog.com/e/2007 ]
Jan 26 06:04:09 camserver rsyslogd-2007: action 'action 17' suspended, next retry is Thu Jan 26 06:05:39 2017 [try http://www.rsyslog.com/e/2007 ]
Jan 26 06:15:01 camserver rsyslogd-2007: action 'action 17' suspended, next retry is Thu Jan 26 06:16:31 2017 [try http://www.rsyslog.com/e/2007 ]
Jan 26 06:17:01 camserver rsyslogd-2007: action 'action 17' suspended, next retry is Thu Jan 26 06:18:31 2017 [try http://www.rsyslog.com/e/2007 ]
Jan 26 06:25:01 camserver rsyslogd-2007: action 'action 17' suspended, next retry is Thu Jan 26 06:26:31 2017 [try http://www.rsyslog.com/e/2007 ]
Jan 26 06:35:01 camserver rsyslogd-2007: action 'action 17' suspended, next retry is Thu Jan 26 06:36:31 2017 [try http://www.rsyslog.com/e/2007 ]
Jan 26 06:36:07 camserver rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="550" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Jan 26 06:45:01 camserver rsyslogd0: action 'action 17' resumed (module 'builtin:ompipe') [try http://www.rsyslog.com/e/0 ]
Jan 26 06:45:01 camserver rsyslogd-2359: action 'action 17' resumed (module 'builtin:ompipe') [try http://www.rsyslog.com/e/2359 ]

Grund war, das in der /etc/rsyslog.conf der letzte Block Richtung xconsole loggen soll (was bei meinem Armbian auf odroidxu4 nicht geht).

Die Lösung ist einfach: In der /etc/rsyslog.conf den letzten Block

daemon.*;mail.*;\
 news.err;\
 *.=debug;*.=info;\
 *.=notice;*.=warn |/dev/xconsole

auskommentieren oder löschen.

Danach noch ein

/etc/init.d/rsyslog restart

und die Meldungen sind weg.

 

Xenserver unter win10 kann nicht mit xenserver 6.2 verbinden

Eines Tages hatte ich Probleme mittels des Xencenters unter Windows 10 meinen XenServer 6.2 anzusprechen.

Die nichtssagende Fehlermeldung lautete:

Unable to connect to server ‚aaa.bbb.ccc.ddd‘.

An unknown error occured.

Ich habe lange suchen müssen bis ich herausgefunden habe das es sich um einen Zertifikatfehler handelt.

Die schlichte Reparatur auf de XenServer Konsole:

service xapissl stop


mv /etc/xensource/xapi-ssl.pem /etc/xensource/xapi-ssl.pem.bak


 /opt/xensource/libexec/generate_ssl_cert "/etc/xensource/xapi-ssl.pem" 'aaa.bbb.ccc.ddd'


service xapissl start


 xe-toolstack-restart

 

Das war’s. Anstelle von aaa.bbb.ccc.ddd muss man natürlich die IP des Xenservers eintragen.

 

Gemeinschaft auf raspberry

Installation der PBX Gemeinschaft auf raspberry (3)

Auf der Suche nach einer VoIP PBX Software mit möglichst deutscher Oberfläche bin ich auf „Gemeinschaft“ gestoßen.

Leider scheint es nicht üblich zu sein die Software, in diesem Fall Gemeinschaft 3 , auf einem Raspberry laufen zu lassen.

Da ich es mir in den Kopf gesetzt habe das meine neue PBX aber auf dem Raspberry 3 läuft habe ich mir einen Installationsweg gesucht, letztlich waren es bei aktuellem Stand nur wenige Änderungen. „Gemeinschaft auf raspberry“ weiterlesen

Gemeinschaft 3.2 auf Raspberry 3

Es gibt eine aktuellere Version des Artikels, bitte diese nehmen:

Gemeinschaft auf raspberry

 

Auf der Suche nach einer VoIP PBX Software mit möglichst deutscher Oberfläche bin ich auf „Gemeinschaft“ gestoßen.

Leider scheint es nicht üblich zu sein die Software, in diesem Fall Gemeinschaft 3 , auf einem Raspberry laufen zu lassen.

Da ich es mir in den Kopf gesetzt habe das meine neue PBX aber auf dem Raspberry 3 läuft habe ich mir einen Installationsweg gesucht, letztlich waren es bei aktuellem Stand nur wenige Änderungen. „Gemeinschaft 3.2 auf Raspberry 3“ weiterlesen