-=Kernel-Error=-

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

Schlagwort: Networking (Seite 9 von 12)

DKIM Schüssel getauscht

12. November 2012 / / Keine Kommentare

Nachdem nun alle etwas nervös wegen zu kurzer DKIM Keys sind (512Bit), diese lassen sich wohl bei Amazon in knapp 72 Stunden knacken. Habe ich dann meine Schlüssel auch einmal getauscht. Diese hatten bisher eine Länge von 1024 Bit, mit diesen wäre ich also noch locker auf der sicheren Seite denn noch kann es ja nicht schaden sie auf 2048Bit aufzubohren. Fast alle Systeme können mit diesen inzwischen umgehen. Die Leistung aktueller Systeme sollte heute ebenfalls nicht sonderlich unter diesen Schlüssellänge leiden.

Die Schlüssel sind schnell erstellt:

$ dkim-genkey -b 2048 -s kernel-error.de -d kernel-error.de

Wie gewohnt habe ich dann den TXT-RECORD in mein Zonenfile gekippt. Beim signieren der Zone per DNSsec sprang mich aber folgende Fehlermeldung an:

dnssec-signzone: error: dns_rdata_fromtext: kernel-error.de:25: ran out of space

Na nu? Ach so… ja klar! Der TXT-RECORD ist zu lang. Da gibt es ja eine Beschränkung…. Fast vergessen! Mehr als 255 Zeichen sind ja nicht zulässig. Ich musste den DKIM TXT-RECORD also in ein multi-line TXT-RECORD umwandeln. Nicht weiter kompliziert, einfach Klammer auf, Klammer zu und alles brav mit Anführungszeichen trennen. Damit sieht mein Zoneneintrag nun wie folgt aus:

kernel-error.de._domainkey IN TXT ( "v=DKIM1; g=*; k=rsa; "
                    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1V7WG+ZchvAxfJ2wi9jn7vWVs2mDkk66cqrKjTETdbuPwL"
                    "CX4N4IXTemT7SMS2Z+gTxcPNnUCorcMsXigNlGJK4Oq8GNx0fcxbXB+vq522FpM6FY8FVTfhL7bqLg5ajp9k0boJnSRv"
                    "F4wY3nci6E7CYCdP9XjHVoOciJdlrGFMo8rYGGiI9Ubgvue8etqgPCV2T8BKEZgys7kabPyaujSHmqrPbBkjb/F+QPJH"
                    "WqcyD7ywfT5vUkrj40Qiwsr7HxGk9aYCAHwyvdP4dvXd5xfMH2QlRKbrMjIQfKJfD5cfTiAl7YgFBFO1n7Wfj5syB6FE"
                    "bRZR9HO+rusv0hojiViQIDAQAB" )

Schnell noch mit einer Testmail an: check-auth@verifier.port25.com prüfen ob alles korrekt ist.

Fertig….

----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result:         pass (matches From: kernel-error@kernel-error.com)
ID(s) verified: header.d=kernel-error.com
Canonicalized Headers:
    To:'20'<check-auth@verifier.port25.com>;'0D''0A'
    Subject:'20'check-auth@verifier.port25.com'0D''0A'
    MIME-Version:'20'1.0'0D''0A'
    Content-Type:'20'text/plain;'20'charset=UTF-8;'0D''0A'
    '20'format=flowed'0D''0A'
    Content-Transfer-Encoding:'20'7bit'0D''0A'
    Date:'20'Fri,'20'09'20'Nov'20'2012'20'11:33:48'20'+0100'0D''0A'
    From:'20'Sebastian'20'van'20'de'20'Meer'20'<kernel-error@kernel-error.com>;'0D''0A'
    Message-ID:'20'<c580aed4c89d48c1a93fea35ee80fe30@vandemeer.de>;'0D''0A'
    DKIM-Signature:'20'v=1;'20'a=rsa-sha256;'20'c=simple/simple;'20'd=kernel-error.com;'0D''0A'
    '09's=kernel-error.com;'20't=1352457228;'0D''0A'
    '09'bh=v55t4Oe0VsnE3Xa3exogjgnS10dkjG1rhPQxGz4STJo=;'0D''0A'
    '09'h=To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:'0D''0A'
    '09''20'Date:From:Message-ID;'0D''0A'
    '09'b=

Canonicalized Body:
    check-auth@verifier.port25.com'0D''0A'
    

DNS record(s):
    kernel-error.com._domainkey.kernel-error.com. 300 IN TXT "v=DKIM1; g=*; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtlhidIl+KZgelAOOVYiGHi+uGxEnpjmhXH2IVZNpH69ZsWYTYd1OgXIvWQnAiQ4rRCyvbjcrKaFnXJUpda9eGJeqlr3hE4YhOPLS34K86+8Gr17+WOofkdc3STmlqAI60r1+bQQh8rCWb1YPXIssinq3ll8GVDwAEmh3Bm8zSWz2Ntc+W/maURTlZbMGaRoi+lwhBzr+DnNYL+mPs3UVQoE9ei2Z/bjNQzdpzWeriFgfk56muVZNTvmn8LxkugMhoHMohCr/vkr99xTVmIeMFwMerB2B/JOpeADIf4Wsz6OJQR3GaBA91MX9T2nFncvW3pL03O4wYYVCGnFqz8gbcQIDAQAB"

NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions.  If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.

 

Siehe auch: DKIM einrichten

Fragen? Einfach melden.

IPv6 / Default Route / DNS /DHCP

18. Oktober 2012 / / Keine Kommentare
Nun arbeite ich schon seit einigen Jahren, privat wie im Berufsleben, mit IPv6. Was mir bei vielen Schulungen, Einführungen, Netzumstellungen usw… auffällt ist dass es vielen Admins schwer fällt zu verstehen wie der Client nun an seine Netzwerkkonfiguration kommt. Da in der letzten Zeit immer mehr Fragen zu dem Thema bei mir landen (scheinbar müssen viele jetzt noch „auf den letzten Drücker“ IPv6 lernen), versuche ich es hier mal grob aufzuschlüsseln. Im Grunde ist es ganz einfach: –    Bei IPv6 verteilt der DHCPv6 Server keine Default Route, das macht der Router! –    Der DHCPv6 kann DNS Server, NTP-Server usw. verteilen und für eine automatische Eintragung des Clients am DNS Server sorgen. Er kann natürlich auch zusätzliche IPv6 Adressen verteilen. –    Der Router verteilt sein Präfix per RA (Router Advertisment).       o    Der Client kümmert sich um die Generierung einer IP-Adresse.       o    Im RA kann der Client aufgefordert werden einen DHCPv6 Server nach weiteren Informationen zu fragen.       o    Im RA kann ein DNS Server an den Client übergeben werden (RDNSS) Erst einmal ist also für eine vollständige Autokonfiguration des Clients kein DHCPv6 Server mehr nötig. Denn der Client hat immer und direkt eine IPv6 Adresse vom scope link (fe80:….). Diese Adresse hat der Client sobald er einen Netzwerklink hat und wird aus der eigenen MAC-Adresse per EUI (Extended Unique Identifier) erstellt. Nun sendet der Client im einfachsten Fall ein RS (Router Solicitation) an die Multicast Adresse, auf welche ALLE Router hören, ins Netzwerk (ff02::2). Der Router antwortet dann mit einem RA und übermittelt dem Client das IPv6-Präfix. Der Client baut dann aus diesem Präfix und EUI wieder eine Adresse vom scope global. Sowie bei aktivierten Privacy Extensions eine gewürfelte Adresse. Der Client hat nun mindestens zwei IPv6 Adressen bei aktivierten Privacy Extensions sogar bereits drei IPv6 Adressen, sowie eine Default Route über den Router welcher uns den RA verpasst hat. Ist am Router die Option RDNSS gesetzt wird dem Client zum Präfix auch noch ein DNS Server übergeben. Dieses ~verstehen~ leider noch nicht alle Clients. Damit wäre der Client schon in der Lage vollständig am „Internetleben“ teil zu nehmen. Ist am Router das Other Config Flag gesetzt, wird der Client angewiesen einen DHCPv6 Server nach weiteren Einstellungen/Informationen zu fragen. Nun kommt der DHCPv6 Server ins Spiel. Wird dieser vom Client nach weiteren Einstellungen/Informationen gefragt wird er die gewünschten Informationen an den Client übermitteln. Was nicht bedeutet dass der Client damit eine weitere IPv6 Adresse bekommen muss. Es ist auch möglich nur wins, ntp, dns usw.. an die Client zu übermitteln. Der Client muss dazu über einen DHCPv6-Client verfügen. Dieser ist bisher noch nicht bei allen Clientsystemen per Default vorhanden bzw. aktiviert! Natürlich kann man seinen DHCPv6 Server auch so konfigurieren dass er zusätzlich noch eine dritte bzw. vierte (oder mehr) IPv6 Adresse an den Client übermittelt. Damit wäre der DHCPv6-Server zusätzlich in der Lage diese IPv6 Adressen einem DNS Server bekannt zu machen. Wie auch beim Thema NAT bei IPv6 gibt es Vorschläge dem DHCPv6 Server wieder die Option Route zu spendieren, ich denke es ist nicht nötig / sinnvoll… Hier kann man sich streiten! Die Idee bei IPv6 möglichst viel Arbeit auf den Client zu verlagern ergibt meist erst auf den zweiten Blick Sinn. Bei IPv4 war es bisher so dass der Client als erstes ins Netzwerk herumbrüllt ob den ein DHCP Server da ist, dann gab es einen regen Austausch zwischen diesen Systemen und am Ende hatte der Client alle seine Informationen. Denkt man aber nun daran dass im größten IPv4 Netzausbei maximal (24^2)-2 Hostadressen herausspringen und beim IPv6 im kleinsten Netzausbau minimal (64^2)-2 Hostadressen herausspringen… Ja dann ahnt man schon, wenn sich hier ein Router noch ums Popo abwischen kümmern muss, dann ist nicht mehr viel mit Netzwerk. Noch Fragen? Dann fragen….

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

Postfix für sichere E-Mail-Auslieferung: Nur noch per TLS konfigurieren

25. September 2012 / / Keine Kommentare

Verschlüsselte E-Mail-Übertragungen sind meist ganz gut. Zumindest hält sie einem lästige Lauscher vom Hals. Besonders wichtig ist dabei der verschlüsselte Austausch zwischen Mail-Server und Mail-Client. Denn die User sitzen mit ihren Mail-Clients sehr schnell in einem „unsicheren“ Netzwerk. Daher wird inzwischen sehr oft und gut darauf geachtet diese Verbindungen zu sichern.

Die Verbindungen zwischen den Servern werden oft als nicht SO wichtig empfunden. Denn die Kisten stehen ja meist in gesicherten Bereichen (Serverraum, DMZ, Rechenzentrum) und dort zu lauschen ist schon aufwendiger – nicht unmöglich.
Es macht also Sinn seinem Postfix zu ermöglichen seine Server zu Server Verbindungen kryptisch zu gestalten.

Mit folgender Änderung sagt man seinem Postfix dass bei ausgehenden Verbindungen TLS benutzt werden kann, wenn möglich.

$ postconf -e smtp_tls_security_level=may

Wird Postfix nun ein Zertifikat gereicht, welches von Postfix mangels der Root-Zertifikate nicht geprüft werden kann… Ja, dann ist hier schon wieder Ende.

Sep 25 10:38:07 rootserver postfix/qmgr[2069]: D69471A2026: from=<kernel-error@kernel-error.com>;, size=38273, nrcpt=1 (queue active)
Sep 25 10:38:07 rootserver postfix/smtp[9454]: certificate verification failed for gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1b]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority

Auf Debian Systemen finden sich eine recht gepflegte Ansammlung im Paket: ca-certificates. Nachdem dieses installiert ist:

$ apt-get install ca-certificates

Sagt man Postfix noch wie er es findet:

$ postconf -e smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Schon sollte Postfix in der Lage sein, ausgehende Serververbindungen zu prüfen und zu verschlüsseln.

Siehe auch: Client-Initiated Renegotiation deaktivieren

Fragen? Einfach melden.

Unser RIPE ist bald wirklich alle: Einblick in die Erschöpfung der IPv4-Adressen

11. September 2012 / / Keine Kommentare

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.

Telekommailserver verschärfte Bedingungen der Mailannahme

22. Juni 2012 / / Keine Kommentare

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.

R-DNS geht nicht

14. Juni 2012 / / Keine Kommentare

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“

Mehr hier: http://www.ripe.net/internet-coordination/news/announcements/update-regarding-the-reverse-dns-services-issues

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.

Mehr als nur A-Records

27. Mai 2012 / / Keine Kommentare

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.

GPG-Schlüssel per PKA im DNS veröffentlichen

27. Mai 2012 / / Keine Kommentare

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.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑