IT-Blog von Sebastian van de Meer

Kategorie: Kernel-Error-Blog (Seite 5 von 45)

Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.

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.

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

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.

Time is up: Mark Benecke im EU-Parlament – Einblick und Diskussion

Klimawandel… Joar, den gibt es. Das wir Menschen dran schuld sind wissen wir ebenfalls. Im Grunde ist es uns allen schon seit Jahren klar. Wir machen nur so schön die Augen davor zu.

Probleme zu ignorieren hilft leider nicht immer (ok in der IT geht es hin und wieder *lach*)… Ich möchte hier auf einen Vortrag verweisen, welcher es für normale Menschen, fachlich belegt zusammenfasst. Vorsicht youtube!

Ich habe seit dem Video schlechte Laune :-/

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑