-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Seite 5 von 46

FNIRSI GC-01 Upgrade: Akku, Zählrohr & Rad Pro Firmware installieren​

Bei meinen letzten Einkaufstouren auf AliExpress ist mir immer wieder ein FNIRSI GC-01 Nuclear Radiation Detector vorgeschlagen worden — ein Geigerzähler für knapp 30 €. Irgendwann lag das Ding im Einkaufswagen. Nach ein paar Spielereien ging mir aber schnell die Batterielaufzeit auf die Nerven — das Teil war im Grunde immer leer. Also aufschrauben und schauen, was man verbessern kann.

Was steckt drin?

PCB des FNIRSI GC-01: Spannungswandler, Multiplier und MCU sichtbar.

Das Gerät kam mit einem J613 Geiger-Müller-Zählrohr — Beta- und Gammastrahlung, Betriebsspannung 300–400 V, ganz brauchbar für niedrige Strahlungsniveaus. Die Platine ist simpel aufgebaut:

  1. Spannungswandler — baut vom USB-C-Anschluss oder 3,7-V-Akku ca. 130 V AC auf.
  2. 3-Stage Multiplier — vervielfacht die Spannung auf die nötigen ~400 V für das Zählrohr.
  3. CH32F103 MCU — je nach Revision auch ein ARM-Controller. Steuert Display, Piezo-Tongeber und Messlogik.

Dazu eine CR1220 Knopfzelle für Uhrzeit und Messwertespeicher und ein 3,7-V-Akku mit mageren 1.100 mAh (~4 Wh) — das erklärt die kurze Laufzeit. Nahe der MCU sind vier Löcher mit der Beschriftung JP1. Das ist ein ST-Link-Anschluss: von links nach rechts +3,3 V, SWDIO, SWCLK, GND.

ST-Link-Anschluss (JP1) auf dem FNIRSI GC-01 PCB mit angeloeteter Stiftleiste.

Aufgefallen ist mir auch, dass nicht jedes Teilchen ein hörbares Knacken auslöst. Die rote LED über dem Display blinkt bei jedem Impuls, aber der Piezo-Tongeber wird ausschließlich per Firmware angesteuert — und die Entwickler haben da anders entschieden.

Hardware-Upgrades: Akku und Zählrohr

Die CR1220 kam schon verbraucht an — ausgetauscht. Für den Akku hat sich ein passender Ersatz mit 2.200 mAh gefunden, der ins Gehäuse passt. Das sollte die Laufzeit fast verdoppeln.

FNIRSI GC-01 mit ausgetauschtem 2200-mAh-Akku.

Das J613 ist solide, aber ich hatte noch ein SBM-20-1 aus einem früheren Projekt in der Schublade. Das SBM-20-1 braucht 380–450 V, erfasst ebenfalls Beta- und Gammastrahlung und hat eine ähnliche Bauform. Wenn man die beiden Haltepfosten des J613 auslötet, passt die SBM-20-1 rein — ein Tropfen Heißkleber hält sie an Ort und Stelle.

FNIRSI GC-01 mit eingebautem SBM-20-1 Zaehlrohr anstelle des originalen J613.

Das SBM-20-1 ist bei geringer Strahlung nicht ganz so empfindlich wie das J613 und das Fenster für Betastrahlung ist etwas kleiner. Aber das Ding ist fast unkaputtbar — und wenn die Firmware das Zählrohr kennt, kann sie die Unterschiede per Kalibrierung ausgleichen. Sowohl auf der Röhre als auch auf dem PCB sind +/−-Markierungen — Polarität beim Einbau beachten.

Rad Pro — alternative Firmware

Die Stock-Firmware konnte wenig. Kein Datalogger, keine Hintergrundstrahlung filtern, kein Einfluss auf den Stromverbrauch. Bei der Recherche bin ich schnell auf Rad Pro gestoßen — eine Open-Source-Firmware für den GC-01 und andere Geigerzähler. Die kann alles, woran ich gedacht habe, und mehr.

Die Installationsanleitung ist überschaubar. Der Weg über das USB-Laufwerk hat bei mir nicht funktioniert — am Ende habe ich eine Stiftleiste auf JP1 gelötet und die Firmware über ST-Link geflasht. Fühlt sich zuverlässiger an.

Update auf Rad Pro 3.x

Mittlerweile ist Rad Pro bei Version 3.x angekommen — ein deutlicher Sprung. Installation wieder über ST-Link, wieder auf Anhieb sauber:

kernel@ErrorWork:~/radpro/fnirsi-gc01_ch32f103r8$ sudo ./install.sh
Available language codes: bg cs da de el en es fi fr hr hu it nl ...
Enter language code for Rad Pro installation: de
** Programming Started **
** Programming Finished **

Nach dem Flashen lief das Gerät sofort stabil. Alle Einstellungen wurden übernommen, nur den Zählrohrtyp musste ich neu setzen.

Die wichtigsten Neuerungen in 3.x gegenüber den 2.x-Versionen:

  • 27 Sprachen — Deutsch, Englisch und 25 weitere.
  • History bis zu einem Jahr — deutlich erweiterte Aufzeichnung.
  • Power-Management — Auto-Shutdown, überarbeitete Akku-Logik, kein versehentliches Einschalten bei USB-Power.
  • Messgenauigkeit — längere Mittelungsintervalle, größere Sensitivitätsspanne, verbesserte Dead-Time-Kompensation.
  • UI — Skalierung, sekundäre Einheiten, visuelle Alarm- und Warnzonen.
  • Weitere Geräte — u. a. GQ GMC-800.

Den vollständigen Changelog gibt es bei den Rad Pro Releases auf GitHub.


Ein paar Bilder vom Gerät mit der Rad Pro Firmware — die einzelnen Menüs und Anzeigen:

Fazit

Für 30 € plus ein paar Euro für Akku und Zählrohr hat man einen brauchbaren Geigerzähler mit Open-Source-Firmware, Datalogger, konfigurierbaren Alarmen und ordentlichem Power-Management. Dass beim GC-01 weiterhin der Weg über ST-Link nötig ist, bleibt unschön — liegt aber an der Hardware, nicht an Rad Pro.

Wer sich für Messtechnik und Physik-Hardware interessiert — im Quantis-USB-Beitrag geht es um einen Hardware-Quantenzufallsgenerator, ein ähnlich spannendes Bastelprojekt.

Viel Spaß beim Basteln — bei Fragen einfach melden.

Google Chrome: Hardwarebeschleunigung unter Linux (auch Flatpak) aktivieren

Wer Chrome unter Linux für Videocalls oder Microsoft Teams nutzt, kennt das Problem: hohe CPU-Auslastung, träge Performance, unscharfer Hintergrund fühlt sich an als wäre das System 15 Jahre alt. Ob Chrome aus den Paketquellen oder als Flatpak installiert ist, macht keinen Unterschied.

Die Ursache: Chrome nutzt unter Linux standardmäßig kaum GPU-Beschleunigung. Das lässt sich ändern.

Voraussetzung: VA-API prüfen

Zuerst sicherstellen, dass vainfo in der Konsole ohne Fehler läuft. Die meisten Distributionen bringen das out of the box mit. Falls nicht, gibt es im Arch Wiki gute Anleitungen dazu.

Aktuellen Status prüfen

In Chrome chrome://gpu aufrufen. Typischerweise sind Video Encode, Vulkan und WebGPU deaktiviert. Nach der Anpassung sieht es so aus:

  • Rasterization: Hardware accelerated on all pages (vorher: nur „Hardware accelerated“)
  • Video Encode: Hardware accelerated (vorher: Software only)
  • Vulkan: Enabled (vorher: Disabled)
  • WebGPU: Hardware accelerated (vorher: Disabled)

Konfiguration

Die Flags kommen in eine Konfigurationsdatei:

  • Chrome/Chromium aus Paketquellen: ~/.config/chromium-flags.conf
  • Chrome als Flatpak: ~/.var/app/com.google.Chrome/config/chrome-flags.conf
--ignore-gpu-blocklist
--enable-zero-copy
--enable-gpu-rasterization
--enable-gpu-compositing
--enable-smooth-scrolling
--canvas-oop-rasterization
--disable-direct-composition-bug-workarounds
--enable-unsafe-webgpu
--enable-features=VaapiVideoDecoder,VaapiVideoEncoder,VaapiIgnoreDriverChecks,Vulkan,DefaultANGLEVulkan,VulkanFromANGLE,UseOzonePlatform
--ozone-platform=x11

Chrome neu starten und chrome://gpu erneut prüfen.

Tipp für Flatpak-Nutzer: Flatseal macht die allgemeine Konfiguration von Flatpaks deutlich bequemer.

Fragen? Einfach melden.

Kernel-Error jetzt auch im Tor-Netz: meine .onion-Adresse

Kurzfassung: www.kernel-error.de ist jetzt zusätzlich als Tor Hidden Service erreichbar.
Meine .onion-Adresse: jjyvff6eh3kp7ydfkamm27cldhsee2cl6wzfa5lfjyrfyribgeaesgqd.onion

Damit gibt’s die Seite auch dann stabil und datensparsam, wenn Clearnet gerade zickt – oder wenn ihr grundsätzlich über Tor unterwegs seid.

Warum?

  • Datenschutz: weniger Metadaten, keine Exit-Node–Mitleser auf dem letzten Hop.
  • Integrität: über Onion-Routing direkt zu mir, kein „Dazwischenfunken“ per CDN/Proxy.
  • Erreichbarkeit: Mirror unabhängig vom Clearnet-DNS.

Wie verifizieren?

  • Auf https://www.kernel-error.de sende ich den Header Onion-Location, der auf die .onion-Version zeigt.
  • Zusätzlich gibt’s in meinem DNS einen TXT-Record der Form:
dig in txt www.kernel-error.de +short
"onion=jjyvff6eh3kp7ydfkamm27cldhsee2cl6wzfa5lfjyrfyribgeaesgqd.onion"
  • So lässt sich die Zugehörigkeit Clearnet ↔︎ Onion nachvollziehen.

Hinweise

  • Die Onion-Variante läuft ohne HTTPS – das ist bei .onion normal, Ende-zu-Ende-Schutz liefert Tor selbst.
  • Feature-Gleichstand: Seiten, Feeds und Sitemaps sind identisch erreichbar. Falls euch irgendwo ein Asset noch auf www.kernel-error.de verweist, kurzer Hinweis genügt.

Have fun & stay safe. 🧅

Siehe auch: HTTP/3 und QUIC

Fragen? Einfach melden.

WordPress wp-cron.php: Ist die angebliche Sicherheitslücke real?

Picture of an hacker checken for wordpress vulnerability

In letzter Zeit begegnen mir immer wieder sogenannte „Vulnerability Report Scams“. Klar, mit Angst und Unwissenheit kann man Geld verdienen, also wird es auch jemand tun. Besonders fällt mir das im Zusammenhang mit der wp-cron.php auf.

Ich habe häufig Reports gesehen, die in etwa so aussehen:

Critical Vulnerability Report- {Critical BUG #P1} - https://www.example.com/ - vulnerable to attack via wp-cron.php

Hello  Security team,

I am a Security Engineer, Cyber Security Researcher, Bug Bounty Hunter  & Ethical Hacker. While testing your domain https://www.example.com/ I have found some important vulnerabilities in your site.

Vulnerability Name:   https://www.example.com/  -  vulnerable to DoS attack via wp-cron.php

Vulnerable Domain:  https://www.example.com/wp-cron.php

Description:

The WordPress application is vulnerable to a Denial of Service (DoS) attack via the wp-cron.php script. This script is used by WordPress to perform scheduled tasks, such as publishing scheduled posts, checking for updates, and running plugins.
An attacker can exploit this vulnerability by sending a large number of requests to the wp-cron.php script, causing it to consume excessive resources and overload the server. This can lead to the application becoming unresponsive or crashing, potentially causing data loss and downtime.

I found this vulnerability at https://www.example.com/wp-cron.php endpoint.

Steps to Reproduce: reference- https://hackerone.com/reports/1888723

navigate to: https://www.example.com/wp-cron.php
intercept the request through the burp suite
right click on the request and send it to the repeater
Now send a request, and you will see the response as  200 OK

---

this can be also done by the curl command given below

curl -I "https://www.example.com/wp-cron.php"

POC: Attached

Impact:

If successful, this misconfigured wp-cron.php file can cause lots of damage to the site, such as:

Potential Denial of Service (DoS) attacks, resulting in unavailability of the application.
Server overload and increased resource usage, leading to slow response times or application crashes.
Potential data loss and downtime of the site.
Hackers can exploit the misconfiguration to execute malicious tasks, leading to security breaches.

Exploitation:
Exploitation can be done through a GitHub tool called doser.go https://github.com/Quitten/doser.go
I did not do that as this can impact your website.
Get the doser.py script at https://github.com/Quitten/doser.py
Use this command to run the script: python3 doser.py -t 999 -g 'https://www.example.com/wp-cron.php'
Go after https://www.example.com/ 1000 requests of the doser.py script.
The site returns code 502.

Suggested Mitigation/Remediation Actions:

To mitigate this vulnerability, it is recommended to disable the default WordPress wp-cron.php script and set up a server-side cron job instead. Here are the steps to disable the default wp-cron.php script and set up a server-side cron job:
Access your website's root directory via FTP or cPanel File Manager.
Locate the wp-config.php file and open it for editing.
Add the following line of code to the file, just before the line that says "That's all, stop editing! Happy publishing.":

1define('DISABLE_WP_CRON', true);

Save the changes to the wp-config.php file.
Set up a server-side cron job to run the wp-cron.php script at the desired interval. This can be done using the server's control panel or by editing the server's crontab file.
References:

For more information about this vulnerability, please refer to the following resources:

https://hackerone.com/reports/1888723

https://medium.com/@mayank_prajapati/what-is-wp-cron-php-0dd4c31b0fee

Cron
Fix Them ----- I have protected your company and saved it from a big loss so give me some appreciation Bounty Reward. I am sharing my PayPal ID with you. Paypal ID: woop woop Current Market Value Minimum Bounty Reward for Critical BUG P1 Type. The bug I reported is part of type P1 Vulnerability severity Bug bounty reward amount (in USD) P1 (Critical) $2500 P2 (High) $1500 P3 (Medium) $1000 P4 (Low) $500 Please feel free to let me know if you have any other questions or need further information. I am happy to secure it. I hope this will be fixed soon. Feel free to let me know if you have any other questions. Thanks & Regards

Ist das nun ein echtes Problem oder nicht?

Ja und Nein. In der Nachricht wird korrekt beschrieben, was die wp-cron.php tut und warum sie wichtig ist. Auch die Tatsache, dass sie extern unendlich oft aufgerufen werden kann und dadurch potenziell eine Überlastung auslösen könnte, ist nicht falsch. Selbst der Tipp, auf eine lokale Crontab-Version umzusteigen, ist nicht verkehrt. Allerdings muss man das Ganze in den richtigen Kontext setzen: wp-cron.php ist standardmäßig in WordPress aktiviert und wird für geplante Aufgaben genutzt. Die geplanten Aufgaben werden in der Datenbank abgelegt. Gibt es etwas zu tun und die wp-cron.php wird aufgerufen, dann wird auch gearbeitet. Gibt es nichts zu tun, dann gibt es auch keine Arbeit. Die Empfehlung, sie zu deaktivieren und durch einen serverseitigen Cron-Job zu ersetzen, ist eher eine Performance-Optimierung als eine echte Sicherheitsmaßnahme.

Es handelt sich nicht um einen Zero-Day-Exploit und es gibt keine direkte Gefahr eines Datenabflusses. Falls es wirklich zu Performance-Problemen kommt, gibt es einfache Gegenmaßnahmen. Sollte tatsächlich jemand versuchen, die wp-cron.php gezielt anzugreifen, hilft ein simples Rate Limiting, entweder über die Firewall oder direkt mit mod_security (Apache) bzw. limit_req (nginx).

Rate Limiting mit nginx

limit_req_zone $binary_remote_addr zone=cronlimit:10m rate=1r/s;

server {
    location = /wp-cron.php {
        limit_req zone=cronlimit burst=3 nodelay;
        limit_req_status 429;
    }
}

Das begrenzt die Anfragen auf 1 pro Sekunde, mit maximal 3 Anfragen in kurzer Zeit.

Sollte man wp-cron.php deaktivieren?

Nicht unbedingt. Klar, im Fall eines Angriffs kann das als erste Maßnahme helfen. Besser ist es aber, wp-cron.php lokal auszuführen und den Zugriff darauf über den Webserver auf bestimmte IP-Adressen zu beschränken. Anschließend kann man einen Cronjob anlegen, der alle 15 Minuten ausgeführt wird:

*/15 * * * * wget -q -O - https://www.example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Zugriff per nginx einschränken:

location ~* ^/wp-cron.php$ {
    allow 1.2.3.4;  # Ersetze mit deiner IP
    deny all;
}

Fazit

Das ist ganz sicher kein P1-Bug. Und wenn der Report direkt eine Preistabelle mitliefert, ist das schon ein ziemlich eindeutiges Zeichen für einen Scam.

  • Ja, wp-cron.php könnte unter bestimmten Umständen zu Problemen führen.
  • Nein, es ist kein echter Sicherheits-Bug.
  • Wer weiß, was er tut, hat bereits die richtigen Maßnahmen getroffen.

Keine Panik. Stattdessen lieber kurz die eigene Konfiguration prüfen und gut ist. Wer auf das nginx Rate Limit setzt und dieses testen möchte, kann mein rate_limit_test.sh auf GitHub nutzen.

Siehe auch: Ist mein Netzwerk kompromittiert?

Fragen? Einfach melden.

FreeBSD SSH-Server absichern: MFA mit Google Authenticator einrichten​

SSH-Keys sind der Standard. Aber manchmal lässt es sich nicht vermeiden, dass ein Login nur mit Benutzername und Kennwort abgesichert ist. Um das aufzuwerten, lässt sich der SSH-Server mit einem zweiten Faktor ausstatten — hier mit dem Google Authenticator (TOTP) auf FreeBSD.

Installation

pkg install pam_google_authenticator

PAM-Konfiguration

In /etc/pam.d/sshd das Google Authenticator PAM-Modul als zweiten required-Eintrag nach pam_unix einfügen:

#
# PAM configuration for the "sshd" service
#

# auth
auth		required	pam_unix.so		no_warn try_first_pass
auth		required	/usr/local/lib/pam_google_authenticator.so

# account
account		required	pam_nologin.so
account		required	pam_login_access.so
account		required	pam_unix.so

# session
session		required	pam_permit.so

# password
password	required	pam_unix.so		no_warn try_first_pass

Die Reihenfolge ist wichtig: Erst das Kennwort (pam_unix), dann der TOTP-Code. Auf dem gleichen Weg lässt sich MFA auch für su, den Konsolen-Login oder SSH-Keys einrichten — einfach das entsprechende PAM-File anpassen.

sshd_config anpassen

In /etc/ssh/sshd_config muss Challenge-Response aktiviert sein:

# Seit OpenSSH 8.7 heißt die Option KbdInteractiveAuthentication
# ChallengeResponseAuthentication ist ein Alias und funktioniert weiterhin
KbdInteractiveAuthentication yes

Danach service sshd restart — aber vorher sicherstellen, dass man noch eine offene Session hat, falls etwas nicht stimmt.

Authenticator einrichten

Auf dem Smartphone den Google Authenticator installieren (oder eine andere TOTP-App wie Aegis, 2FAS oder den Microsoft Authenticator). Dann auf dem Server mit dem gewünschten Benutzer google-authenticator aufrufen:

cd ~
google-authenticator

Das Tool zeigt einen QR-Code im Terminal, den man mit der Authenticator-App scannt:

Danach den angezeigten Code einmal eingeben — fertig. Bei jedem Kennwort-Login wird jetzt zusätzlich der aktuelle TOTP-Code abgefragt.

Wichtig: Das Tool zeigt auch Backup-Codes an. Diese unbedingt sicher aufbewahren — wenn das Smartphone verloren geht, kommt man sonst nicht mehr rein. Die Konfiguration liegt in ~/.google_authenticator und kann dort auch nachträglich eingesehen werden.

Siehe auch: FreeBSD OpenSSH: OS-Banner sicher entfernen, SSH-Bruteforce, DigitalOcean und AbuseIPDB – warum Blocken das Problem nicht löst

Unter Linux ist die Einrichtung sehr ähnlich — das PAM-Modul heißt dort libpam-google-authenticator. Fragen? Einfach melden.

DNSSEC und SSHFP unter Linux Mint und Ubuntu zum Laufen bringen

Heute habe ich versucht, mich von meiner neuen Linux Mint Installation aus mit einem meiner SSH-Server zu verbinden. Mein SSH-Client hat mich direkt gefragt, ob ich dem Hostkey vertrauen möchte:

ssh username@hostname.kernel-error.org
The authenticity of host 'hostname.kernel-error.org (2a01:5a8:362:4416::32)' can't be established.
ED25519 key fingerprint is SHA256:kTRGVCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl3iJu.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Für viele ist das normal — man tippt „yes“ und sieht die Meldung nie wieder. Aber diese Meldung hat ihren Grund. Beim ersten Verbindungsaufbau zeigt SSH den Fingerprint des Server-Hostkeys an, damit man prüfen kann, ob man wirklich mit dem richtigen Server spricht und nicht mit einem Angreifer. Wer eh immer „yes“ sagt, könnte den Check auch gleich in seiner ~/.ssh/config abschalten:

Host *
    StrictHostKeyChecking no

SSHFP — Hostkeys per DNS verifizieren

Es gibt einen besseren Weg: SSHFP-Records (RFC 4255). Man hinterlegt die Fingerprints der erwarteten Hostkeys als DNS-Einträge. Der SSH-Client prüft diese automatisch — vorausgesetzt die DNS-Antwort ist per DNSSEC abgesichert. In der ~/.ssh/config:

Host *
   VerifyHostKeyDNS yes

Meine DNS-Server unterstützen alle DNSSEC, mein lokaler Resolver auf dem Router auch, die SSH-Config stimmt — und trotzdem erscheint die Meldung. Also mit ssh -vvv debuggen:

debug1: found 2 insecure fingerprints in DNS

Insecure. SSH findet die SSHFP-Records, vertraut ihnen aber nicht, weil die DNS-Antwort nicht als DNSSEC-validiert markiert ist.

Das Problem: systemd-resolved

Schneller Test mit dig +dnssec gegen Google DNS:

dig +dnssec hostname.kernel-error.org @8.8.8.8
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Das ad-Flag (Authenticated Data) ist gesetzt — meine DNS-Server liefern DNSSEC korrekt aus. Auch der lokale Router-Resolver liefert ad. Aber ohne expliziten @server:

dig +dnssec hostname.kernel-error.org
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Kein ad. Was steht in /etc/resolv.conf? 127.0.0.53systemd-resolved. Der Stub-Resolver von systemd schluckt das AD-Flag.

Man könnte in /etc/systemd/resolved.conf einfach DNSSEC=yes setzen — bei mir ging danach aber gar keine DNS-Auflösung mehr. Das liegt am Stub-Resolver, den man ebenfalls umkonfigurieren müsste. Nennt mich oldschool, aber für meine Zwecke reicht der klassische Weg über die vom NetworkManager gepflegte resolv.conf.

Lösung: systemd-resolved abschalten

sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
sudo rm /etc/resolv.conf

In /etc/NetworkManager/NetworkManager.conf in der [main]-Sektion:

dns=default

NetworkManager neu starten:

sudo systemctl restart NetworkManager
cat /etc/resolv.conf
# Generated by NetworkManager
search kernel-error.local
nameserver 10.10.88.1
nameserver fd00:424e:6eff:f525:454e:6eff:f525:4241

DNS-Auflösung geht. Aber SSH sagt weiterhin „insecure“. Es fehlen noch zwei Optionen in der resolv.conf.

edns0 und trust-ad

Erste Erkenntnis — edns0 muss aktiviert sein, damit DNSSEC-Daten überhaupt transportiert werden. In /etc/resolv.conf:

options edns0

Jetzt zeigt dig das ad-Flag. Aber SSH sagt immer noch „insecure“. Warum? Ein Blick in den SSH-Quellcode — die ldns-Bibliothek macht die DNSSEC-Validierung:

        /* Check for authenticated data */
        if (ldns_pkt_ad(pkt)) {
                rrset->rri_flags |= RRSET_VALIDATED;
        } else { /* AD is not set, try autonomous validation */
                ldns_rr_list * trusted_keys = ldns_rr_list_new();
                /* ... */
                if ((err = ldns_verify_trusted(ldns_res, rrdata, rrsigs,
                     trusted_keys)) == LDNS_STATUS_OK) {
                        rrset->rri_flags |= RRSET_VALIDATED;
                }
        }

ldns prüft das AD-Flag im DNS-Paket. Aber die glibc setzt das AD-Flag in der Antwort nur dann, wenn trust-ad in der resolv.conf steht — sonst wird es aus Sicherheitsgründen herausgefiltert. Die vollständige Option:

options edns0 trust-ad

Und jetzt:

ssh username@hostname.kernel-error.org -vvv
[...]
debug1: found 2 secure fingerprints in DNS
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 1
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 1
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 2
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2
debug1: matching host key fingerprint found in DNS

secure statt insecure. SSH verifiziert den Hostkey automatisch per DNSSEC — keine manuelle Fingerprint-Prüfung mehr nötig.

Rebootfest machen

Die manuell eingetragenen Optionen in der resolv.conf überleben keinen Reboot — der NetworkManager überschreibt die Datei. Per nmcli die Optionen dauerhaft im Netzwerkprofil setzen, für IPv4 und IPv6:

nmcli conn modify DEINE-PROFIL-UUID ipv4.dns-options edns0,trust-ad
nmcli conn modify DEINE-PROFIL-UUID ipv6.dns-options edns0,trust-ad

Die UUID des aktiven Profils findet man mit nmcli conn show. Beide Zeilen sind nötig — fehlt eine, greift es nicht.


Zusammenfassung: systemd-resolved unter Linux Mint und Ubuntu filtert das DNSSEC-AD-Flag heraus. Ohne AD-Flag kann SSH die SSHFP-Records nicht als vertrauenswürdig einstufen. Lösung: systemd-resolved abschalten, NetworkManager mit dns=default nutzen, edns0,trust-ad per nmcli setzen.

Wer einen DNSSEC-validierenden Resolver sucht — dns.kernel-error.de ist ein öffentlicher DNS-Resolver mit DNSSEC, DNS over TLS und DNS over HTTPS.

Und die offene Frage: Ich bin mit meinem FreeBSD-Wissen an das Thema gegangen. Wie macht man das als Linux-User mit systemd-resolved richtig? Schreibt mir, wenn ihr es wisst.

Siehe auch: SSH Host Keys per SSHFP

VC-64 Turbo Tape (1986): Seltene C64-Cartridge von CIK im Detail​

In meinem Keller sammelt sich unter anderem die eine oder andere Hardware an, die wohl inzwischen der Retro-Computer-Ecke zugeordnet werden kann. Dazu gehört auch diese Cartridge für den Commodore 64.

Der Name „Turbo Tape“ ist dabei wörtlich zu nehmen. Das kleine Programm, das auf dem IC in der Cartridge gespeichert ist, ermöglicht es, das Lesen und Schreiben auf einem Kassettendeck zu beschleunigen. Ja, früher speicherten wir unsere Programme auf Kassetten.

Da dieses Produkt offenbar von einem kleineren, lokalen Anbieter stammt und ich selbst im Internet nichts weiter darüber finden konnte, möchte ich ihm hiermit eine Bühne bieten, damit es nicht einfach in Vergessenheit gerät.

Der Hersteller ist wohl Computertechnik Ingo Klepsch, Postfach 13 31, 5828 Ennepetal 1. Die Telefonnummer lautete: 0 23 33 / 8 02 02. An der kurzen Postleitzahl erkennt man bereits, dass die Adresse noch vor der Änderung der Postleitzahlen aufgedruckt wurde. Ich habe auch Informationen zum Unternehmen gefunden. Die Ingo Klepsch – CIK – Computertechnik war ein Unternehmen aus Hagen, das am 25.07.1990 im Handelsregister eingetragen und am 24.02.1992 bereits wieder gelöscht wurde. Außerdem habe ich noch Werbung für dieses Unternehmen in der Amiga Kickstart 2-90 gefunden.

Wie auf den Bildern zu erkennen, ist das PCB sehr übersichtlich gestaltet. Es enthält einen Widerstand, ein MC74HC00 als NAND-Gate, einen kleinen Folienkondensator, einen kleinen Schalter und natürlich das Herzstück, den MBM2716 UV-EPROM mit dem eigentlichen Programmcode. Diesen habe ich mit meinem kleinen TL866 II Plus ausgelesen und biete ihn euch ebenfalls unten zum Download an.

Download: MBM2716_VC-64_Turbo_Tape_1986_by_CIK.BIN

Siehe auch: Commodore – PC Projekt, Commodore Floppy Disk Preservation: Firmware-Bug im xum1541 gefunden und gefixt

Fragen? Einfach melden.

QIDI i-Mate S 3D-Drucker: Erfahrungen, Upgrades & Support-Tipps

Seit gut zwei Jahren druckt bei mir ein QIDI i-Mate S. Damals gesucht: kompaktes Design, beheizbares Druckbett, geschlossener Druckraum, Druckbett nur in der Z-Achse, PLA/ABS/PETG. Gefunden, bestellt, seitdem im Einsatz.

Der Drucker tut, was er soll. Für den Preis in guter Qualität. Die Slicer-Software QIDI Print basiert auf Cura, ist aber speziell auf den Drucker angepasst. Soweit findet man das in jedem Testbericht. Was dort meistens fehlt: Infos zu Upgrades, dem Support und den kleinen Macken im Alltag.

Support

Der Support von QIDI war bisher durchgehend exzellent. Per E-Mail direkt an mateb@qd3dprinter.com kam immer innerhalb von 24 Stunden eine Antwort. Auch an Wochenenden und Feiertagen. Freundlich, hilfsbereit, mit Videos, Anleitungen und angepassten Konfigurationsdateien. Dateiaustausch lief unkompliziert über Google Drive. Wer schon einmal mit Herstellern hinter der chinesischen Firewall Daten austauschen wollte, versteht den Mehrwert.

All-Metal Hotend

Nach knapp einem Jahr kam das erste Upgrade: ein Full-Metal Extruder von AliExpress. Das passende Firmware-Update gab es direkt vom Support inklusive Anleitung. Einbau war einfach, besondere Einstellungsänderungen in QIDI Print nicht nötig.

Austausch All-Metal-Hotends beim Qidi iMate S

Mit dem neuen Druckkopf war die Layerhaftung zunächst schlechter. Der Support half: Nicht jeder Schrittmotor läuft exakt gleich. Bei 2 cm Filamentvorschub kamen bei mir keine 2 cm. Drei E-Mails und 15 Minuten später hatte ich eine angepasste Konfigurationsdatei. Einfach „gedruckt“ und das Problem war Geschichte.

Schrittmotor-Kühlung

Die Schrittmotoren werden beim Druck spürbar warm. Nicht zu warm, aber warm genug, dass ich dem Drang nicht widerstehen konnte. Selbstklebende Kühlkörper von AliExpress auf alle Achsen-Motoren. Den Druckkopf-Motor ausgenommen, der wird bereits aktiv gekühlt und das zusätzliche Gewicht wäre kontraproduktiv.

Kühlkörper auf dem Schrittmotor des Qidi iMate S

Wer die passive Kühlung direkt aktiv machen will: Es gibt passende 24V-Lüfter dafür.

Filament Sensor

Filament bricht selten, aber es passiert. Oder es ist mitten im Druck leer und der Drucker läuft einfach weiter. Ein Filament Run Sensor von AliExpress erkennt das und stoppt den Druckvorgang. Filament nachladen, weitermachen.

Installation wieder einfach, wieder mit Anleitung vom Support und einer Konfigurationsdatei zum „Drucken“. Kleines Detail am Rande: In der deutschen Übersetzung der Firmware heißt der Filament Sensor „Glühfaden-Sensor“. Der Support hat sich über den Hinweis gefreut.

Bed Leveling

Automatisches Leveling gibt es nicht. Das geführte Leveling-Programm im Druckmenü funktioniert problemlos, die eigentlichen Muttern auch. Was nervt: die Sicherung mit einer zusätzlichen Flügelmutter. Man stellt alles perfekt ein, sichert die Muttern und dabei verschiebt sich der Abstand zur Nozzle wieder. Vielleicht habe ich zu dicke Finger.

Die einfachste Lösung war ein 3D-gedrucktes Ersatzteil von Thingiverse zusammen mit selbstsichernden M4 Muttern. Gedruckt aus PETG. Seitdem macht Bed Leveling fast Spaß. So viel Spaß, wie manuelles Leveling halt machen kann.

3D-gedruckte Ersatzmutter für das Bed-Leveling beim Qidi iMate S

Nozzle und Filament

Zusammen mit dem All-Metal Hotend bin ich auf eine Nozzle von Brozzl gewechselt. Beschichtetes Kupfer statt Messing: besserer Wärmeleitwert und etwas härter. Bei Messing und erst recht bei Stahl muss man die Temperatur 5-10 Grad höher setzen. Kupfer macht das überflüssig.

Filament kommt ebenfalls direkt von QIDI über AliExpress. Tut und hält.

Fragen? Einfach melden.

Cloudflare Deal: Günstige YubiKeys für 10–11 USD im Oktober 2022

Es gibt aktuell einen EEEECCCHHHTTTT guten Deal um günstig an bis zu 10 YubiKeys 5 NFC und/oder 5C NFC zu kommen.

Man benötigt dafür einen Cloudflare Account, der ist ja schnell geklickt. Dann klickt man ein paar Links und wartet auf eine E-Mail mit seinem Discount Code.

Da die Keys in der Regel etwas um die 50€ Kosten, ist dieses schon eine extreme Ersparnis.

Oh der Link: https://www.reddit.com/r/yubikey/comments/xrcly7/cloudflare_deal_for_1011_keys/

Screenshot der Bestellübersicht für den YubiKey 5 NFC und YubiKey 5C NFC

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑