Posts by m_ueberall

    Linktip: "knock: A port-knocking implementation"

    Quote

    This is a port-knocking server/client. Port-knocking is a method where a server can sniff one of its interfaces for a special "knock" sequence of port-hits. When detected, it will run a specified event bound to that port knock sequence. These port-hits need not be on open ports, since we use libpcap to sniff the raw interface traffic.

    Das Konzept wäre dadurch keinesfalls hinfällig (und DKIM und ARC sind nicht das Gleiche). Sofern man sauber definiert, welche IP-Adressen/Domänen als Einheit bzw "zur/m Rspamd-Instanz/-Cluster gehörend" anzusehen sind, erfolgt auch keine unnötige ARC-Signierung. Funktioniert hier dank "Whitelists" mit internen Statusmeldungen von Cron, Monit, Tenshi und Co. einwandfrei.

    Und die Änderung, welche irgendwann in einem Bug-Report kurz diskutiert wurde, wenn ich mich recht erinnere, erfolgte schlichtweg aus dem Grund, weil das ursprüngliche Verhalten eben nicht RFC-konform war.

    Einige Definitionen in den Konfigurationsdateien haben sich in der Vergangenheit tatsächlich deutlich geändert, so dass es sich empfiehlt, automatische Updates zu deaktivieren und vor einem Wechsel ein zeitversetztes, explizites Review durchzuführen (und neben der Mailingliste unbedingt aktuelle Tickets im Auge zu behalten).

    Mir ist aufgefallen, dass Rspamd kürzlich (Version 2.4) die ARC-Message-Signature nicht mehr bei ausgehenden Nachrichten einfügt. Stattdessen erfolgt das Hinzufügen bei allen eingehenden Nachrichten.

    Das liegt an der korrekten Umsetzung von RFC8617, vergleiche Abschnitt 5 oder auch hier auf Folie 9 (ARC = Authenticated Received Chain).

    Quote

    ARC-enabled Internet Mail Handlers generally act as both ARC Validators (when receiving messages) and ARC Sealers (when sending messages onward, not originated locally).

    Hey schön, jetzt habe ich einen jitsi-Server. Nachdem ich von [netcup] Felix sein "Debian 10 jitsi"-Image repariert habe und auch noch etwas an der Sicherheit geschraubt habe.


    Bekomme ich 'nen Keks?

    Zur Belohnung sollte es Dir (und… hust'… anderen) in absehbarer Zeit erlaubt sein, NAPTR-DNS-Einträge im CCP vorzunehmen!

    Code
    1. nginx[1502]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

    Bin verwirrt.

    Naja… netstat -tulpen | grep :443 wird sofort zeigen, welcher Dienst die Adresse bzw. den Port in Beschlag hat, wenn es nicht nginx ist.

    => Wie löst ihr das Problem? Gibts irgendeine no-brainer Methode die ich bisher übersehen habe?

    Zweitrechner allokieren (kann auch stundenweise gemietet werden), dort ZFS aufsetzen, Inhalt des Erstrechners dorthin übertragen, nebeneinander laufen lassen und Funktionalität verifizieren. Im Erfolgsfall: Vollbackup des Erstrechners erstellen, Übertragung auf den Zweitrechner wiederholen/aktualisieren, dann Ergebnis (inkl. Dateisystem) zurückübertragen auf den Erstrechner[*]. Zweitrechner abkündigen.

    Wenn es nicht allzu eilig ist, würde ich Ende April das Erscheinen von Ubuntu 20.04 abwarten (plus wenige Wochen "Sicherheitsabstand"; bis dahin sollten etwaige Fehler nach "Massentest" korrigiert sein). Wenn es um eine andere Distribution geht, spielt der Anfangszeitpunkt der obengenannten Aktion eine geringere Rolle.


    [*] Das muss nicht via SCP-Snapshot geschehen, es genügt, die virtuelle Platte des Erstrechners mit einem ZFS-Pool zu versehen (über eine Minimalinstallation, welche auch den Bootsektor usw. entsprechend präpariert), dann kann man den gesamten Inhalt zwischen beiden Pools via zfs send/receive synchronisieren. Solange genügend Platz vorhanden ist, spielt es keine Rolle, ob der Zweitrechner von der Ausstattung her ein "Klon" des Erstrechners ist oder nicht. ACHTUNG: ZFS-Dateisystem (Pool!) niemals über 85% füllen oder sonst… hier nimmt man vorher eine "Sicherheitsreservierung" vor, damit das nicht passieren kann.

    Weil es auch dieses Forum betrifft: Falls der Blutdruck heute noch nicht hoch genug ist, hilft vielleicht ein Blick in die Drucksache 70-20 des Bundesrates, für welche ursprünglich heute ein Tagesordnungspunkt vorgesehen war?

    […] Durch eine Änderung des Netzwerkdurchsetzungsgesetzes und Einführung einer Verpflichtung der Anbieter sozialer Netzwerke und der Anbieter von Spieleplattformen, von den Nutzern bei der Registrierung Namen und Anschrift sowie deren Geburtsdatum zu erheben, wird die Identifizierbarkeit von Täterinnen und Tätern erleichtert und so eine Strafverfolgung vereinfacht. […]

    Wird sicherlich zeitnah durch ein Sozialkredit-System ergänzt, damit man Registrierungen gleich im Vorfeld abbügeln kann…

    Wenn das System regelmäßig gepatcht wird – sei es nun (semi-)automatisch oder händisch –, dann haben sich in den zwei Monaten bestimmt Änderungen ergeben. Auch ohne Änderungen kann man je nach Anzahl und Umfang der installierten Programme nicht ausschließen, dass man früher oder später einmal Probleme haben wird.

    Die genannten Fehlermeldungen sind auch unterschiedlich – ich vermute aus der Beschreibung einmal einen vollständigen Ausfall der IPv4-Konnektivität. Clamav bekommt keine DNS-Daten mehr, weil der DNS-Server nicht kontaktiert werden kann; aber nfs arbeitet eigentlich ohne dynamische (d.h. wiederholte) Adressauflösung, und dort steht ja, dass eine IP nicht erreichbar war. (Das erscheint mir ggf. ein genauerer Hinweis auf mögliche Ursachen.)

    Ich würde anraten, Dienste nach Möglichkeit sowohl über IPv4 als auch IPv6 verfügbar zu machen/zu nutzen. Stimmt obengenannte Hypothese und wird die Netzwerkschnittstelle durch einen Reboot "wiederbelebt", hilft das Rettungssystem wenig bei Eingrenzung der Fehlerursache, sofern der Fehler nicht so häufig auftritt, dass es sich lohnt, das Rettungssystem beispielsweise einmal über das Wochenende durchlaufen zu lassen (sofern auf den Server in dieser Zeit verzichtet werden kann).

    Wie unangenehm... ich versuche gerade ein Git Repo auf einem Samba Mount anzulegen, aber irgendwie will das ganze nicht so wie ich will...

    Code
    1. user@whodeb:/run/user/1000/gvfs/smb-share:server=meinnas.lan,share=meinshare/html/webradio$ git init
    2. error: chmod auf /run/user/1000/gvfs/smb-share:server=meinnas.lan,share=meinshare/html/webradio/.git/config.lock fehlgeschlagen: Vorgang wird nicht unterstützt
    3. fatal: Konnte 'core.filemode' nicht zu 'false' setzen.

    Wenn sich da nicht viel geändert hat seit diesem Posting und core.filemode einfach nicht deaktiviert werden kann, ist da wohl nichts zu machen.

    Code
    1. gunzip rootfs.cpio.gz
    2. mkdir out
    3. cd out
    4. cpio -id < ../rootfs.cpio
    5. find . | cpio -o -H newc > ../rootfs.cpio
    6. gzip rootfs.cpio

    Das Ergebnis ist ein Kernel-Panic mit zuvor genanntem Fehler.

    Das Originalpaket enthält "trailing zero bytes", um die Gesamtgröße auf 4MB zu bringen. Idee: Zuerst das Originalarchiv dekomprimieren und danach erneut komprimieren (nur gzip -d/gzip -1, keine cpio-"Modifikation"). Das entfernt die "Nullbytes". Tut es dann noch? Zusätzlich: Nachschauen, ob da wirklich nur "Nullbytes" stehen.

    Wenn das modifizierte Archiv nicht mehr bootet, könnte man ausschließlich die "Nullbytes" entfernen ohne umzupacken – vorher würde ich aber versuchen, zunächst das eigene gepackte Archiv auf 4MB mit der entsprechenden Anzahl von "Nullbytes" aufzufüllen.

    Dachte ich auch, aber der Kernel (4.1.17) bootet nur mit cpio in gz. Anderweitig wirft er not syncing: VFS: Unable to mount root fs on unknown-block(0,0) und ist tot.

    Das kann mehrere Ursachen haben (vgl. https://unix.stackexchange.com/q/414655/238272). Wenn man jetzt noch wüsste, welche Distribution das ist (über die letzten drei Seiten dieses Themas nicht eruierbar) und mit welchen Befehlen/warum genau das initramfs neu gebaut werden soll…

    PS: Wenn gzip wirklich "hängt" (eher unnormal), würde ich das einmal auf einer anderen/stärkeren Maschine ausführen. Alternativ, wenn genügend Platz da ist, wird man aber auch nicht gezwungen, das initramfs zu komprimieren.