-=Kernel-Error=-

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

Kategorie: Kernel-Error-Blog (Seite 18 von 47)

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

FreeBSD: WLAN und der Ländercode korrekt einstellen

31. Mai 2017 / / 1 Kommentar
Grafik zum Thema FreeBSD WLAN und Ländercode: Ein WLAN-Router mit Antennen, daneben Terminal-Kommandos zur ifconfig-Konfiguration von Regdomain und Country. Im Hintergrund eine Weltkarte mit Markierungen für FCC/US-Default und ETSI/DE sowie der FreeBSD-Daemon als zentrales Element.

Funkregulierung ist länderspezifisch. Jede Region definiert, welche 2,4 GHz und 5 GHz-Kanäle, Sendeleistung und Radar-/DFS-Regeln gelten. In FreeBSD steuert eine Kombination aus Regulatory Domain (z. B. ETSI für Europa, FCC für USA, APAC für Asien/Pazifik) und Country (z. B. „DE“ bzw. „Germany“, „AT“ bzw. „Austria“, „GB“ bzw. „United Kingdom“) den erlaubten Betrieb. Ohne Anpassung bleibt oft der US-Default aktiv, der in Europa eingeschränkter ist.

FreeBSD nutzt keine ISO-Kurzcodes allein (also nicht nur „DE“, „UK“). Der Country-Name muss exakt aus den Einträgen in /etc/regdomain.xml kommen (z. B. „United Kingdom“ statt „UK“). Diese Erkenntnis hat bei mir zum Beginn etwas gebraucht

Praxis: So stellst du es sauber ein.

1 Hardware/Interface prüfen

sysctl net.wlan.devices      # listet WiFi-Chips
ifconfig wlan0               # zeigt aktuelles Regdomain/Country
ifconfig wlan0 list regdomain
ifconfig wlan0 list countries

2 Interface runterfahren

ifconfig wlan0 down

3 Regdomain & Country setzen

ifconfig wlan0 regdomain etsi2 country DE
# etsi2 bezieht sich auf die regionale Definition (Europa),
# DE ist der länderspezifische Eintrag aus /etc/regdomain.xml

4 Interface wieder hochfahren

ifconfig wlan0 up

5 Persistenz in /etc/rc.conf (denn das was wir bis jetzt gemacht haben ist nach dem nächsten Reboot weg).

sysrc create_args_wlan0="country DE regdomain etsi2"
sysrc wlans_iwn0="wlan0"
sysrc ifconfig_wlan0="WPA DHCP"

Ersetze iwn0 durch dein Device und etsi2 durch den passenden Regdomain-Block, wenn du nicht DE bist, sonst ist copy&paste gut.

Warum das wichtig ist

  • Rechtliche Konformität: falsche Domain/Code kann gegen lokale Funkbestimmungen verstoßen. Was in der Regel aber eher ein theoretisches Problem sein sollte.
  • Kanalauswahl: Europa nutzt 1–13, USA nur 1–11. US-Default kann daher Kanäle ausblenden. Kanal 13 ist meist sehr „leer“ also gut, wenn viel um einen herum los ist ABER alle Geräte müssen das auch können und passend, wie hier beschrieben, für sich konfiguriert sein.
  • DFS/5 GHz: moderne Regime wie ETSI/ETSI2 definieren zusätzliche Regeln für 5 GHz/DFS; FCC-Default kann hier ebenfalls andere Limits haben.

Aktuelle Unterschiede zu älteren Releases (Update 2026).

FreeBSD 14.x/15.x haben bessere Treiber und WLAN-Stack-Support (siehe auch FreeBSD auf dem Desktop), was dazu führt, dass viele Geräte stabiler laufen. Die Regulatory Domain-Mechanik selbst hat sich nicht grundlegend verändert; sie ist weiterhin über ifconfig steuerbar. Firmware-Unterstützung für Chips kann aber Einfluss auf die tatsächliche Kanalnutzung haben, unabhängig von RegDomain-Einstellungen. Auf Probleme bin ich damit noch nicht gestoßen, was aber nur bedeutet, dass meine Hardware kein Problem macht.

Risiken/Trade-offs

  • Falsche Codes: „AU“ ist nicht immer Australien, manchmal Österreich im Regdomain XML; achte auf die Einträge. Aber hey, es gibt in Wien am Flughafen ja auch einen Schalter, nur um Menschen zu erklären, warum sie jetzt in Österreich und nicht in Australien sind Hin und wieder würde ich da gerne Sitzen, nur um die Gesichter zu sehen. Ja, das ist böse, ich weiß.
  • Installer-Defaults: Der FreeBSD-Installer setzt nicht immer den passenden Regdomain/Country für WLAN – du musst das nachinstallieren/konfigurieren. Aber hey, das kennen wir doch von FreeBSD und mögen ja auch irgendwie diese Verlässlichkeit, oder?
  • Treiber/Firmware: Manche WLAN-Adapter benötigen separate Firmware-Blobs (z. B. Realtek), sonst funktioniert WiFi gar nicht – unabhängig von Regdomain.

Fragen? Einfach melden.

Piwigo 2.8.2/2.9 Upgrade: Häufige Fehler und Lösungen

31. Mai 2017 / / Keine Kommentare

Upgrade von Piwigo 2.8 auf 2.9 geklickt, schien sauber durchgelaufen zu sein. Danach zeigte die Galerie nur noch eine Fehlermeldung.

Das Problem

Warning: [mysql error 1054] Unknown column 'last_visit' in 'field list'

UPDATE piwigo_user_infos
  SET last_visit = NOW(),
      lastmodified = lastmodified
  WHERE user_id = 1

Die Spalte last_visit existierte nicht. Ein Blick ins Nginx-Error-Log zeigte, dass der Fehler schon während des Upgrades auftrat:

ALTER TABLE `piwigo_user_infos`
  ADD COLUMN `last_visit` datetime default NULL,
  ADD COLUMN `last_visit_from_history` enum('true','false') NOT NULL default 'false'
;

Das ALTER TABLE war beim Upgrade aus irgendeinem Grund fehlgeschlagen. Die Datenbank-Migration ist abgesoffen.

Die Lösung

Die fehlenden Statements aus dem Upgrade-Script herausgesucht und von Hand auf die Datenbank losgelassen:

ALTER TABLE `piwigo_comments` CHANGE `date` `date` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_history` CHANGE `date` `date` date NOT NULL default '1970-01-01';
ALTER TABLE `piwigo_images` CHANGE `date_available` `date_available` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_old_permalinks` CHANGE `date_deleted` `date_deleted` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_rate` CHANGE `date` `date` date NOT NULL default '1970-01-01';
ALTER TABLE `piwigo_sessions` CHANGE `expiration` `expiration` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_upgrade` CHANGE `applied` `applied` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_user_infos` CHANGE `registration_date` `registration_date` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_user_infos`
  ADD COLUMN `last_visit` datetime default NULL,
  ADD COLUMN `last_visit_from_history` enum('true','false') NOT NULL default 'false'
;

Danach lief alles wieder. Lektion: Nach einem Piwigo-Upgrade immer prüfen, ob die Datenbank-Migration vollständig durchgelaufen ist. Im Zweifel ins Error-Log schauen.

Siehe auch: Umzug auf FreeBSD/Nginx

Fragen? Einfach melden.

matrix und Riot als Ersatz für Jabber?

24. Mai 2017 / / Keine Kommentare

Ich teste im Moment matrix als Basis für die Kommunikation. Client ist dabei Riot auf Android und iOS und als Server probiere ich im moment Synapse aus. Alles unter der Domain: https://matrix.kernel-error.com

Beim Identiy Server bin ich einfach mal bei https://matrix.org geblieben! Alles ist noch sehr beta. Dafür tut es aber schon ganz ordentlich. Schreiben und Dateien verschicken funktioniert problemlos. Videocalls gehen so mäßig. Das Bild hängt halt immer mal wieder. Einfache Voicecalls klappten dafür richtig gut, sowohl zu zweit als auch in der Konferenz.

Etwas hakelig war das Einfügen von E-Mail Adresse und Rufnummer über den Andoid Client… Das war etwas verwirred. Hier ist der Workflow und die UI auf dem iOS besser. Insg. tut es aber….

Zuletzt habe ich nun den nginx als proxy for den matrix-synapse Server gesetzt. Dem vertraue ich an der Stelle einfach etwas mehr. Oh es läuft in einer FreeBSD 11 jail und dort auch recht Problemlos.

Sobald es mehr zu berichten gibt schreibe ich mehr! Wer es ebenfalls nutzt und mich anschreiben möchte: @kernel:matrix.kernel-error.com

So long…

Siehe auch: Eigenen Jabber-Server betreiben

Fragen? Einfach melden.

Brute-Force Angriffe auf Joomla

10. April 2017 / / Keine Kommentare

Sobald man einen standard Dienst im Netz stehen hat wird dieser auch von verschiedenen Bots abgegrabbelt. Diese testen nach ungepatchten Versionen mit nutzbaren Sicherheitslöchern oder gehen Rainbow Tables durch. Gegen Sicherheitslöcher hilft ein Patchmanagement gegen Rainbow Tables helfen gute Kennwörter und ein Schutz gegen Brute-Force…. Einfach ist hier zum Beispiel der fail2ban Ansatz. Einfach mit zählen wie viele Fehlerhafte Logins in einem gewissen Zeitraum von einer IP-Adresse kommen und dann direkt die IP-Adresse für einen gewissen Zeitraum sperren.

Jetzt sind die Entwickler der Bots nicht dumm… Zuerst haben diese Bots genau so angefangen. Erstmal alle möglichen Kennwörter durchprobieren. Als ersten Schutz natürlich fail2ban, dann haben die Bots angefangen nicht mehr als genau drei Anfragen von einer IP Adresse zu stellen, etwas warten und dann wieder drei Anfragen. Man musste also im fail2ban „nachstellen“. Nun sind wir schon beim Punkt das diese Anfragen nicht mehr gebündelt als Dreierblock kommen sondern immer nur eine Anfrage von einer Adresse und 2 – 3 Stunden später erst wieder von dieser Adresse. Der einzelne Bot würde also Jahrzehnte brauchen um einige Versuche durch zugehen! Wenn er sich mit vielen anderen Abspricht, werden in kurzer Zeit noch immer sehr viele Kombinationen durchprobiert. Also wieder nachrüsten… Zwei Faktor, „Lebenderkennung“, Zertifikatslogin usw… Damit hat man sicher erst mal etwas Ruhe. OK, hier gibt es ebenfalls Möglichkeiten nur gibt es sicher genug schlechter gesicherte Ziele die zuerst angegangen werden können!

Siehe auch: SSH-Server absichern mit MFA

Fragen? Einfach melden.

Neues S/MIME Zertifikat

31. März 2017 / / Keine Kommentare

Neues S/MIME Zertifikat, neuer SMIMEA-Record. Weil E-Mail-Verschlüsselung nicht nur für Paranoide ist. Oder doch? Egal, ich mache es trotzdem.

S/MIME Zertifikat getauscht

Wie angekündigt habe ich ein neues S/MIME Zertifikat. Wer mir verschlüsselt schreiben will, braucht den neuen öffentlichen Schlüssel. Den gibt es wie immer über die üblichen Wege oder halt per erster unverschlüsselter Mail an mich.

SMIMEA: S/MIME trifft DANE

Das Spannende daran: ich habe direkt einen SMIMEA-Record dazu im DNS hinterlegt. SMIMEA ist quasi DANE für S/MIME. Statt nur TLS-Zertifikate von Servern im DNS zu veröffentlichen, kann man damit auch S/MIME-Zertifikate von E-Mail-Adressen per DNS verifizierbar machen. Der RFC dazu war 2017 noch im Draft-Status (RFC 8162), inzwischen ist er finalisiert.

Die Idee ist simpel: Du hast DNSSEC für deine Domain (habe ich), du hast ein S/MIME-Zertifikat (habe ich jetzt neu) und du packst den Fingerprint oder das ganze Zertifikat als SMIMEA-Record in deine DNS-Zone. Jeder der mir eine verschlüsselte Mail schicken will, kann mein Zertifikat dann per DNS-Abfrage verifizieren. Kein Rumsuchen auf Keyservern, keine manuelle Prüfung ob das Zertifikat echt ist.

In der Praxis nutzt das aktuell fast niemand. Mailclient-Support ist mager, die meisten Leute wissen nicht mal was S/MIME ist, geschweige denn SMIMEA. Aber genau deshalb mache ich es. Jemand muss ja anfangen.

Wer sich für DANE, SMIMEA oder E-Mail-Sicherheit interessiert, kann mich gerne fragen.

GlobalSign S/MIME und so…

31. März 2017 / / Keine Kommentare

Nach dem „tot“ von StartSSL brauche ich ja auch mal ein neues S/MIME Zertifikat. Class 2 bei GlobalSign sollte für mich privat reichen (auch wenn ich schon auf Class 3 geschielt habe, mal sehen ob ich das noch nachziehe). Als erstes habe ich da trocken angerufen und gefragt ob ich auf sie bauen kann oder mich am Ende so ärgere wie über StartSSL / Symantec usw… Klar es ist eine große CA die zu viel Geld für Mist bekommen und der Anruf war total nutzlos. Er hat dennoch für Spaß bei mir und da bin ich mir sicher, ebenfalls bei GlobalSign geführt.

Nun klicke ich mich also gerade durch die Anmeldung und muss alle möglichen Daten eingeben sowie Vereinbarungen zustimmen usw. an einer Stelle soll ich dann schon mal mein Kennwort für die Zertifikatsverwaltung festlegen. Ich überzeuge also wie immer pwgen mir eines zu würfeln werfe es rein. Die Info unter dem Kennwortformular lese ich natürlich nicht und bekomme direkt die Quittung. Ich habe unerlaubte Sonderzeichen in meinem Passwort für die Zertifikatsverwaltung angegeben. Unerlaubte Sonderzeichen?!?!? Stimmt… Die Kennwörter dürfen nur aus Zahlen und Buchstaben (groß/klein) bestehen..

Das Kennwort für die Zertifikatsverwaltung darf also keine Sonderzeichen enthalten. Den Satz habe ich jetzt schon ein paar mal gesagt aber öhm ich begreife ihn irgendwie noch nicht. *kopfschüttel* Kann mir das bitte mal jemand verständlich machen? Am besten ich ruf da noch mal an, oder?

Siehe auch: S/MIME per DNS mit SMIMEA, Kleiner Nachtrag zum GlobalSign S/MIME Zertifikat…, Neues StartSSL S/MIME Zertifikat

Fragen? Einfach melden.

IPv6 – Bewerbung – Unitymedia

26. März 2017 / / Keine Kommentare

Das IPv6 eines meiner Lieblingsthemen ist muss ich ja keinem von euch erzählen. Auf das Thema bringt mich gerade sixxs. Die Jungs stellen nämlich ihren Service ein…. War ja fast zu erwarten! Sixxs kann sicher für sich behaupten eines der Projekte zu sein/gewesen zu sein welches extrem stark an der Verbreitung von IPv6 mitgewirkt hat!

Passend dazu saß ich vor kurzem in einem Bewerbungsgespräch irgendwann sind wir ebenfalls kurz auf das Thema IPv6 gekommen und da hat der Bewerber etwas gesagt was mir bis jetzt nicht mehr aus dem Kopf gegangen ist. Er sagt: „IPv6, ja… das war vor 5/6 Jahren mal so ein Hype, weil ja alle Adressen aufgebraucht sind, das ist aber inzwischen vorbei.“ Der Mann hat recht! OK, Adressen sind wirklich leer aber merkt man es denn wirklich? Also normaler User nicht. Von jedem gängigen ISP bekommt man IPv6 einfach in den Router geworfen und ob man jetzt noch eine „echte“ IPv4 Adresse hat oder man wie im Mobilfunk hinter einem carrier grade nat versteckt wird merken die normalen Nutzer eh nicht. Wenn man nicht gerade ein /24 haben will ist ebenfalls jeder DataCenterbetreiber oder Business ISP ohne großes hin und her gewillt einem das Netz zu geben. Selbst Unitymedia bekommt das hin!

Dabei kommt mit Unitymedia immer als der unprofessionellste Verein aller Zeiten vor. *kopfschüttel* Gut gut… Sie haben noch nicht SO viel Zeit als ISP verbracht wie der rosa Haufen. Habt ihr da mal versucht einen PTR Record zu setzen? Ach was schreib ich… Nicht setzten, setzten zu lassen?!?! Das geht per Fax. Echt jetzt PER FAX!!! Man bekommt so ein tolles PDF Formular OHNE Felder! Also so als PDF Bild zum Ausdrucken und dann muss man mit der Hand in so Kästchen seinen Wunsch PTR, die IP seine Kundennummer usw. eintragen und es dann zu ihnen zurück FAXEN. Nicht mal einscannen und E-Mail… Echt FAXEN! Jetzt ratet doch mal was passiert ist nachdem ich mein Fax mit 4 PTR Wünschen geschrieben habe? Richtig… Ich habe eine E-Mail vom Support bekommen, das sie leider nicht alles lesen konnten und ich das Fax doch bitte noch mal schicken solle *aaaarrrrggggghhhhh*

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

ZFS send/recv: „Cannot receive incremental stream“ beheben

20. März 2017 / / Keine Kommentare

Inkrementelle Replikation mit ZFS

Mit zfs send und zfs recv lassen sich Datasets über SSH auf ein anderes System replizieren. Das Schöne daran: Nach einem initialen Vollabgleich muss man nur noch die Differenz zwischen zwei Snapshots übertragen. Bei großen Datasets spart das enorm Bandbreite und Zeit.

Beispiel: Eine FreeBSD Jail mit 100 GB Mediadaten. Wöchentliche Snapshots werden automatisch erstellt. Der initiale Transfer:

zfs send zroot/jails/subsonic@weekly-2017-03-12 | ssh zfsrecv@system02 zfs recv zroot/backup/subsonic

Ab jetzt nur noch das Delta zum nächsten Snapshot:

zfs send -i zroot/jails/subsonic@weekly-2017-03-12 zroot/jails/subsonic@weekly-2017-03-19 \
  | ssh zfsrecv@system02 zfs recv zroot/backup/subsonic

Der Fehler

Das funktioniert nur, solange das Ziel-Dataset seit dem letzten Snapshot nicht verändert wurde. Jede Änderung — und sei es nur ein Update der Access-Time (atime) durch einen Lesezugriff — reicht aus, damit ZFS den inkrementellen Stream ablehnt:

cannot receive incremental stream: destination zroot/backup/subsonic has been modified
since most recent snapshot
warning: cannot send 'zroot/jails/subsonic@weekly-2017-03-19': signal received

ZFS sagt damit: Zwischen dem letzten gemeinsamen Snapshot und jetzt hat sich am Ziel etwas geändert. Das Delta passt nicht mehr.

Lösung und Prävention

Man muss nicht alles neu übertragen. Mit -F weist man zfs recv an, das Ziel-Dataset auf den letzten gemeinsamen Snapshot zurückzurollen und dann das Delta anzuwenden:

zfs send -i zroot/jails/subsonic@weekly-2017-03-12 zroot/jails/subsonic@weekly-2017-03-19 \
  | ssh zfsrecv@system02 zfs recv -F zroot/backup/subsonic

Damit das Problem gar nicht erst auftritt, setzt man das Ziel-Dataset auf readonly:

zfs set readonly=on zroot/backup/subsonic

So kann nichts am Ziel verändert werden — kein atime-Update, kein versehentliches Schreiben. Das -F im Skript schadet trotzdem nicht als Sicherheitsnetz. Und nicht vergessen: Auf dem Zielsystem regelmäßig alte Snapshots aufräumen, sonst wächst der Plattenverbrauch stetig.

Mehr Details in der OpenZFS-Dokumentation zu zfs send. Mehr zu ZFS: ZFS Compression und Deduplication und TRIM im ZFS-Pool aktivieren. Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑