SSH mit Google Authenticator absichern

heladodementa / Pixabay

Vor einem Jahr, zur damaligen CeBIT, nahm ich an einem sehr interessanten Vortrag zur Absicherung von Diensten, wie der ownCloud via Zwei-Faktor-Authentifizierung, im Open Source Forum teil. Seit dieser Zeit setze ich immer häufiger den Google Authenticator ein. So waren die ersten Dienste die dahingehend abgesichert wurden WordPress, Nextcloud und mein Google-Konto.

Bei den diesjährigen Chemnitzer Linux Tagen konnte ich einem Vortrag „Linux-Server absichern“ lauschen. Auch hier wurde u.a. über die Problematik Zwei-Faktor-Authentifizierung referiert. Was mich dazu bewogen hat den SSH-Zugang meines vServers mit dem Authenticator zu schützen. Auf meinem Server läuft ein Debain 9 als Betriebssystem.

Dazu installiert man folgende Pakete

und aktiviert den Google Authenticator wie folgt:

Nun kann der QR-Code entsprechend gescannt oder der „secret key“ per Hand eingegeben werden. Die entsprechenden Backup-Codes sind zu sicher. Die nachfolgenden Fragen werden wie beschrieben beantwortet.

Do you want me to update your „/root/.google_authenticator“ file (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, tokens are good for 30 seconds. In order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with
poor time synchronization, you can increase the window from its default
size of +-1min (window size of 3) to about +-4min (window size of
17 acceptable tokens).
Do you want to do so? (y/n) n

If the computer that you are logging into isn’t hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

Nun wird mit dem Editor 

dieser Eintrag ans Ende gesetzt.

„nullok“ sorgt dafür, dass nur der SSH-Zugang für root abgesichert wird. Andere eingerichtete User bleiben hier außen vor.

Weiterhin wird der vorhandene Eintrag in

auf

gesetzt und der SSH-Service neu gestartet.

Schließt bitte nicht den SSH-Zugang! Testet in einem weiteren Terminal, ob alles funktioniert. Nicht, dass Ihr Euch versehentlich aussperrt. Ein vorheriges Backup des Servers setze ich natürlich voraus.

Google Authenticator
Google Authenticator App

Nachtrag

Übrigens wird Filezilla via SFTP nun den Zugang verweigern. Hier setzt Ihr die Verbindungsart auf Interaktiv.

Viel Spaß!

searx.intux.de

Seit Ende letzten Jahres habe ich auf meinem Server die Metasuchmaschine Searx searx.intux.de laufen. Diese habe ich in Docker neben meiner Mailcow installiert. Was mich bei der Installationsanleitung gestört hat, dass man hierbei keinen Service für den Dienst berücksichtigt hat. Nach einem Reboot des Servers wäre also die Suchmaschine offline.

Searx
Metasuchmaschine Searx

Dies konnte ich nun in meinem Fall umgehen, indem ich Searx folgendermaßen gestartet habe.

Viel Spaß!

Mailcow Dockerized Postfach sichern

Ob es nun die eleganteste Lösung ist sein Postfach so zu sichern, sei einmal dahin gestellt. Ich habe nach einem Weg gesucht und mich hierfür entschieden.

Dazu wurde ein Script /root/MailBoxscript.sh

mit folgendem Inhalt erstellt

und

ausführbar gemacht. Weiterhin wurde ein Crontab angelegt.

Hier habe ich am Ende 

eingetragen, um die Sicherung drei Uhr morgens auszuführen. Zum Schluss startet man den Dienst Cron neu.

Servercow – Image mounten

Regelmäßig sichere ich die Snapshots meines vServers, welcher auf Servercow läuft auf meinem lokalen Rechner. Um diese Images jedoch in Debian zu mounten, muss die Startposition des Images angeben werden.

Im Beispiel wird diese wie folgt abgefragt:

Nun wird der Mountbefehl entsprechend angepasst und das Image ins Dateisystem eingebunden.

Searx in Docker

Inspiriert durch Martins Artikel „Searx auf Uberspace einrichten“ habe ich mich nun auch an der Metasuchmaschine Searx versucht. Da es mit der aktuellen Installationsanleitung aber unter Debian Stretch aktuell Probleme gibt, habe ich mich für die Docker-Variante entschieden. Hierzu wurde Searx hinter einen Reverse Proxy auf dem Apache2 meines Servers gepackt. 

Searx läuft auf dem Port 8888 (http://5.1.76.25:8888/). Der Reverse Proxy leitet nun die über https://searx.cybt.de (Port 443) eingehende Anfrage auf den Port 8888 des Servers um.

Der Reverse Proxy wurde als VirtualHost in /etc/apache2/sites-available/proxy.conf angelegt und sieht in meinem Fall so aus:

Damit das alles auch funktioniert, müssen die entsprechenden Module aktiviert sein. Hier die Ausgabe zu meinem Apache2 der HTTPS für die entsprechende URL erzwingt.

TUXEDO InfinityBook Pro 13 – Teil 7

Seit einer ganzen Weile habe ich nun das TUXEDO InfinityBook Pro 13 von TUXEDO zum Testen. Meine vorherigen Artikel bezogen sich darauf, wie das Notebook mit diversen Betriebssystemen u.a. Windows, Ubuntu oder Debian zurecht kommt.

InfinityBook Pro 13
dem InfinityBook geht mobil kaum die Puste aus

Nun möchte ich aber darüber berichten, wie sich das Gerät in meinem normalen Alltag bei schlägt.

Um arbeitsfähig zu sein, habe ich meine Daten, auf die ich regelmäßig zugreife, auf das Gerät kopiert. Die eMail-Konten waren, dank Evolution sichern/wiederherstellen, schnell eingerichtet. Seit Jahren nutze ich ausnahmslos Notebooks. So fiel mir die Umgewöhnung auf dieses Gerät nicht sonderlich schwer. Die Tastatur des InfinityBook finde ich persönlich, bei ausreichendem Hub und gutem Anschlag, recht angenehm. Dadurch bereitet das Tippen von Texten keinerlei Schwierigkeiten. Was mir jedoch ein wenig fehlt, ist der Nummernblock. Darauf muss man jedoch bei einem 13 Zoll Gerät verzichten können. Dieser Umstand stellt aber kein wirkliches Problem dar. Das matte entspiegelte Display ist kontrastreich und lässt genügend Spielraum für ausreichend Helligkeit. Ich persönlich bevorzuge auf dem Pro 13, auf Grund der Full-HD Auflösung, die GNOME-Shell. Texte und Menüs werden so für meine Begriffe recht gut dargestellt.

Die kompakte Bauform sammelt bei mir einige Pluspunkte, weil ich das Gerät ständig dabei haben möchte, um Artikel zu schreiben oder aus der Ferne am Server zu arbeiten. Das InfinitiBook Pro 13 ist dünn, leicht und besitzt ein robustes Gehäuse, welches allerdings im produktiven Einsatz schnell einmal einen Kratzer abbekommen kann. Abnutzungen an den Touchpad-Tasten sind entgegen meiner Erwartung noch nicht zu erkennen.

Des Weiteren finde ich es angenehm wenn kein WLAN am Standort vorhanden ist, auf LAN ausweichen zu können. Dies ist ein großer Vorteil gegenüber dem Vorgängermodell. Da die Nutzung von CDs oder DVDs immer weiter an Bedeutung verliert, habe ich auch kein Problem mit diesem Gerät auf ein entsprechendes Laufwerk zu verzichten.

InfinityBook Pro 13
LAN und HDMI

Ich arbeite in meinem kleinen Home-Office gern mit einem zweiten Monitor. Das InfinityBook Pro 13 lässt mich auch hierbei, dank einer HDMI-Schnittstelle, nicht im Stich. Der Kartenleser (SD/MMC) ist für meine Zwecke ausreichend. Dieser kommt aber nur zum Einsatz wenn ich mit meinem Raspberry Pi experimentiere oder ein Backup des Einplatinencomputer-Systems mache. Mit den vorhandenen USB-Schnittstellen kann ich mich arrangieren.

Arbeitsplatz
mein Arbeitsplatz

Im Gegensatz zu meinem ThinkPad bin ich auch durch die an neuere Prozessoren anpassten Kernel ab Version 4.11 von der Akkulaufleistung des Notebooks begeistert. Wo mein ThinkPad schlapp macht, arbeitet das InfinityBook locker noch ein paar Stündchen weiter.

Fazit

Gerade im mobilen Einsatz komme ich sehr gut mit dem InfinityBook zurecht. Das Gerät benötigt wenig Stauraum, ist leicht und verfügt über genug Power um einige Stunden mit dem Gerät zu arbeiten. Das InfinityBook macht aber auch am Schreibtisch eine gute Figur. Ein zweiter Monitor lässt sich problemlos anschließen.

Vorschau

In den nächsten Artikeln werde ich berichten, wie das InfinityBook mit Virtualisierungen und der Spiele-Plattform Steam zurecht kommt.

Prosody Admin Web

Das Neuaufsetzen von Prosody auf einen Server mit Debian 9 lief bei mir mal wieder nicht ganz ohne Probleme. So hatte ich erst am Wochenende festgestellt, dass es nicht möglich war einzelne Usern zu löschen. Die letzten Spam-User-Registrierungen, wollte ich aber schnell wieder los werden. Der Lösch-Befehl

brachte in /var/log/prosody/prosody.err eine Fehlermeldung mit dem Hinweis auf ein Upgrade der neuen Datenbank. Dies war notwendig, da Prosody zuvor auf MySQL lief. Debian 9 hingegen nutzt MariaDB. Dieser Fehler konnte nun recht einfach mit

behoben werden.

Nun fiel mir aber noch ein weiteres Problem ins Auge. Seit einiger Zeit nutze ich das Modul mod_admin_web. Auch hier konnte ich mich nicht mehr im Webinterface einwählen.

Prosody – Admin Web

Die Ursache bestand darin, dass ich das Modul wie in der offiziellen Beschreibung

zwar in die prosody.cfg.lua eingebunden hatte, jedoch die Installation im Nachgang nicht ausgeführt hatte.

Da meine Community-Module in /usr/lib/prosody/prosody-modules liegen, sah die Lösung dann wie folgt aus:

Der Systemstatus sah danach nun wieder unauffällig aus:

Und immer wieder Servercow

Mein Umstieg auf Debian 9

Aus IT-technischer Sicht sollte man Web- und Mailserver auf getrennten Systemen laufen lassen. Da ich aber meinen Server privat betreibe und das Ganze mehr ein Hobby ist, laufen bei mir Web- und Mailserver auf einem Host. 

vServer, Servercow
Übersicht der laufenden Prozesse mit htop

Angefangen hatte ich mit Debian 8 auf dem bisher meine Seite intux.de lief. Parallel dazu hatte ich einen Mailserver mit Mailcow 0.14 aufgesetzt. Beides arbeitete bisher ohne Probleme und es gab eigentlich keinerlei Bedarf hieran irgendetwas zu ändern, da Debian 8 als LTS noch bis Ende April 2020 unterstützt wird.

Da ich aber mein System auf die aktuelle Version Debian 9 Stretch anheben wollte, musste ich mir Gedanken machen, wie das am besten zu realisieren ist. Da es momentan kein Upgrade für Mailcow 0.14 gibt und diese Version nicht auf dem aktuellen Debian Stretch läuft, kam für mich nur die Container-Variante Mailcow Dockerized in Frage.

Ein Upgrade auf Debian 9 wäre natürlich möglich gewesen, jedoch habe ich mich dazu entschlossen Stretch auf einem separaten Server zu installieren und alle Dienste nacheinander rüber zu holen. Dieses Vorhaben konnte ich ohne Zeitdruck auf Servercow realisieren. Der grandiose Support von André Peters war hierbei mehr als hilfreich. Bei einigen Problemen hatte ich so einen kompetenten Ansprechpartner, der sehr schnell auf Anfragen reagierte.

Da Mailcow Dockerized autonom und aus dem System herausgelöst in einer eigenen Virtualisierung arbeitet, wär mein Apache 2 mit dem Webserver Nginx in Dockerized kollidiert. Hierzu war es notwendig einen Reverse Proxy auf dem Apache, wo mein Blog läuft, einzurichten. Des Weiteren konnten von meinem frischen System keine Mails über PHP abgesetzt werden. Auch hier musste ich mich in eine für mich neue Thematik, einen Local MTA, einarbeiten, welcher dann u.a. Systemnachrichten an Mailcow Dockerized zum Versenden übergibt. 

Fazit

Den Server parallel einzurichten und alle Dienste nach und nach umzuziehen stellte sich aus der Situation als die richtige Entscheidung heraus. Ich war so nicht gezwungen alles am Stück wieder zum Laufen zu bringen. Mailcow Dockerized ist leicht zu installieren und ohne ewige Konfiguration sofort einsatzbereit. Trotz zwei nun nebeneinander arbeitender Webserver läuft das gesamte System performanter als vorher. 

Ich habe mich zur Verwirklichung meiner kleinen Projekte vor fast 10 Monaten bewusst und aufgrund guter Kritiken für Servercow entschieden. Bei Problemen am Server und speziell mit Mailcow steht ein kompetenter Ansprechpartner zur Seite. Diesen Schritt habe ich zu keinem Zeitpunkt bereut. Sicher hat man mit einem eigenen Server einiges an Arbeit und Verantwortung auf dem Schirm, aber man ist dafür wesentlich flexibler. Dafür bietet Servercow ein gutes Zuhause.

Angriff auf Joomla!-Installation

Vor ein paar Tagen wurde eine auf meinem vServer laufende Joomla!-Instanz massiv angegriffen. Der Inhaber dieser Seite bekam in ca. einer Stunde über 600 Mails vom Nachrichtensystem. So etwas ist bedauerlich und nicht gerade schön mit anzusehen.

Was war passiert?

Die Analyse des Logs /var/log/mail.log zeigte, dass Mails im 5-6 Sekunden-Takt vom Server an den Administrator gesendet wurden. 

Was wurde kurzfristig unternommen?

Zu allererst wurde der Versand der Systemmails der Joomla!-Installation deaktiviert. Damit konnte die Spam-Welle vorerst gestoppt werden. Bei der weiteren Analyse stellte sich heraus, dass die User-Registrierung aktiv war und sich über 600 User registriert hatten. Die dazu verwendeten eMail-Adressen hatten alle die Domain-Endung .ru. Im nächsten Schritt wurde die Registrierung ebenfalls deaktiviert. Warum diese aktiv war, kann ich leider nicht mehr nachvollziehen. Alle verdächtigen registrierten User der Seite wurden gelöscht.

Wie ging es weiter?

Da ich zu dem Zeitpunkt immer noch nicht genau wusste was genau passiert war, habe ich ein älteres Backup der Datenbank eingespielt (zum Glück werden Backups der Datenbanken, wie im Artikel „MySQL- Sicherung ohne Passwort im Script“ beschrieben, täglich automatisch angelegt). Nach dem Einspielen stellte sich heraus, dass hier nur die bekannten Administratoren als Benutzer in der Joomla!-Installation gespeichert waren. Die Registrierung wurde wieder deaktiviert und so die Sicherheitslücke geschlossen. Abschließend habe ich nachgeschaut, ob Dateien oder Verzeichnisse der Joomla!-Installation in den letzten Tagen verändert wurden. Dazu wechselte ich in das entsprechende Verzeichnis

und suchte die Änderungen der Dateien der letzten fünf Tage

Ausgabe:

sowie den Änderungen der Verzeichnisse

Ausgabe:

Die Dateien und Verzeichnisse wurden dann meinerseits überprüft. Da es hier keinerlei Auffälligkeiten gab, konnte auf das Einspielen eines Backups der kompletten Installation verzichtet werden.

Was war nun tatsächlich passiert?

Es konnten sich von außen User registrieren. Die so erstellten Accounts wurden aber nicht aktiviert, da die angegeben eMail-Adressen wahrscheinlich nicht valide waren. Das System verschickte jedoch bei jeder neuen Registrierung eine entsprechende eMail an den Superadministrator. So kam es zu einer massiven Welle von Registrierungsbestätigungen. Da die registrierten Accounts nicht aktiviert werden konnten, hatten die Aktionen keine Auswirkungen auf das System.

Kann das nochmal vorkommen?

Durch die deaktivierte Registrierung kann es zu dieser Art von Angriffen nun nicht mehr kommen.

MySQL- Sicherung ohne Passwort im Script

Nach dem ich nun nieder geschrieben hatte, wie ich meine SQL-Datenbanken automatisch sichere, kamen einige gute Anregungen in den Kommentaren. Darauf hin habe ich das System etwas umgestellt. Dazu wurde zu allererst der Storage vom root auf einen User übertragen. Somit konnte ich auch den Cronjob für den User einrichten. Der Eintrag, wie im ersten Artikel „MySQL-Sicherung“ in /etc/crontab wurde wieder entfernt. und der Cron neu gestartet.

Als eingeloggter User habe ich dem selbigen mit

folgenden Befehl eingetragen.

Dann wurde eine ~/.my.cnf

mit entsprechendem Inhalt erstellt. Diese enthält das MySQL root Passwort.

„meinpasswort“ musste hier natürlich angepasst werden. Nach dem Abspeichern wurden der Datei die Rechte 600 vergeben.

Im Anschluss habe ich ein neues Script mit dem Inhalt

erstellt und dieses mit

ausführbar gemacht. Um die Datenbanken besser auseinander halten zu können, bekamen alle Datenbanken dieses Mal ein separates Verzeichnis.

Nun werden die Datenbank-Sicherungen jeden Morgen 2:00 Uhr in von einander getrennten Verzeichnissen komprimiert abgelegt.

Der Servercow-Storage wurde mit der Nextcloud-App „External Storage“ in die Cloud eingebunden und die Sicherungen landen so regelmäßig auf meinem Notebook.