Debian

Prosody inaktive User löschen

Im Artikel „Prosody – inaktive User ausfindig machen“ hatte ich beschrieben, wie man nach inaktiven XMPP-Accounts in Prosody suchen kann. Eine elegante Möglichkeit diese User wieder loszuwerden zeigt Thomas Leister auf seinem Blog.

Ich habe mich für meinen XMPP-Server entschieden, Accounts welche drei Monate inaktiv waren zu löschen. Hierzu erstelle ich lt. Anleitung ein Script.

# prosodyctl mod_list_inactive intux.de 3month default | sed -e 's/^/prosodyctl deluser /' > delusers.sh

1	# prosodyctl mod_list_inactive intux.de 3month default \| sed -e 's/^/prosodyctl deluser /' > delusers.sh

Dieses wird dann im Anschluss ausgeführt.

# sh ./delusers.sh

1	# sh ./delusers.sh

Danach sind alle inaktiven User des zuvor erwähnten Zeitraums vom drei Monaten vom Server gelöscht.

XEP-0368 auf dem Prosody XMPP-Server

Letztes Wochenende hatte ich den ComplianceTester von Daniel Gultsch durchlaufen lassen und gesehen, dass enige XMPP-Erweiterungen (XEP) nicht aktiviert waren. Die größten Probleme hatte ich bei der Suche nach einer Lösung zur Aktivierung von XEP-0368. Schlußendlich half mir die Anleitung von Dominion auf adminforge.de.

Hier meine Änderungen am XMPP-Server intux.de:

Zuerst wurde sslh installiert.

# apt install sslh

1	# apt install sslh

An dieser Stelle wurde ein „eigenständiger Server“ ausgewählt.

Dann musste die Datei /etc/apache2/ports.conf (Apache2) mit

# nano /etc/apache2/ports.conf

1	# nano /etc/apache2/ports.conf

von

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80

<IfModule ssl_module>
        Listen 443
</IfModule>

<IfModule mod_gnutls.c>
        Listen 443
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

# If you just change the port or add more ports here, you will likely also

# have to change the VirtualHost statement in

# /etc/apache2/sites-enabled/000-default.conf

Listen 80

Listen 443

</IfModule>

Listen 443

</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80

<IfModule ssl_module>
        Listen 127.0.0.1:443
</IfModule>

<IfModule mod_gnutls.c>
        Listen 127.0.0.1:443
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

# If you just change the port or add more ports here, you will likely also

# have to change the VirtualHost statement in

# /etc/apache2/sites-enabled/000-default.conf

Listen 80

Listen 127.0.0.1:443

</IfModule>

Listen 127.0.0.1:443

</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

geändert werden. Im Anschluss wurde in die /etc/prosody/prosody.cfg.lua (Prosody) mit

# nano /etc/prosody/prosody.cfg.lua

1	# nano /etc/prosody/prosody.cfg.lua

die Zeile

legacy_ssl_ports = 5223

1	legacy_ssl_ports = 5223

eingefügt. In der /etc/default/sslh musste via

# nano /etc/default/sslh

1	# nano /etc/default/sslh

Bidirektionale Zwischenablage in VirtualBox

Wenn man ein Betriebssystem in der VirtualBox von Oracle testet, möchte man auch in der Lage sein Code oder Text vom Hostsystem in die Virtualisierung zu kopieren. Von Haus aus geht das ohne eine entsprechende Konfiguration nicht. Dazu ist es nötig die Gasterweiterung auf dem Hostsystem zu installieren. Ist dies erledigt, kann man nachdem man ein paar Einstellungen vorgenommen hat die Virtualisierung starten. In meinem Fall ist ein Ubuntu 18.04 LTS schon vorinstalliert.

Einstellungen VirtualBox

Vor dem Start des Systems wird über Ändern => Erweitert die gemeinsame Zwischenablage und Drag’n’Drop auf bidirektional gesetzt. Somit wird das Kopieren später in beide Richtungen möglich.

Nach dem Start der Virtualisierung

Nun wird in der Virtualisierung wie auf dem Screenshot zu sehen, die Gasterweiterung ins System Geräte => Gasterweiterung einlegen geladen.

Jetzt öffnet man mit Ctrl+Alt+t das Terminal in Ubuntu 18.04 und wechselt dort in das entsprechende Verzeichnis. In meinem konkreten Beispiel wäre das das Verzeichnis /media/intux/VBox_GAs_5.2.8.

cd /media/intux/VBox_GAs_5.2.8

1	cd /media/intux/VBox_GAs_5.2.8

Hier ist jedoch entsprechend des eigenem Systems der Benutzer und die gewählte Version der Gasterweiterung anzupassen. Danach wird die Datei VBoxLinuxAdditions.run wie folgt ausgeführt und installiert.

sudo sh ./VBoxLinuxAdditions.run

1	sudo sh ./VBoxLinuxAdditions.run

Ist dies geschehen, kann man nun Texte vom Hostsystem in die Virtualisierung kopieren. Dies geht natürlich auch in die andere Richtung.

Viel Spaß!

Nextcloud Talk

Die App Talk der Nextcloud ist für mich momentan die beste Alternaive für Videokonferenzen. Dabei benötigt der Gesprächspartner weder eine Nexcloud noch einen Account in einer Nextcloud.

USB in VirtualBox aktivieren

Sehr oft teste ich die verschiedensten Betriebssysteme in der VirtualBox von Oracle. Hierzu muss man hin und wieder Daten von einem angeschlossenen USB-Stick in die Virtualisierung einspielen. Dies gelingt in der Regel nicht ohne weiteres, da die Treiber erst geladen werden müssen. Voraussetzung hierfür ist das installierte Extension Pack der VirtualBox. Wurde das Paket eingespielt, gelingt es aber im Normalfall nicht das USB-Device einzubinden.

Am folgenden Beispiel der virtualisierten Version Ubuntu 18.04 LTS Bionic Beaver auf einem Debian 9 Stretch zeige ich was hierzu getan werden muss.

Zuerst weist man der Gruppe vboxusers den User zu über den die VitualBox gestartet wird. In meinem Fall ist das intux (den Befehl bitte an den User anpassen).

# usermod -aG vboxusers intux

1	# usermod -aG vboxusers intux

Ist dies geschehen, muss man sich im System neu anmelden oder den Rechner neu booten, damit die Änderungen übernommen werden. Dann geht man in die Einstellung der VitualBox (hier Ubuntu 18.04) und wählt unter USB den entsprechenden Controller (USB-1.1, USB-2.0 oder USB-3.0) aus. Dann werden, wie im Screenshot zu sehen die entsprechen USB-Filter hinzugefügt.

Nun kann die Virtuelle Maschine gestartet werden, um von dort auf den USB-Stick zuzugreifen.

Viel Spaß!

TUXEDO InfinityBook Pro 13 – Teil 12

Ein Jahr durfte ich nun das InfinityBook Pro 13 der Firma TUXEDO aus Königsbrunn testen. Ich hatte hierbei freie Hand bei der Auswahl der zu installierenden Betriebssysteme. Das Gerät war nicht nur Testgerät, sondern auch Arbeitsgerät während des gesamten Zeitraums. Abschließend zu dieser Serie hier eine kurze Zusammenfassung.

Besonders positiv fiel die Leistung des Notebooks ins Gewicht. Die 16 GB RAM und der i7-7500U in Verbindung mit der 250GB M.2 SSD von Samsung sorgten für ordentlich Geschwindigkeit. Das Gerät ist platzsparend und leicht. Der Akku, welcher je nach Anwendung bis zu sieben Stunden durch hielt ist ganz OK, erfüllte jedoch nicht die Erwartungen die das Datenblatt auf den ersten Blick verspricht. Hierfür ist aber eine in der Branche umstrittene Testmethode verantwortlich. Dennoch kam ich gut mit einer Akkuladung über den Tag. Die Kapazität des wechselbaren Akkus hat nach einem Jahr intensiver Nutzung kaum spürbar nachgelassen. Die Funktionstasten ließen sich zum Großteil „out of the box“ ansprechen. Die Flugmodus-Taste musste jedoch bei den linuxoiden Betriebssystemen im Grub nachkonfiguriert werden. Dieses Problem wurde in der von TUXEDO angepassten Xubuntu-Version allerdings schon beseitigt. Das Aluminiumgehäuse ist bis auf ein paar kosmetische Fehler gut verarbeitet. Zu bedenken ist, dass ein solches Gerät Einwirkungen mechanischer Art von außen nicht verzeiht. Stürze aus einem Meter Höhe können durchaus solche Spuren hinterlassen.

Die Funktionalität des InfinityBooks wurde jedoch hierbei nicht beeinträchtigt. Was die Reparatur eines solchen Schadens am Gerät kostet, konnte ich bis zum Zeitpunkt der Veröffentlichung dieses Artikels leider nicht in Erfahrung bringen.

Die weitere Ausstattung des InfinityBooks ist ebenfalls gut durchdacht. Das matte entspiegelte FullHD-Display ist sehr hell und kontrastreich. Ein verbauter Kartenleser ist Standard. Ein UMTS-Modul kann optional dazu bestellt werden. Leider konnte ich diese Option nicht nutzen. Die vorhandenen USB-Schnittstellen (2 x USB 3.1 Type A und 1 x USB Typ-C mit Thunderbolt 3) reichten in meinem Fall völlig aus. Das Fehlen eines DVD-Laufwerks stellte ebenfalls kein Problem dar. Etwas bedauerlich ist, dass es für das verbaute WLAN-Modul keinen freien Treiber gibt. Unter Debian muss also etwas nachgeholfen werden. Der Boden des Notebooks kann komplett abgenommen werden. Die Reinigung des Lüfters ist so ohne weiteres möglich. Zusätzlicher Arbeitsspeicher bis zu 32 GB RAM oder weitere Festplatten lassen sich problemlos nachrüsten.

Preislich gesehen spielt das InfinityBook Pro 13 definitiv mit 1411,99€ (damaliger Grundpreis 1099,00€) in der Oberklasse mit. Zum heutigen Stand wird das InfinityBook aber schon ab 910,00€ angeboten.

Fazit

Das InfinityBook mit der Pinguintaste ist eine Überlegung wert, egal welches Betriebssystem man hier favorisiert. Hochwertige Materialien sowie eine flotte Hardware machen das Gerät nicht nur zu einem Hingucker, sondern auch unterwegs zu einem perfekten Arbeitsgerät für Entwickler, Journalisten oder Blogger. Über kleinere Schwächen kann man getrost hinweg sehen.

FTP-Daten der Webseite nach Samba-Share sichern

FTP-Daten einer Webseite können per SSH folgendermaßen manuell gesichert werden. Ein Archiv wird iin diesem Beispiel in das zuvor erstellte Samba-Share Verzeichnis geschrieben. Alle Dateiberechtigungen bleiben erhalten.

# cd /var/www/html

1	# cd /var/www/html

# tar -cf /samba_share/website.tar website/

1	# tar -cf /samba_share/website.tar website/

SSH mit Google Authenticator absichern

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

# apt install libpam-google-authenticator

1	# apt install libpam-google-authenticator

und aktiviert den Google Authenticator wie folgt:

# google-authenticator

1	# google-authenticator

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

# nano  /etc/pam.d/sshd

1	# nano /etc/pam.d/sshd

dieser Eintrag ans Ende gesetzt.

auth required pam_google_authenticator.so nullok

1	auth required pam_google_authenticator.so nullok

„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

# nano  /etc/ssh/sshd_config

1	# nano /etc/ssh/sshd_config

auf

ChallengeResponseAuthentication yes

1	ChallengeResponseAuthentication yes

gesetzt und der SSH-Service neu gestartet.

# service ssh restart

1	# service ssh restart

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.

Nachtrag

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

Viel Spaß!

TUXEDO InfinityBook Pro 13 – Teil 11

Als vorerst letztes Betriebssystem habe ich mir Qubes OS auf dem InfinityBook Pro 13 von TUXEDO angesehen. Diese Distribution setzt auf Sicherheit durch Isolation und rangiert bei Distrowatch derzeit auf Rang 53.

Auf Wikipedia heißt es hierzu:

Qubes OS ist ein auf IT-Sicherheit fokussiertes Computer-Betriebssystem, welches dies durch Isolation gewährleistet. Die dafür benötigte Virtualisierung wird durch Xen ermöglicht. Die Benutzerumgebung kann basierend auf Fedora, Debian, Whonix, Microsoft Windows und weiteren anderen sein.

Installation

Leider war es mir nicht möglich die aktuelle Version Qubes Release 3.2 auf dem InfinityBook zu installieren. Hier gab es Probleme, wie auch bei einigen anderen Distributionen, mit der NVMe M.2 SSD von Samsung.

Die Version Qubes Release 4.0-rc4 (release candidate) hingegen ließ sich im Legacy-Mode auf dem Gerät installieren. Um später Zugriff auf das Netzwerk zu erhalten, sollte im BIOS Thunderbold deaktiviert werden.

Qubes OS im Einsatz

Wer sich auf das Abenteuer Qubes einlässt, sollte ein wenig Frickelei in Kauf nehmen. Nach der Installation auf TUXEDOs InfinityBook wird man feststellen, dass das Netzwerk fehlt. An dieser Stelle ist etwas Handarbeit angesagt. Hierzu erstellt man im Editior in dom0 die Datei /etc/systemd/system/qubes-pre-netvm.service

sudo nano /etc/systemd/system/qubes-pre-netvm.service

1	sudo nano /etc/systemd/system/qubes-pre-netvm.service

mit folgendem Inhalt:

[Unit]
Description=Netvm fixup
Before=qubes-netvm.service

[Service]
ExecStart=/bin/sh -c 'echo -n "1" >
/sys/bus/pci/devices/0000\:02\:00.0/remove'
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

[Unit]

Description=Netvm fixup

Before=qubes-netvm.service

[Service]

ExecStart=/bin/sh -c 'echo -n "1" >

/sys/bus/pci/devices/0000\:02\:00.0/remove'

Type=oneshot

RemainAfterExit=yes

[Install]

WantedBy=multi-user.target

Dann wird der Befehl

sudo systemctl enable qubes-pre-netvm.service

1	sudo systemctl enable qubes-pre-netvm.service

zum Erstellen des Service abgesetzt und das System neu gestartet.

In der VM sys-net müssen dann noch in Devices LAN und WLAN hinzugefügt werden. Im Anschluss startet man im Qube-Manager sys-net neu. Ist dies erledigt, ist das Netzwerk aktiv und es haben u.a. die vorinstallierten VMs von Debian, Fedora und Co. Zugriff auf das World Wide Web.

Die meisten Funktionstasten lassen sich auch bei Qubes OS wie bei den zuvor getesteten Systemen nach der Installation problemlos ansteuern.

Fazit

Qubes OS hat ein interessantes Konzept und lässt sich mit einigen Kniffen auf dem InfinityBook Pro 13 installieren. Auch hier sperrt die Hardware von TUXEDO diesen Exoten nicht aus. Allerdings hatte ich das Gefühl, dass das Arbeiten in den Virtualisierungen doch an der Performance nagt und so auch die Akkulaufleistung deutlich beeinflusst. Im Arbeitsmodus kam ich über 4 Stunden meist nicht hinaus. Darüber sieht aber sicher der typische auf Sicherheit bedachte Qubes-User hinweg.

Vorschau

Im letzten Artikel werde ich eine kleine Zusammenfassung bringen, wie sich das InfinityBook Pro 13 rückblickend im letzten Jahr geschlagen hat.

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

# cd /root

1	# cd /root

# nano MailBoxscript.sh

1	# nano MailBoxscript.sh

mit folgendem Inhalt erstellt

#!/bin/bash
rsync -av --delete /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/ /samba_share/backup_mailbox

1 2	#!/bin/bash rsync -av --delete /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/_data/ /samba_share/backup_mailbox

und

# chmod +x MySQLscript.sh

1	# chmod +x MySQLscript.sh

ausführbar gemacht. Weiterhin wurde ein Crontab angelegt.

# nano /etc/crontab

1	# nano /etc/crontab

Hier habe ich am Ende

* 3 * * * root /root/MailBoxscript.sh

1	* 3 * * * root /root/MailBoxscript.sh

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

# /et12c/init.d/cron restart

1	# /et12c/init.d/cron restart