B.t.w.: Your internet fits in my subnet…. IPv6, new world order.
Fragen? Einfach melden.
Kategorie: Kernel-Error-Blog (Seite 39 von 47)
Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.
RIPE ist in Sachen IPv4 Adressen nun soweit leer dass sie nun auf ein „erweitertes“ Vergabeverfahren wechseln. Soll bedeuten dass nun ganz super streng (bla bla bla) kontrolliert wird warum und wo die Adresse hingeht und ob die auch wirklich gebraucht wird…..
Wie auch immer! Damit man sich besonders gut anschauen kann was noch übrig ist gibt es von den Jungs selbst eine kleine Grafik (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph).
Dass ich ein großer Freund davon bin, mal endlich mit IPv6 aus dem Arsch zu kommen, muss ich ja keinem mehr erzählen. Wenn ich mir andere Hochrechnungen anschaue (http://www.potaroo.net/tools/ipv4/index.html) dann haben wir aktuelle noch bis zum 24.09.2012 (das ändert sich noch mal) IPv4 Adressen.
Ja ja… IPv4 ist ab dem Tag nicht tot (Dualstack für die nächsten Jahre..) und unsere Provider und Hoster haben auch noch Reserven. Zusätzlich kann man ab dem Moment beginnen seine IPv4 Adressen zu verkaufen *lach*….. AAAABBBER, warum der ganze Stress? Warum nicht einfach mal mit IPv6 beschäftigen? Nein nein, ich meine wirklich beschäftigen, nicht nur so tun als ob.
Siehe auch: IPv4-Adressen sind aufgebraucht
Fragen? Einfach melden.
Ein trauriger Tag *schnief* denn ich muss mich wohl von meiner lieblings Pommesbude trennen. Nostalgie Pizzeria in Sprockhövel….. Die Gerichte sind nicht wirklich schlecht aber Preis/Leistung passt aus meiner Sicht einfach nicht mehr zusammen. Die Qualität ist irgendwie in den letzten 1,5 Jahren immer immer immer weiter abgesackt. Langsam aber stetig, so zumindest der eindeutige Eindruck von mir und meiner Familie.
Nun ist es dann wohl so weit, lange habe ich es herausgezögert 🙁 jetzt muss ich mir denn noch einen neuen Lieferservice suchen. Die letzte Bestellung beendete eindeutig unser „Verhältnis“. Bye bye Restaurant Pizzeria Nostalgie.
Fragen? Einfach melden.
Wie jeden letzten Freitag im Juli ist es wieder so weit: Sysadmin Day *feier*
Ich hoffe ihr wart auch alle bei euren Sysadmins und habt lieb danke gesagt, mit einem kleinen Geschenk…. Ein Kasten vorgekühlte Mate wäre da schon das mindeste, oder? Da muss ich doch heute einfach noch mal Devotion to Duty zur Feier des Tages lesen.
Also lieb dem Admin danke sagen, nicht vergessen.
Fragen? Einfach melden.
Na also, nun hat die Telekom die Sicherheitsrichtlinien ihrer E-Mail Server so angepasst dass helo, hostname und R-DNS zusammenpassen müssen. Sonst gibt es diese Meldung:
A problem occurred. (Ask your postmaster for help or to contact tosa@rx.t-online.de to clarify.)
So gefällt mir das! Meine Kiste macht dieses ja schon länger so und ich bekomme immer mal wieder die Info, man könne mir keine E-Mail schicken. Mein Mailserver sei wohl kaputt, er sage immer:
550 5.7.1 Client host rejected: cannot find your hostname….
Wenn ich dann erkläre um was es geht bekomme ich immer mal wieder den Vorwurf da zu –genau- zu sein. Da jetzt noch ein weiteres großes Unternehmen genau so verfährt werden sich wohl noch mehr Mailserver „Administratoren“ um dieses Problem kümmern müssen. Lustig finde ich ja dass die Telekom direkt eine E-Mail Adresse angegeben hat tosa@rx.t-online.de, was da wohl abgehen muss.
http://www.kernel-error.de/postfix-spam-und-virenabwehr-durch-helo
Siehe auch: SPF-Record einrichten
Fragen? Einfach melden.
Na toll… Unsere RIPE hat gerade echte Probleme mit ihrem DNS System. Da brennt wohl gerade der Busch:
RIPE schreibt folgendes an die RIPE-Members-Mailingliste:
„It seems that our DNS provisioning system has developed a major fault, with the result that it is unable to generate DNS zonelets for the other RIRs.
This required a complete bootstrap of the system, and unfortunately, this may take a few hours, during which no DNS provisioning will happen.
We are aware of the problems and our engineers in the DNS department are working hard to fix the issue as soon as possible. Unfortunately at the moment we are not able to provide an estimated time of the repair yet.
An announcement will be sent out to all the Working Group Mailing list with a detailed explanation of the issue and a summary of what is actually being done for fixing it.
Please accept our apologies for the inconvenience and the troubles that the issue may have caused to you.
Regards,
Jarek“
Die Liste ist aber nicht wirklich aktuell….
Hier auch noch mehr: http://www.ripe.net/lir-services/service-announcements
Siehe auch: Reverse Map Delegation
Fragen? Einfach melden.
Dass mein DNS-Server DNSsec http://www.kernel-error.de/dnssec beherscht und so meine Zonen schützt, das wissen ja fast alle. Wie man damit nun seinen GPG Schlüssel verteilen kann und/oder die SSH-Fingerprints einzelner Hosts gegen den DNS Server validieren lassen kann…. Dieses findet sich nun hier:
GPG im DNS: http://www.kernel-error.de/dnssec/gpg-im-dns
SSH-Key im DNS: http://www.kernel-error.de/dnssec/ssh-key-im-dns
Fragen? Einfach melden.
Hinweis: PKA (Public Key Association) wird von GnuPG seit Version 2.1 (2014) nicht mehr unterstützt. Der Nachfolger ist der OPENPGPKEY Resource Record, der den kompletten Schlüssel direkt im DNS speichert. Dieser Beitrag beschreibt das ältere PKA-Verfahren — historisch interessant, aber für neue Setups nicht mehr empfehlenswert.
Die Idee hinter PKA
GnuPG konnte über DNS nach GPG-Schlüsseln fragen. Der Vorteil: Ich muss meinen öffentlichen Schlüssel nicht auf Keyservern verteilen, sondern veröffentliche ihn über meinen eigenen DNS-Server. Ist die Zone per DNSSEC geschützt, kann der Schlüssel nicht gefälscht werden — deutlich vertrauenswürdiger als Keyserver, auf denen jeder beliebige Schlüssel hochladen kann.
PKA funktioniert mit einem TXT-Record, der den Fingerprint des Schlüssels und eine URL zum Download enthält. GnuPG prüft den Fingerprint gegen den heruntergeladenen Schlüssel — stimmt beides überein, wird der Schlüssel importiert.
Schlüssel exportieren
Zuerst den öffentlichen Schlüssel exportieren und auf dem Webserver ablegen:
gpg --list-keys --fingerprint kernel-error@kernel-error.com gpg --export --armor 0F9874D8 > kernel-error.asc
Die exportierte Datei muss per HTTP erreichbar sein — HTTPS ist nicht zwingend nötig, da der Schlüssel am Ende gegen den Fingerprint aus dem DNS geprüft wird.
PKA-Record erstellen
Der PKA-Record ist ein TXT-Record unter localpart._pka.domain. Er enthält den Fingerprint und die URL zum Schlüssel:
kernel-error._pka.kernel-error.com. IN TXT "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"
Aufbau: Das @ in der E-Mail-Adresse wird durch ._pka. ersetzt. Der Record enthält die PKA-Version (v=pka1), den vollständigen Fingerprint (fpr=...) und die Download-URL (uri=...). Für jede E-Mail-Adresse, unter der man erreichbar ist, braucht man einen eigenen Record — auch über verschiedene Zonen hinweg.
Prüfen
Mit dig testen, ob der Record im DNS angekommen ist:
dig +short kernel-error._pka.kernel-error.com TXT "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"
GnuPG (bis Version 2.0) konnte den Schlüssel dann automatisch finden und importieren:
echo "test" | gpg --auto-key-locate pka --keyring /tmp/test.gpg \ --encrypt --armor -r kernel-error@kernel-error.com
GnuPG fragt den PKA-Record ab, lädt den Schlüssel von der angegebenen URL herunter, prüft den Fingerprint und importiert den Schlüssel in den Keyring.
Warum OPENPGPKEY besser ist
PKA hatte zwei Schwächen: Der Schlüssel lag nicht im DNS selbst, sondern musste per HTTP heruntergeladen werden — ein zusätzlicher Angriffsvektor. Und der TXT-Record war auf 255 Bytes pro String begrenzt, was bei langen URLs und Fingerprints knapp wurde.
Der OPENPGPKEY Resource Record (RFC 7929) löst beides: Der komplette Schlüssel steckt direkt im DNS, kein HTTP-Download nötig. Mit DNSSEC ist die gesamte Kette vom DNS-Lookup bis zum Schlüssel kryptographisch abgesichert.
Siehe auch: OPENPGPKEY im DNS, GPG: E-Mails signieren und verschlüsseln mit GnuPG, Der sichere GPG-Schlüssel
Fragen? Einfach melden.
OpenSSH kann die Fingerprints seiner Host Keys als SSHFP-Records im DNS veröffentlichen. Beim Verbindungsaufbau prüft der Client dann automatisch, ob der Fingerprint des Servers mit dem DNS-Eintrag übereinstimmt, ein wirksamer Schutz gegen Man-in-the-Middle-Angriffe. Ist die Zone zusätzlich per DNSSEC gesichert, kann der DNS-Record selbst nicht gefälscht werden. Die Spezifikation steht in RFC 4255.
Client konfigurieren
Damit OpenSSH beim Verbindungsaufbau SSHFP-Records prüft, muss VerifyHostKeyDNS aktiviert werden. Global für alle Benutzer in /etc/ssh/ssh_config:
VerifyHostKeyDNS yes
Oder nur für die aktuelle Sitzung:
ssh -o "VerifyHostKeyDNS=yes" server.example.de
SSHFP-Records erzeugen
Am einfachsten direkt auf dem Server mit ssh-keygen, das erzeugt die fertigen DNS-Records für alle vorhandenen Host Keys:
ssh-keygen -r server.example.de.
Ausgabe (Beispiel mit RSA, ECDSA und Ed25519):
server.example.de. IN SSHFP 1 1 47890eecc9a2893061734b07b8f60caa1a856148 server.example.de. IN SSHFP 1 2 b2518ad49cc2adf517d3f6a9faaf4017abc2c3e3... server.example.de. IN SSHFP 3 1 3dd9de0dcf1523341b45a53f1d57043609e26c62 server.example.de. IN SSHFP 3 2 e1c76bd66b5a0641789b0b37be5b80ae3f6395c1... server.example.de. IN SSHFP 4 1 a1b2c3d4e5f6... server.example.de. IN SSHFP 4 2 d4e5f6a7b8c9...
Aufbau des SSHFP-Records
Ein SSHFP-Record besteht aus zwei Zahlen und dem Fingerprint:
hostname IN SSHFP [Algorithmus] [Hash-Typ] [Fingerprint]
Algorithmus:
- 1, RSA
- 3, ECDSA
- 4, Ed25519 (empfohlen, ab OpenSSH 6.7)
DSS (2) ist seit OpenSSH 7.0 standardmäßig deaktiviert und sollte nicht mehr verwendet werden.
Hash-Typ: 1 = SHA-1, 2 = SHA-256. Beide sollten veröffentlicht werden, ältere Clients verstehen nur SHA-1, neuere bevorzugen SHA-256.
Prüfen
Mit dig lässt sich prüfen, ob die Records im DNS angekommen sind:
dig +short server.example.de SSHFP 1 1 47890EECC9A2893061734B07B8F60CAA1A856148 1 2 B2518AD49CC2ADF517D3F6A9FAAF4017ABC2C3E3... 3 1 3DD9DE0DCF1523341B45A53F1D57043609E26C62 4 2 D4E5F6A7B8C9...
Wichtig: Bei der DNSSEC-validierten Abfrage muss das ad-Flag (Authenticated Data) gesetzt sein, sonst ist die Antwort nicht vertrauenswürdig:
dig +dnssec server.example.de SSHFP | grep flags ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
Verbindungsaufbau mit SSHFP
Ohne SSHFP-Records im DNS meldet OpenSSH:
DNS lookup error: data does not exist No matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?
Mit SSHFP-Records und DNSSEC:
debug1: found 4 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS
secure bedeutet: Die DNS-Antwort wurde per DNSSEC validiert. Ohne DNSSEC steht dort insecure, der Fingerprint wurde zwar gefunden, aber der DNS-Antwort selbst kann nicht vertraut werden. Für echte Sicherheit braucht man beides: SSHFP-Records und DNSSEC.
Strenge Prüfung erzwingen
Optional: OpenSSH anweisen, die Verbindung nur aufzubauen, wenn der Host Key erfolgreich validiert wurde:
Host *
VerifyHostKeyDNS yes
StrictHostKeyChecking yes
Damit wird die Verbindung abgelehnt, wenn kein passender SSHFP-Record gefunden wird oder die DNSSEC-Validierung fehlschlägt. Das ist die sicherste Einstellung, setzt aber voraus, dass alle Zielserver SSHFP-Records haben.
Kleiner Aufwand, viel mehr Sicherheit. Fragen? Einfach melden.
Ein Scrub ist die Integritätsprüfung von ZFS — jeder Block im Pool wird gelesen und seine Checksumme verifiziert. Beschädigte Blöcke werden automatisch aus der Redundanz repariert (Mirror oder RAID-Z). Ohne Redundanz erkennt ZFS den Fehler immerhin, kann ihn aber nicht korrigieren.
Empfehlung: Einmal pro Woche oder mindestens einmal im Monat. Auf Produktivsystemen am besten per Cronjob.
Scrub starten
zpool scrub backup
Fortschritt prüfen
zpool status backup
pool: backup
state: ONLINE
scan: scrub in progress since Sun May 27 11:11:00 2012
4.20G scanned out of 74.5G at 102M/s, 0h11m to go
0 repaired, 5.64% done
Scrub abbrechen
Braucht man die I/O-Leistung gerade für etwas anderes:
zpool scrub -s backup
Im Status sieht man dann den Unterschied — stopped statt completed:
# Abgebrochen scan: scrub stopped after 0h7m with 0 errors on Sun May 27 11:18:52 2012 # Normal beendet scan: scrub completed after 0h7m with 0 errors on Sun May 26 10:52:13 2012
Ein abgebrochener Scrub setzt beim nächsten Start nicht dort fort, sondern beginnt von vorne.
Scrub per Cronjob
# Jeden Sonntag um 02:00 alle Pools scrubben 0 2 * * 0 /sbin/zpool scrub backup
Unter FreeBSD läuft der Scrub standardmäßig über periodic daily — dort muss man nichts extra einrichten. Unter Linux gibt es je nach Distribution einen systemd-Timer (zfs-scrub-weekly.timer) oder man legt den Cronjob selbst an.
Mehr zu ZFS: ZFS RAID: Mirror und RAID-Z und ZFS Snapshots. Fragen? Einfach melden.