.local, .home.arpa and .localzone.xyz
11.11.2019 yahe administration
35 years ago the IETF defined special IPv4 addresses in RFC 1597 to be used solely in private intranets and with that created the separation between internal networks and the internet. 5 years later they proceeded to define special-use top-level domains like .example, .invalid and .test in RFC 2606. However, the IETF did not reserve a top-level domain to be used within the private intranets that they had introduced before. This lead to confusion with administrators that still persists to the current day.
Every time an administrator was tasked to design a network structure they also had to think about naming conventions within the network. As there was a pre-defined set of "valid" top-level domains within the internet, it was rather easy to just select an "invalid" TLD and use that for the private network. At least, until the ICANN decided to delegate new TLDs to anyone who was willing to apply and pay the required fees. The ICANN even provided a paper on how to identify and mitigate name collisions to be used by professionals.
With RFC 6762 the .local TLD was approved as a special-use TLD to be used in internal networks and many administrators thought that this would solve the problems, but unfortunately, it did not. .local was designated to be used with multicast DNS, meaning that each device in a network could grab its preferred hostname. At the beginning this was not a big deal, but as more and more devices implemented Apple's Bonjour protocol (also known as zeroconf) interoperability problems started to pop up. Appendix G of said RFC even mentioned alternative TLDs that might be used, however, the ICANN did not accept any of them as special-use domain names.
Years later the new RFC 7788 defined .home as a potential local-only TLD, but it was changed to the rather unusual .home.arpa domain name with RFC 8375. This domain is safe to be used in local networks and was accepted as a special-use domain name by the ICANN. Unfortunately, due the word "home" in the domain it is not quite fitting for business environments.
There are two more TLDs that might be safe to use: .corp and .home are not officially recognized special-use domain names but the ICANN has refrained from delegating them to bidders as the risk of breaking internal networks is deemed to be too big.
As of today, most tutorials still propose to use a publicly registered domain for internal networks. This is why I registered .localzone.xyz about half a year ago. It is explicitly meant to be used locally, has public DNS records set to prevent any public CA from issuing trusted TLS certificates for that domain as well as DNS records defining all mails using that domain as SPAM and will not be used for publicly accessible services as long as it is owned by me. I am using this domain internally myself and am also trying to get the domain added to the public suffix list. This list defines domain and cookie boundaries so that e.g. example-a.com is not able to set cookies for example-b.com.
So if you are looking for a domain that you can use for internal domain names then look no further: Either use the special-use domain name .home.arpa (which might not be fitting for businesses) or use .localzone.xyz as I am. It makes clear that you are in a local environment without being too specific about whether it is a private or business network.
Yahe.sh wechselt ins Englische
Im letzten Artikel hatte ich erklärt, weshalb ich mich dazu entschieden habe, von der Domain "weizenspr.eu" hin zur Domain "yahe.sh" zu wechseln. Hintergrund ist der Fokus der Webseite, der sich in den letzten fast 10 Jahren von Alltagserfahrungen hin zu technischen Themen gewandelt hat. Mit dem Wechsel des Themenfeldes geht jedoch auch ein Wechsel des Zielpublikums einher.
In der IT ist Englisch die Sprache der Wahl, um ein möglichst großes Publikum zu erreichen. Daher habe ich mich nach langem Ringen dazu entschlossen, auch diesen Blog zukünftig auf Englisch zu führen. Meine Hoffnung ist, dass die Leute, die auch bisher schon meine technischen Inhalte gelesen haben, der englischen Sprache mächtig sind. Zumindest in meinem Bekanntenkreis stellt der Sprachwechsel kein Problem dar, eröffnet mir jedoch die Möglichkeit einer internationalen Leserschaft.
Daher bleibt mir an dieser Stelle nur noch zu sagen: Welcome to Yahe.sh!
Goodbye WeizenSpr.eu
Am 02.02.2009 habe ich die Domain "weizenspr.eu" registriert. Der Blog, der sich dahinter verbarg, durchlebte die Blütezeit des Bloggens in Deutschland. Damals brauchten Blogs unbedingt ein Motto und so entschied ich mich für "trennt Spreu vom Weizen". Ich wollte sowohl die guten Dinge ("Weizen"), als auch die schlechten Dinge ("Spreu") im Alltag thematisieren.
Der unbeschwerte Studentenalltag wich dem stressigen Berufsalltag und damit auch die alltäglichen Themen aus dem Blog und genauso wandelten sich die kurzen Wortmeldungen zu längeren Themenartikeln. Um dem gerecht zu werden, begann ich, nicht mehr passende Artikel offline zu nehmen, um eine ausgewogenere Webseite zu erhalten. Doch die kleineren Arbeiten hier und da führten eher dazu, dass die Seite immer inkonsistenter wurde. Und das ursprüngliche Spreu-vs.-Weizen-Konzept machte keinen Sinn mehr. Ein Neuanfang musste her.
Der begann damit, dass ich mich auf Github und auf Twitter umbenannte. Der Nickname, den ich mir ausgesucht habe, basiert entfernt auf meinem Nachnamen und nicht mehr auf einem thematischen Konzept.
Wenn ich schon dabei war, alles neu zu machen, wollte ich in dem Zuge auch gleich die technische Basis meiner Onlinepräsenz überarbeiten. Seit ich mit WeizenSpr.eu begonnen habe, verwende ich für alle Webseiten WordPress, was an vielen Stellen eher übertrieben ist. Ich wollte etwas kleineres, schlankeres, schnelleres haben. Ich schaute mir verschiedene dateibasierte Content-Management-Systeme an, war jedoch mit keinem wirklich zufrieden. Also begann ich, in meiner Freizeit das CMS Urlaube zu entwerfen und zu programmieren.
Als das CMS nun im Juli 2018 halbwegs Fortschritte gemacht hatte, begann ich, die Artikel von WeizenSpr.eu zu übertragen. Ich nahm mir jeden Artikel einzeln vor und überlegte, ob er zur neuen Webseite passen würde. Falls ja, migrierte ich ihn händisch von HTML zu Markdown. Dabei nahm ich mir die Zeit, Formulierungen zu verbessern, defekte Links zu reparieren und veraltete Inhalte zu aktualisieren. Von den ursprünglich 667 Artikeln haben es 111 Artikel auf die neue Webseite geschafft. All diese Artikel befinden sich in der Legacy-Kategorie.
Die nächste Zeit werde ich nun dafür nutzen, neue Artikel zu verfassen, die ich bereits ewig vor mir hergeschoben habe, weil ich unbedingt bis zum Relaunch der Seite warten wollte.
Wie euch aufgefallen sein dürfte, gibt es aktuell noch keine Kommentarfunktion. Ich bin bereits am überlegen, ob und wie diese am besten implementiere. Bis dahin habt ihr natürlich die Möglichkeit, mich per Mastodon, Twitter oder über das Mailkontaktformular zu erreichen.
Vermeiden. Erkennen. Beheben.
21.08.2017 yahe legacy security thoughts
Bereits seit einiger Zeit orientiere ich mich bei der Auswahl von Sicherheitsmaßnahmen an einer Einteilung, die ich bereits im Artikel über die aktive Verteidigung gegen Kryptotrojaner einmal verwendet hatte: Vermeiden. Erkennen. Beheben.
Bisher war ich davon ausgegangen, dass es sich dabei um ein gängiges Modell handelt, schließlich wird es in vielen Bereichen eingesetzt, in denen es um Fehlervermeidung geht. Bezogen auf das Management der Informationssicherheit habe ich jedoch keine relevanten Quellen ausfindig machen können, die sich mit dieser Klassifizierung von Sicherheitsmaßnahmen beschäftigt. Aus diesem Grund habe ich mir überlegt, einfach einmal aufzuschreiben, was ich mit den drei Punkten meine und wie deren Anwendung einem helfen kann, die Absicherung der eigenen Informationssicherheit ganzheitlicher zu gestalten.
tl;dr
Anstatt sich im risikoorientierten Sicherheitsmanagement nur mit der Frage zu beschäftigen, wie man Schäden vermeidet, sollte man in seinen Prozessen auch die Frage berücksichtigen, wie man entstandene Schäden erkennt und wie man diese entstandenen Schäden behebt.
Grundsätzliches
Sicherheitsmanagement, wie es heutzutage praktiziert wird, ist primär risikoorientiert. Man baut sich einen Pool an potentiellen Bedrohungen auf; prüft, ob ein spezifisches Asset Schwachstellen hat, die durch eine Bedrohung zu tatsächlichen Gefährdungen werden; bewertet das daraus entstehende Risiko und überlegt sich, wie man mit diesem Risiko umgehen möchte. Möglichkeiten sind die Übernahme des Risikos, man lebt also damit, dass das Risiko existiert; man transferiert das Risiko auf jemand anderen, z.B. indem man eine Versicherung abschließt; man vermeidet das Risiko, z.B. indem man eine andere technische Lösung wählt; oder man reduziert das Risiko, indem man Maßnahmen ergreift, die dabei helfen, die Eintrittswahrscheinlichkeit oder die Auswirkung zu verringern.
Wie man erkennt, beschränkt sich diese Form der Betrachtungsweise primär auf die Vermeidung von Schäden. Was fehlt, ist die Betrachtung von Maßnahmen, die dabei helfen, eingetretene Schäden zu erkennen und diese zu beheben. Meiner Erfahrung nach führt diese einseitige Herangehensweise dazu, dass sich Unternehmen darauf versteifen, Gefahren abzuwehren und sich zu wenig damit auseinander setzen, was passiert, wenn ein Schaden trotzdem eintreten sollte. Erst in jüngerer Zeit scheint es hier ein Umdenken zu geben. Nachdem sogar Sicherheitsunternehmen wie z.B. Antivirenhersteller und Sicherheitsbehörden gehackt werden, entsteht langsam das Mantra "es stellt sich nicht die Frage, ob man gehackt wird, sondern wann".
Die Klassifizierung von Sicherheitsmaßnahmen in die Kategorien Vermeidung, Erkennung und Behebung, wobei Mehrfachklassifizierungen je nach Nutzungsart durchaus möglich sind, kann dabei helfen, einen ganzheitlichen Ansatz des Sicherheitsmanagements zu etablieren.
Vermeiden
Meiner Erfahrung nach handelt es sich bei der Vermeidung von Schäden um den Maßnahmenkomplex, den Unternehmen als erstes betrachten, wenn sie sich mit dem Thema Sicherheits- oder Risikomanagement beschäftigen. Als ich begonnen habe, mich mit der IT-Security zu beschäftigen, ist man häufig noch davon ausgegangen, dass es ausreichend ist, genügend technische Maßnahmen zu ergreifen, um sich vollständig abzusichern. Das Nutzen von Verschlüsselung, der Einsatz von Antivirenscannern und Firewalls, das Nutzen von RAIDs, das Erstellen von Backups, sowie das regelmäßige Patchen von Anwendungen waren die klassischen zu ergreifenden Maßnahmen. Wie bereits weiter oben beschrieben, führen auch die klassischen Risikomanagementmethoden dazu, sich primär mit Maßnahmen zur Vermeidung von Schäden zu beschäftigen.
Erkennen
Die Erkennung von Schäden ist, so zumindest meine Erfahrung, selten vom Gedanken des Risikomanagements getrieben, dafür aber umso häufiger vom Gedanken der operativen Funktionstüchtigkeit. Die klassische Erkennungsmethode ist der Einsatz einer Monitoringlösung im IT-Umfeld. Diese beschränkt sich jedoch sehr häufig auf Themen wie die Verfügbarkeit von Services und der Ressourcenauslastung von Hardware.
Nur selten wird sie genutzt, um regelmäßig nach veränderten Dateien, unzulässigen Netzwerkverbindungen, unbekannten Prozessen oder bekannten Prozessen mit unbekannten Parameterlisten zu scannen. Hintergrund dürfte auch sein, dass sich das Erkennen von Verfügbarkeitsproblemen recht einfach standardisieren lässt, während Verhaltensmuster von Systemen und Anwendungen sehr unterschiedlich sein können und eines individuelles Profiling bedürfen. Das führt dazu, dass solche komplexeren Erkennungen in Form von IDS- und IPS-Lösungen erst dann zum Einsatz kommen, wenn das gesamte Sicherheitsmanagement des Unternehmens einen gewissen Reifegrad erreicht hat.
Eine andere klassische Maßnahme ist die Einführung einer zentralen Logging-Infrastruktur, die es prinzipiell ermöglicht, durch das Analysieren einer Vielzahl von Systemevents einen möglichen Schaden zu erkennen. Aber auch hier müssen erst im Zuge einer SIEM-Lösung entsprechende Trigger definiert werden, bevor ein tatsächlicher Nutzen aus der Maßnahme gezogen werden kann.
Doch auch abseits der Technik sollte man sich im Zuge seines Risikomanagements immer die Frage stellen, welche Maßnahmen ergriffen werden, um das Eintreten eines Schadens überhaupt erkennen zu können.
Beheben
Nachdem man sich Gedanken gemacht hat, wie man eingetretene Schäden erkennt, besteht die schlussendliche Arbeit darin, sich zu überlegen, wie man den Schaden wieder beheben kann. Eine klassische Maßnahme zur Behebung von Schäden ist das Wiedereinspielen von Backups oder das Neuaufsetzen von kompromittierten Systemen. Doch evtl. muss je nach Anwendung granularer vorgegangen werden oder es ergibt sich die Möglichkeit, die Behebung einzelner Schäden automatisiert durchzuführen.
Meiner Erfahrung nach bestehen viele Maßnahmen zur Behebung von Schäden im ersten Schritt aus spontanen Ideen, die im tatsächlichen Ernstfall umgesetzt werden. Diese verfestigen sich anschließend durch die Formulierung von Wiederherstellungsplänen oder, gröber gefasst, durch Notfallpläne im Zuge der Etablierung eines Notfallmanagements. Die erstellten Pläne stützen sich anfangs oft vor allem auf händische Prozesse. Erst bei zunehmender Reife werden manuelle Arbeiten durch automatisierte Tasks abgelöst. Denn auch hier müssen viele individuelle Aspekte berücksichtigt werden.
Auch abseits der Technik sollte man sich Gedanken über die Behebung von Schäden machen. Wie reagiert man als Unternehmen, wenn essentielle Ressourcen nicht zur Verfügung stehen oder wie würde man beim Abhandenkommen sensibler Daten vorgehen?
Praxisbeispiel
Um diese Dreiteilung an Maßnahmen einmal im Zusammenspiel zu zeigen, möchte ich einmal Antivirensoftware als plakatives Beispiel wählen, unabhängig von der Diskussion über deren tatsächlichen Nutzen.
Wir beginnen mit der Hauptaufgabe von Antivirensoftware, dem Erkennen von Viren. Im ersten Schritt wird man nur einzelne Dateien geprüft haben und diese Maßnahme Stück für Stück erweitert haben; um das Scannen ganzer Ordner, um das Scannen des ganzen Systems und schlussendlich auch um das Scannen des Bootsektors. Die Erkennung erfolgte früher allein auf Basis einer Virensignatur, sprich, der Information darüber, wie der kompilierte Quelltext des Virus aussieht.
Als man Viren erkennen konnte, stellte sich die Frage, wie man mit ihnen umgeht, sprich, wie das Beheben eines Virenbefalls aussehen könnte. Man könnte sie z.B. in Quarantäne schieben, sie direkt löschen oder, mit entsprechend viel Wissen über den Virus, diesen evtl. sogar aus einer infizierten Datei entfernen.
Als man nun weiter fortschritt, Festplatten größer und die Scans damit zeitaufwändiger wurden, kam man evtl. nicht mehr dazu, regelmäßig alle Dateien händisch zu prüfen. Trotzdem war es wichtig, zu verhindern, dass eine virenverseuchte Datei geöffnet oder verteilt wird. Also begann man damit, Dateien noch vor einem tatsächlichen Zugriff zu prüfen. Das Live-Scannen von Dateien half, das Ausführen von Viren zu vermeiden, optimierte gleichzeitig aber auch das Erkennen von Viren.
Viren wurde intelligenter und polymorph, ihr Quelltext änderte sich regelmäßig, sodass einfache Virensignaturen nicht mehr in der Lage waren, diese zu erkennen. Erst durch die Einführung von Heuristiken kam Antivirensoftware dazu, auch diese neuen, komplexeren Viren überhaupt erkennen zu können.
Das Internet hielt Einzug und verdrängte Wechseldatenträger als primäres Einfallstor für Viren. Die Hersteller von Antivirensoftware gingen mit und begannen, sich in den Datenkanal einzuklinken. Man wollte Viren bereits erkennen können, noch bevor sie auf der Festplatte des Nutzers gespeichert werden. Das sollte auch vermeiden, dass Nutzer überhaupt die Möglichkeit haben, irgendetwas mit der virenverseuchten Datei anstellen zu können.
Im Businessumfeld sind die Risiken, die von einem Virenbefall ausgehen, sogar noch größer, als in anderen Bereichen. Virenschreiber haben es vor allem auch auf diesen Bereich abgesehen, mitunter sogar mit speziell entwickelten Viren. Aber auch Antivirenhersteller haben dies erkannt und bieten spezifische Lösungen für solche Unternehmen an. Eine Lösung ist, Anwendungen vor ihrem Download auf einen Nutzerrechner in einer VM einer Scanning-Appliance gezielt zur Ausführung zu bringen, um ein verdächtiges Verhalten dieser Anwendung bereits im Vorfeld erkennen zu können. Hiermit will man die Ausführung eines Virus auf einem Nutzerrechner vermeiden.
Fazit
Wie man am Beispiel der Antivirensoftware gut erkennen kann, kann die Klassifizierung von Maßnahmen in die Themenfelder Vermeidung, Erkennung und Behebung dabei helfen, diese besser in einem gesamtheitlichen Sicherheitsansatz zu begreifen. Je nach Reifegrad des Sicherheitsmanagements im eigenen Unternehmen sollte man sich einmal ansehen, in welchem der drei Themenkomplexe noch Nachholbedarf bzgl. der geplanten und umgesetzten Maßnahmen besteht.
Das Scrollrad unter Linux beschleunigen
10.07.2017 yahe administration legacy linux
Wie ich bereits im letzten Artikel beschrieben habe, wechsele ich derzeit zu Linux als mein Hauptbetriebssystem. Leider gibt es dabei immer wieder kleinere Stolpersteine, die die Arbeit mit dem System nervig machen. Eines davon war die absolut träge Scrollgeschwindigkeit innerhalb des Systems. Nicht nur, dass man sich dadurch durch längere Webseiten und Terminalsessions krampfen muss, das System fühlt sich oft einfach lahm und überfordert an.
Auf der Suche danach, diesen Missstand zu beseitigen, wanderte ich natürlich erst einmal in die Systemeinstellungen, die bzgl. der Einstellungsmöglichkeiten der Maus, recht spartanisch ist. Von Themen wir Beschleunigung ist man hier offenbar meilenweit entfernt.
Also begann ich damit, mich durch Google zu graben. Als erstes stolperte ich über Beschreibungen zur Nutzung von "xinput". Also fix installiert und per "xinput list" erst nach der ID des Devices gesucht und anschließend per "xinput list-props <DeviceID>" die möglichen Optionen durchforstet. Leider fand ich in der Auflistung nichts, was nach der Scrollgeschwindigkeit aussah oder wenigstens wie etwas, was dem nahe kam, was laut den Foreneinträgen der korrekte Konfigurationswert hätte sein sollen.
Noch gab ich aber nicht auf und suchte weiter. Dabei stieß ich auf das Tool "imwheel", das genau das tun sollte, was ich erreichen wollte. Es funktioniert allerdings nicht out-of-the-Box und die meisten Artikel, die ich zuerst fand, bezogen sich darauf, wie man mit imwheel zusätzliche Maustasten unter Linux zum Laufen kriegt. Erst ein halbwegs neuer Artikel half mir dann tatsächlich weiter. Zuerst einmal muss man imwheel installieren:
sudo apt-get install imwheelAnschließend muss man eine Konfigurationsdatei namens "~/.imwheelrc" erstellen:
".*"
None, Up, Button4, 3
None, Down, Button5, 3
Control_L, Up, Control_L|Button4
Control_L, Down, Control_L|Button5
Shift_L, Up, Shift_L|Button4
Shift_L, Down, Shift_L|Button5Der Wert ".*" sorgt dafür, dass imwheel in allen Anwendungsfenstern aktiv ist. Man kann hier auch alternativ Fensternamen eintragen, um die Funktion von imwheel auf einzelne Anwendungen zu beschränken. Die einzelnen Zeilen sind nun Ersetzungen, die von imwheel durchgeführt werden. "Button4" ist das nach-oben-scrollen der Maus, "Button5" das nach-unten-scrollen. Diese werden hier durch 3-faches Drücken der Up- bzw. Down-Taste ersetzt. Das gleiche geschieht für Situationen, in denen die Ctrl- bzw. Shift-Taste gedrückt wird. Nun muss man diese Ersetzung nur noch aktivieren:
imwheel --kill --buttons "4 5"Mit "--kill" werden alle bereits laufenden Instanzen von imwheel beendet, damit sich unterschiedlich konfigurierte Instanzen nicht in die Quere kommen können. Die Angabe "--buttons "4 5"" sorgt dafür, dass imwheel sich nur um die Behandlung des Scrollrads kümmert. Man kann über imwheel auch die Scrollrichtung umkehren. Entweder, indem man die oben stehende Konfigurationsdatei umschreibt oder aber, indem man einfach den zusätzlichen Parameter "--flip-buttons" verwendet:
imwheel --kill --buttons "4 5" --flip-buttonsDas ganze funktioniert unter Debian mit Gnome schon ganz gut, aber nur bis zum nächsten Neustart. Um die Änderung dauerhaft einzurichten, muss man noch dafür sorgen, dass imwheel beim Hochfahren aktiviert wird. Hierfür bietet sich an, die Autostart-Funktion von Gnome zu verwenden. Um das zu erreichen, legt man die Datei "~/.config/autostart/imwheel.desktop" an und befüllt diese wie folgt:
[Desktop Entry]
Name=imwheel
Comment=Use imwheel to increase scroll speed
Exec=/usr/bin/imwheel --kill --buttons "4 5"
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true
X-GNOME-Autostart-Delay=10Auch hier kann man optional den Parameter "--flip-buttons" verwenden, um die Scrollrichtung umzukehren:
[Desktop Entry]
Name=imwheel
Comment=Use imwheel to increase scroll speed
Exec=/usr/bin/imwheel --kill --buttons "4 5" --flip-buttons
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true
X-GNOME-Autostart-Delay=10Ich muss gestehen, dass ich ziemlich genervt bin, dass man halbe Handstände vollführen muss, nur um das Scrollrad zu beschleunigen. 🙄
