Daniel

Kopano Webapp mit fail2ban schützen

von

Gerade eben stand ich vor der Aufgabe, die Kopano-Web-App mit einem fail2ban Schutz zu versehen. Fail2ban arbeitet mit regulären Ausdrücken (regular expressions). Ehrlich gesagt, habe ich davon so gut wie keine Ahnung. 🙂

Egal! Aufgegeben wird nur ein Brief…

Schließlich kam ich zu folgender Lösung.

Der Logeintrag

Im Apache-Error-Log wird bei einem fehlerhaften Loginversuch in die Webapp Folgendes protokolliert:

[Thu Mar 09 19:20:56.097859 2017] [:error] [pid 25634] [client xx.119.xxx.141:6640] Kopano WebApp user: dsafasdf: authentication failure at MAPI, referer: https://kopano.mysite.at/webapp/?logon

Der Fail2ban Filter

Da es sich bei der Fehlermeldung um eine vom „Apachen“ kreierte Fehlermeldung handelt, greife ich im Filter auf die apache-common.conf (siehe INCLUDES) zurück und baue mir folgenden Filter (failregex):

# FILE : /etc/fail2ban/filter.d/kopano-webapp-login.conf
# Fail2Ban configuration file
[INCLUDES]
before = apache-common.conf
failregex = ^%(_apache_error_client)s Kopano WebApp user: .+?(?=:): authentication failure at MAPI

ignoreregex =

Der erste Teil wertet die Clientinformationen aus, danach folgt ein normaler String Kopano Webapp user: gefolgt von einer regular expression .+?(?=:) die besagt, dass alle folgenden Zeichen bis zum nächsten Doppelpunkt als Übereinstimmung angesehen werden.

Schließlich folgt ein weiterer Doppelpunkt, der wieder als String zu sehen ist, gefolgt von weiterem Text, der dem Text im Logfile entspricht.

Update – So gehts auch: 

failregex =  ^%(_apache_error_client)s Kopano WebApp user:.* authentication failure at MAPI

Somit ist man nicht mehr auf den Doppelpunkt und die in der ersten Variante angegebene Verrenkung angewiesen.

Die Datei selbst wird unter  /etc/fail2ban/filter.d/kopano-webapp-login.conf gespeichert.

Den Filter aktivieren

Im Verzeichnis /etc/fail2ban/ ist die Datei jail.local um folgende Zeilen zu erweitern:

[kopano-webapp]
enabled = true
port = https
filter = kopano-webapp-login
logpath = /var/log/apache2/kopano_ssl_error.log

Fail2ban Bann oder fail?

Ob es wirklich richtig bannt, ist im Logfile schnell erkannt.

2017-03-09 19:20:56,586 fail2ban.actions[26156]: WARNING [kopano-webapp] Ban xx.119.xxx.141

Scheint zu klappen!

Verbesserungsvorschläge werden gerne angenommen. 😉

Windows 10 und WSUS – Server 2012: Produkte und Klassifizierungen

von

Heute gibts ausnahmsweise mal wieder ein Windowsthema.

Wir befinden uns auf dem WSUS – Server 2012 und wollen die Produktkategorien für Windows 10 wählen, für die der Server die Updates von MS holen soll.

Gar kein Problem! Mal „schnell“ durchgeklickt und schon kann man sich wieder den wichtigen Dingen des Adminlebens widmen.

Wenn man sich dann allerdings folgendes anschaut…

und vielleicht noch dazu nicht permanent mit der Thematik der verschiedenen Zweige Releases und Releasevarianten beschäftigt ist, hat man womöglich ein Problem damit, die relevanten Windows 10 Einträge auszuwählen.

Es gibt einige Beiträge zu diesem Thema:

Es scheint jedenfalls so zu sein, dass sehr viele Admins nicht zu hundert Prozent sicher sind, welche Häkchen hier die richtigen sind.

Die Informationen aus den Artikeln, ergeben für mich folgendes Bild:

  • Windows 10 and later drivers: Treiber für alle Windows 10 Versionen, die jedoch nur im normalen laufenden Betrieb installiert werden. Nicht aber, im Zuge eines Inplace Upgrades.
  • Windows 10 and later Upgrade & Servicing drivers: Treiber die auch im Zuge eines Dynamic Updates zum  Einsatz kommen. (Von einem Win 10 Build zum nächsten). Wird im Zuge eines Inplace Upgrades benötigt. Beinhaltet auch Treiber, die für spätere Win 10 Versionen gedacht sind!
  • Windows 10 Anniversary Update and later Servicing Drivers: Treiber die nur für die Version 1607 gelten. Es werden keine Treiber für spätere Upgrades vorgehalten. Die Treiberwartung für die aktuelle Windowsversion (1607) ist aber inkludiert.
  • Windows 10 Anniversary Update and Later Upgrade & Servicing Drivers: Treiber die auch im Zuge eines Dynamic Updates zum  Einsatz kommen. (Von Build 1607 zum nächsten). Wird im Zuge eines Inplace Upgrades benötigt. Es werden auch Treiber für spätere Upgrades vorgehalten.
  • Windows 10 Anniversary Update Server and Later Servicing Drivers: Betrifft Server 2016
  • Windows 10 Dynamic Update: Beinhaltet Updates, die im Zuge eines Inplace-Upgrades (von einer Win 10 Version zur nächsten) benötigt werden könnten.
  • Windows 10 Feature On Demand: Korrespondiert mit den Programmen / Features, die unter Windows 10 nachinstalliert werden können, wobei die Installationsfiles in dem Fall vom WSUS-Server geholt werden. (wenn angehakt)
  • Windows 10 GDR-DU LP: Sprachpaket, welches bei einem dynamischen Update (Inplace Upgrade) Verwendung findet und nur für das General Distribution Release gilt.
  • Windows 10 GDR-DU: Updates die nur verwendet werden, wenn ein dynamisches Update eines GDR Version durchgeführt wird.
  • Windows 10 Language Interface Packs: Für mich unklar, ob notwendig?
  • Windows 10 Language Packs: Für mich unklar, ob notwendig?
  • Windows 10 LTSB: Gilt nur, wenn Long Term Servicing Branch eingesetzt wird. Also ab Windows 10 Enterprise!

Verwirrung…?!

Vielleicht geht es ja nur mir so, aber ich finde das alles sehr kompliziert.

Der WSUS ist meiner Meinung nach ein hochwichtiges Instrument, um Windows Clients im Unternehmensnetzwerk aktuell halten zu können. Deshalb sehe ich es als essentiell an, dass es hier klar zu erkennende Strukturen gibt.

Ach wäre da doch nur eine wenig mehr „apt-get Infrastruktur“ dahinter…

Fazit (und das ist nur MEINE Meinung)

Mit der LTSB-Branch hat man als Firma einfach mehr Freude, muss aber natürlich auch tiefer in die Tasche greifen – Stichwort: Windows 10 Enterprise + Volumenlizenzvertrag.

Die Pro-Version und niedriger scheint zur Spielwiese degradiert zu werden.

Ich lehne mich mal weit aus dem Fenster und sage, dass die PRO Version bald nicht mehr mit „Firmeneinsatz“ in Verbindung gebracht werden wird.

Zeit für „Linux@Desktop!“ 😛

 

 

 

Diskussionsforum „Selfpublishing“

von

Unter http://forum.it-yourself.at ist ab sofort ein Forum zum Thema „Selfpublishing“ zu finden.

Hauptsächlich soll hier über die Bücher, die ich über Amazon KDP vertreibe, diskutiert werden (sofern jemand dazu Lust hat…).

Spart nicht mit Anregungen, Wünschen, Beschwerden, Lob, …

Ich werde mich bemühen, sehr zeitnah darüber zu berichten, sofern es Updates der Bücher gibt. Interessant vor allem für „E-Book-Lesende“, die die Gratisaktion doch recht intensiv genutzt haben. 🙂

Im internen Bereich (welcher nur für registrierte Forennutzer ersichtlich ist) kann man einen Teil der Konfigurationsbeispiele einsehen und ggf. per copy&paste übernehmen. Ich habe vor, diesen Bereich immer weiter zu befüllen.

Käufer der Bücher ersparen sich so unter Umständen das Abtippen der Konfigurationen.

 

 

E-Book: Rootserver unter Debian GNU/LINUX Fehlerbereinigung

von

In den kommenden Tagen folgt eine aktualisierte Version des E-Book. Leider haben sich in der Apachekonfiguration während der Formatierung des Textes ein paar Fehler eingeschlichen.

Die Aktualisierung ist natürlich kostenlos! Allerdings muss ich die Änderungen genau dokumentiert an Amazon senden. Amazon bewertet die Anpassungen und gibt dann das Update frei.

Fehler kurz dokumentiert

Abschnitt Apache -> Mit vHosts arbeiten -> vHost für Port 80:

Hier ist das Require all granted verloren gegangen.

<Directory /var/www/www.it-yourself.at>
AllowOverride All
Options -FollowSymLinks -Includes -ExecCGI
   Require all granted
</Directory>

Im folgenden Block, in dem mod_fastcgi.c definiert ist, muss folgende Zeile ohne Zeilenschaltung „in einer Zeile“ stehen:

FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi-www.it-yourself.at -socket /var/run/php5 fpm-www.it-yourself.at.sock -pass-header Authorization

Abschnitt php5-fpm -> separate Konfiguration pro Domain -> php_admin_value[open_basedir]:

Anführungszeichen korrigiert.

Xenserver 7: Sicherheit erhöhen – Rootserverbetrieb

von

Wenn der Xenserver auf einem Rootserver im Internet installiert wird, ist dieser über die ihm zugeordnete offizielle IP Adresse erreichbar. Dies bedeutet, dass das Managementnetzwerk / Managementinterface grundsätzlich von jedem aufrufbar ist.

Um dieser Problematik etwas entgegenzuwirken, kann man die iptablesfirewall umkonfigurieren bzw. den SSH-Port verschieben.

Mir ist bewusst, dass das nur ein Tropfen auf den heißen Stein ist, jedoch jedenfalls besser wie nichts.

SSH Port verlegen

Per XenCenter Serverkonsole sind folgende Anpassungen durchzuführen.

Im Verzeichnis /etc/ssh/sshd_config wird der Port verlegt. Standardmäßig läuft SSH auf Port 22. Dies verlegt man z.B. auf Port 2232.

Iptables anpassen

Nun muss natürlich die Firewall angepasst werden, damit Verbindungen auf Port 2232 erlaubt werden.

Das anzupassende File namens iptables findet sich im Ordner /etc/sysconfig. Es beinhaltet bereits einige Regeln. Unter anderem findet sich auch die Regel für den Standardport (22) in dieser Datei. Diese wird entsprechend angepasst, sodass sie dem „neuen“ SSH-Port entspricht.

Schließlich ist die Datei noch zu speichern und iptables und sshd neu zu starten.

service iptables restart && service sshd restart

hosts.deny und hosts allow einsetzen

Genaugenommen eigentlich ein MUSS in einer solchen Netzwerkkonstellation.

Sofern der PC, mit dem man auf den Xenserver einsteigt, mit einer statischen offiziellen IP-Adesse ins Internet geht, gibt es eine elegante Methode, den Zugriff auf den Xenserver einzuschränken.

In der Datei /etc/hosts.allow wird definiert, welche IPs auf den Server zugreifen dürfen. Die anzuführenden IPs sind neben der localhost IP (127.0.0), auch noch die statische IP, von der aus man den Xenserver managed.

Der Eintrag kann z.B. so aussehen:

ALL: 127.0.0 89.163.225.17

D.h. diese IPs dürfen sämtliche Services auf dem Xenserver nutzen.

Nun muss in /etc/hosts.deny noch für alle anderen ALLES verboten werden. Dieser Eintrag ist recht simpel gehalten und sieht folgendermaßen aus:

ALL: ALL

Durch diese Einstellungen wird jedem Client der Zugriff verweigert, solange nicht die Ausnahmeregelung in den hosts.allow greift.

Nachteil

Natürlich bedingt dies, dass man immer mit den angeführten IP Adressen auf den Xenserver zugreift. Blöd nur, wenn man gerade „irgendwo“ ist und man nicht von seiner gewohnten IP-Adresse aus aufs Internet zugreift.

Workaround

Sollte neben dem Dedicated Root(Xen)Server noch ein weiterer Server mit statischer offizieller IP im (Inter)net aktiv sein, kann man diese IP ebenso in die hosts.allow eintragen. Schließlich könnte dann der Umweg über den zusätzlichen Server genommen werden.

Sprich also:

Client mit dynamischer IP -> ssh zu zusätzlichem Rootserver (IP steht am Xen in den hosts.allow) -> ssh zu Xenserver.