IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.
Veraltet: Sabayon Linux wurde 2020 eingestellt. Der Paketmanager Rigo (Entropy) existiert nicht mehr.
Da bekomme ich doch gerade die folgende Info von Rigo präsentiert:
<=|=< (optimistisch gesehen: ein Fisch)
Ich bin natürlich sofort in wildes Lachen ausgebrochen. Ich stehe auf den …..!
Veraltet: ownCloud wird nicht mehr aktiv weiterentwickelt. Der Nachfolger ist Nextcloud.
Zur kurzen Beschreibung von ownCloud greife ich jetzt einfach mal ganz faul auf den ersten Absatz aus dem passenden Wikipediaartikel zurück:
### schnipp ###
ownCloud ist eine Software-Suite, die einen ortsunabhängigen Speicherbereich für Daten zur Verfügung stellt. Das Projekt wurde im Januar 2010 vom KDE-Entwickler Frank Karlitschek ins Leben gerufen, um eine freie Alternative zu kommerziellen Cloud-Anbietern zu schaffen. Im Gegensatz zu kommerziellen Speicherdiensten kann ownCloud auf einem privaten Server ohne Zusatzkosten installiert werden. Somit können gerade bei sensiblen Daten die Bedenken gegenüber einer Datenweitergabe und der damit einhergehenden Abgabe der Kontrolle über die Daten zerstreut werden.
Als Grundlage setzt das Projekt auf PHP und einer angebundenen SQLite-, MySQL- oder PostgreSQL-Datenbank. Die ownCloud kann über eine Weboberfläche bedient werden und ist dadurch nicht an ein bestimmtes Betriebssystem gebunden. Aber auch andere Anwendungen, wie beispielsweise Dateimanager oder Groupwares, können die ownCloud über eine Schnittstelle ansprechen und Dateien und Daten lokal bereitstellen.
### schnapp ###
Im Grunde lässt sich ownCloud also mit recht kleinen Grundvoraussetzungen ownCloud in Betrieb nehmen. Selbst die einfache Installation ist nicht weiter aufwendig. Natürlich hängt es immer etwas davon ab, welche Systeme man noch anbinden möchte und wie groß es am Ende wirklich werden soll.
Inzwischen gibt es für alle möglichen Clients auch Software, welche sie an ownCloud anbindet. Evolution, Thunderbird, Kmail (und Anhang), Sync-Clients für Windows/Linux/… Man kann einfach auf seine Dateien per WebDAV zugreifen usw. usw…
Man hat also seine Daten wirklich unter der eigenen Kontrolle und würfelt sie nicht irgendwo hin. Dabei ist die nötige Basis so gering dass es alles sogar über einen Raspberry Pi läuft.
OK… Es hat natürlich einen Haken. Denn es ist wie immer, wenn man selbst dafür verantwortlich ist, dann ist man auch selbst dafür verantwortlich. Alles ist dann nur so sicher wie man es selbst abgesichert hat, sich um die Patchstände kümmert und die Konfiguration vorgenommen hat.
Denn noch bietet man natürlich selbst in der Regel ein nicht ganz so attraktives Ziel wie ein großer Clouddienstleister (ich mag das Wort cloud nicht…).
Siehe auch: ownCloud und Kalender / Kontakte synchronisieren, ownCloud News-App, ownCloud und Mozilla-Sync, Davdroid ownCloud sync
Fragen? Einfach melden.
Lange habe ich nach einem ordentlichen Anbieter für einen neuen vServer gesucht. Dabei galt es folgende Kriterien zu erfüllen:
– Min. 2 IPv4 Adressen
– Ein kleines IPv6 Netz
– Unbegrenzter Traffic
– Min. 100Mbit/s Anbindung
– Min. 2 CPUs
– Min. 4 GB RAM
– Min. 200 GB HDD
– Linux als OS
Natürlich habe ich zuerst die Großen abgeklappert.
– 1und1 kein IPv6 (warum nicht? Ich meine 2014 HALLO!?!?)
– Strato nur EINE IPv6 Adresse (Ö_ö eine IPv6 Adresse…. eine?)
– Host Europe kein IPv6 bei den vServer nur bei den Root Server EINE (tz..)
– 1blue kein IPv6
– Server4you kein IPv6 beim vServer, sonst soll es wohl gehen…
– Serverloft… Joar, die Kosten sind mir zu hoch. Sind aber auch keine vServer.
– usw. usw. usw…
IPv6 scheint noch immer ein größeres Problem zu sein, ist nicht voll integriert oder ist (wie auch meherer IPv4 Adressen) hochpreisigen Produkten vorbehalten.
Dann bin ich auf Contabo gestoßen. Ich war Opfer der Werbung im Linux Magazin 🙁 Preis/Leistung sah dabei einfach zu gut aus. Daher habe ich angerufen. Ohne lange Hoteline sprach ich mit einem Menschen. Diesem stellte ich direkt meine Fragen und er konnte sie überraschenderweise direkt und sicher beantworten. Mit sicher meine ich, dass man nicht das Gefühl hatte er würde es irgendwo nachlesen oder wäre nach einer kurzen Schulung auf die Hotline losgelassen worden. Nein, es war wirklich gut!
Natürlich habe ich abschließend die Frage gestellt wie es klappt dass die angegebene Leistung so gut ist, der Support so schön zu funktionieren scheint und die Ausstattung und Randbedingungen ebenfalls so gut erscheinen. Nach hörbarem Schmunzeln bekam ich die Antwort: Das würde oft gefragt…. Ich müsse es so sehen. Contabo selbst stellt wirklich nur die Hardware und die Infrastruktur. Für das System selbst ist man selbst verantwortlich. Wenn es da mal Probleme gibt, könnte der Support zwar helfen diese wäre dann aber Kostenpflichtig (er meinte damit wenn man seine Kiste mal zerfriemelt hat). Man müsse schon wissen was man tut, dieses würden Contabo bei seinen Produkten einfach voraussetzten.
Schien also genau das zu sein was ich gesucht habe! Daher habe ich bestellt… Wobei ich genau eine solche Antwort von jedem Root-Server erwarten würde.
Alles ging schnell und für mich verständlich online. Ich bekam eine E-Mail mit der Bitte Geld zu überweisen (wer konnte damit nur rechnen. ). Kurz nach meiner Überweisung flatterten bereits die Zugangsdaten in mein Postfach.
Wie bei der Bestellung angeklickt hatte ich schon eine zweite IPv4 Adresse und konnte die PTR-Records flott im Webmenü eintragen. Um die PTR-Records der IPv6 Adressen zu ändern musste ich kurz den Support per E-Mail bemühen. Freitags um 23:36 Uhr habe ich ihn angemailt als ich morgens aufgewacht bin hatte ich schon die Bestätigung in meinem Postfach. Das System selbst ist genau wie bestellt und hat mehr Leistungsreserven als erwartet. Ich habe 8GB Arbeitsspeicher, 400Gb Festplattenplatz und zwei CPUs mit 3,4GHz. Auf der Webseite war nur etwas von 3,2GHz zu lesen. Ok ok… die paar MHz machen den Braten jetzt nicht fett, das es Core I7 CPUs sind hat mich denn noch überrascht!
Ich habe natürlich Speicher und CPU mal mit Arbeit beworfen um zu testen ob es nicht nur Schein ist. Alles prima…. Die Storage Anbindung ist ja gerne mal etwas zu genau auf den Punkt dimensioniert. Bei meinem System kann ich nicht klagen. Performance und I/Os sind wunderbar und mehr als ausreichend.
100Mbit/s sind auch 100Mbit/s… Wobei man hier auf das „Kleingedruckte“ achten muss: Keine zusätzlichen Kosten durch Traffic (bei einem Durchschnittsverbrauch über 40 Mbit/s in einem zusammenhängenden Zeitraum von mindestens 5 Tagen erfolgt eine Umstellung der Anbindung auf 10 Mbit/s).
Zu dem Thema muss ich dann wohl mal eine kleine Auswertung vom Support anfordern. Sollte doch machbar sein, oder?
Ob mich dieses noch ärgert, werde ich herausfinden. Ob mich noch mehr ärgert wird sich zeigen!
Fragen? Einfach melden.
Früher also man noch ifconfig nutzte, da gab es vconfig um VLANs auf einem Linux Rechner zu konfigurieren. Wenn ich mich richtig erinnere ist die Verwendung von ifconfig inzwischen unter Strafe gestellt.
Also BITTE nutzt ip. Es kann mehr, es zeigt auch alles an und es ist viel einfacher. Vertraut mir…
Hier einmal kurz VLAN mit command ip!
Anlegen des VLAN Interfaces:
$ ip link add link eth0 name eth0.10 type vlan id 10
Vergeben eine IPv4 Adresse auf dieses neue VLAN Interface:
$ ip -4 addr add 192.168.10.1/24 dev eth0.10
Aktivieren des neuen VLAN Interfaces:
$ ip -4 addr add 192.168.10.1/24 dev eth0.10
Damit haben wir nun ein VLAN Interface mit der VLAN ID 10 und der IPv4 Adresse 192.168.10.1 und der Netzmaske 255.255.255.0. Die .10 im Interfacenamen hat nichts mit der VLAN ID zutun. Ich nenne es nur gerne so um es für mich einfacher zu machen.
Ein Tool, sinnvoll aufgebaut, für fast alles nutzbar, funktioniert, geil. Benutzt es.
Fragen? Einfach melden.
Ich hocke hier an meinem Sabayon Linux Hobel und bin etwas genervt da ich einen einfachen ping oder ping6 nur mit den erweiterten Rechten vom root ausführen kann.
$ ping www.kernel-error.de ping: icmp open socket: Operation not permitted
Um es mir einfach zu machen hilft es die Rechte an den beiden Programmen zu ändern:
$ chmod u+s /bin/ping $ chmod u+s /bin/ping6
Schon kann fast jeder User wieder pingen!
Fragen? Einfach melden.
Ja, die liebe fe80 Adressen! Wer schon mal ganz unbedarft folgendes in seine Konsole hämmert:
$ ping6 fe80::20c:42ff:fe72:2ba6 connect: Invalid argument
Wundert sich sicher im ersten Moment über die freche Antwort: „connect: Invalid argument“. ABER das ist absolut richtig. Denn wenn man mehrere Netzwerkkarten in seinem Rechner verbastelt hat, dann hat man ebenfalls mehrere fe80 link local Adressen. Nämlich mindestens eine pro Netzwerkkarte. Damit sollte es jetzt schon klingeln, hm? Noch nicht? Na woher soll das Paket den bitte wissen über welche der Netzwerkkarten es denn den Weg zur angepingten Adresse nehmen soll?!?!? Genau überhaupt nicht! Daher muss das Interface welches als „Ausgang“ genutzt werden soll immer mit angegeben werden.
$ ping6 fe80::20c:42ff:fe72:2ba6%eth0 PING fe80::20c:42ff:fe72:2ba6%eth0(fe80::20c:42ff:fe72:2ba6) 56 data bytes 64 bytes from fe80::20c:42ff:fe72:2ba6: icmp_seq=1 ttl=64 time=0.323 ms --- fe80::20c:42ff:fe72:2ba6%eth0 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.323/0.323/0.323/0.000 ms
Unter Linux gibt man einfach %NIC-Name an und unter Windows einfach %NIC-ID:
C:\>ping -6 fe80::20c:42ff:fe72:2ba6%3 Ping wird ausgeführt für fe80::20c:42ff:fe72:2ba6%3 mit 32 Bytes Daten: Antwort von fe80::20c:42ff:fe72:2ba6%3: Zeit<1ms Antwort von fe80::20c:42ff:fe72:2ba6%3: Zeit<1ms Ping-Statistik für fe80::20c:42ff:fe72:2ba6%3: Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms C:\>
Wobei ich die Meldung eines Microsoft Windows doch schnell etwas verwirrend finde. Denn hier gibt es nur die Rückmeldung dass das Zielnetz nicht erreichbar ist. Was ja im Grunde korrekt ist, nur grenzt es leider den Fehler nicht so schön ein!
C:\>ping -6 fe80::20c:42ff:fe72:2ba6 Ping wird ausgeführt für fe80::20c:42ff:fe72:2ba6 mit 32 Bytes Daten: Zielnetz nicht erreichbar. Zielnetz nicht erreichbar. Zielnetz nicht erreichbar. Zielnetz nicht erreichbar. Ping-Statistik für fe80::20c:42ff:fe72:2ba6: Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust), C:\>
Japp, so einfach kann es sein.
Siehe auch: IPv6 Grundlagen
Fragen? Einfach melden.
Veraltet: Sabayon Linux wurde 2020 eingestellt. ClamAV lässt sich unter jedem aktuellen Linux problemlos installieren.
Ich sitze hier gerade vor einem Sabayon mit XFCE und wundere mich darüber dass der ClamAV nicht nach der Installation „out of the Box“ funktioniert.
Folgende kurze Schritte sind nötig damit er bei mir die Basisarbeit in aktueller Form aufnimmt.
$ equo install app-antivirus/clamav $ cp /etc/freshclam.conf.sample /etc/freshclam.conf $ systemctl enable freshclamd.service $ systemctl enable clamd.service $ systemctl start freshclamd.service $ systemctl start clamd.service
So long…
Veraltet: Solaris 11 und OpenIndiana werden kaum noch eingesetzt. Unter FreeBSD lautet der Befehl shutdown -p now, unter Linux systemctl poweroff.
Ich habe heute einen Anruf eines befreundeten Sysadmins bekommen. Der arme muss darf heute bei einem seiner Kunden den Serveraum umziehen… Dafür möchte er nun die Systeme abschalten. Jetzt steht dort ein Solaris 11 System und der zum System gehörende Admin ist krank (zufällig am Feiertag des Serverraumumzuges…)! Jetzt steht mein Bekannter also vor der Konsole und will die Kiste im Grunde nur abschalten. Folgendes Gespräch ergab sich:
Bekannter: init 0 geht nicht, beim shutdown -h now soll -h eine unknown option sein. Ich bin genervt… Wie geht das aus?
Ich: Solaris 11 im poduktiveinsatz? Dann habt ihr auch Support von Oracle; anrufen / chatte die helfen immer sofort.
Bekannter: Laber nicht rum, ich bin hier für die Microsoft Maschinen. Keine Ahnung wo ich weh anrufen kann. Du kannst das doch, oder?
Ich: Joar… Folgendes sollte dir helfen:
$ shutdown -y -i5 -g0
Bekanter: *Klacker Tipper*
Ich: Root Konsole hattest du schon oder?
Bekannter: *Klacker* japp *Klacker*
Ich: shutdown ist shutdown, -y ist damit du nicht gefragt wirst -i5 ist um die Kiste nach dem Shutdown auch aus zu machen und -g0 ist das es unverzüglich gemacht wird.
Bekannter: Warum ist das so kompliziert? Geht das nicht einfacher? Bei Linux ist das doch einfach shutdown -h now… Man… Ich will eine Maus! Ahh ich glaube er fährt runter!
Ich: Du hättest mit man shutdown den korrekten Befehl erlesen können.
Bekannter: Ach, das muss einfacher gehen!
Ich: Ok dann nimmer das nächste mal den Befehl poweroff…
Bekannter: Du Sack! Danke..
Ich finde es schon sinnvoll unterschiedliche Arten eines shutdown zu haben. Vor allem mit verschiedenen Arten der Signalisierung.
Man stolpert irgendwann über diese Meldung im Kernel-Log:
rt6_redirect: source isn't a valid nexthop for redirect target
Gerne im Zusammenhang mit IPv6, gerne dann, wenn man glaubt, eigentlich alles richtig gemacht zu haben. Routing stimmt. Neighbors sehen gut aus. Und trotzdem meckert der Kernel.
Die Kurzfassung: Der Linux-Kernel hat ein ICMPv6 Redirect bekommen und lehnt es ab, weil der vorgeschlagene Next Hop aus seiner Sicht kein gültiger First Hop ist.
ICMPv6 Redirects (Typ 137) sind Teil von Neighbor Discovery. Ein Router sagt damit zu einem Host sinngemäß:
„Für dieses Ziel gibt es einen besseren ersten Hop als mich.“
Wichtig: erster Hop. Nicht irgendein Router irgendwo, sondern ein direkt erreichbarer Nachbar auf dem Link.
Ein Redirect enthält deshalb zwei zentrale Informationen:
Und jetzt kommt der Teil, den viele Implementierungen (und Admins) gerne unterschätzen:
Der Host muss diesem Vorschlag nicht glauben.
Linux ist bei Redirects ziemlich streng. Zu Recht. Redirects sind ein beliebtes Einfallstor für Unsinn und Angriffe.
Bevor der Kernel ein Redirect akzeptiert, prüft er u. a.:
Und genau hier schlägt diese Logmeldung zu.
Der Kernel schaut auf den Better Next Hop im Redirect und stellt fest:
„Diese Adresse kann für dieses Ziel kein gültiger Next Hop sein.“
Dann wird das Redirect verworfen. Keine neue Route. Kein Update. Nur diese Meldung.
In der Praxis sieht man das oft in Setups, in denen Router ihre Default-Route oder interne Routen nicht sauber über Link-Local-Adressen aufbauen.
Beispiel (vereinfacht):
default via 2001:db8:1::1 dev eth0
Sieht harmlos aus. Funktioniert auch meistens. Aber:
IPv6 erwartet, dass Router auf einem Link über ihre Link-Local-Adresse angesprochen werden.
Korrekt wäre also eher:
default via fe80::1 dev eth0
Was passiert nun?
Der Router verschickt ein Redirect und trägt als „Better Next Hop“ seine globale Adresse ein (z. B. 2001:db8:1::1).
Der Host bekommt das Redirect, prüft es – und sagt:
„Moment. Dieser Next Hop ist kein gültiger direkt erreichbarer Neighbor für dieses Ziel.“
Und genau dann landet diese Meldung im Log.
Wichtig:
Das Problem ist nicht primär, dass die Adresse global ist.
Das Problem ist, dass der Kernel den vorgeschlagenen Next Hop nicht als legitimen First Hop auf diesem Link akzeptiert.
Link-Local ist der Normalfall. Alles andere muss extrem gut begründet sein – und ist es fast nie.
Wenn man wissen will, warum der Kernel das Redirect ablehnt, lohnt sich ein Blick in die Neighbor-Daten:
ip -6 neigh show
Oder gezielter:
ip -6 route get 2001:db8:dead:beef::1
Wenn der vorgeschlagene Next Hop dort nicht als sinnvoller Neighbor auftaucht, ist die Sache im Prinzip entschieden.
Kein Neighbor → kein gültiger Next Hop → Redirect wird verworfen.
Wenn man genau wissen will, ob der Router wirklich ein Redirect schickt und was er als Next Hop vorschlägt, hilft tcpdump. ICMPv6 Typ 137 ist das Redirect:
tcpdump -n -i eth0 'icmp6 and ip6[40] == 137'
Im Paket sieht man den Router als Absender, das Target (Ziel, für das der Hinweis gilt) und den Better Next Hop. Passt der Next Hop nicht zu einem gültigen Neighbor auf dem Link, ist klar warum der Kernel ablehnt.
Ebenfalls nützlich: ob der Host Redirects überhaupt annehmen will.
sysctl net.ipv6.conf.all.accept_redirects sysctl net.ipv6.conf.eth0.accept_redirects
Default ist 1 auf einem Host, 0 auf einem Router. Zusätzlich greift secure_redirects (Default 1): nur Redirects von bereits bekannten Gateways werden überhaupt akzeptiert.
Wer die Route selbst setzt (statische Konfiguration ohne RA), sollte Link-Local nehmen. Link-Local ist pro Interface nicht eindeutig, der Eintrag braucht also immer ein dev:
ip -6 route add default via fe80::1 dev eth0
Persistenz hängt vom System ab. systemd-networkd in /etc/systemd/network/*.network unter [Route] Gateway=fe80::1, netplan in /etc/netplan/*.yaml, die klassische /etc/network/interfaces kennt post-up ip -6 route .... Wichtig: das Interface muss im Eintrag stehen.
Mit Link-Local als Next Hop verschwindet die rt6_redirect-Meldung in der Regel. Der Kernel hat einen gültigen First Hop als Neighbor, und ein Redirect desselben Routers passt dann sauber ins Modell.
Auf Servern in kontrollierten Hosting-Umgebungen (Hetzner, Netcup, Cloud-VPCs) ist das Routing sauber vorgegeben, und der Provider-Router hat keinen besseren Next Hop anzubieten. Dann sind ICMPv6-Redirects nur Rauschen im Log:
sysctl -w net.ipv6.conf.all.accept_redirects=0 sysctl -w net.ipv6.conf.default.accept_redirects=0
Persistent in /etc/sysctl.d/99-ipv6.conf. Nachteil: kennt der Router tatsächlich einen legitimen besseren Weg, bleibt der Host trotzdem bei seiner existierenden Route. Im Rechenzentrum mit einer einzigen Default-Route ist das genau richtig, in einem verzweigten Firmennetz mit mehreren Uplinks eher nicht.
Die Meldung klingt erstmal nach kaputtem Routing. Ist es aber meistens nicht.
Im Gegenteil:
Der Kernel verhält sich exakt so, wie es das Protokoll vorsieht. Redirects sind Hinweise, keine Befehle. Und Linux nimmt diese Hinweise nur an, wenn sie sauber in das bestehende Neighbor- und Routing-Modell passen.
Das schützt unter anderem vor:
In modernen Setups begegnet einem die Meldung seltener. Nicht weil das Protokoll sich geändert hätte, sondern weil die Umgebung drumherum sauberer geworden ist:
Übrig bleibt die Meldung heute fast nur in selbstgebauten VM- und Container-Setups, in denen Host- und Gast-Routing nicht sauber zusammenpassen, oder wenn in statischer Konfiguration aus Gewohnheit eine globale Adresse als Next Hop gesetzt wird.
Die Meldung
rt6_redirect: source isn't a valid nexthop for redirect target
bedeutet nicht „IPv6 kaputt“.
Sie bedeutet: Ein Router hat ein Redirect geschickt, das aus Sicht des Hosts keinen gültigen Next Hop beschreibt.
In der Praxis ist das fast immer ein Hinweis auf:
Oder anders gesagt:
Der Kernel ist hier nicht pingelig. Er ist vorsichtig. Und das ist gut so.
Siehe auch: IPv6 Grundlagen. Zum Nachlesen: RFC 4861 §8 (Redirect-Handling bei Hosts) und RFC 6980 (fragmentiertes Neighbor Discovery ist verboten — ein harter Security-Fix für ND-Spoofing).
Fragen? Einfach melden.
Absolut sicher ist nichts. Man kann nur versuchen, es Angreifern so aufwendig wie möglich zu machen. Bei GPG-Schlüsseln fängt das bei der Schlüssellänge und den Algorithmen an.
DSA-Schlüssel sind auf 512-1024 Bit begrenzt und anfällig bei schlechten Zufallsgeneratoren. ElGamal-Schlüssel können beliebig groß werden, teilen aber das Zufallsproblem. RSA mit 4096 Bit ist heute ein guter Kompromiss: rechenbar für aktuelle Hardware, nicht rechenbar für bekannte Angriffe. Quantencomputer könnten RSA in Zukunft gefährden, sind davon aber noch weit entfernt.
gpg --version
Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2
MD5 ist gebrochen, SHA1 gilt als unsicher. SHA-256 und SHA-512 sind die sinnvolle Wahl. Bei den symmetrischen Verfahren sind AES-256 und Twofish solide. 3DES bleibt als Fallback, weil GPG es als Pflichtverfahren mitführt.
Man kann im eigenen Schlüssel festlegen, welche Algorithmen in welcher Reihenfolge bevorzugt werden. Die kurze Key-ID (0x0F9874D8) reicht dafür, auch wenn man für andere Zwecke besser die volle Fingerprint-ID nutzt.
gpg --edit-key 0x0F9874D8
Aktuelle Einstellungen anzeigen:
gpg> showpref [ uneing.] (1). Sebastian van de Meer (E-Mail Address) kernel-error @ kernel-error.com; Verschlü.: TWOFISH, AES256, AES192, 3DES Digest: RIPEMD160, SHA512, SHA256, SHA1 Komprimierung: BZIP2, ZLIB, nicht komprimiert Eigenschaften: MDC, Keyserver no-modify
Gewünschte Algorithmen setzen:
gpg> setpref TWOFISH AES256 AES192 RIPEMD160 SHA512 SHA256 BZIP2 ZLIB gpg> q Änderungen speichern? (j/N) j
Der Schlüssel arbeitet ab sofort nur noch mit den festgelegten Verfahren. Kommunikationspartner, deren GPG-Installation keines dieser Verfahren unterstützt, fallen automatisch auf 3DES zurück.
Welchen Verfahren man letztlich vertraut, muss jeder für sich entscheiden.
Die Schlüssel-Präferenzen oben sind der erste Schritt. Der zweite ist die lokale gpg.conf. Sie bestimmt, welche Algorithmen GnuPG überhaupt anbietet, wie die Passphrase gehärtet wird und wo nach Schlüsseln gesucht wird. Meine aktuelle Konfiguration für GnuPG 2.4 unter Linux:
# ~/.gnupg/gpg.conf — Hardened Config für GnuPG 2.4 # Ausgabe: lange Key-IDs und Fingerprints anzeigen keyid-format 0xlong with-fingerprint utf8-strings # Schlüssel automatisch suchen: erst WKD, dann DANE, dann Keyserver auto-key-retrieve auto-key-locate wkd,dane,local,keyserver keyserver hkps://keys.openpgp.org # Starke Defaults cipher-algo AES256 digest-algo SHA512 cert-digest-algo SHA512 # KDF-Härtung: S2K mit 65 Mio. Iterationen s2k-mode 3 s2k-digest-algo SHA512 s2k-cipher-algo AES256 s2k-count 65011712 # Legacy-Algorithmen komplett deaktivieren disable-cipher-algo 3DES disable-cipher-algo IDEA disable-cipher-algo CAST5 disable-cipher-algo BLOWFISH disable-cipher-algo TWOFISH # Metadata minimieren no-comments no-emit-version export-options export-minimal # Trust-Modell: TOFU kombiniert mit Web of Trust trust-model tofu+pgp # Bevorzugte Algorithmen (lokal) personal-cipher-preferences AES256 AES192 AES personal-digest-preferences SHA512 SHA384 SHA256 weak-digest SHA1 force-ocb # Default-Key (Ed25519) default-key 0x5F279C362EEAB216
Ed25519 statt RSA. Mein aktueller Schlüssel ist ein Ed25519. Kürzere Schlüssel, schnellere Operationen, gleiche Sicherheit. RSA 4096 funktioniert weiterhin, aber für neue Schlüssel gibt es keinen Grund mehr dafür.
Legacy-Algorithmen deaktiviert. 3DES, IDEA, CAST5, Blowfish und Twofish sind per disable-cipher-algo komplett gesperrt. GnuPG bietet sie nicht mehr an und akzeptiert sie nicht. Das ist aggressiver als setpref, weil es auch eingehende Nachrichten betrifft. Wer damit Probleme bekommt, hat ein Gegenüber mit sehr veraltetem Setup.
S2K-Hardening. Die s2k-count Direktive bestimmt, wie oft die Passphrase bei symmetrischer Verschlüsselung gehasht wird. 65 Millionen Iterationen machen Brute-Force auf die Passphrase deutlich teurer. Der Wert ist der Maximalwert, den GnuPG akzeptiert.
OCB statt MDC. force-ocb erzwingt Authenticated Encryption (OCB) statt des älteren MDC (Modification Detection Code). OCB erkennt Manipulationen kryptographisch, nicht nur per Hash.
TOFU+PGP. trust-model tofu+pgp kombiniert das klassische Web of Trust mit Trust on First Use. Beim ersten Kontakt wird der Schlüssel akzeptiert, danach warnt GnuPG bei Änderungen. Pragmatischer als reines WoT, das in der Praxis kaum jemand pflegt.
WKD und DANE. auto-key-locate wkd,dane,local,keyserver sucht Schlüssel zuerst per Web Key Directory und DANE, bevor der Keyserver gefragt wird. WKD liefert den Schlüssel direkt von der Domain des Empfängers. keys.openpgp.org als Keyserver statt der alten SKS-Pools, weil dort E-Mail-Adressen nur nach Bestätigung veröffentlicht werden.
Metadata minimieren. no-comments, no-emit-version und export-minimal sorgen dafür, dass verschlüsselte Nachrichten und exportierte Schlüssel keine unnötigen Informationen enthalten. Kein Kommentarfeld, keine GnuPG-Versionsnummer, keine überflüssigen Signaturen beim Export.
Siehe auch: GPG: E-Mails signieren und verschlüsseln mit GnuPG, GPG-Schlüssel per PKA im DNS veröffentlichen, OPENPGPKEY: GPG-Schlüssel direkt im DNS veröffentlichen
Fragen? Einfach melden.
© 2026 -=Kernel-Error=- — RSS
Theme von Anders Norén — Hoch ↑