Archiv der Kategorie: Linux

Sehr günstige SATA-Controller: Vorsicht ist geboten

Wie der KFZ-Mechaniker es sich leisten kann, ein altes verrumpeltes Auto zu fahren, so leiste ich mir den Betrieb von billiger oder alter Hardware zur Datenspeicherung im privaten Umfeld. Und wenn man von billigen SATA-Controllern anfängt, kommt man unweigerlich zum Marvell 88SE9215 und Konsorten.

Für normale Anwender, oder diejenigen, die nicht stundenlang zur Rücksicherung ihrer Daten meditieren wollen, sei hier Vorsicht geboten: Diese sehr günstigen SATA-Controller können fehlerbehaftet sein und man bekommt gerade bei den sehr günstigen Herstellern der Karte selten bis keine Firmware-Updates, da die Referenzupdates meistens nur an die Kartenhersteller direkt vergeben werden.

Mein konkretes Beispiel: Der Marvell 88SE9215 – zweimal als 4-Port Karte bestellt, eine sofort kaputt, eine paar Jahre später. Dateisystem korrupt, Backup einspielen. Aua. Wenn man das paarmal gemacht hat, hat man keine Lust mehr. Formatieren, rücksichern, fortfahren. Und beim nächsten mal vielleicht auf eine andere Karte mit anderem Chip setzen. Meine ASMedia ASM1064 basierte Karte ist nun ein Jahr problemlos im Betrieb. Firmware gibts da gleichermaßen schlecht, aber dafür funktioniert sie.

qcow2 Overlay zur Read-Only Datenanalyse großer Speichermedien

Arbeitet man sich in die Materie der Datenanalyse und -wiederherstellung unter Linux ein, kommt man auch automatisch mit den grundlegenden Prinzipien dieser in Kontakt. Ein Prinzip ist: Bei der Analyse und Wiederherstellung sind die Ursprungsdaten nicht zu beschreiben. Entsprechend werden Geräte, Partitionen und Dateisysteme stets nur als Read-Only gemounted oder nur auf 1-zu-1 Abzügen gearbeitet.

Diese Abzüge haben aber einen Haken: Analysiere ich zum Beispiel ein 12 TB Dateisystem, welches partiell überschrieben wurde, so bräuchte ich einen vergleichsweise großen Zwischenspeicher (oder vergleichbares RAID-Array) um einen komplette Abzug zu speichern. Würde ich den Speicher in eine große 12-24 TB externe Festplatte laden, wäre das zwar auch möglich, würde aber ewig dauern.

qcow2 Overlay zur Read-Only Datenanalyse großer Speichermedien weiterlesen

Mit iptables-persistent/netfilter-persistent dafür sorgen, dass nur zusätzliche Regeln angewendet werden

Unter aktuellen Linux-Distributionen kommt meist ufw (uncomplicated firewall) oder iptables-persistent zum Einsatz um Firewall-Regeln auch ernsthaft zu persistieren. iptables-persistent ist dabei bei aktuellen Versionen nurmehr ein Alias für netfilter-persistent. netfilter-persistent ist wiederum ein einfaches sh-Skript, welches über den Systemd-Unit netfilter-persistent ausgelöst wird.

Im Normalfall wird mittels

netfilter-persistent save

der aktuelle Stand an Regeln gesichert und dann automatisch beim Neustart angewendet.

Nutzt man jedoch Docker oder ähnliche Tools, welche eigens generierte iptables- oder nftables-Regeln für ihre Funktion nutzen, so ist es nicht empfehlenswert, die gesamten Regeln zu sichern und zurückzuspielen, da dies zu unerwarteten Netzwerkproblemen mit Docker führen würde.

Mit iptables-persistent/netfilter-persistent dafür sorgen, dass nur zusätzliche Regeln angewendet werden weiterlesen

Passbolt: Benutzer kann nicht angelegt werden, Fehler 400

Seit einiger Zeit betreibe ich zwei Passbolt-Instanzen zur sicheren und dennoch praktischen Verwaltung von Passwörtern. Der offizielle Docker-Stack funktioniert ansich einwandfrei, jedoch muss mir in den Anfängen mit Passbolt ein Fehler unterlaufen sein, bei dem ich ein oder zwei Kommandos über die Kommandozeile mit dem Benutzer „root“ statt „www-data“ ausführte.

Das führte dann dazu, dass /var/lib/passbolt/tmp/ und darin enthaltene Dateien und Unterverzeichnisse mit falschen Berechtigungen angelegt wurden, sodass im normalen Betrieb der Benutzer „www-data“ keine Schreibrechte hatte.

Das äußerte sich auch gar nicht so offensichtlich: Beim anlegen eines neuen Benutzers beispielsweise erhielt ich unvermittelt einen Fehler 400, der nicht klar auf ein Berechtigungsproblem verwies.

Abhilfte schaffte letztlich im Docker-Container:

chown -R www-data:www-data /var/lib/passbolt/tmp/
chmod -R 775 $(find /var/lib/passbolt/tmp/ -type d)
chmod -R 664 $(find /var/lib/passbolt/tmp/ -type f)

Fehlerbehebung TPM 2.0: cannot load key – value is out of range or is not correct for the context

Spielt man mit TPM 2.0 im Zusammenhang mit OpenSSL, stößt man heutzutage unweigerlich auf folgenden Fehler:

error:4000000C:tpm2::cannot load key::-1:708 tpm:parameter(2):value is out of range or is not correct for the context

Das liegt daran, dass an mindestens einer Stelle der Zertifikatskette ein Schlüssel mit einer Länge von mehr als 2048 Bit genutzt wird. Meistens 4096 oder auch 3072. Das von der Trusted Computing Group festgelegte Minimum welches unterstützt werden muss, ist 2048. Sobald man TPM als „Provider“ für OpenSSL nutzt werden jegliche Verifizierungen über das TPM-Modul abgehandelt. Unterstützt dieses nur 2048 muss die gesamte Verifizierungskette auf diesen gemeinsamen Nenner gebracht werden.

Ein Test für das eigene TPM-Modul:

$ tpm2_testparms rsa4096
ERROR: Unsupported algorithm specification
ERROR: Unable to run tpm2_testparms
$ tpm2_testparms rsa3072
ERROR: Unsupported algorithm specification
ERROR: Unable to run tpm2_testparms
$  tpm2_testparms rsa2048
$

Im Beispiel: Nur 2048 Bit erlaubt.

Quellen:

https://stackoverflow.com/questions/78200082/tpm-2-0-based-tls-handshake-fails-against-rsa-4k-server-keys-out-of-range

https://community.infineon.com/t5/OPTIGA-TPM/Issue-with-TLS-Handshake-Using-TPM2-and-Level-3-CA-Chain/td-p/1054292#.

Vorsicht mit CRLF/LF in beim Generieren von Alpine-ISOs mittels mkimg.sh

Kürzlich habe ich mich mit Alpine Linux und der Erstellung eigener ISOs befasst. Dabei stieß ich aufgrund meines Workflows, oder vielmehr aufgrund meines Texteditors auf ein kurioses Problem: DOS vs. Unix Zeilenenden.

Nach Bearbeitung einer sh-Textdatei im GitLab Single-File Editor erschien mir beim ISO-Generator „mkimg.sh“ von Alpine folgende Fehlermeldung:

: not foundpts/mkimage.sh: aports/scripts/mkimg.profil.sh: line 2: profile_standard

Das Kommando zum generieren des ISO war dabei recht nornal und auch das Skript wurde bis auf eine minimale Änderung nicht angepasst.

/ # sh aports/scripts/mkimage.sh --tag alpha --outdir /media/sda1/iso --arch x86_64 --repository https://dl-cdn.alpinelinux.org/alpine/v3.22/main --repository https://dl-cdn.alpinelinux.o
rg/alpine/v3.22/community --profile profil

Es dauerte eine Weile, bis ich realisierte, dass der GitLab Single-File Editor die Zeilenenden oder Line-Endings von LF (Unix) auf CRLF (DOS) änderte und das zur fehlerhaften Ausführung meines sh-Skripts führte.

Mit der GitLab Web-IDE, einem beliebigen anderen Editor oder dem dos2unix-Tool ließ sich das Skript wieder zurückwandeln und funktionierte auf Anhieb einwandfrei.