Heute soll es darum gehen, ein Samba Active Directory um eine neue eigene auxiliary ObjectClass zu erstellen, mit eigenen Attributen.
Doch hier erst ein wichtiger Hinweis:

Das Ändern des Schemas in ein schwer Eingriff in die Struktur des Active Directories und sollte gut überlegt und geplant sein. Eine einmal in Active Directory eingespielte Änderung kann nicht wieder Rückgängig gemacht werden! Vor dem Einspielen sollten Sie auf jeden Fall Ihre Active Directory sichern. Testen Sie die Schemaänderung immer erst in einer Testumgebung!

Das Vorgehen beim Einspielen einer neuen ObjectClass und neuer Attribute ist hier anders, als Sie es vielleicht vom OpenLDAP her kennen. Im ersten Schritt müssen Sie immer erst die Attribute im Schema eintragen, erst dann kann die ObjectClass eingespielt werden. Hier im Beispiele sollen zwei neue Attribute angelegt werden, die dann später einzelnen Benutzern zugewiesen werden können. Sie sollten sich, sofern noch nicht passiert, auf jeden Fall einen eigene ODI bei der IANA registrieren um Ihre ObjectClass und Ihre Attribute weltweit eindeutig zu halten. Der Eigene ODI beginnt immer mit 1.3.6.1.4.1. Von der IANA erhalten Sie dann eine sechsstellige Nummer. Hier habe ich zur Demonstration die „123456“ genutzt. Die Zahlen nach dem OID sind frei wählbar. die erste ‚1‘ verweist hier immer auf meine erste eigenen Objectclass. Jede weitere neue ObjectClass wird immer um ‚1‘ hochgezählt. Die folgenden Zahl gib hier die Position des Attributs an. Alle neuen Attribute werden immer wieder um ‚1‘ hochgezählt. Verwenden Sie auch immer einen Suffix für Ihre ObjectClass und Ihre Attribute so ist auch beim Namen die Eindeutigkeit besser gegeben. Ich nutze hier „stka“ Jetzt folgt der LDIF für die Attribute

————-
dn: CN=stka-geburtstag,CN=Schema,CN=Configuration,DC=example,DC=net
objectClass: top
objectClass: attributeSchema
cn: stka-geburtstag
attributeID: 1.3.6.1.4.1.123456.1.1
lDAPDisplayName: stka-geburtstag
attributeSyntax: 2.5.5.12
omSyntax: 64
isSingleValued: TRUE
searchFlags: 0
description: Geburtstag des Benutzers (Datum als String)

dn: CN=stka-kfz,CN=Schema,CN=Configuration,DC=example,DC=net
objectClass: top
objectClass: attributeSchema
cn: stka-kfz
attributeID: 1.3.6.1.4.1.123456.1.2
lDAPDisplayName: stka-kfz
attributeSyntax: 2.5.5.12
omSyntax: 64
isSingleValued: TRUE
searchFlags: 0
description: Fahrzeugkennung des Benutzers (String)
————-

Aber woher kommen die Werte für die attributeSyntax und omSyntax? Laden Sie sich dafür die Quellen zu ihrer Samba-Version von der Webseite www.samba.org herunter. Nachdem Sie die Datei entpackt haben, suchen Sie nach der Datei source4/dsdb/schema/schema_syntax.c, in der Datei suchen Sie nach dem Muster ’static const struct‘, darunter finden Sie die Werte für die verschiedene Syntaxattribute. Dort finden Sie auch, welches Format für das Attribut gültig ist.

Nachdem Sie die Datei erstellt haben, können Sie die Attribute, mit dem folgenden Kommando, einspielen:

ldbmodify -H /var/lib/samba/private/sam.ldb /root/new-attrib.ldif –option=“dsdb:schema update allowed“=true

Die Option ist zwingend erforderlich, da das Verändern des Schemas normaler Weise gesperrt ist.

Im Anschluss kann dann die neu ObjectClass erstellt werden. Das folgenden Listing zeigt ein Beispiel:

————
dn: CN=stka-user,CN=Schema,CN=Configuration,DC=example,DC=net
objectClass: top
objectClass: classSchema
cn: stka-user
governsID: 1.3.6.1.4.1.123456.1.3
lDAPDisplayName: stka-user
subClassOf: top
objectClassCategory: 3
mayContain: stka-geburtstag
mayContain: stka-kfz
description: Auxiliary ObjectClass zur Erweiterung von Benutzerobjekten
————

Dann können Sie die ObjectClass einspielen:
ldbmodify -H /var/lib/samba/private/sam.ldb /root/new-objectclass.ldif –option=“dsdb:schema update allowed“=true

Für alle folgenden Änderungen an den Objekten, verwenden Sie immer das Kommando:
ldbmodify -H /var/lib/samba/private/sam.ldb <datei.ldif>
Jetzt einen LDIF erstellen um die neue ObjectClass zu einem Benutzer hinzuzufügen:

———–
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
add: objectClass
objectClass: stka-user
———–

Erst jetzt können die neuen Attribute dem Benutzer hinzugefügt werden. Dafür wird der folgende LDIF benötigt:
———–
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
add: stka-geburtstag
stka-geburtstag: 1990-05-14
–
add: stka-kfz
stka-kfz: AB-XY-1234

———–

Jetzt ist der Benutzer geändert und die Änderung kann angezeigt werden:
————
root@dc01:~# ldbsearch -H /var/lib/samba/private/sam.ldb cn=Karl_Klammer
# record 1
dn: CN=Karl_klammer,CN=Users,DC=example,DC=net
cn: Karl_klammer
instanceType: 4
whenCreated: 20251030190730.0Z
uSNCreated: 4080
name: Karl_klammer
objectGUID: 8c932e96-9ae7-4d77-b0f8-62553617cfe8
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
primaryGroupID: 513
objectSid: S-1-5-21-1270304378-1688964665-1878507777-1106
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: Karl_klammer
sAMAccountType: 805306368
userPrincipalName: Karl_klammer@example.net
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=example,DC=net
pwdLastSet: 134063248508330770
userAccountControl: 512
objectClass: top
objectClass: stka-user
objectClass: person
objectClass: organizationalPerson
objectClass: user
stka-geburtstag: 1990-05-14
stka-kfz: AB-XY-1234
whenChanged: 20251030191518.0Z
uSNChanged: 4084
distinguishedName: CN=Karl_klammer,CN=Users,DC=example,DC=net

# Referral
ref: ldap://example.net/CN=Configuration,DC=example,DC=net

# Referral
ref: ldap://example.net/DC=DomainDnsZones,DC=example,DC=net

# Referral
ref: ldap://example.net/DC=ForestDnsZones,DC=example,DC=net

# returned 4 records
# 1 entries
# 3 referrals
————

Natürlich können die Werte in den Benutzerobjekten auch geändert oder gelöscht werden. Dazu wird wieder ein entsprechender LDIF benötigt. Als erstes sehen Sie den LDIF für die Änderung eines der beiden Attribute:
————
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
replace: stka-geburtstag
stka-geburtstag: 1999-05-14
————

Das folgende Listing zeigt das löschen eines Attributs

————
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
delete: stka-geburtstag
————

Um die ObjectClass bei einem Objekt zu entfernen, müssen erst alle Attribute der ObjectClass vom Objekt entfernt werden. Dazu wird der LDIF aus dem folgenden Listing benötigt:

————
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
delete: objectClass
objectClass: stka-user
————

Hier noch einmal der Hinweis: Die eingespielten Attribute und Objektklassen können NICHT wieder entfernt werden.

So können Sie in Zukunft Ihren Samba-AD um eigen ObjectClasses und Attribute erweitern.

Wenn ich bei so manchem Betreiber frage: „Wann habt ihr denn das letzt Mal den Masterkey eures Kerberos-Servers getauscht?“ Ist oft die Antwort „noch nie“ oder noch schlimmer „was für einen Masterkey?“

Der Masterkey auf einem Kerberos-Server sollte aber immer regelmäßig getauscht werden, spätestens dann, wenn der Admin, der den aktuellen Key vergeben hat, fas Unternehmen verlässt. Um das Verfahren mal darzustellen, stelle ich hier mal eine Schritt für Schritt Anleitung bereit:

Alles wird auf dem primary KDC ausgeführt.
Anzeigen des aktuellen Schlüssels

root@kerberos01:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.NET
KVNO: 1, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Do Jan 01 01:00:00 CET 1970 *

Das Datum „Do Jan 01 01:00:00 CET 1970“ zeigt, dass der Masterkey, seit erstellen der Datenbank noch nie gewechselt wurde. Jetzt wird erst noch einmal sichergestellt, dass der Schlüssel verwendet wird.

root@kerberos01:~# kdb5_util use_mkey 1

Jetzt kann der neuen Schlüssels erstellt werden  und in den stash-file geschrieben werden.

root@kerberos01:~# kdb5_util add_mkey -s
Es wird ein neuer Hauptschlüssel für den Hauptschlüssel-Principal »K/M@EXAMPLE.NET« erstellt. Sie werden nach einem neuen Datenbank-Master-Passwort gefragt.
Es ist wichtig, dass Sie dieses Passwort NICHT VERGESSEN.
Enter KDC database master key:
Re-enter KDC database master key to verify:

Der Schlüssel wird erzeugt und in die Datei geschrieben, aber noch nicht aktiviert

Erneutes Auflisten der Schlüssel

root@kerberos01:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.NET
KVNO: 2, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, keine Aktivierungszeit gesetzt
KVNO: 1, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Fr Feb 07 16:54:01 CET 2025 *

Noch ist der Schlüssel mit KVNO 1 aktiv (erkennbar an dem Stern am Ende der Zeile)

Wenn mehrere Kerberos-Server vorhanden sind, dann ist jetzt der Zeitpunk gekommen, den stash-file zu verteilen und die Datenbank neu replizieren.

Es macht Sinn auf allen KDCs mit kdb5_util list_mkeys zu prüfen, ob der neue Schlüssel vorhanden ist

Auf dem primary KDC den neuen Schlüssel aktivieren:

root@kerberos01:~#  kdb5_util use_mkey 2

Dann sollten Sie sich  noch einmal die Schlüssel auflisten lassen

root@kerberos01:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.NET
KVNO: 2, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Fr Feb 07 17:12:11 CET 2025 *
KVNO: 1, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Fr Feb 07 16:54:01 CET 2025

Jetzt ist der neu Schlüssel aktiv. die (2) ist die KVNO des neuen Schlüssels

Anschließend muss der kdc-Dienst, auf allen KDCs, neu gestartet werden.

Jetzt müssen noch alle Schlüssel der Principals in der Datenbank mit dem neuen Master-key verschlüsselt werden. Das passiert wieder auf dem primary KDC. Dafür gibt es zwei Möglichkeiten:
1. Die schneller Methode, aber dann ist der KDC währen der neuen Verschlüsselung nicht erreichbar. Clients können aber die anderen KDC zur Authentifizierung nutzen.

root@kerberos01:~#  kdb5_util update_princ_encryption
Sollen alle Schlüssel neu verschlüsselt werden, die nicht die Hauptschlüssel-VNO 2 verwenden?
(Geben Sie als Bestätigung »yes« ein) yes
6 Principals verarbeitet: 6 aktualisiert, 0 bereits aktuell

2. Muss der primary KDC während des Prozesse verfügbar bleiben geht das mit:

root@kerberos01:~# kdb5_util -x unlockiter update_princ_encryption
Sollen alle Schlüssel neu verschlüsselt werden, die nicht die Hauptschlüssel-VNO 2 verwenden?
(Geben Sie als Bestätigung »yes« ein) yes
6 Principals verarbeitet: 0 aktualisiert, 6 bereits aktuell

Dauert bei einer großen Anzahl an Principals aber länger.
Jetzt muss wieder dafür gesorgt werden, dass die Datenbank auf alle KDCs repliziert wird!

Nach der Replikation kann der alte Schlüssel entfernt werden mit:

root@kerberos01:~#  kdb5_util purge_mkeys
Sind Sie sicher, dass alle nicht verwendeten Hauptschlüssel, die für Principal »K/M@EXAMPLE.NET« gespeichert sind, vollständig entfernt werden sollen?
(Geben Sie als Bestätigung »yes« ein)? yes
Ok, die nicht verwendeten Hauptschlüssel von »K/M@EXAMPLE.NET« werden vollständig entfernt …
Der/Die folgende(n) Hauptschlüssel werden/wird von K/M@EXAMPLE.NET vollständig entfernt:
KVNO: 1
1 Schlüssel vollständig entfernt

Beim Auflisten wird nur noch der neue Schlüssel angezeigt:

root@kerberos01:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.NET
KVNO: 2, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Fr Feb 07 17:12:11 CET 2025 *

Liegt die Kerberos-Datenbank im LDAP, wird die Replikation automatisch durchgeführt. Nur wenn standalone Kerberos-Server mit einer lokalen Datenbank verwendet werden, muss die Replikation von Hand angestoßen werden.

Für mein Samba 4 Buchprojekt, für die englische Ausgabe, habe ich ja auf Amazons KDP-Programm gesetzt. Neben dem Paperback wollte ich auf jeden Fall ein ebook anbieten. Das ging natürlich nur als .kdp also im Kindle-Format. Aber wie bekomme ich aus meinem PDF, das aus meinen LaTeX-Quellen erstellt wurde, ein .epub? Denn ein PDF lässt sich zwar übernehmen, sieht aber gruselig aus. Also erst einmal ein epub erstellen. Hört sich einfach an, ist aber etwas komplizierter. Denn meine Formatierungen mit den Kästen und vor allen Dingen die ALT-Texte zu den Bildern sollten erhalten bleiben. Leider gab es im Netz dazu nirgendwo ein passende Lösung. Also dachte ich, frage mal chatGPT, und nach drei Tagen (musste immer ans Maximum meiner Anfragen gehen) stand dann die Lösung, die ich hier gerne mal präsentieren möchte. Es reicht ja, wenn es einmal erstellt wird :-). Ich brauchte ein Skript, das die Umstellung vornimmt, das hat mit chatGPT auch schnell erstellt. Aber dann fehlten alle Formatierungen. Dafür gibt es jetzt eine .css Datei, die dafür sorgt, dass alles auch hübsch ist. Fehlten immer noch meine ALT-Texte. Die können mittels pandoc und einem LUA-Filter erstellt werden. Dieser Filter sucht dann nach den ALT-Texten im LaTeX-Dokument und und erzeugt den ALT-Text im ebook. Wenn kein ALT-Text vorhanden ist, wird der „caption“ Text aus dem LaTeX-Dokument genutzt. Im Skript wird der Filter direkt eingebunden, muss also beim Erstellen des epub nicht mit angegeben werden. Alle benötigten Dateien finden Sie hier. Das Kommando für die Einrichtung lautet dann:

latex2kpf.sh buch.tex –title „Buchtitel“ –author „Name des Autors“ –cover <cover.jpg> –css kindle.css –math mathml

Im Anschluss finden Sie dann, im Ordner „build-kindle“, das Buch als epub. Das kann dann direkt im KDP hochgeladen werden. Das Kindle-Format wird dann daraus automatisch erstellt und alle Formatierungen bleiben erhalten.
Nachdem ich alles hochgeladen habe, kamen dann 72 Stunden banges warten, ob auch alle gut gegangen ist. Solange dauert die Prüfung, ob das Buch auch allen Regeln von Amazon entspricht. Passt! Das Buch ist jetzt auf Amazon (englisch) und (deutsch) verfügbar.

I have planned various new seminars for the fall. All seminars listed will take place online and in English. I offer the following seminars:
Linux Basics
OpenLDAP Administration
Samba Administration
The exact contents, prior knowledge, and prerequisites are described in the corresponding announcements.
All seminars listed here will take place online and in English.
Do you have any further questions? Just get in touch with me.

Alle guten Dinge sind drei, deshalb hier der dritte Artikel über die Einrichtung meiner Opencloud-Instanz auf einem Raspberry. Bis zu diesem Zeitpunkt läuft der Dienst mit allen benötigten Containern. Die Festplatte ist eingebunden und kann genutzt werden. Aber was passiert, wenn der Rechner neue gestartet wird? Genau, der Dienst startet noch nicht automatisch. Um den Dienst, mit allen benötigten Container bei jedem Start zu aktivieren und beim Herunterfahren zu deaktivieren, habe ich ein kleines Systemd-Skript geschrieben. Das Skript /etc/systemd/system/owncloud.service

[Unit]
Description=Firewall
After=network.target

[Service]
Type=oneshot
ExecStart=/home/stka/opencloud-start.bash
RemainAfterExit=true
ExecStop=/home/stka/opencloud-stop.bash
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Beim Start wird das skript /home/stka/opencloud-start.bash ausgeführt:

#!/bin/bash
OC_PATH=/opt/opencloud/deployments/examples/opencloud_full
OC_CMD=’docker compose up -d‘
cd $OC_PATH
$OC_CMD

Und beim Stoppen des Dienstes das Skript /home/stka/opencloud-stop.bash:

#!/bin/bash
OC_PATH=/opt/opencloud/deployments/examples/opencloud_full
OC_CMD=’docker compose down‘
cd $OC_PATH
$OC_CMD

Damit ist die Einrichtung von Opencloud soweit abgeschlossen.

Jetzt fehlt dann nur noch eine Erweiterung der Firewall. Leider konnte ich in den Containern nicht so ohne weiteres ermitteln, wo denn die iptables-Regeln abgelegt sind. Aus dem Grund habe ich ein Skript geschrieben, dass die bestehenden Regeln erweitert. Wichtig war es mir, dass ein Angriff auf den ssh-Port dazu führt, dass die IP-Adresse des Angreifers gesperrt wird und das Portscanns erkannt und geblockt werden. Hier das Skript:

# Verwerfe SYN-Pakete
$IPT -A INPUT -p tcp ! –syn -m state –state NEW -j DROP
$IPT -I INPUT -m conntrack –ctstate NEW -p tcp ! –syn -j DROP

# Verwerfe fragmentierte Pakete
$IPT -A INPUT -f -j DROP

# Verwerfe XMAS-Pakete
$IPT -A INPUT -p tcp –tcp-flags ALL ALL -j DROP

# Verwerfe alle NULL-Pakete
$IPT -A INPUT -p tcp –tcp-flags ALL NONE -j DROP

# Verwerfe Spoof-Pakete
for SPOOF in 224.0.0.0/4 240.0.0.0/5 240.0.0.0/5 0.0.0.0/8 239.255.255.0/24 255.255.255.255; do
$IPT -A INPUT -d ${SPOOF} -j DROP
done
for SPOOF in 10.0.0.0/8 169.254.0.0/16 172.16.0.0/12 127.0.0.0/8 192.168.0.0/24 224.0.0.0/4 240.0.0.0/5 0.0.0.0/8 ; do
$IPT -A INPUT -s ${SPOOF} -j DROP
done

# Einfacher Schutz vor Spoofing
$IPT -I INPUT -m conntrack –ctstate NEW,INVALID -p tcp –tcp-flags SYN,ACK SYN,ACK -j REJECT –reject-with tcp-reset

# Einfacher DDoS-Schutz
$IPT -A INPUT -p tcp -m tcp –tcp-flags SYN,ACK,FIN,RST RST -m limit –limit 1/s -j ACCEPT

# Verwerfe alle ungültigen Pakete
$IPT -A INPUT -m state –state INVALID -j DROP
$IPT -A FORWARD -m state –state INVALID -j DROP
$IPT -A OUTPUT -m state –state INVALID -j DROP

# Einfacher Schutz vor Port-Scannern
# Angreifende IP wird für 24 Stunden gesperrt
# (3600 x 24 = 86400 Sekunden)
$IPT -A INPUT -m recent –name portscan –rcheck –seconds 86400 -j DROP
$IPT -A FORWARD -m recent –name portscan –rcheck –seconds 86400 -j DROP

# Freigeben der IP nach 24 Stunden
$IPT -A INPUT -m recent –name portscan –remove
$IPT -A FORWARD -m recent –name portscan –remove

# Erlaube ICMP
$IPT -A INPUT -p icmp –icmp-type 3 -j ACCEPT
$IPT -A INPUT -p icmp –icmp-type 8 -j ACCEPT
$IPT -A INPUT -p icmp –icmp-type 8 -j LOG –log-level debug –log-prefix „PING IP_TABLES:“
$IPT -A INPUT -p icmp –icmp-type 11 -j ACCEPT
$IPT -A INPUT -p icmp –icmp-type 12 -j ACCEPT

# Schutz vor Brute-Force-SSH-Angriffen
$IPT -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m recent –set –name SSH –rsource
$IPT -A INPUT -p tcp -m tcp –dport 22 -m recent –rcheck –seconds 30 –hitcount 4 –rttl –name SSH –rsource -j REJECT –reject-with tcp-reset
$IPT -A INPUT -p tcp -m tcp –dport 22 -m recent –rcheck –seconds 30 –hitcount 3 –rttl –name SSH –rsource -j LOG –log-prefix „SSH brute force “
$IPT -A INPUT -p tcp -m tcp –dport 22 -m recent –update –seconds 30 –hitcount 3 –rttl –name SSH –rsource -j REJECT –reject-with tcp-reset
$IPT -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m recent –update –seconds 600 –hitcount 3 –rttl –name SSH -j DROP

# Schutz vor Brute-Force-SSH-Angriffen auf port 2222
$IPT -A INPUT -p tcp -m tcp –dport 2222 -m state –state NEW -m recent –set –name SSH –rsource
$IPT -A INPUT -p tcp -m tcp –dport 2222 -m recent –rcheck –seconds 30 –hitcount 4 –rttl –name SSH –rsource -j REJECT –reject-with tcp-reset
$IPT -A INPUT -p tcp -m tcp –dport 2222 -m recent –rcheck –seconds 30 –hitcount 3 –rttl –name SSH –rsource -j LOG –log-prefix „SSH brute force “
$IPT -A INPUT -p tcp -m tcp –dport 2222 -m recent –update –seconds 30 –hitcount 3 –rttl –name SSH –rsource -j REJECT –reject-with tcp-reset
$IPT -A INPUT -p tcp -m tcp –dport 2222 -m state –state NEW -m recent –update –seconds 600 –hitcount 3 –rttl –name SSH -j DROP

# Erlaube SSH
$IPT -A INPUT -p tcp -m tcp –dport 2222 -j ACCEPT

# Erlaube Ping
$IPT -A OUTPUT -p icmp -m icmp –icmp-type 8 -j ACCEPT

# Erlaube https
$IPT -A INPUT -p tcp -m tcp –dport 443 -j ACCEPT

Auch für die Erweiterung der Firewall habe ich ein passendes Systemd-Skript geschrieben:

[Unit]
Description=Firewall
After=network.target
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/home/stka/firewall-start.bash
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Ein Brut-Force Angriff erscheint jetzt mit der folgenden Meldung im Log:

SSH brute force IN=wlan0 OUT= MAC=d8:3a:dd:24:da:8d:d0:6e:de:c3:ec:30:08:00 SRC=45.135.232.177 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=37812 DF PROTO=TCP SPT=53954 DPT=2222 WINDOW=42340 RES=0x00 SYN URGP=0

Die IP-Adresse wird dann gesperrt. Aber keine Angst, da kommen gleich die nächsten.
Gerne hätte ich noch mit xtables-addons-common eine Erweiterung für iptables geladen, die auf Grund von Listen ganze Länder blockiert, aber leider bekomme ich das benötigte Kernelmodul auf meinem Raspberry nicht zum Laufen. Aber der Anfang ist gemacht.

Alle Skripte können hier runtergeladen werden.

Im zweiten Teil will ich jetzt meine Installation der Opencloud Anwendung beschreiben. Auf der Webseite zu opencloud www.opencloud.eu werden verschiedene Möglichkeiten zur Installation beschrieben. Siehe da! Es gibt auch eine Anleitung für die Installation auf dem Raspberry.  Also alles mit docker compose installieren. Ich habe schon ein paar mal einen Docker Container installiert, aber in so einem Umfang? Nö! Aber den Mutigen gehört die Welt, also frisch ans Werk.

Das Einrichten des Routers habe ich ja schon im ersten Teil beschrieben. Alle Kommandos von Abschnitt 1.4 bis 1.8 habe ich, mit kleinen Änderungen bei der Einrichtung des Datenträgers, einfach aus der Anleitung kopiert. Hat alles geklappt. Ach so, den Installationspfad habe ich angepasst. Die Installation von Software im $HOME eines Benutzers? Och nöööö muss nicht. Meine Installation liegt jetzt in /opt/opencloud, auch meine ssd für die Daten habe ich dort gemountet.

Der Zugriff von Außen ist in der Anleitung ganz gut beschrieben, nur fehlt dort ein wichtiger Teil, die Einrichtung der Netzwerkzugriffe für:

1. COLLABORA_DOMAIN=
2. WOPISERVER_DOMAIN=
3. TRAEFIK_DOMAIN=
4. OC_DOMAIN=

Es gibt auf der Webseite noch zwei weiter Anleitungen, einmal eine für die Installation direkt auf dem Blech und dann noch drei verschiedene Docker Varianten. Leider konnte ich in keiner eine genaue Beschreibung zur Einrichtung von DNS finden. An vielen Stellen, auch an bei anderen Quellen im Internet, steht immer das die Domänen auf 127.0.0.1 in der /etc/hosts eingetragen werden können. Das hat bei mir nicht geklappt. Also schnell in mein Konto bei no-ip.com angemeldet und die entsprechende cname-records erstellt. Meine Records bei no-ip, in die Konfigurationsdatei .env eingetragen, sehen jetzt wie folgt aus:

TRAEFIK_DOMAIN=traefikstka.example.net
OC_DOMAIN=stka.example.net
COLLABORA_DOMAIN=collaborastka.example.net
WOPISERVER_DOMAIN=wopiserverstka.example.net

Wobei der Eintrag für OC_DOMAIN mein A-record ist und alle anderen eine cname auf stka.example.net. So eingetragen, werden auch keine weiteren Einträge in der /etc/hosts benötigt.

Dann endlich war es soweit, die Anmeldung funktionierte und auch der Aufruf der Anwendungen aus Collabora funktioniert, aber der Browser hat immer noch über das Zertifikate gemeckert, denn noch ist das selbst signiert. Fehlte also noch Let’s encrypt für das Zertifikat. Jetzt hatte ich schon auf der Webseite von Let’s encrypt geschaut, wie man dort Zertifikate erstellt und einträgt, aber schau mal einer an, das macht Opencloud alles für mich. Erst ein Test ob alles klappt, dafür wird in der Datei .env die folgenden Zeile angepasst:

TRAEFIK_ACME_CASERVER=https://acme-staging-v02.api.letsencrypt.org/directory

So wird ein Testzertifikat erstellt. Was dort passiert wird im Kommentar zum Parameter genau beschrieben. Docker compose neu gestartet, mit dem Browser zugegriffen und sieh da, das Testzertifikat wurde genau so angezeigt wie im Kommentar beschrieben.

Dann docker compose wieder stoppen und die nicht mehr benötigten Zertifikate mit dem Kommando

docker volume rm opencloud_full_certs

löschen. Die vorher eingetragene Zeile in der Datei .env auskommentieren und docker compose wieder starten. Trommelwirbel, Zugriff mit dem Browser und super jetzt wird die Domäne mit einem gültigen Zertifikat im Browser angezeigt.

Zum Abschluss hier mal alle aktiven Zeilen meiner Konfiguration aus der Datei .env:

LOG_DRIVER=
TRAEFIK_DASHBOARD=
TRAEFIK_DOMAIN=traefikstka.example.net
TRAEFIK_BASIC_AUTH_USERS=sperduper:$$2y$$05$$u3X…
TRAEFIK_ACME_MAIL=stefan@dummy.de
OPENCLOUD=:opencloud.yml
OC_DOCKER_IMAGE=opencloudeu/opencloud-rolling
OC_DOCKER_TAG=
OC_DOMAIN=stka.example.net
ADMIN_PASSWORD=Uecs…
DEMO_USERS=
LOG_LEVEL=
OC_CONFIG_DIR=/opt/opencloud/config
OC_DATA_DIR=/opt/datadisk
DECOMPOSEDS3_ENDPOINT=
DECOMPOSEDS3_REGION=
DECOMPOSEDS3_ACCESS_KEY=
DECOMPOSEDS3_SECRET_KEY=
DECOMPOSEDS3_BUCKET=
MINIO_DOMAIN=
START_ADDITIONAL_SERVICES=“notifications“
EXTENSIONS=:web_extensions/extensions.yml
UNZIP=:web_extensions/unzip.yml
DRAWIO=:web_extensions/drawio.yml
JSONVIEWER=:web_extensions/jsonviewer.yml
PROGRESSBARS=:web_extensions/progressbars.yml
EXTERNALSITES=:web_extensions/externalsites.yml
COMPANION_IMAGE=
COMPANION_DOMAIN=
COMPANION_ONEDRIVE_KEY=
COMPANION_ONEDRIVE_SECRET=
TIKA=:tika.yml
TIKA_IMAGE=
COLLABORA=:collabora.yml
COLLABORA_DOMAIN=collaborastka.example.net
WOPISERVER_DOMAIN=wopiserverstka.example.net
COLLABORA_ADMIN_USER=superduper
COLLABORA_ADMIN_PASSWORD=NnJ…
COLLABORA_SSL_ENABLE=false
COLLABORA_SSL_VERIFICATION=false
CLAMAV_DOCKER_TAG=
INBUCKET_DOMAIN=
COMPOSE_PATH_SEPARATOR=:
LDAP_ADMIN_PASSWORD=
LDAP_MANAGER_DOMAIN=
IDP_DEFAULT_SIGNIN_PAGE_TEXT=
KEYCLOAK_DOMAIN=
KEYCLOAK_REALM=
KEYCLOAK_ADMIN_USER=
KEYCLOAK_ADMIN_PASSWORD=
COMPOSE_FILE=docker-compose.yml${OPENCLOUD:-}${TIKA:-….

Ein kleiner Wermutstropfen auch hier: Nachdem alle soweit läuft, wollte ich gerne den amavis Virenscanner noch einbinden, aber leider gibt es dafür keinen Docker container.

Im nächsten Teil werde ich dann noch zeigen, wie ich die iptables Firewall erweitert habe und wie ich dafür sorge, dass sowohl Opencloud als auch die Firewall automatisch beim Systemstart gestartet werden.

Dieses ist der erste Artikel einer Reihe in der ich über die Erfahrungen und die Installation einer Opencloud-Instanz auf einem Raspberry berichten werde. Angefangen von der Installation des Pi bis zur Konfiguration der Opencloud-Instanz.

Warum Opencloud, es gibt doch schon so viele andere Cloud-Lösungen? Ich habe mich für Opencloud entschieden, weil die gesamte Entwicklung in Deutschland stattfindet und die Software auf dem aktuellen Stand ist. Auch ist die Installation recht einfach, alle Funktionen werden über Docker compose bereitgestellt. Außerdem wird mit Opencloud gleich collaborate als browserbasierte Officelösung eingerichtet. Mehr zu Opencloud unter www.opencloud.eu.

Warum überhaupt eine eigene Lösung hier zu Hause? Alles was es sonst so gibt, wird entweder irgendwo in den USA gespeichert (wer will das noch) oder kostet mehr als das was ich für den Raspberry, die ssd und alles was drumherum benötigt wird, bezahlt habe. Klar, um die Backups muss ich mich selber kümmern, aber das geht dann auch später automatisch.

Im ersten Artikel geht es erst einmal um die Grundeinrichtung des Raspberry.

Als Grundlage dient ein Raspberry 4 mit 8 Gb RAM und einer 32GB SD-Karte für das Betriebssystem. Für die Daten habe ich eine 4TB ssd gekauft und über den USB-3 Port mit dem Raspberry verbunden. Da sollte für eine Heimanwendung ausreichen.

Nach der Installation von Raspbian (Debian 12) geht es erst einmal um die Absicherung der Zugriffe. Dazu wird der sshd angepasst und der Google-Authenticator installiert um später eine zwei Faktor Authentifizierung durchführen zu können. Eine Anmeldung per einfachem Passwort soll später nicht mehr möglich sein.

Installation des Google-Authenticators

sudo apt install libpam-google-authenticator

Anschließend muss die Datei /etc/pam.d/ssh wie folgt anpassen:

port 2222
# @include common-auth
auth required pam_google_authenticator.so
AuthenticationMethods publickey,keyAuthenticationboard-interactive
KbdInteractiveAuthentication yes

Die include-Zeile muss auskommentiert werden, da sonst der Inhalt der Datei common-auth alles übersteuert auch die gerade gesetzt Verwendung des Google-Authenticators.

Anschließend wird der sssd neu gestartet, um die Änderungen wirksam werden zu lassen. Rufen Sie jetzt auf dem Raspberry als Benutzer das Programm google-authenticator auf, das Programm leitet Sie durch die Einrichtung. Scannen Sie den QR-Code mit einer entsprechenden App auf Ihrem Smartphone um den zweiten Faktor generieren zu können.

Damit der Raspberry auch von Außen erreichbar ist, benötigen Sie einen DNS A-Record der dynamisch aktualisiert wird. Ich habe dafür ein Konto bei no-ip.com eingerichtet. Hier können Sie dann später auch die cname-Records für Opencloud einrichten.

Zusätzlich müssen Sie auf Ihrem Internet-Router eine Portweiterleitung auf den Port 2222 (dem geänderten ssh-Port) und schon mal auf Port 443 einrichten, sodass später die Zugriffe aus dem Internet auf Ihren Raspberry weitergeleitet werden.

Wenn Sie alle diese Einrichtungen vorgenommen haben, sollte ein Zugriff über den dynamischen A-Record möglich sein. Wenn die Installation und Konfiguration von Opencloud abgeschlossen ist, wird später noch ein iptables-Skript hinzukommen, das dann noch ssh-Angriffe und Portscanns blocken soll. Da aber bei der Installation von Opencloud bereits ein Firewallskript, basierend auf iptables, eingerichtet wird, hänge ich mein Skript später nur an die bestehende Konfiguration an.
Damit wäre dann der erste Teil, die Vorbereitung des Raspberry, abgeschlossen.

Im zweiten Teil geht es dann um die Installation und Konfiguration von Opencloud inklusive der Einrichtung der DNS-Records bei no-ip.

Heute habe ich den ersten Teil der neuen Ansible-Rollen für die Erstellung einer multi Providerumgebung in mein git-Repository hochgeladen. Die Rollen stehen nicht nur für die Besitzer des Ansible-Buchs zur Verfügung, sonder können auch so genutzt werden. Die Rollen sind Bestandteil der Downloads zum Buch und können komplett mit dem Kommando „git clone https://github.com/stkania/openldap-in-der-praxis“ heruntergeladen werden.

Im zweiten Teil wird es dann Rollen für die Einrichtung von Kerberos und der Einbindung in OpenLDAP geben.

Bei OpenLDAP werden sich zum Anfang des Jahres 2025 die Versionen wie folgt ändern:

• Die Version 2.5 wird auslaufen, bekommt aber noch bis 15.01.2027 Sicherheitsupdates. Nach diesem Datum bekommt die Version den Status „historical“ und erhält dann keine Updates oder Sicherheitspatches mehr.
• Die Version 2.6 wird zur neuen LTS-Version werden.
• Im Herbst 2024 wird die Version 2.7 erscheinen, bei dieser Version handelt es sich um die neue „feature Release“ Version. Also mit allen Neuerungen.

Die Umstellung vom 2.5 auf 2.6 kann mit der laufenden Konfiguration stattfinden. Nur beim Einsatz des Loadbalancers muss die Konfiguration angepasst werden.

Die Replikation zwischen Version 2.5 und 2.6 läuft ohne Probleme, so kann ein Server nach dem anderen Umgestellt werden.