Category: administration

Nextcloud-Tools: Working with the Nextcloud Server-Side Encryption

02.12.2019 yahe administration code security

At the beginning of the year we ran into a strange problem with our server-side encrypted Nextcloud installation at work. Files got corrupted when they were moved between folders. We had found another problem with the Nextcloud Desktop client just recently and therefore thought that this was also related to synchronization problems within the Nextcloud Desktop client. Later in the year we bumped into this problem again, but this time it occured while using the web frontend of Nextcloud. Now we understood that the behaviour did not have anything to do with the client but with the server itself. Interestingly, another user had opened a Github issue about this problem at around the same time. As these corruptions lead to quite some workload for the restore I decided to dig deeper to find an adequate solution.

After I had found out how to reproduce the problem it was important for us to know whether corrupted files could still be decrypted at all. I wrote a decryption script and proved that corrupted files could in fact be decrypted when Nextcloud said that they were broken. With this in mind I tried to find out what happened during the encryption and what broke files while being moved. Doing all the research about the server-side encryption of Nextcloud, debugging the software, creating a potential bugfix and coming up with a temporary workaround took about a month of interrupted work.

Even more important than the actual bugfix (as we are currently living with the workaround) is the knowledge we gained about the server-side encryption. Based on this knowledge I developed a bunch of scripts that have been published as nextcloud-tools on GitHub. These scripts can help you to rescue your server-side encrypted files in cases when your database was corrupted or completely lost.

I also wrote an elaborate description about the inner workings of the server-side encryption and tried to get it added to the documentation. It took some time but in the end it worked! For about a week now you can find my description of the Nextcloud Server-Side Encryption Details in the official Nextcloud documentation.


.local, .home.arpa and .localzone.xyz

11.11.2019 yahe administration

35 years ago the IETF defined special IPv4 addresses in RFC 1597 to be used solely in private intranets and with that created the separation between internal networks and the internet. 5 years later they proceeded to define special-use top-level domains like .example, .invalid and .test in RFC 2606. However, the IETF did not reserve a top-level domain to be used within the private intranets that they had introduced before. This lead to confusion with administrators that still persists to the current day.

Every time an administrator was tasked to design a network structure they also had to think about naming conventions within the network. As there was a pre-defined set of "valid" top-level domains within the internet, it was rather easy to just select an "invalid" TLD and use that for the private network. At least, until the ICANN decided to delegate new TLDs to anyone who was willing to apply and pay the required fees. The ICANN even provided a paper on how to identify and mitigate name collisions to be used by professionals.

With RFC 6762 the .local TLD was approved as a special-use TLD to be used in internal networks and many administrators thought that this would solve the problems, but unfortunately, it did not. .local was designated to be used with multicast DNS, meaning that each device in a network could grab its preferred hostname. At the beginning this was not a big deal, but as more and more devices implemented Apple's Bonjour protocol (also known as zeroconf) interoperability problems started to pop up. Appendix G of said RFC even mentioned alternative TLDs that might be used, however, the ICANN did not accept any of them as special-use domain names.

Years later the new RFC 7788 defined .home as a potential local-only TLD, but it was changed to the rather unusual .home.arpa domain name with RFC 8375. This domain is safe to be used in local networks and was accepted as a special-use domain name by the ICANN. Unfortunately, due the word "home" in the domain it is not quite fitting for business environments.

There are two more TLDs that might be safe to use: .corp and .home are not officially recognized special-use domain names but the ICANN has refrained from delegating them to bidders as the risk of breaking internal networks is deemed to be too big.

As of today, most tutorials still propose to use a publicly registered domain for internal networks. This is why I registered .localzone.xyz about half a year ago. It is explicitly meant to be used locally, has public DNS records set to prevent any public CA from issuing trusted TLS certificates for that domain as well as DNS records defining all mails using that domain as SPAM and will not be used for publicly accessible services as long as it is owned by me. I am using this domain internally myself and am also trying to get the domain added to the public suffix list. This list defines domain and cookie boundaries so that e.g. example-a.com is not able to set cookies for example-b.com.

So if you are looking for a domain that you can use for internal domain names then look no further: Either use the special-use domain name .home.arpa (which might not be fitting for businesses) or use .localzone.xyz as I am. It makes clear that you are in a local environment without being too specific about whether it is a private or business network.


Das Scrollrad unter Linux beschleunigen

10.07.2017 yahe administration legacy linux

Wie ich bereits im letzten Artikel beschrieben habe, wechsele ich derzeit zu Linux als mein Hauptbetriebssystem. Leider gibt es dabei immer wieder kleinere Stolpersteine, die die Arbeit mit dem System nervig machen. Eines davon war die absolut träge Scrollgeschwindigkeit innerhalb des Systems. Nicht nur, dass man sich dadurch durch längere Webseiten und Terminalsessions krampfen muss, das System fühlt sich oft einfach lahm und überfordert an.

Auf der Suche danach, diesen Missstand zu beseitigen, wanderte ich natürlich erst einmal in die Systemeinstellungen, die bzgl. der Einstellungsmöglichkeiten der Maus, recht spartanisch ist. Von Themen wir Beschleunigung ist man hier offenbar meilenweit entfernt.

Gnome Mauseinstellungen

Also begann ich damit, mich durch Google zu graben. Als erstes stolperte ich über Beschreibungen zur Nutzung von "xinput". Also fix installiert und per "xinput list" erst nach der ID des Devices gesucht und anschließend per "xinput list-props <DeviceID>" die möglichen Optionen durchforstet. Leider fand ich in der Auflistung nichts, was nach der Scrollgeschwindigkeit aussah oder wenigstens wie etwas, was dem nahe kam, was laut den Foreneinträgen der korrekte Konfigurationswert hätte sein sollen.

Noch gab ich aber nicht auf und suchte weiter. Dabei stieß ich auf das Tool "imwheel", das genau das tun sollte, was ich erreichen wollte. Es funktioniert allerdings nicht out-of-the-Box und die meisten Artikel, die ich zuerst fand, bezogen sich darauf, wie man mit imwheel zusätzliche Maustasten unter Linux zum Laufen kriegt. Erst ein halbwegs neuer Artikel half mir dann tatsächlich weiter. Zuerst einmal muss man imwheel installieren:

sudo apt-get install imwheel

Anschließend muss man eine Konfigurationsdatei namens "~/.imwheelrc" erstellen:

".*"
None,      Up,   Button4, 3
None,      Down, Button5, 3
Control_L, Up,   Control_L|Button4
Control_L, Down, Control_L|Button5
Shift_L,   Up,   Shift_L|Button4
Shift_L,   Down, Shift_L|Button5

Der Wert ".*" sorgt dafür, dass imwheel in allen Anwendungsfenstern aktiv ist. Man kann hier auch alternativ Fensternamen eintragen, um die Funktion von imwheel auf einzelne Anwendungen zu beschränken. Die einzelnen Zeilen sind nun Ersetzungen, die von imwheel durchgeführt werden. "Button4" ist das nach-oben-scrollen der Maus, "Button5" das nach-unten-scrollen. Diese werden hier durch 3-faches Drücken der Up- bzw. Down-Taste ersetzt. Das gleiche geschieht für Situationen, in denen die Ctrl- bzw. Shift-Taste gedrückt wird. Nun muss man diese Ersetzung nur noch aktivieren:

imwheel --kill --buttons "4 5"

Mit "--kill" werden alle bereits laufenden Instanzen von imwheel beendet, damit sich unterschiedlich konfigurierte Instanzen nicht in die Quere kommen können. Die Angabe "--buttons "4 5"" sorgt dafür, dass imwheel sich nur um die Behandlung des Scrollrads kümmert. Man kann über imwheel auch die Scrollrichtung umkehren. Entweder, indem man die oben stehende Konfigurationsdatei umschreibt oder aber, indem man einfach den zusätzlichen Parameter "--flip-buttons" verwendet:

imwheel --kill --buttons "4 5" --flip-buttons

Das ganze funktioniert unter Debian mit Gnome schon ganz gut, aber nur bis zum nächsten Neustart. Um die Änderung dauerhaft einzurichten, muss man noch dafür sorgen, dass imwheel beim Hochfahren aktiviert wird. Hierfür bietet sich an, die Autostart-Funktion von Gnome zu verwenden. Um das zu erreichen, legt man die Datei "~/.config/autostart/imwheel.desktop" an und befüllt diese wie folgt:

[Desktop Entry]
Name=imwheel
Comment=Use imwheel to increase scroll speed
Exec=/usr/bin/imwheel --kill --buttons "4 5"
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true
X-GNOME-Autostart-Delay=10

Auch hier kann man optional den Parameter "--flip-buttons" verwenden, um die Scrollrichtung umzukehren:

[Desktop Entry]
Name=imwheel
Comment=Use imwheel to increase scroll speed
Exec=/usr/bin/imwheel --kill --buttons "4 5" --flip-buttons
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true
X-GNOME-Autostart-Delay=10

Ich muss gestehen, dass ich ziemlich genervt bin, dass man halbe Handstände vollführen muss, nur um das Scrollrad zu beschleunigen. 🙄


Emojis unter Linux nutzen

06.07.2017 yahe administration legacy linux

Da Apple sich aus meiner Sicht mit den MacBooks in die falsche Richtung entwickelt, arbeite ich derzeit an einem Soft-Exit aus der macOS-Welt. Da ich sowieso noch einen Tower-PC umher stehen hatte, habe ich mir deshalb gedacht "Warum nicht den ersten Schritt gehen und einen alltagstauglichen Rechner mit Linux bestücken und anfangen, diesen häufiger zu nutzen?".

Genau dabei bin ich gerade. Ich habe mir ein hübsches neues Debian 9 eingerichtet, zwei ordentliche Monitore besorgt und nutze den Desktoprechner nun als Linux-only Haupt-PC. Das klappt soweit auch ganz gut. Eine Sache hat mir als jahrelanger MacBook- und iPhone-Nutzer jedoch gefehlt: Emojis! 😭

Also machte ich mich auf die Suche nach einer Möglichkeit, Emojis zu verwenden. Die meisten Lösungen, die ich gefunden habe, waren jedoch eher suboptimal. Vor allem unterstützte keine davon farbige Emojis in der Auswahlansicht. Und Schwarz-/Weiß-Emojis unterscheiden zu wollen, ist nahezu ein Ding der Unmöglichkeit.

Glücklicherweise bin ich über diesen Artikel gestolpert, der von einem Emoji-Picker handelt, der zu Ubuntu-14.04-Zeiten für Unity 7 entwickelt worden ist. Glücklicherweise ist der EmojiOne Picker for Ubuntu auch unter Debian 9 mit Gnome lauffähig. Um das zu bewerkstelligen, muss zuerst einmal das aktuelle Release heruntergeladen und entpackt werden. Dieses enthält die Datei "install.sh". Dieser Installer kann als Root aufgerufen werden, um den Emoji-Picker für alle Nutzer zu installieren. Oder aber man startet ihn als normaler Nutzer, damit der Emoji-Picker nur für diesen spezifischen Nutzer installiert wird.

Leider war es bei mir an der Stelle noch nicht getan. Um die Integration in die Oberfläche zu erhalten, nutzt das Tool die Library "AppIndicator 3.0". Um diese zu installieren, muss man erst einmal den korrekten Paketnamen ausfindig machen. Die Installation kann folgendermaßen angestoßen werden:

sudo apt-get install gir1.2-appindicator3-0.1

Nach einem Reboot erhält man nun in der unteren linken Bildschirmecke einen Eintrag für den Emoji-Picker, der sich wunderbar aufklappen lässt, um das passende Emoji rauszusuchen, in Farbe und bunt.

EmojiOne Picker Ubuntu

Leider ist das Tool nicht ganz so komfortabel wie die Emoji-Eingabe bei macOS. Anstatt das Menü über eine Tastenkombination aufzurufen, muss man händisch mit der Maus in den Bildschirmbereich fahren. Und im Gegensatz zu macOS wird das gewählte Emoji lediglich in die Zwischenablage kopiert, anstatt direkt ins aktive Textfeld geschrieben zu werden. Aber zumindest scheint es erst einmal besser zu sein, als alles, was ich bisher sonst so unter Linux gesehen habe. Leider.


CentOS 7 mit Two-Factor-Authentication absichern

11.08.2016 yahe administration legacy linux security

Nach meiner Migration zu CentOS 7 wollte ich Two-Factor-Authentication für SSH-Logins einrichten. Allerdings musste ich feststellen, dass es für CentOS 7 keine aktuellen Pakete des entsprechenden PAM (Pluggable Authentication Module) gibt. So musste ich wohl oder übel das ganze selbst kompilieren. Bevor man jedoch loslegen kann, benötigt man zuerst einmal ein paar zusätzliche Pakete:

sudo yum install autoconf automake libtool make pam-devel unzip wget zip

Nun können wir mit der eigentlichen Installation beginnen:

wget https://github.com/google/google-authenticator/archive/master.zip
unzip ./master.zip
cd ./google-authenticator-master/libpam
./bootstrap.sh
./configure

Bis hierhin sollte alles funktioniert haben. Leider enthält die erstellte Konfiguration einen kleinen Fehler. Deshalb müssen wir händisch an den Anfang der Datei "./Makefile" folgende Zeile einfügen:

LDFLAGS="-lpam"

Nun kann es mit dem Kompilieren weitergehen:

make
sudo make install
sudo cp /usr/local/lib/security/pam_google_authenticator.so /lib64/security
make clean
cd ../..
rm ./master.zip
rm -R ./google-authenticator-master

Um die Nutzer zu markieren, für die die Two-Factor-Authentication aktiviert werden soll, legen wir eine Gruppe "google-auth" an:

sudo groupadd google-auth

Zudem ändern wir in der Datei "/etc/ssh/sshd_conf" eine Einstellung:

ChallengeResponseAuthentication yes

Danach schreiben wir folgendes in die Datei "/etc/pam.d/sshd" (z.B. unter die restlichen "auth"-Einträge):

auth [success=1 default=ignore] pam_succeed_if.so user notingroup google-auth
auth required pam_google_authenticator.so

Mit einem Restart des SSH-Servers sind die Änderungen aktiv:

sudo systemctl restart sshd.service

Nun müssen die Nutzer, für die die Two-Factor-Authentication aktiviert werden soll, das Skript zur Einrichtung der Two-Factor-Authentication in ihrem Account aufrufen:

google-authenticator

Abschließend müssen diese Nutzer noch in die Gruppe "google-auth" aufgenommen werden:

sudo usermod -a -G google-auth <username>

Das war's! Mit diesen Schritten lässt sich unter CentOS 7 eine Two-Factor-Authentication einrichten.


Search

Links

RSS feed

Categories

administration (42)
arduino (12)
calcpw (2)
code (37)
hardware (16)
java (2)
legacy (113)
linux (28)
publicity (6)
review (2)
security (60)
thoughts (21)
windows (17)
wordpress (19)