Infosec Handbook RSS

Der folgende RSS-Feed stammt von „Infosec Handbook”.

Im Infosec Handbook geht es um das zeitgemäße Absichern von Serverdiensten. Es werden anhand von Howtos, die in handliche, einfach verständliche Portionen eingeteilt sind, Anleitungen bereitgestellt.

  • Monthly review – March 2020
    Each month, we publish a review that covers essential activities of the last 30 days. This month, we talk about coronavirus-related news, Let’s Encrypt’s certificate revocation, new attacks on hardware, issues with Tor Browser, and more. Always stay in the loop!Subscribe to our RSS/Atom feeds. News of the month In… Read more »
  • Social engineering: The story of JessikaSocial engineering: The story of Jessika
    In January 2020, we gave another lecture on social engineering and awareness at the University of Regensburg, Germany. During our interactive session, Master students had to invade the privacy of our fictional character Jessika. Each student became a social engineer for this course, and some of them managed to “hack”… Read more »
  • Monthly review – January and February 2020
    Each month, we publish a review that covers the most important activities of the last 30 days. This time, our monthly review actually covers the first two months of 2020. We talk about the 36C3, the end of SHA-1, CRLite in Firefox, the Kr00k attack, and more. Always stay in… Read more »
  • Monthly review – December 2019
    Each month, we publish a review that covers essential activities of the last 30 days. This month, we talk about Python 2 EOL, malicious Python libraries, technical previews by Signal, WebAuthn for iOS, and more. Always stay in the loop!Subscribe to our RSS/Atom feeds. News of the month In December… Read more »
  • Cryptography myths
    Some people are convinced that applying cryptography to their product or service solves all problems regarding security and privacy. Of course, this isn’t the case as shown in this article. Always stay in the loop!Subscribe to our RSS/Atom feeds. Myth 1: Applying cryptography makes everything secure For encryption, you need… Read more »
  • Using a YubiKey as a second factor for LUKSUsing a YubiKey as a second factor for LUKS
    The Linux Unified Key Setup (LUKS) is a platform-independent specification for hard disk encryption. In this tutorial, we use the challenge-response feature of a YubiKey to add two-factor authentication (2FA) to an existing LUKS-protected device. Always stay in the loop!Subscribe to our RSS/Atom feeds. The goal of this tutorial We… Read more »
  • The state of the LineageOS-based /e/ ROM in December 2019
    More than four months ago, we checked the LineageOS-based ROM provided by the French /e/ foundation for the second time. In this article, we recheck our findings for the last time since Google dropped support for Android 7.1.2, the underlying Android version of the /e/ ROM for our device. Always… Read more »
  • Yubico Security Key vs. Nitrokey FIDO2Yubico Security Key vs. Nitrokey FIDO2
    WebAuthn, Web Authentication: An API for accessing Public Key Credentials Level 1, is a W3C Recommendation released in March 2019. It defines creation and use of strong, attested, scoped, public key-based credentials by web applications. It is very similar to the Universal 2nd Factor (U2F) standard, but extended and customized… Read more »
  • 3 Don'ts of penetration testing and security assessments
    Penetration testing can be used to systematically find security vulnerabilities and discover security risks. However, if done wrong, penetration testing results in a list of arbitrary problems that aren’t necessarily related to security. In this article, we show three things good penetration testers don’t do. Always stay in the loop!Subscribe… Read more »
  • European GDPR myths – Part 2
    In May 2018, we debunked 3 GDPR myths. In this article, we discuss three additional myths. Always stay in the loop!Subscribe to our RSS/Atom feeds. Notice Please note: We aren't lawyers and don't pretend to be lawyers. Please do not rely on any information provided below. Contact your data protection… Read more »
WordPress RSS Feed by thememason.com

DNS Transfer Cheat Sheet

Erstentwurf – Review ausständig; Fehler möglich; Änderungen vorbehalten.

Hilfestellung beim DNS-Umzug

Beim Umzug von Domains gibt es ein paar Dinge zu beachten.

In diesem Artikel beschreibe ich stark vereinfacht und gekürzt ein paar Grundlagen des Domain Name Systems, die für Domaininhaber, die den Registrar wechseln möchten, von Relevanz sind. Immer wieder liest man in Support-Foren von verzweifelten Nutzern, denen offenbar nicht klar ist, dass ein Domain-Umzug nicht in Echtzeit abläuft, sondern, dass ein Domaintransfer ein paar Vorbereitungen und etwas Nachbearbeitung erfordert, damit die Ausfallzeiten möglichst gering ausfallen.

Wenn man sich vorher informiert, schont das die Nerven aller Beteiligten – vor allem aber die eigenen.

Wie funktioniert das Domain Name System?

Für Laien erklärt, ist das DNS am ehesten mit einem Telefonbuch für eine Region vergleichbar. Es übersetzt Namenseinträge (Domainnamen und Hostnamen) in Nummern (Internetprotokolladressen – kurz IP-Adressen). Die einfachste Art eines solchen Datensatzes ist ein sogenannter „A-Eintrag“ für das Internetprotokoll in der Version 4 (IPv4), dem heutzutage noch gängigen Protokoll, oder einem „AAAA-Eintrag“ für das Nachfolgeprotokoll IPv6.

Solche Einträge sehen in etwa so aus – im Beispiel sind die öffentlich abrufbaren Google-Nameserver:

dns.google.com. IN A 8.8.8.8
dns.google.com. IN AAAA 2001:4860:4860::8888

Dieses „Telefonbuch“ ist hierarchisch aufgebaut, d.h. es gibt einen Haupteintrag, unter dem dann weitere Einträge oder Verweise zu finden sind.

Organisatorisch läuft das wie folgt ab:

Ganz oben steht die  Top Level Domain („TLD“). Ein prominentes Beispiel für eine TLD ist „.com“. Für eine TLD zuständig ist eine Vergabestelle (Registry). Sie regelt, wer unter welchen Voraussetzungen einen Namen unterhalb der TLD registrieren darf. Wer eine Domain registriert, wird zum Domaininhaber (Registrant). Die Registry bedient sich meist mehrerer Vertragspartner (Registrare), um diese Domains zu verkaufen – sprich: Namensrechte auf Zeit zu lizenzieren. Die Registrare  sind die primären Vertragspartner der Registrants und vermitteln gegenüber der Registry – sie verrechnen dem Registrant auch die anfallenden Gebühren und rechnen sie mit der Registry ab.

Technisch funktioniert DNS so:

Die Registry betreibt sogenannte Root-Nameserver, die in aller Regel nur einen Verweis vom registrierten Namen vorhalten, der auf untergeordnete Nameserver (DNS-Server) zeigt. Haben diese DNS-Server einen Hostnamen, der innerhalb der Domain, um die es geht, liegen -es geht zum Beispiel um die Domain example.com, und der DNS-Server heißt ns1.example.com- ist zusätzlich ein sogenannter „Glue-Record“ vonnöten. Dabei handelt es sich schlicht um einen „A“ oder „AAAA“ -Eintrag, den allerdings der Registrar bei den Nameservern der Registry hinterlegen muss, damit er funktioniert.

Zusätzlich können die Rootserver auch noch kryptographische Schlüssel und Signaturen ausliefern, anhand derer man gefälschten Domaininformationen vorbeugen kann. Das gegenwärtig vorherrschende System dafür heißt DNSSEC.

Die Verweise vom Root-Nameserver zu den Servern des DNS-Providers (in der der Regel sind das zugleich die des Registrars) heissen „NS-Einträge“.

Im Falle dieses Blogs ist der Registrar der deutsche Hoster „netcup“ und die Einträge sehen so aus:

grundsoli.de. 120 IN NS root-dns.netcup.net.
grundsoli.de. 120 IN NS second-dns.netcup.net.
grundsoli.de. 120 IN NS third-dns.netcup.net.

Wir sehen also, dass für den Namen „grundsoli“ innerhalb der TLD „.de“ drei verschiedene Server zuständig („autoritativ“) sind.

Jeder dieser drei Server hält die sogenannte „Zone“ vor. Die Zone kann im einfachsten Fall eine Textdatei sein, oder die in ihr enthaltenen Informationen liegen in einer Datenbank.

Die Zone im Detail beschrieben:

Eine Zone setzt sich aus mehreren Resource Records („RR“) zusammen. Zu diesen RRs gehören auch die zuvor genannten NS, A und AAAA-Einträge.

Resource Records setzen sich zusammen wie folgt:

  • dem Zonennamen = Domain. Mancherorts wird auch vom „Origin“ gesprochen. Dieser Zonenname kann stets mit dem Platzhalter „@“ abgekürzt werden.
  • der TTL (Time to Live). Dieser Wert bestimmt, wieviele Sekunden der SOA-Eintrag in einem Cache gültig bleibt.
  • dem Schlüsselwort „IN“ für die Zonenklasse „Internet“. Einen anderen Wert wird man in der Praxis kaum je irgendwo sehen.
  • dem Typ – ich nenne hier nur die häufigsten – wer mehr wissen möchte, kann im RFC 1035 nachlesen.
    • A für einen Hostnamen
    • NS für einen autoritativen Name Server
    • CNAME für einen kanonischen Namen (in aller Regel also ein Verweis auf A oder AAAA)
    • SOA für den Beginn einer Autoritätszone („start of a zone of authority“)
    • PTR für einen „Domain Name Pointer“ – dieser Typ ist nur für die umgekehrte Namensauflösung von einer IP-Nummer in einen Domain-/Hostnamen erforderlich, aber für unsere Thema hier nicht relevant
    • MX für den Mail exchange. Dieser Eintrag bestimmt, an welchen Mailserver E-Mails gesendet werden sollen.
    • TXT für Texteinträge. Diese Eintragsart ist vor allem für Verifikationsdienste (Bestätigung der Inhaberschaft gegenüber bestimmten Anbietern) von zunehmender Bedeutung.
  • einem Wert oder mehreren Werten für den jeweiligen Typ.

Am Beginn der Zone steht stets ein Eintrag vom Typ SOA. Kehren wir zum Beispiel mit example.com zurück:

@ 3600 IN SOA dns1.example.com. hostmaster.example.com. (
2019090900 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
600 ; nc-ttl
);

Wir haben also die Variable für den Domainnamen „@“, die Gültigkeitsdauer des SOA-Eintrag in Caches „3600“, die Klasse Internet „IN“, die Art des Eintrags „SOA“ den primären Nameserver, das ist jener autoritative Nameserver, von dem aus die Zone vervielfältigt wird „dns1.example.com“ und eine E-Mailadresse in besonderer Schreibweise „hostmaster.example.com“ für hostmaster@example.com. Die Punkte am Ende von dns1.example.com. und hostmaster.example.com. sind extrem wichtig, da sie das Ende des Werts markieren. Fehlt der Punkt am Ende wird der Domainname an den Wert erneut angehängt. Aus „dns1.example.com“ würde dann „dns1.example.com.example.com“ – ein von Anfängern häufig gemachter Fehler. Die in Klammern folgenden Zahlenwerte schlüsseln sich wie folgt auf:

  • serial: die Versionsnummer -also fortlaufende Nummern- der Zone. Es hat sich eingebürgert, hier einen Datumsstempel der Art [vierstellige Jahreszahl, zweistellige Monatsnummer, zweistellige Tageszahl und zweistellige fortlaufende Nummer] zu verwenden. „2019090900“ steht also für die erste Version der Zone, die am 9. September 2019 erstellt worden ist. Siehe auch RFC 1912.
  • refresh: Ein Intervall in Sekunden, nach dessen Ablauf sekundäre Nameserver die Seriennummer vom primären Master erneut abfragen sollen. Empfohlen wird von RIPE NCC 86400 ≙ 24 Stunden¹.
  • retry: Ein Sekundenintervallwert, der zum Tragen kommt, um einen Refresh zu wiederholen, der fehlgeschlagen ist. RIPE-Empfehlung: 7200 ≙ 2 Stunden¹.
  • expire: Wenn diese Zeitspanne in Sekunden verstrichen ist, ohne, dass ein Refresh funktioniert hat, verwirft der sekundäre Nameserver seine zuletzt  erhaltene Zone. RIPE-Empfehlung: 3600000 ≙ 1000 Stunden¹
  • nc-ttl: Time to Live für Negatives Caching – seit RFC 2308. Zuvor: Minimale Lebensdauer für alle Resource Records, wenn diese nicht explizit angegeben waren. Negatives Caching bedeutet, dass ein cachender DNS-Server mit „NXDOMAIN“ antwortet, wenn ihm der abgefragte Eintrag nicht bekannt ist.
    RIPE-Empfehlung: 3600 ≙ 1 Stunde¹.

1: Die RIPE-Empfehlungen gelten stets für „für kleine und stabile Zonen“.

Der Wert für Retry muss kleiner sein, als der für Refresh. Der Wert für expire darf nicht kleiner sein als die Summe von Refresh und Retry.

Und damit haben wir die technischen Grundlagen für beeinflussbare Verzögerungen beim Domaintransfer im Grunde vollständig besprochen.

Die nicht beeinflussbaren Faktoren liegen bei der Registry, die etwa Widerspruchsfristen für einen Transfer definieren kann. Sie ist es auch, die festlegt, zu welchen Tageszeiten die Root-Nameserver eine neue Information, die von einem ihrer Registrare eingemeldet worden ist – wir reden da von neuen Nameserver-Einträgen – verarbeitet wird.

Um also einen Transfer so durchzuführen, dass er möglichst schnell über die Bühne geht, sollte man Tage oder Wochen vor dem Transfer die Werte für TTL, Refresh und NC-TTL verringern, wodurch in aller Regel auch der Wert für Retry verringert werden wird müssen. Dadurch setzt man sich vorübergehend zwar einem erhöhten Risiko aus, dass die Zone im Fehlerfall des Primärservers auch auf den Sekundärservern schneller mit ausfällt, umgekehrt müssen aber auch DNS-Resolver Dritter, auf die wir im Normalfall keinen Einfluss nehmen können, sofern sie standardkonform arbeiten, die vorgehaltenen Informationen schneller verwerfen.

Wenn man sich nun noch informiert, wann die Registry die Daten neu laden lässt, kann man den  Umzug auch dahingehend zeitlich koordinieren.

Laden beispielsweise etwa die Root-Nameserver laut Registry um 13 und um 16 Uhr die Daten neu, und der Registrar aktualisiert alle 15 Minuten, so kann man nach 13 Uhr die Änderungen machen. Die anderen Kunden des Registrars hätten die neuen Informationen so – sofern sie nicht in einem Cache liegen, um 13.15 Uhr, weltweit würde der Verweis auf die neuen Server erst um 16 Uhr aktiv. Um also Gleichzeitigkeit zu erwirken, wären die Änderungen nach 15.45 Uhr, aber vor 16.00 in Auftrag zu geben. Caching Server würden die alte Information aber zumindest noch für die in TTL definierte Zeit ausliefern, wenn sie die Standards einhalten – sonst länger.

Da sich heutzutage aber auch sogenannte Public-DNS-Resolver-Dienste großer Beliebtheit erfreuen – gemeint sind damit Google DNS, Cloudflare, OpenDNS und dergleichen, und diese oft eine Möglichkeit bieten, die Cache-Information über ein Webinterface neu zu laden, also den „Cache“zu „flushen“, kann man auch hier mit globaler Wirkung für alle Nutzer dieses Dienstes Einfluss auf die Erneuerung der Information nehmen. In der Linksammlung stehen einige Dienste gelistet.

 

Linksammlung:

How to Clear DNS Cache on Chrome, Firefox and Safari

Olympia GSM-Alarmanlage und Yesss SIM

Interessante Beobachtung: Bei einer Olympia Protect Serie 96XX GSM-Alarmanlage funktioniert anscheinend eine Charge von Yesss/A1 SIM-Karten nicht.
Während die Karten in einem alten Handy klaglos funktionieren, findet die Basiseinheit eines getesteten Alarmsets schlicht kein Netz. Die sonst bei GSM in einem Radiolautsprecher typischen Geräusche, wenn ein Handy sich ins Netz einbucht, fehlen in diesem Fall gänzlich. Konkret sind mit mehreren Yesss-SIM Serie 89431215071000XXXXX mit einer Olympia Protect 9061 (5943 rev.03) diese Anomalien zu beobachten gewesen, während folgende Serien funktionieren:
89431215050304XXXXX
89431214093005XXXXX
89431214093005XXXXX

Spannend…

Hallo Leser – Willkommen!

Willkommen auf grundsoli(.)de!

Hier befassen wir uns mit Reviews von IT- und Telekommunikationsprodukten, Security Audits, OpenSource und Sparangeboten. Wenn ich einem Thema begegne, das mich bewegt, schreibe ich einfach einmal meine Gedanken hier nieder und nehme Feedback entgegen. Betrachten wir es als öffentlich einsehbares Notizbuch, das auch dem Leser punktuell grundsolides IT-Wissen vermitteln und andererseits eine Entscheidungshilfe sein soll. Die Beiträge werden, soweit es für das deutschsprachige Publikum dieses Blogs von Interesse ist, mit https://technicalexperiments.wordpress.com abgestimmt.

Es ist geplant, die geringen Kosten des Betriebs dieses Blogs durch Werbeeinnahmen zu decken. Auf Werbung wird auch als solche hingewiesen werden. Soweit jedoch ein Artikel Produkte behandelt , die auf Amazon.de erhältlich sind, werden diese auch verlinkt. Ungeachtet dessen wird die Kritik schonungslos sein, denn meine Leser möchte ich ja nun wirklich nicht vergrämen.

Wir starten am heutigen 30. November 2018.

In diesem Sinne, herzlich willkommen!