Zugschlusbeobachtungen - Computer und Netze

Daten mit Privilege Escalation abholen über eine named pipe

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 11 Feb 2013 09:58:00 +0100

Aufgabe: Transportiere Daten von einem Host auf den anderen über eine ssh-Verbindung. Dafür kann man scp oder sftp verwenden, wenn der eigene Account auf der anderen Seite die Daten lesen darf:

myuser@$TRGHOST$ scp $SRCHOST:$PATH/file .

Interessanter wird das dann, wenn die Daten auf der anderen Seite vom eigenen Account nicht gelesen werden können, man also erst einmal sudo bemühen muss, um die Daten lesen zu können. An dieser Stelle versagt scp bereits - es sei denn, man kann sich auf der anderen Seite als anderer User einloggen:

myuser@$TRGHOST$ scp $ANDERER_USER@$SRCHOST:$PATH/file .

Nur, das scheitert oft daran, dass man das Passwort von $ANDERER_USER nicht kennt, nicht neu setzen kann und/oder seinen ssh-Key nicht in $ANDERER_USER/.ssh/authorized_keys fallen lassen kann oder darf.

Die kanonische Umgehung hierfür war immer

myuser@$TRGHOST$ ssh $SRCHOST sudo -u $ANDERER_USER cat  $PATH/file > file

gerne auch für ganze Unterverzeichnisse mit tar:

myuser@$TRGHOST$ ssh $SRCHOST sudo -u $ANDERER_USER tar --create --$ZIP --file -  --directory $PATH . | tar --extract
--$ZIP --file -

Die Auswahl von $ZIP hängt von der Dicke der Verbindung zwischen den beiden Systemen und ihrer Ausstattung mit CPU ab.

Dieser Trick funktioniert neuerdings allerdings nicht mehr. sudo beklagt sich darüber, dass es kein pty vorfindet, und ssh -t zu benutzen scheitert oftmals daran, dass ein pty die Daten nicht hundertprozentig clean überträgt. Außerdem ist das Caching von sudo-Credentials seit etlichen Monaten an das eine pty gebunden, so dass die Passwortabfrage auf jeden Fall in der Pipe erfolgen muss. Früher hat es gereicht, dann sudo -v in einer anderen Shell auf $HOST auszuführen, aber dass das inzwischen nicht mehr geht, ist eigentlich ganz gut so.

Abhilfe kommt hier in Form der ersten sinnvollen Anwendung einer Named Pipe meiner Unix-Laufbahn, indem man auf der einen Seite das schreibende tar (mit sudo!) aufruft, dass es in die Named Pipe schreibt und man dann die Daten ohne besondere Privilegien von einer anderen Maschine abholt:

myuser@$SRCHOST$ mkfifo foo; chmod 666 foo
myuser@$SRCHOST$ sudo -u $ANDERER_USER tar --create --$ZIP --file foo --directory $PATH .
myuser@$TRGHOST$ ssh $SRCHOST cat foo | tar --extract --$ZIP --file -

Wenn die Daten irgendwelche Wichtigkeit haben, möchte man natürlich über geeignete Rechte auf der pipe dafür sorgen, dass nicht irgendjemand anders vor einem selbst auf die pipe connected und die Daten abholt; für den Hausgebrauch tut es chmod 666.

Domain, Zone, Web- und Nameserver, Ägypten?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 18 Oct 2012 07:00:00 +0200

Aus aktuellem Anlass hier ein aus den wegen dummer Software derzeit unerreichbaren “Zugschlus’ manchmal nützlichen Antworten” schnell reingepasteter Artikel

Ungenaue Terminologie wird im Internet oft von Leuten verwendet, die zwar ungefähr wissen, wie die Dinge funktionieren, sich aber nicht im hinreichenden Maße mit den Hintergründen beschäftigt haben. Dies erschwert die Kommunikation und ist oft dafür verantwortlich, dass ein Auftragnehmer nicht das ausführt, was sein Auftraggeber eigentlich möchte.

Ein besonders von diesem Problem geplagter Bereich der Internet-Technik ist der Domain Name Service (DNS), da hier in besonderem Maße die Kommunikation zwischen verschiedenen Leistungsträgern in unterschiedlichen Unternehmen notwendig ist.

Mit diesem Text will ich versuchen, etwas Klarheit in die Terminologie zu bringen.

Was ist ein Nameserver?

Nameserver sind im Internet erreichbare Computer, die an der Namensauflösung beteiligt sind. Diese Rolle können die Rechner in verschiedenen Formen wahrnehmen:

Ein für eine Domain authoritativer Nameserver kann Anfragen für diese Domain authoritativ, also mit endgültiger Sicherheit, beantworten, weil er die Informationen für die Domain selbst vorliegen hat und sich hierbei nicht auf die Antworten anderer Nameserver verlassen muss.

Ein authoritativer Nameserver, der als Master (auch als “primary” bezeichnet) konfiguriert ist, ist ein Nameserver, der die Informationen für seine Domains von ausserhalb des Domain Name System erhält. Gängig sind hier beispielsweise Zonefiles oder Datenbanken. Ein Master, an den die Zone selbst nicht delegiert ist , wird als “hidden master” bezeichnet und kommt vor allen Dingen dort zum Einsatz, wenn der Domaininhaber zwar die Zone selbst unter eigener Kontrolle haben möchte, aber nicht hinreichend gut angebunden ist, um die Zone selbst zu sich delegieren zu lassen.

Ein authoritativer Nameserver, der als Slave konfiguriert ist, erhält die Informationen für seine Domains mit DNS-Mechanismen (Zone Transfer, AXFR oder neumodische IXFR) von einem als Master konfigurierten authoritativen Nameserver, der in der Konfiguration des Slaves festgelegt ist. Der Slave holt sich die aktuellen Daten für die Domain in regelmässigen Abständen oder auf explizite Anforderung vom Master und kann fortan auch dann für “seine” Domains authoritative Auskünfte erteilen, wenn der Master gerade nicht erreichbar ist. Wenn der konfigurierte Master für eine bestimmte Zeit nicht erreichbar war, stellt der Slave die Erteilung authoritativer Auskünfte für die betreffende Domain ein.

Erhalten die DNS-Server ihre Daten über andere Wege (z.B. über eine replizierte SQL-Datenbank), ist auch der Server, dessen DNS-Server auf einen SQL-Slave als Datenquelle zugreift, im DNS-Sinne ein Master.

An einen authoritativen Nameserver ist eine Zone delegiert, wenn dieser Nameserver in einem auf diese Zone zeigenden NS-Record in der “Parent Zone” auftaucht. Die in der Parent Zone eingetragenen NS-Records müssen mit denen in der Zone selbst übereinstimmen.

Ein Full Resolver oder auch Recursor ist ein Nameserver, der auch Anfragen entgegennimmt, für deren Domains er nicht authoritativ ist. Er bemüht sich dann, die benötigten Informationen aus dem DNS herbeizuschaffen und liefert eine nicht authoritative, “best effort” Antwort an den Anfragenden aus.

Die Nameserver, die ein Endbenutzer in seinem Rechner eintrögt oder (z.B. per PPP, DHCP oder DNSSD) zugewiesen bekommt, sind Full Resolver. Die von Endbenutzern beim Full Resolver ankommenden Anfragen sind sogenannte “rekursive” Anfragen.

Anstelle des Begriffs “Full Resolver” sind auch die Begriffe Full Service Resolver, Recursive Server, Recursive Resolver und Forwarder in Verwendung. Im Zusammenhang mit dynamischen Updates geniesst der Begriff Forwarder aber eine Sonderbedeutung, so dass dieser Begriff im Allgemeinen nicht korrekt verwendet wird.

Oft findet man bei kleineren Installationen die Funktionen eines authoritativen Nameservers und eines Full Resolvers auf einer Maschine vereint. Für die dort liegenden Zonen wird dem gesamten Internet authoritativ Auskunft erteilt, und zusätzlich werden rekursive Anfragen aus dem “eigenen” Netz beantwortet.

Diese Vereinigung von Aufgaben ist nach meiner Meinung nur in den seltensten Fällen sinnvoll, da sie nichts miteinander zu tun haben, die sachgerechte Konfiguration des Nameservers unnötig verkomplizieren und im Falle von Konfigurationsfehlern sehr leicht dazu führen können, dass die Benutzer des fehlkonfigurierten eigenen Nameservers eine andere Sicht auf das Internet haben als der Rest der Welt.

Was ist eine Domain, was ist eine Zone?

Der DNS ist eine verteilte, hierarchische Datenbank, in der die Namen und IP-Adressen aller im Internet sichtbaren Systeme hinterlegt sind. Ein Beispiel für die Hierarchie sieht man in der Abbildung.

Jeder Knoten im abgebildeten Baum ist eine Domain. Eine Domain, die im Baum unterhalb einer anderen Domain liegt, wird eine Subdomain genannt. Die Blläter des Baumes sind ebenfalls Domainnamen, wobei dieser Sonderfall auch als Hostname bezeichnet werden kann. mail.at.example.com ist also ein Hostname, eine Domain und eine Subdomain von at.example.com.

Die Wurzel des Baumes wird in der Literatur als “.” bezeichnet; die direkt darunter liegenden Domains (z.B. de, com, net, org) als “Top-Level-Domains” oder “First-Level-Domains”. Die “höchsten” Domains, die man als Unternehmen oder Privatmensch mit vertretbarem Aufwand selbst registrieren kann, sind die “Second-Level-Domains” wie zum Beispiel example.com.

Manche First-Level-Domains vergeben sogenannte "generische Second-Level-Domains". In diesen First-Level-Domains kann man dann erst Third-Level-Domains selbst registrieren lassen, die dann wie zum Beispiel in Grossbritannien unterhalb von co.uk oder or.uk liegen können.

Glücklicherweise ermöglicht der DNS, die Verteilung der Daten etwas von der Hierarchie unabhängig zu gestalten. Das ist insbesondere dann praktisch und wichtig, wenn Subdomains einer Domain unter unterschiedlicher Verwaltung stehen oder auch nur ihre Größe ungleichmäßig verteilt ist. Die Einheit für die Verteilung der Daten ist die Zone. Im Beispiel ist die Domain example.com und ihre Subdomains auf zwei Zonen verteilt. example.com ist an die im Beispiel rechts eingezeichnete Zone delegiert, die die Resource Records für www.example.com, at.example.com und die Domains unterhalb von at.example.com direkt selbst enthält. de.example.com ist an die im Beispiel links eingezeichnete Zone delegiert, die auf einem ganz anderen Nameserver liegen kann und von anderen zuständigen Personen verwaltet werden kann. Bei der weit verbreiteten Nameserver-Software bind liegen die Daten einer Zone stets in einer Datei, dem sogenannten Zone File.

Im Zone File werden schlussendlich die eigentlichen Einträge gemacht, die den DNS mit Leben füllen. Diese Einträge erfolgen in Form von Resource Records (RR), die einen Domainnamen mit Informationen verschiedenster Art verknüpfen. Wegen der Wichtigkeit dieses Stoffes wird es hierfür einen eigenen ZMNA-Artikel geben.

Der Weg vom Registrar zum Webserver

Eigentlich ist das alles ganz einfach. Gehen wir Schritt für Schritt vor für den üblichen Fall, dass K unter dem Namen www.example.com eine Webseite ins World Wide Web stellen möchte:

K bittet seinen Provider P, für ihn die Domain example.com zu registrieren.
P legt auf seinen Nameservern N1 und N2 eine Zone an, die die gewönschten Nameservice-Daten für die Domain example.com enthält.
P sucht sich einen der für die von K gewählte Top-Level-Domain (hier: .com) zuständigen Registrare R heraus und registriert über diesen die Domain example.com.
R trägt K als kaufmännischen Ansprechpartner (admin-c) und P als technischen Ansprechpartner (tech-c, zone-c) in der Domainregistrierungsdatenbank ein und sorgt dafür, dass in den für com zuständigen Nameservern die Zone für example.com an N1 und N2 delegiert wird.
Somit ist P nun in der Lage, weltweit sichtbare Resource Records für die Domain example.com im DNS bekannt zu machen.
P legt einen Webserver W für www.example.com an und gibt K die Möglichkeit, auf diesen Webserver die gewünschten Inhalte zu hinterlegen.
P trägt in der Zone für example.com die passenden Resource Records (hier: einen A- oder einen CNAME-Record) an, damit die IP-Adresse von W mit dem Domainnamen www.example.com verknüpft sind.

Von der Idee bis zum benutzbaren Webserver führten also die folgenden Schritte:

Registrierung der Domain.
Vorbereitung der Nameserver.
Delegation der Domain.
Vorbereitung des Webservers
Hinterlegung der Inhalte auf dem Webserver
Eintragung des Hostnamens www auf dem Nameserver

Diese Schritte können in den verschiedenen Geschäftsmodellen auf unterschiedliche Beteiligte verteilt werden. Oben beschrieben ist eine der üblichsten Vorgehensweisen, bei der der Kunde sowohl die Domain selbst, den DNS und den Webserver beim gleichen Liferanten bestellt.

Was für Einträge brauche ich in meiner frisch delegierten Zone?

Die Antwort auf diese Frage ist wie so häufig “es kommt darauf an”, nämlich darauf, was man mit der Zone eigentlich machen möchte.

Eine Zone muss immer und zwingend mindestens zwei Einträge enthalten: Einen SOA- und mindestens einen NS-Eintrag. Die NS-Einträge müssen mit den Einträgen in der “Parent Zone” (z.B. .com für .example.com) übereinstimmen.

Weitere Einträge sind nur dann notwendig, wenn die Domain wirklich benutzt werden soll:

Wenn die Domain im E-Mail-Verkehr verwendet werden soll, so sind MX-Records notwendig, die den Mailservern draussen im Internet bekannt geben, wo Mail an die Domain abzuliefern ist.
Hier sind wiederum andere Dinge zu beachten:
- Ein MX-Record sollte immer nur auf einen Rechnernamen zeigen, der wiederum als A-Record eingetragen sein muss. Insbesondere funktionieren hier keine IP-Adressen, und auf CNAMEs zeigende MX-Records sind mindestens umstritten.
- Ein MX-Record ist mit einer Priorität versehen. Ein externer Mailserver wird zuerst versuchen, Mail für die Domain bei dem Rechner abzuliefern, auf den der MX-Record mit der kleinsten Priorität zeigt. Erst wenn dieser nicht erreichbar ist, kommen die mit höherer Priorität zum Zuge.
- Ein Mailserver muss dafür konfiguriert sein, Mails für eine Domain anzunehmen. Blosses Eintragen eines MX-Records funktioniert in aller Regel nicht.
- In vielen Fällen soll eine Domain nicht am Mailverkehr teilnehmen. In diesen Fällen ist es zweckmässig, den MX-Record einfach wegzulassen. Einen MX-Record auf 127.0.0.1 oder auf einen anderen beliebigen Host zu setzen, der keine Mail für die Domain annehmen kann, ist unhöflich und sollte unterbleiben.
- Mail an einen Domainnamen, für den ein A-Record, aber kein MX-Record eingetragen ist, wird an die IP-Adresse zugestellt, die im A-Record genannt ist. Dieses Verhalten ist eine Altlast aus längst vergangenen Zeiten, in denen jeder Rechner sein eigenes unabhängiges Mailsystem hatte und ist heute in vielen Fällen ist dies unerwünscht.
  
  Besonders lästig ist es in dem Fall, in dem eine Domain nicht am Mailverkehr teilnehmen soll, aber ein Webserver ohne vorangestelltes www erreichbar sein soll. Somit werden nämlich Mails an die Domain beim Webserver zugestellt, was heutzutage in den meisten Fällen nicht sinnvoll ist. Dieses Problem ist wirklich befriedigend nicht zu lösen. Unter Umständen ist es ratsam, einen MX-Record auf einen Mailserver zu setzen, der Mails für den Domainnamen mit "550 no e-mail service for this recipient domain" ablehnt.
Die allermeisten Domains werden registriert, um einen Webserver anzubieten. Hierfür hat sich eingebürgert, den Hostnamen “www” in der registrierten Domain zu wählen, was zu Hostnamen wie “www.example.com” führt. Um dies zu erreichen, wird im Zonefile ein A-Record eingetragen, der den Hostnamen “www” mit der IP-Adresse des Webservers verknüpft. Die explizite Reservierung einer weiteren Domain ist hierfür nicht notwendig; der Inhaber einer Domain hat die Kontrolle über alle Domain- und Hostnamen unterhalb dieser Domain.

Allerdings ist es nicht zwingend notwendig, für einen Webserver den Hostnamen “www” zu verwenden. Webserver können unter beliebigen Hostnamen angelegt werden, und es ist selbstverständlich auch möglich, innerhalb einer Domain oder innerhalb einer Zone mehrere Webserver anzulegen. Sie müssen nur unterschiedliche Namen haben, damit sie unterschieden werden können.

Die gängigsten Terminologiefehler im DNS

"Lieber Provider, bitte registriere für mich die Domain www.example.com."

Das kann der Provider nicht tun. Der Kunde will in diesem Fall die Domain example.com registriert haben, und in der Zone für diese Domain einen Eintrag “www”, für den der Provider zusätzlich zum Domainnamen auch noch eine IP-Adresse braucht.
"Lieber Provider, ich möchte bitte die Zugangsdaten, um die Webseiten auf meine Domain www.example.com hochzuladen."

Diese Anfrage ist Unsinn. Eine Domain ist ein Begriff aus dem DNS. Im DNS gibt es weder Webseiten noch Zugangsdaten. Was der Kunde möchte, sind die Zugangsdaten zu dem Webserver, der in der Domain example.com mit dem Hostnamen www eingetragen ist.
“Lieber Provider, meine Domain www.example.com ist nicht erreichbar.”

Auch hier meint der Kunde meist, dass anstelle der Domain sein Webserver nicht erreichbar ist. Das kann eine Störung im Netz, eine Störung im Webserver, oder wirklich eine Störung im Domain Name Service sein. Dies korrekt zu diagnostizieren, überfordert die meisten Netzteilnehmer, und führt den Support des Providers in die Irre, weil jeder, der täglich mit Internetsystemen zu tun hat, bei einer gemeldeten Domainstörung immer zuerst und sofort den Nameserver prüfen wird, wenn auch die häufigsten Ursachen für die hier besprochenen Störungen nicht dort zu finden sind.
"Lieber Provider, bitte route die Domain www.example.com auf die IP-Adresse a.b.c.d"

Diese Anfrage ist - wie so oft - aus der Verwechslung zwischen Domain und Webserver entstanden, gemischt mit dem Halbwissen, dass IP-Adressen geroutet werden. Das ist natürlich auch terminologisch falsch.

Mit diese Anfrage möchte der Kunde dem Provider in aller Regel mitteilen, dass er auf der IP-Adresse a.b.c.d einen Webserver bereitgestellt hat, der in der Lage ist, http-Anfragen für Webseiten unter http://www.example.com/ zu beantworten. Der Provider soll nun, damit dieser Webserver auch über den Namen erreichbar wird, einen A-Record im DNS eintragen, der den Namen www.example.com mit der IP-Adresse a.b.c.d verknöpft.

Das ganze hat mit Routing noch weniger zu tun als mit Domains.

Heute mal wieder Debian

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 18 Jun 2012 18:53:44 +0200

In den letzten 24 Stunden habe ich endlich mal wieder was für Debian gemacht: dnstop und sipcalc vom bisherigen Maintainer übernommen, auf Vordermann gebracht und uploaded, und immerhin einen Alibi-Upload von pdns-recursor, damit auch der recursor mit der neuen Maintainer-Mailingliste im Maintainerfeld und dem korrekten Alioth-Vcs-Link im debian/control nach Wheezy kommt.

Next PowerDNS version for Debian ready for testing

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 17 Jun 2012 17:34:00 +0200

I have published PowerDNS version 3.1-1.0 on https://ivanova.notwork.de/~mh/debian/pdns/

This is a preliminary package and a release candidate to be 3.1-2 in Debian. If you’re interested in PowerDNS on Debian, please test this package.

I plan to upload next week. This package will vanish from the web server once the package is visible in Debian.

Eine Zahl mit 37 Nullen und vielen Mißverständnissen

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 09 Jun 2012 13:25:47 +0200

SWR3 hat anlässlich des World IPv6 Launch Days einen Artikel über IPv6 veröffentlicht.

Und gemessen an dem, was sonst so in der Presse über IPv6 geschrieben wird, war dieser Artikel nicht so, dass man ihn neu schreiben müsste, um ihn mit der Realität in Verbindung zu setzen. Nach einer kurzen Twitter-Diskussion mit @SWR3 habe ich mich entschlossen, nicht das Kommentierspielchen auf der SWR3-Webseite zu spielen, sondern einen Blogartikel darüber zu schreiben

Vorab sei gesagt: Ich nutze IPv6 täglich, auf fast allen meinen eigenen Rechnern ist IPv6 aktiviert. Dies tue ich hauptsächlich, um von überall auch auf die Rechner zugreifen zu können, für die keine eigene IPv4-Adresse verfügbar ist, und die ich sonst nur auf Umwegen erreichen könnte. Dies gilt sowohl für meine Rechner zuhause als auch für die virtuellen Maschinen, die auf Housingservern angesiedelt sind, für die es nur eine IPv4-Adresse gibt.

Da ich dies über ein OpenVPN tue, könnte man dieses Ziel zwar auch mit IPv4 und intern gerouteten RFC1918-Adressen erreichen, IPv6 tut dies aber schöner und ohne Unterscheidung zwischen “intern” und “weltweit”.

Freilich hat IPv6 auch Nachteile. Und zwar so viele und so nervige, dass ich vermutlich noch dieses Jahr einen Vortrag über die größten IPv6-Marketinglügen für eine noch näher zu bestimmende Konferenz einreichen werde. Es ist wirklich nicht alles Gold was glänzt.

Aber nun zu Peter Mühlfeits Artikel auf SWR3.de. IPv4-Adressen sind knapp. So knapp, dass auch größere Internetprovider nicht mehr so viele IPv4-Adressen neu zugewiesen bekommen, und deswegen nicht mehr so schnell weiter wachsen können, wie sie eigentlich wollten. Dies entwickelt sich zunehmend zur Innovationsbremse für die ganze Branche.

IPv6 ist eine langfristige Maßnahme, Carrier Grade NAT eine kurzfristig helfende. Über Carrier Grade NAT kommt in Kürze in diesem Blog ein weiterer Artikel (dafür muss ich aber schlecht genug drauf sein, dieser Artikel wird keinen Spaß machen).

Niemand hat vor, 34*10³⁷ Systeme ins Internet zu hängen. Die vielen Adressen werden dazu dienen, das Netz besser zu strukturieren und um die Administration leichter zu machen. Für die meisten Administratoren wird das Hantieren mit Netzmasken beispielsweise zur Vergangenheit gehören: Anstelle heute mit dem oft unangemessen großen /24 (v4) zu arbeiten (weil viele nichts anderes kennen), wird man bald nur noch /64-Netze (v6) verwenden, was natürlich noch viel mehr unangemessen groß ist, aber da die Adressen so lang sind, wird das sicher nicht mehr stören.

Und “umstellen” wird man auf IPv6 sicher in den nächsten Jahren nicht. Das hat Peter Mühlfeit ja auch richtig vestanden, denn er schreibt ja, dass der alte Standard parallel aktiv bleiben wird. Warum er trotzdem persistent in seinem Artikel von der “Umstellung” auf IPv6 spricht, verstehe ich nicht. Bestenfalls wird IPv6 parallel aktiviert, und die meisten Nutzer werden davon in der Tat nichts merken. Schief laufen kann dabei allenfalls, dass plötzlich und ungeplant IPv6 hinzukommt, und der Benutzer darauf noch nicht vorbereitet ist. Da kann vorkommen, dass zwar ein Hostname plötzlich eine IPv4- und eine IPv6-Adresse zugeordnet bekommt, aber auf der IPv6-Adresse noch kein Dienst konfiguriert ist, oder eine Firewall-Freigabe fehlt. Das ist dann aber ein Adminfehler, für den IPv6 erstmal nichts kann. Das kann mit IPv4 genau so passieren.

“Wenn der Provider schon umgestellt hat” ist ein Beispiel für “ex falso quodlibet”. Kein ISP auf dieser Welt hat am 06. Juni IPv4 abgeschaltet. Und dass IPv6 hinzugekommen ist, wird man zunächst nicht merken. Wenn man plötzlich IPv4 und IPv6 hat, wird IPv6 genutzt, wo es möglich ist. In den meisten Betriebssystemen kann man konfigurieren, welches Protokoll genutzt werden soll, wenn beide verfügbar sind. Unter Linux beispielsweise wird IPv6, so verfügbar, bevorzugt genutzt. IPv6-fähige Browser auf IPv6-fähigen Betriebssystemen werden beispielsweise dieses Blog per IPv6 abrufen, denn blog.zugschlus.de ist schon seit Jahren per IPv6 erreichbar. Wer durch die Aktivierung von IPv6 parallel zu IPv4 seine Konnektivität verliert, hat einen ISP, der es nicht kann. “This should not happen”.

Nun aber zum Kernthema der IPv6-Gegner, der Privacy. Man sagt, mit IPv6 hat jedes Endgerät seine eigene, statische IP-Adresse und wird identifizierbar. Nun, das ist eingeschränkt heute schon so. Dass wir unsere Heimnetze in aller Regel täglich hinter einer neuen IPv4-Adresse verstecken, hat den Grund, dass die Telekom damals bei der Einführung von DSL eine tägliche Zwangstrennung vorgesehen hat. Dies tat sie nicht aus Wohltätigkeit, sondern weil sie wenig Vertrauen in ihr eigenes UDP-basiertes Accounting hatte und lieber alle 24 Stunden einen Reset des Accounting erzwingen wollte, um zeitbasierte DSL-Zugänge sinnvoll und zuverlässig abrechnen zu können. Das hat sich durch Flatrates weitgehend erübrigt, aber die Zwangstrennung blieb - heute hauptsächlich, um Nutzer davon abzuhalten, aktiv am Netz teilzunehmen und eigene Server zuhause zu betreiben. Dynamic DNS ist nur Flickwerk.

Viele Nutzer genießen die Möglichkeit, in ihrem Router auf “Trennen” zu klicken und eine neue IPv4-Adresse zu bekommen. So kann man IP-basierte Trackingmechanismen aushebeln, bleibt aber natürlich trotzdem dank Cookies, Zählpixeln etc für diejenigen trackbar, die das wirklich wollen. Nutzer mit anderen Zugangstechniken, z.B. am Fernsehkabel, müssen ihr Modem aus der Steckdose ziehen, damit sie eine neue IPv4-Adresse zugewiesen bekommen, sonst bleibt diese über Monate hinweg konstant.

In diesen Szenarien bleibt nicht das Endgerät trackbar, sondern der Anschluß. Somit kann man rein am IP-Datenstrom nicht erkennen, wenn das mit IPv4 angebundene Notebook daheim, am Kneipenhotspot oder im UMTS-Netz betrieben wird.

Bei IPv6 wird das in der Tat ein wenig schlechter. Eine IPv6-Adresse teilt sich auf in Prefix und Hostadresse. Dabei wird diese Trennung in typischen Heimnetzwerken in der Mitte, nach dem 64sten Bit liegen. Ich sage voraus, dass “kleinere” Netze in der Praxis kaum auftreten werden, und in den typischen Netzen, in denen sich mobile Endgeräte bewegen werden (daheim, LANs in Firmen, Kneipen-Hotspot etc) wird man ausschließlich /64-Netze sehen. Denn nur bei der Netzgröße /64 funktionieren die Automatismen, die IPv6 so einfach machen.

Ein Tracking des DSL-Anschlusses wird also auch bei IPv6 weiterhin möglich sein: Man guckt sich dabei halt nicht die komplette IPv4-Adresse, sondern nur die ersten 64 Bit der IPv6-Adresse an. Wenn die DSL-Provider bei der Aktivierung von IPv6 auf die Zwangstrennung verzichten und beim Neuaufbau der Verbindung keinen neuen, mehr oder weniger zufälligen IPv6-Prefix zuweisen, wird der mit IPv6 erreichbare Anschluß seinen festen Prefix haben und jeder wird erkennen können, dass die Verbindung heute vom gleichen DSL-Anschluß in Ilvesheim kommt wie die Verbindung von vor einer Woche. Wenn ich mich irgendwo angemeldet habe, hat der Betreiber dieses Dienstes auch die Zuordnung zwischen meinem IPv6-Prefix und meiner Person.

Dass man das nicht will, liegt auf der Hand. Aber die Situation ist bei IPv4 auch nicht anders: Tut mir mein ISP nicht den Gefallen und weist mir täglich eine neue IPv4-Adresse zu, bin ich mit IPv4 genau so trackbar wie ich es mit einem statischen IPv6-Prefix bin.

Deswegen meine dringende Bitte an die Endkunden-ISPs: Bitte implementiert für IPv6 genau so einen regelmäßigen Wechsel des Prefixes, wie Ihr das heute mit IPv4 tut. Tut ihr das richtig, geht sogar der Wechsel des Prefixes, ohne dass bestehende Verbindungen abbrechen, wie es heute bei der Zwangstrennung passiert. Für diejenigen, die für eigene lokale Dienste eine feste IP-Adresse haben wollen, könnt Ihr dies wie heute schon bei IPv4 als (kostenpflichtigen?) Zusatzdienst anbieten. Auch hier kann man die Dinge wieder “richtig” machen und dem Kunden zusätzlich zum statischen Prefix auch einen dynamischen Prefix anbieten. Ich sehe allerdings nicht, dass sich dieses, doch recht komplexe Zugangsmodell in der Praxis durchsetzen will.

Bei IPv6 gibt es noch einen weiteren Privacy-Aspekt, der aus der IP-Adresse erwächst: Den Host-Teil der Adresse. Der kann im Autoconfigurations-Verfahren vom Endgerät frei gewählt werden. Dabei muss natürlich darauf geachtet werden, dass keine Kollisionen auftreten. Deswegen hatte man zunächst ein Verfahren definiert, das die (in der Theorie) weltweit eindeutige, 48 Bit lange MAC-Adresse des Netzwerkinterfaces mit in den Hostteil der IPv6-Adresse einfließen lässt. Somit wählt sich jedes Endgerät in einem autokonfigurierten IPv6-Netzwerk denselben Hostteil, was natürlich dazu führt, dass mein Notebook als “mein Notebook” identifizierbar wird, und zwar unabhängig davon, ob ich im Hotel-WLAN, im Gästenetz beim Kunden oder bei mir zuhause bin.

Das ist natürlich ein Privacy-GAU, und zwar einer, der bei IPv6 neu ist, und den wir gesondert behandeln müssen. Aber - natürlich - gibt es dafür auch eine Lösung, die auch Peter Mühlfeit in seinem Artikel angesprochen hat: Mit aktivierten Privacy Extensions würfelt sich ein Rechner in einstellbaren Zeitabständen einen neuen Host-Teil und nutzt diesen für neue Verbindungen. Damit hat man eine regelmäßig wechselnde IPv6-Adresse und hat somit den Privacy-GAU elegant umschifft. Elegant deswegen, weil der Adresswechsel so stattfindet, dass die neue Adresse für neue Verbindungen benutzt wird, während die alte(n) Adresse(n) weiterhin nutzbar bleiben, um bereits aufgebaute Verbindungen weiter bedienen zu können. Ach ja: Privacy Extensions sind bei Windows 7 im default eingeschaltet.

Wenn man zuende denkt, ist natürlich das Tracking über die IP-Adresse nur die offensichtlichste Anwendung. Wenn man wirklich anonym im Netz unterwegs sein will, möchte man Tor oder andere Anonymisierungdienste verwenden, und muss auch dann noch darauf achten, dass man nicht über Login-Daten, Cookies etc identifizierbar wird oder bleibt. Das ganze IP-Adressen-Privacy-Geraffel ist im Grunde genommen nur Augenwischerei - was nicht heißen soll, dass man es ignorieren kann.

Dem aufmerksamen Leser wird nach der Lektüre dieses viel zu langen Artikels nicht entgangen sein, dass man mit IPv6 mehrere Adressen pro Endgerät haben kann. Das ist für den Systemadministrator der Kernunterschied und eigentlich auch das Killerfeature von IPv6. Mehrere Adressen pro Host sind zwar schon bei IPv4 möglich, aber immer mit Klimmzügen verbunden. Mit IPv6 kann man einfacher kontrollieren, welche Adresse für ausgehende Verbindungen genommen wird, und man kann bei IP-Adress-Wechseln die “alte” Adresse im Status “deprecated” weiterführen, damit man bestehende Verbindungen nicht abbrechen muss. Leider stößt dabei das bald 40 Jahre alte UNIX network socket API hierbei an seine Grenzen, so dass viele Applikationen mit mehreren oder sich gar während der Laufzeit des Dienstes ändernden IP-Adressen mehr schlecht als recht umgehen können. Zumindest auf Servern ist der nahtlose Wechsel zwischen IP-Adressen mit heutiger Software leider eine Marketinglüge: Renumbering tut bei IPv6 genau so weh wie bei IPv4.

atop in unstable

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 31 May 2012 09:13:06 +0200

Eight days ago, I uploaded atop 1.26-1 to DELAYED/8, listing me as new maintainer. This means that the package has in the mean time appeared in unstable, and I hope that it’ll swiftly migrate to testing.

btrfs gegen ext4, ein unerwarteter Sieger

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 20 May 2012 10:39:57 +0200

Alle Leute sagen, btrfs sei die Zukunft. Es gibt Leute, die einen schon mitleidig angucken, wenn man ihnen sagt, dass man immer noch ext4 einsetzt, wie ich das tue. Aber ich hatte neulich einen Grund, btrfs auszuprobieren. Mit btrfs kann man nämlich Snapshots innerhalb einer verschlüsselten LV einsetzen. Mit ext4 muss man vom Cryptodevice einen Snapshot machen und dann den Snapshot gesondert aufschließen. Damit ist schroot derzeit noch überfordert (#639105).

Also habe ich mal btrfs ausprobiert und musste feststellen, dass es mindestens beim Anlegen eines chroot massiv langsamer ist als ext4. Hier meine Messergebnisse für das Anlegen eines sid-chroot mit debootstrap mit und ohne eatmydata:

fs	eatmydata	Laufzeit
ext4	nein	4:40
ext4	ja	4:17
btrfs	nein	8:50
btrfs	ja	8:46

Ich muss sagen, ich bin entsetzt. Sowohl darüber, dass btrfs so viel langsamer ist, als auch darüber, dass eatmydata so gut wie nix bringt. Habe ich etwas falsch gemacht? Braucht btrfs beim Erstellen des Dateisystems bzw. beim Einhängen desselben irgend eine magische Option, um in die gleiche Performanceregion wie ext4 zu kommen?

Testumgebung war Debian GNU/Linux sid auf einer KVM VM.

rrdcached schont die Platte

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 12 Mar 2012 22:21:56 +0100

Schon im neunten Eintrag in diesem Blog im Jahr 2005 ging es um munin. Es ist jetzt schon sieben Jahre her, dass ich dieses Tool einsetze. An vielen Stellen nervt es, aber die schlimmsten Macken sind mit der hoffentlich bald erscheinenden (aber auch als beta schon stabil laufenden) 2.0 abgestellt.

Munin 2.0 rechnet die Grafiken nur noch auf Anforderung neu, und mit einer noch mehr im Betastadium befindlichen weiteren Konfigurationsoption gehört auch munin-html der Vergangenheit an.

Bleibt nur noch das Problem, dass munin bei mehr als einer Handvoll Rechnern die Platte foltert. rrdtool rödelt auf den Datenfiles herum wie nichts gutes, und die Platte ist die ganze Zeit über beschäftigt. Auf die Dauer macht das keinen Spaß.

Mit rrdcached kann man die Datensicherheit gegen Geschwindigkeit oder geringere Systembelastung tauschen. munin 2.0 unterstützt rrdcached direkt, und nach wenigen Minuten Konfiguration und ein wenig Gefrickel mit den Permissions landen die fünfminütigen Updates nicht direkt im rrd-File, sondern erstmal im RAM des Munin-Masters. Der rrdcached schreibt die Daten dann auf Anforderung oder nach Ablauf einer bestimmten Zeit. Die Auswirkung des rrdcached sieht man hier:

Die Bilder sprechen für sich.

letzte netfilter-init Installation ausser Betrieb

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 19 Feb 2012 17:02:35 +0100

Im Jahr 1999 habe ich im Rahmen meiner Diplomarbeit ein Framework entwickelt, das flexibel und leistungsfähig die Erstellung von - damals noch - ipfwadm-basierten Firewalls erlaubte. Irgendwann wurde es dann auf iptables aktualisiert und war insgesamt zwölf Jahre lang in zahlreichen Installationen im produktiven Betrieb.

Eben habe ich die letzten zwei Instanzen abgeschaltet. Und ich bin froh darüber.

Als ich netfilter-init schrieb, war es Stand der Technik, in einem Script zunächst das komplette Regelwerk zu löschen und dann durch explizit geschrieben Aufrufe von ipfwadm neu aufzubauen. Abhängig davon, wieviel Mühe man sich dabei gab, war die Firewall während dieses Aufbauprozesses für einige Zeit komplett offen oder komplett zu, was auf der einen Seite ein Sicherheitsrisiko ist und auf der andren Seite im Falle eines fatalen Tippfehlers den ssh-Zugriff auf die Firewall unterbindet, wenn der Aufbau des Regelwerks abbricht, bevor die Regeln etabliert sind, die den ssh-Zugriff erlauben.

Mit netfilter-init war ein Konglomerat verschiedener Shellscripts. Das Haupt-Regelwerk war dabei in eigenen Rules versteckt, die nach dem Bau des Regelwerks mit einer atomaren iptables --replace Regel aktiviert wurden. Auf diese Weise war das alte Regelwerk bis zum erfolgreichen Bau des neuen Regelwerks aktiv. Außerdem hatte ich ein Verfahren implementiert, mit dem man Kreuzprodukte schreiben konnte: --src { 192.168.0.0/24 , 192.168.10.0/24 } --dst { 172.16.0.0/24 , 172.17.0.0/24 } erzeugte vier Regeln.

Mit dem Einbau von netfilter-init in das Firewall-Produkt meines damaligen Arbeitgebers bekam netfilter-init kommerzielle exposure und zeigte recht schnell seine Grenzen: Besonders die Expansion der Kreuzprodukte und die Einbindung der aktuellen Netzwerkkonfiguration des Gerätes waren viel zu langsam, so dass die stringintensiven Operationen relativ schnell in einige kurze C++-Programme ausgelagert wurden. perl wollte ich damals vermeiden, weil meine Vision war, ein minimales Firewall-System ohne perl installieren zu können. Leider entwickelte sich Debian in die andere Richtung, und es ist heute richtig schwer, ein Debian ohne perl und ohne python zu betreiben.

Parallel dazu gab es den Versuch, einen in C geschriebenen Konverter zu etablieren, der mir erlauben sollte, dieselben Scripts zum Regelwerkbau zu verwenden wie vorhanden, nur nicht für jede Regel einen eigenen iptables-Aufruf absetzt, sondern die Regeln im Speicher zusammenbaut, um sie dann zum Schluß atomar via iptables-restore in den Kernel zu schieben. So weit kam es dann nicht mehr, weil ich den Arbeitgeber wechselte.

netfilter-init wurde von mir nie wirklich ernsthaft veröffentlicht, weil zu dem Zeitpunkt, zu dem die nötige Reife erreicht war, andere Lösungen wie shorewall etc da waren, die den Job besser gemacht haben. Ich habe nur lange gebraucht, bis ich eine Lösung fand, die auch meine Wünsche erfüllt.

Währenddessen schrumpfte die Installationsbasis von netfilter-init immer weiter, während die großen Installationen so langsam auf unzumutbare Arbeitsgeschwindigkeiten kamen. Dies lag zum Schluß nichtmal mehr an den Shellscripts, sondern an iptables, bei dem es signifikant Zeit dauert, 16000 Regeln aus dem Kernel auszulesen und dann 16001 Regeln wieder in den Kernel zurückzuschreiben. Meine größte Installation hat schließlich 15 Minuten gebraucht, um das Regelwerk neu zu bauen, was besonders beim Booten, wo kein “altes” Regelwerk zur Verfügung stand, unangenehm war.

Schließlich entdeckte ich ferm und arbeitete lange daran, “meine” Spezialitäten auch in einem mit ferm gebauten Paketfilter unterzubringen. Dies gipfelte in einigen kleinen Patches gegen den ferm-Code selbst und einem inzwischen ganz gut ausgefeilten “Drumrum”. Das eigentliche Regelwerk wird auf einem Managementsystem gebaut und das daraus entstehende iptables-restore-taugliche File per scp auf die eigentliche Firewall geschoben. Bevor das neue Regelwerk dort etabliert wird, gibt es einen at-job, der das alte Regelwerk wieder aktiviert, wenn nicht innerhalb von 30 Sekunden ein neuer erfolgreicher Login vom Management-System erfolgt und somit nachgewiesen ist, dass auch das neue Regelwerk den Management-Zugang erlaubt. Versionskontrolle in git rundet die ganze Aktion ab.

Heute habe ich jetzt die beiden letzten, kleinen netfilter-init-Installationen von lenny auf squeeze gehoben und den Bau des Regelwerks auf mein ferm-Framework umgestellt. Damit endet für mich eine Ära. Wenn man mir 1999 gesagt hätte, dass diese Software zwölf Jahre lang leben wird - ich hätte es nicht geglaubt.

In diesem Sinne: netfilter-init ist tot, es lebe ferm.

perl and caches

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 20 Jun 2011 14:02:31 +0200

From the perl DBI manual page:

If you’d like the cache to managed intelligently, you can tie the hashref returned by “CachedKids” to an appropriate caching module, such as Tie::Cache::LRU

And what happens when I don’t do this? Will my cache be unintelligently managed then, with the consequence of my machine exploding when the cache is filled with more than a handful entries?

What are interface labels for

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 11 Mar 2011 19:28:55 +0100

Dear Lazyweb, for a long time I have been using iproute2’s label feature to assign arbitrary labels to IP addresses configured on Interfaces:

40: int152@dotqa: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:25:b3:01:e5:6c brd ff:ff:ff:ff:ff:ff
inet 10.1.152.254/24 brd 10.1.152.255 scope global int152:98fe8

Recently, this has shown to at least confuse both isc-dhcp-relay (#617258) and dhcp-helper (#617264).

As I have never seen interfaces labels used outside my firewalls (which happen to use ifupdown-scripts-zg2 (Debian PTS)) and ifupdown’s rather twisted handling of multiple IP addresses per interface (using Alias Interfaces), I’d like to know whether my usage is a legitimate one and whether there are other uses for interface labels.

At the moment, I’m tempted to remove label support from ifupdown-scripts-zg2 in the next release, or to make it optional. Please comment if you have an opinion.

Am-mann-switch

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 19 Oct 2010 16:44:00 +0200

Als Netzwerker hat man eigentlich immer einen Switch “am Mann”, um sich gegegebenfalls irgendwo mit dem Notebook anschließen zu können, wo kein Port mehr frei ist. Der von mir bisher dafür benutzte 4-Port-Netgear mit dem bleischweren riesigen Steckernetzteil ist jetzt von diesem kleinen Stück Hardware abgelöst worden, das praktischerweise seine Betriebsspannung aus einem USB-Netzteil oder aus dem USB-Port des Rechners erhält.

Und nachdem so viele gefragt haben, hier der Link zum Hersteller. Den Switch gibt es in zwei Varianten, und nur bei der Variante mit Metallgehäuse liegt das USB-Stromversorgungskabel bei.

My GPG key signing notes

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 04 Oct 2010 10:07:09 +0200

BIOS Flash harmful

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 23 Sep 2010 16:22:38 +0200

Ich habe heute zum ersten Mal seit vielen Jahren einen Rechner mit einem BIOS-Update zerstört. Das noch unter DOS laufende Flashprogramm ist bei “Erasing Flash” stehengeblieben und der Rechner wollte danach natürlich nicht mehr booten. Glücklicherweise war das ein echt altes Supermicro-Schätzchen und der Kunde ist hinreichend entspannt, dass er mir nur vorgeweint hat, dass das Heraussuchen der am wenigsten abgetakelten Büchse nun umsonst gewesen war. Ich krieg jetzt eine neue alte Kiste.

Da die Maschine natürlich kein Diskettenlaufwerk hatte, hielt ich es für eine gute Idee, ein FreeDOS Floppyimage per grub2 und memdisk von der Platte zu booten und das Flashprogramm dann von C:, einer 10-MB-FAT-Partition zu starten. War wohl keine so gute solche.

Jetzt könnte man den Server noch wiederbeleben, indem man ihm beim Booten eine richtige Diskette mit dem richtig benannten BIOS-File ins richtige Laufwerk legt und zwei Tasten gedrückt hält. Das scheitert momentan am Nichtvorhandensein eines richtigen, alten Diskettenlaufwerks und des dazugehörigen Mediums. Und andererseits dürfte es kaum noch wirtschaftlich sein, noch mehr Zeit in diese Uraltbüchse zu stecken.

IP-Adressen fuer Testzwecke etc

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 03 Sep 2010 09:53:58 +0200

Ehe ich wieder ständig suchen gehe, das steht in RFC5735

Address Block       Present Use                Reference
------------------------------------------------------------------
0.0.0.0/8           “This” Network             RFC 1122, Section 3.2.1.3
10.0.0.0/8          Private-Use Networks       RFC 1918
127.0.0.0/8         Loopback                   RFC 1122, Section 3.2.1.3
169.254.0.0/16      Link Local                 RFC 3927
172.16.0.0/12       Private-Use Networks       RFC 1918
192.0.0.0/24        IETF Protocol Assignments  RFC 5736
192.0.2.0/24        TEST-NET-1                 RFC 5737
192.88.99.0/24      6to4 Relay Anycast         RFC 3068
192.168.0.0/16      Private-Use Networks       RFC 1918
198.18.0.0/15       Network Interconnect
                    Device Benchmark Testing   RFC 2544
198.51.100.0/24     TEST-NET-2                 RFC 5737
203.0.113.0/24      TEST-NET-3                 RFC 5737
224.0.0.0/4         Multicast                  RFC 3171
240.0.0.0/4         Reserved for Future Use    RFC 1112, Section 4
255.255.255.255/32  Limited Broadcast          RFC 919, Section 7
                                               RFC 922, Section 7