[[Vorlage(Getestet, general ) ]] {{{#!vorlage Wissen [:Pakete installieren: Installation von Programmen] [:Programme_starten: Starten von Programmen] [:Terminal: Ein Terminal öffnen] [:mit Root-Rechten arbeiten:] [:Avahi:] [:systemd/systemd-resolved:systemd-resolved] }}} [[Inhaltsverzeichnis]] [wikipedia:Zeroconf:] ist eine Technik zur automatischen Konfiguration des Netzwerks auf jedem einzelnen Gerät. So ist möglich, zwei Rechner über ein Netzwerkkabel zu verbinden, und sofort kann man kommunizieren ohne lokal IP-Adressen einstellen zu müssen. Ziel ist, lokale Netzwerke aufzubauen, die „einfach“ funktionieren, d.h. ohne den Einsatz von Diensten wie DHCP oder DNS oder gar einer manuellen Konfiguration von IP-Adressen sollen sich Rechner im Netzwerk untereinander ansprechen und wechselseitig ihre Dienste erkennen können. Auf den durch Zeroconf bereit gestellten Grundlagen aufbauend können beispielsweise Programme für [:Instant_Messenger:Instant Messaging] oder [:Internet-Telefonie:], auch [:Videotelefonie:] direkt miteinander kommunizieren, weitere Möglichkeiten sind Netzwerkdrucker, Austausch von Dateien zwischen Rechnern mit [:Samba:SMB] oder [:NFS:], Anmeldung am [:SSH#SSH-Server:SSH-Server]. Bei allen genannten Beispielen gilt die Grundregel: * Zeroconf liefert zwar die Grundvoraussetzungen zur Kommunikation und meldet die Verfügbarkeit des entsprechenden Dienstes, realisiert aber selber nicht dessen Funktionalität. * Zur Gewährleistung der jeweiligen Funktionalität muss auf dem als Server fungierenden Rechner ein entsprechendes Server-Programm installiert und konfiguriert werden und auf dem als Client fungierenden Rechner ein entsprechendes Client-Programm. Dieser Artikel stellt als Übersicht die Grundfunktionen vor und verweist auf weitere Artikel mit ausführlicherer Beschreibung. {{{#!vorlage Experten Zeroconf beachtet grundsätzlich nur Verbindungen aus dem gleichen Ethernet-Link. Hängt der Rechner beispielsweise über ein DSL-Modem direkt im Internet, so braucht man keine Angst zu haben, dass Zeroconf Dienste des Rechners im Internet publiziert. }}} Die Idee eine vollständigen Einrichtung des Netzwerks inkl. höherer Funktionen ist zwar theoretisch realisierbar, aber bleibt in der praktischen Umsetzung ein Mythos. Ubuntu kommt der Idee nahe, aber nicht in jeder denkbaren bzw. praktisch vorkommenden Situation. = Funktionsumfang = Zeroconf stellt diese Funktionen sicher: 1. Besitz einer (unicast) IPv4-Adresse, die der lokale Rechner zum Senden von IP-Paketen verwenden kann. :arrow: [#APIPA APIPA] 1. a: Veröffentlichung des lokalen Rechnernamens und einer damit verbundenen unicast IP-Adressen :arrow: [#mDNS mDNS] \\ b: Bereitstellung eines Dienstes auf dem lokalen Rechner zur Auflösung von Rechnernamen zu IP-Adressen :arrow: [#mDNS-Client mDNS-Client] 1. a: Veröffentlichung der vom lokalen Rechner angebotenen Dienste :arrow: [#DNS-SD DNS-SD] \\ b: Funktionen zur Auffindung von Diensten im Netzwerk :arrow: [#DNS-SD-Client DNS-SD-Client] = Voraussetzungen und Einschränkungen = Zeroconf funktioniert prinzipbedingt nicht über Router hinweg und ist somit für größere Unternehmensnetze oder das Internet ungeeignet. = APIPA = Darunter versteht man heute die automatische Zuweisung einer IPv4-Adresse ohne Verwebung eines DHCP-Servers. Das Verfahren beschreibt [#Links RFC 3927] als ''"Dynamic Configuration of IPv4 Link-Local Addresses"'', die gebräuchliche Bezeichnung [wikipedia:Zeroconf#Microsoft_APIPA:APIPA] beruht auf einer zeitlich früheren Implementierung von Microsoft mit leicht abweichenden technischen Details. Die Verwendung von APIPA ist optional und auch für die [#Funktionsumfang weiteren o.g. Funktionen] von Zeroconf nicht zwingend. die höheren Funktionen von Zeroconf erfordern lediglich den Besitz einer Unicast-IP-Adresse, auf der der Rechner Pakete ins Netzwerk senden und auf der er auch Nachrichten empfangen kann. APIPA ist nur eine von mehreren möglichen Methoden, sich eine solche Adresse zu verschaffen. == Ablauf == Das Verfahren soll nur gestartet werde, wenn der Rechner zwar eine betriebsfähige Netzwerkschnittstelle, aber noch keine IPv4-Adresse besitzt: * Der Rechner wählt eine beliebige IP-Adresse aus einem Pool von 65024 Adressen. Der Pool besteht aus den Adressen im Bereich `169.254/16` ohne die Bereiche `169.254.0/24` und `169.254.255/24`. Der Rechner benutzt zur Wahl einen Pseudozufallsgenerator mit einem aus individuellen Hardware-Eigenschaften (z.B. der permanenten MAC-Adresse des Ethernet-Adapters) abgeleiteten Startwert. Es ist durchaus erwünscht, wenn der Rechner jedes Mal dieselbe IP-Adresse nutzt. Eine einmal genutzte IP-Adresse darf der Rechner auch permanent speichern. * Die gewürfelte Adresse wird geprüft, ob sie bereits einem anderen Rechner gehört. Hierfür schickt der Rechner per ARP Anfragen ins Netzwerk. * Wenn jemand per ARP antwortet, dann verwirft der Rechner die gewählte IP-Adresse und startet das Verfahren erneut. * Wenn niemand antwortet, dann reklamiert der Rechner mit Ankündigungen per ARP die gewählte IP-Adresse für sich und benutzt sie auch für seine Zwecke. Eine APIPA-IP-Adresse (oder auch "Link Local IPv4 Address") ist interoperabel mit anderen IP-Adressen, darf aber nur sehr eingeschränkt geroutet werden, genauer: * Nur Pakete von APIPA nach APIPA dürfen geroutet werden. * Damit gilt: Mit einer APIPA-Adresse kommt man nicht ins Internet. == Installation == Zur Benutzung von APIPA bei Ubuntu kann man (mindestens) 3 verschiedene Wege wählen: Entweder über das Paket [package:avahi-autoipd:] {en} oder über die in zur Konfiguration von Netzwerken gängigen Programmen [:NetworkManager:] und [:systemd/networkd:systemd-networkd] bereits eingebauten Funktionalitäten. 1. Paket installieren[1][2][3][4]: {{{#!vorlage Paketinstallation avahi-autoipd, 'Avahi IPv4LL Daemon zur Netzwerkadresskonfiguration', aus universe }}} 1. Für den Weg über NetworkManager und 1. den Weg über systemd ist nichts weiteres zu installieren. == Konfiguration == 1. Für die Nutzung des Pakets '''avahi-autoipd''' ist nach der Installation nichts zu konfigurieren. Man muss allerdings den Daemon starten; dies kann testweise mit diesem Befehl erfolgen: \\ [[Vorlage(Befehl, "sudo avahi-autoipd --check LAN" ) ]] Der hier beispielhaft verwendete Schnittstellenname `LAN` ist anzupassen. Wer dies dauerhaft verwenden möchte, kann eine Unit für den automatischen Start per [:systemd:] beim Systemstart erstellen, die Manpage von `avahi-autoip` enthält die dafür benötigten Informationen. 1. Ohne Installation des Pakets '''avahi-autoipd''' kann man sich, z.B. mittels [:NetworkManager#nm-connection-editor:nm-connection-editor][2][3] ein Verbindungsprofil für den NetworkManager anlegen. \\ {{{#!vorlage Befehl nmcli connection add type ethernet con-name Link nmcli connection modify Link ipv6.method disabled nmcli connection modify Link ipv4.method link-local nmcli connection modify Link connection.autoconnect-priority -1 }}} Wichtig ist hierbei für `autoconnect-priority` einen kleineren Wert als für alle anderen Verbindungsprofile des Typs `ethernet` zu wählen. 1. Alternativ kann man als [:Root:][4] auch eine Konfigurationsdatei für systemd-networkd mit folgendem Inhalt anlegen: \\ {{{ # /etc/systemd/network/99-APIPA.network [Match] Type = ether [Network] Description = APIPA # LinkLocalAddressing = yes | no | ipv4 | ipv6 LinkLocalAddressing = ipv4 IPv4LLStartAddress = 169.254.128.0 #IPv4LLRoute = yes # MulticastDNS = yes | resolve | no #MulticastDNS = yes }}} Auch hier ist wichtig, über den mit `99` beginnenden Dateinamen die Anwendung erst dann zuzulassen, wenn alle anderen Konfigurationen nicht anwendbar sind. = mDNS = Das Protokoll mDNS (Multicast-DNS) dient zur Veröffentlichung bzw. Ankündigung von Hostname und/oder IP-Adresse(n) und später auch Diensten des Rechners im Netzwerk. [#Links RFC 6267] definiert das Verfahren, welches in weiten Teilen dem Unicast-DNS ähnelt, aber sich von diesem in u.a. folgenden Punkten unterscheidet: * Es gibt keine Namensserver für mDNS. * Es verwendet Multicast auf Layer-2 und -3, konkret die IP-Adressen `224.0.0.251` bzw. `ff02::fb`. * Es verwendet Port `5353/udp`. * Standardmäßig ist der Namensraum `*.local.` reserviert für mDNS, sofern der Rechner keine solche Unicast-DNS-Domäne kennt. Man kann andere Domänen als mDNS-Domänen festlegen. * Das nicht zu den für DNS-Namen zulässigen Zeichen Unterstrich `_` wird in Abfragen per mDNS verwendet. Das kann problematisch werden, wenn man die temporären mDNS-Namen doch dauerhaft ins DNS-System eintragen will (was ursprünglich nicht vorgesehen war), siehe [#Links RFC 8553] für Details. Bei Ubuntu gibt es standardmäßig mit Avahi[5] und systemd-resolved[6] zwei [:Dienste:Daemons] für mDNS: * Bei einer Installation als Ubuntu-Desktop wird Avahi installiert und aktiviert und kümmert sich um mDNS. * Bei einer Installation als Ubuntu-Server wird Avahi nicht installiert, kann aber aus den offiziellen Paketquellen bezogen werden. * In beiden Fällen wird systemd-resolved installiert und aktiviert und kümmert sich um Unicast-DNS; es könnte auch mDNS benutzen, aber man sollte es nicht aktivieren, solange Avahi läuft. Avahi und die mDNS-Komponente von systemd-resolved stören sich gegenseitig und sollen deshalb nicht gleichzeitig aktiviert werden. Zur Installation, Aktivierung und Deaktivierung siehe die jeweiligen Artikel [:Avahi:] und [:systemd/systemd-resolved:systemd-resolved]! Ob die mDNS-Komponente von systemd-resolved aktiv ist, kann man mit dem Befehl[2][3] [[Vorlage( Befehl, resolvectl ) ]] prüfen. In der Ausgabe darf `"+mDNS"` nicht erscheinen, sonst ist mDNS aktiviert. = mDNS-Client = Generell wird die Auflösung per mDNS eines Rechnernamens zu einer IP-Adresse nur dann gelingen, wenn __keine__ Unicast-DNS-Domain `local` registriert ist. Kontrolle: Der Befehl[2][3] [[Vorlage( Befehl, 'resolvectl | grep Domain' ) ]] darf keine Domain `local` listen, sonst: :arrow: [#Unicast-DNS-Domaene-local Problembehebung] == Test == Zum Test der Namensauflösung per mDNS benötigt man neben dem eigenen Rechner (hier beispielhaft: `Maria`) einen weiteren Rechner (hier beispielhaft: `Lieselotte`) im Netzwerk, und dieser weitere Rechner muss seinen Namen und seine IP-Adresse per nDNS veröffentlichen. * Testbefehle[2][3], wenn man auf dem eigenen Rechner Avahi verwendet: * [[Vorlage( Befehl, "avahi-resolve-host-name lieselotte.local" ) ]] Beispielausgabe: \\ {{{Lieselotte.local 169.254.6.219 }}} * [[Vorlage( Befehl, "resolvectl -p mdns query lieselotte.local" ) ]] Beispielausgabe: \\ {{{lieselotte.local: resolve call failed: No appropriate name servers or networks for name found }}} * Testbefehle[2][3], wenn man auf dem eigenen Rechner systemd-resolved mit mDNS verwendet: * [[Vorlage( Befehl, "avahi-resolve-host-name lieselotte.local" ) ]] Beispielausgabe: \\ {{{Klientobjekterstellung ist fehlgeschlagen: Dienst läuft nicht }}} * [[Vorlage( Befehl, "resolvectl -p mdns query lieselotte.local" ) ]] Beispielausgabe: \\ {{{ lieselotte.local: 169.254.6.219 -- link: LAN (Lieselotte.local) -- Information acquired via protocol mDNS/IPv4 in 9.9ms. -- Data is authenticated: no; Data was acquired via local or encrypted transport: no -- Data from: network }}} * In beiden Fällen sollte … * die direkte Abfrage beim DNS-Namensserver per Unicast-DNS eine Fehlermeldung ergeben: [[Vorlage( Befehl, "host lieselotte.local" ) ]] Beispielausgabe: {{{Host lieselotte.local not found: 2(SERVFAIL) }}} * und die direkte Abfrage über Glib funktionieren: [[Vorlage( Befehl, "getent hosts lieselotte.local" ) ]] Beispielausgabe: {{{169.254.6.219 lieselotte.local }}} * und schließlich sollte auch die mDNS-Namensauflösung aus Programmen (über Glib) funktionieren, beispielsweise: [[Vorlage( Befehl, "ping -4 -c1 lieselotte.local" ) ]] == Namensauflösung über Glib == Für die Namensauflösung aus Programmen werden üblicherweise Funktionen aus der Bibliothek Glib benutzt. Die dafür verwendeten Methoden werden mit der Datei '''/etc/nsswitch''' konfiguriert. Bei einem Ubuntu-Desktop-System findet man üblicherweise[2][3]: [[Vorlage( Befehl, 'grep hosts /etc/nsswitch.conf' ) ]] Beispielausgabe: {{{hosts: files mdns4_minimal [NOTFOUND=return] dns }}} Hier sind drei Methoden konfiguriert, die nacheinander aktiviert werden, bis ein Ergebnis erzielt wurde: 1. `files` steht für Nachschlagen in der Datei: '''/etc/hosts''' 1. `mdns4_minimal [NOTFOUND=return]` befragt '''avahi-daemon''', der versucht, per mDNS eine Antwort zu finden. 1. `dns` steht für normales Unicast-DNS, d.h. Befragung der in der Datei '''/etc/resolv.conf''' konfigurierten Namensserver (nameserver). Bei Ubuntu ist das immer `127.0.0.53`, worunter man den Dienst systemd-resolved erreicht, der die Ergebnisse von Anfragen zwischenspeichert und die Forwarder befragt, welche der Befehl[2][3] [[Vorlage( Befehl, resolvectl ) ]] anzeigt. Wenn man Avahi deaktiviert und ggf. mDNS über systemd-resolved aktiviert, muss keine Anpassung in der Datei '''/etc/nsswitch''' erfolgen, denn, wenn der Avahi-DAEMON nicht läuft, macht `mdns4_minimal` gar nichts außer ein wenig Zeit zu verschwenden. Alternativ kann man den 2. Eintrag ersatzlos entfernen, wenn man Avahi nicht benutzt. Alternativ kann man mit Avahi einen anderen Modul verwenden. Näheres dazu liest man in der Dokumentation: [[Vorlage( Befehl, 'zless /usr/share/doc/libnss-mdns/README.md.gz' ) ]] Alternativ kann man ein vom Projekt Systemd geliefertes NSS-Modul einsetzen. Davon wird abgeraten, weil in Experimenten damit kein befriedigendes Zeitverhalten erreicht wurde. == Avahi: Aktivierung und Deaktivierung == Das wird im Artikel Avahi[5] beschrieben. == systemd-resolved: mDNS aktivieren == Standardmäßig ist nDNS mit [:systemd/systemd-resolved:systemd-resolved] deaktiviert. Man aktiviert es global mit einer Konfigurationsdatei: {{{ # /etc/systemd/resolved.conf.d/mDNS.conf [Resolve] MulticastDNS = yes }}} Nach Neustart von systemd-resolved[6] oder des Systems aktiviert dies mDNS für die Veröffentlichung und die Auflösung von Rechnernamen und IP-Adressen auf globaler Ebene, systemd-resolved wird dies auf jede geeignete Schnittstelle übertragen, sofern man das nicht explizit mit [:systemd/networkd:systemd-networkd] oder [:NetworkManager:] anders steuert. Alternativ zum Wert `yes` kann man auch `resolve` angeben, was dann nur die Namensauflösung aktiviert. == systemd-resolved: mDNS deaktivieren == Man entfernt alle Zeilen `MulticastDNS=yes` und `MulticastDNS=resolve` aus der Konfiguration, fügt optional `MulticastDNS=no` hinzu und startet neu. = DNS-SD = Die Veröffentlichung der vom Rechner angebotenen Dienste (Services) im Netzwerk per mDNS ist beschrieben in [#Links RFC 6763]. Voraussetzung ist eine funktionierende Ankündigung von Rechnername und IP-Adresse(n) per mDNS. Bei Ubuntu können hierfür sowohl Avahi wie auch systemd-resolved eingesetzt werden. Details zu Avahi[5] siehe dort. Beim Einsatz von systemd-resolved für diese Aufgabe muss natürlich mDNS wie [#systemd-resolved-mDNS-aktivieren oben] beschrieben aktiviert werden. Außerdem muss für jeden zu veröffentlichen Dienst eine Konfigurationsdatei mit auf '''.dnssd''' endendem Namen erstellt werden[2][3][4] und in einem dieser Ordner abgelegt werden: * '''/usr/lib/systemd/dnssd/''' – Verwendung ggf. durch Software-Pakete * '''/usr/local/lib/systemd/dnssd/''' – Verwendung ggf. durch Software-Pakete * '''/run/systemd/dnssd/''' – nur für temporäre Dienste * '''/etc/systemd/dnssd/''' – empfohlen zur Benutzung durch den Verwalter des Rechners. Sinnvolle Werte für Besitzer, Gruppe und Dateirechte sind `root` bzw. `0644`. Beispiel: {{{# /etc/systemd/dnssd/ssh-fs.dnssd [Service] Name = %H Type = _sftp-ssh._tcp Port = 22 TxtText = path=/ }}} Einzelheiten und weitere mögliche Angaben kann man der Manpage[2][3] entnehmen: [[Vorlage( Befehl, 'man systemd.dnssd' ) ]] Nach Erstellung oder Änderung der Datei muss man systemd-resolved[6] neu starten. = DNS-SD-Client = Für die Suche nach per mDNS-SD angekündigten Diensten im Netzwerk benötigt man einen alleine stehenden oder im Applikationsprogramm eingebauten mDNS-SD-Browser; etliche solche Komponenten werden im Artikel zu Avahi[5] behandelt. Leider ist die Auswahl eines gesegneten mDNS-SD-Browsers __nicht__ unabhängig von dem auf dem Rechner laufenden mDNS-DAEMONs, denn etliche dieser Programme befragen den DAEMON direkt und funktionieren damit nur mit einem der beiden möglichen DAEMONen. Das gilt auch für Programme, die per D-BUS kommunizieren, denn die D-Bus-Schnittstellen von Avahi[5] und systemd-resolved[6] unterscheiden sich. Die für Avahi verfügbaren Browser verfügen auch über eine Benutzerschnittstelle mit Anzeige bzw. Auflistung der gefundenen Dienste. Dies trifft nicht zu für systemd-resolved: Zwar kann man diesem DAEMON per D-Bus eine Suchanfrage stellen, es gibt aber keine praktikable Möglichkeit zur Anzeige der gefundenen Dienste, es sei denn, das jeweilige Anwendungsprogramm übernimmt dies. = Problembehebung = == Unicast-DNS-Domäne local == Manche Reuter für den privaten Gebrauch, darunter die Fritzboxen, verteilen per DHCP die Unicast-DNS-Domäne `local`. Leider ist keine Methode bekannt, dies beim DHCP-Server der Fritzbox abzustellen. Ersatzweise kann man auf jedem Client die Annahme der DHCP-Option verweigern und muss dann ggf. DNS-Server und DNS-Domäne selbst einstellen. Bei Verwendung von [:NetworkManager:] sind dafür in jedem Verbindungsprofil, getrennt für IPv4 und IPv6, Einstellungen `ignore-auto-dns=` zuständig, die nicht per GUI zugänglich sind. Eine Einstellung gelingt aber per [:NetworkManager/nmcli:nmcli]: {{{#!vorlage Befehl nmcli connection modify PROFIL ipv6.ignore-auto-dns yes nmcli connection modify PROFIL ipv4.ignore-auto-dns yes }}} Möglicherweise (z.B. bei FB7490) reicht bereits die Einstellung für IPv6 aus. == Multicast == Die Veröffentlichung von Rechnername und Adresse, die Ankündigung von Diensten und die Auflösung von Rechnername zu IP-Adresse erfordern [wikipedia:Multicast:] auf beiden beteiligten Rechnern: * Normalerweise sollte Multicast bei einem aktuellen Netzwerk- bzw. WLAN-Adapter problemlos funktionieren. * Bei manchen sehr alten Netzwerkkarten muss Multicast explizit eingeschaftet werden. Der Befehl [[Vorlage( Befehl, "ip -br link | grep -v MULTICAST" ) ]] zeigt die Schnittstellen mit fehlendem Multicast an, beispielsweise: {{{ lo UNKNOWN 00:00:00:00:00:00 radio DOWN 48:51:b7:40:66:bd }}} Die Schnittstelle `lo` ist hier nicht relevant, aber wenn man `radio` für Avahi benutzen möchte, sollte man versuchen, Multicast einzuschalten: [[Vorlage( Befehl, "sudo ip link set multicast on radio" ) ]] * Für Multicast müssen die jeweiligen Adressen auf beiden Rechnern verfügbar sein. Die existierenden Multicast-Adressen zeigt der Befehl [[Vorlage( Befehl, "ip maddress" ) ]] sortiert nach Schnittstelle. Für jede von Avahi benutzen Schnittstelle benötigt man mindestens: * `link 01:00:5e:00:00:fb` für Ethernet bzw. Wifi (Layer 2) * `inet 224.0.0.251` für das Protokoll IPv4 bzw. `ff02::fb` für IPv6 * Wenn sich Multicast nicht einschalten lässt oder die vorstehend genannten Multicast-Adressen fehlen, hilft vielleicht, für die IP-Multicast-Adresen einen Unicast-Leitweg einzurichten: [[Vorlage( Befehl, "sudo ip route add 224/4 dev radio" ) ]] Der hier beispielhaft verwendete Schnittstellenname `radio` ist anzupassen. [:NetworkManager:] richtet diese Route automatisch ein, wenn man als Methode `link-local` angibt, aber die Route scheint völlig nutzlos zu sein. Vielleicht ist sie aber doch in bestimmten Situationen erforderlich. == Netzwerkport == Damit der nDNS-DAEMON andere Rechner findet und der eigene Rechner gefunden werden kann, öffnet der DAEMON den Netzwerk-Port `5353/udp`. Dies kann man so überprüfen: [[Vorlage( Befehl, "ss -ulpen 'sport = 5353' " ) ]] Beispielausgabe: {{{ State Recv-Q Send-Q Local Address:Port Peer Address:Port Process UNCONN 0 0 0.0.0.0:5353 0.0.0.0:* uid:108 ino:57433 sk:1001 cgroup:/system.slice/avahi-daemon.service <-> UNCONN 0 0 0.0.0.0:5353 0.0.0.0:* uid:991 ino:8056 sk:1 cgroup:/system.slice/systemd-resolved.service <-> UNCONN 0 0 [::]:5353 [::]:* uid:991 ino:8063 sk:2 cgroup:/system.slice/systemd-resolved.service v6only:1 <-> }}} Im Beispiel sieht man 2 aktive mDNS-DAEMONen `avahi-daemon` und `systemd-resolved` auf Port `5353` lauschend. Das ist so nur für Testzwecke zulässig; da sich die beiden gegenseitig stören können, sollte es im produktiven Betrieb nur einen geben. == Fehlerhafte Namensauflösung == Zerokonf beruht letztlich auf der Zuweisung eines weiteren Namens und der Verknüpfung dieses Namens mit einer IP-Adresse des Rechners. Dies ist normalerweise unkritisch, denn ein Rechner darf theoretisch beliebig viele Namen und auch beliebig viele IP-Adressen besitzen, wenn man dabei folgende Regeln beachtet: * Unterschiedliche Rechner sollten nicht denselben Namen verwenden. * Unterschiedliche Rechner dürfen nicht dieselbe IP-Adresse verwenden. In vorstehenden Sätzen kann das Wort „Rechner“ sowohl ein reales Hardware-Gerät oder eine in Software realisierte virtuelle Maschine bedeuten. Die Verwendung von NAT (Network Address Translation) bedeutet immer eine Missachtung vorstehender Regeln, und wenn man dann noch auf beiden Seiten des Routers einen mDNS-DAEMON verwendet, kommt es zu Fehlfunktionen. Beim Einsatz virtueller Maschinen läuft man z.B. schnell in diese Falle, wenn man Host und Gast per NAT koppelt. Zur Vermeidung von Fehlfunktionen im Netzwerk sollte man generell beachten. * NAT nach Möglichkeit gar nicht einsetzen. Bei virtuellen Maschinen kann man z.B. Brücken bzw. "bridged networking" verwenden. * Oder: Wenn NAT unvermeidlich, dann jedenfalls nicht `MASQUERADE`, sondern `SNAT` verwenden, d.h. die Zieladresse, auf die NAT übersetzt, darf __nicht__ die Adresse des Routers und auch __nicht__ die Adresse des Host sein. * Oder: nDNS nicht auf beiden Seiten eines NAT-Routers verwenden. * Oder: Nicht auf beiden Seiten des NAT-Routers dieselbe mDNS-Domäne verwenden. Man könnte z.B. auf der Seite des Host `local` und auf Seite des Gastes die Subdomäne `VM.local` verwenden. == Logdateien werden zugemüllt == Die im vorstehenden Abschnitt genannte Falle führt neben den Fehlfunktionen bei der Namensauflösung auch zum Zumüllen der Log-Dateien des Gastes und des Hosts und aller (!) weiteren Rechner im Netzwerk mit Einträgen dieser Art: {{{ pp avahi-daemon[1963]: Invalid legacy unicast query packet. ... pp avahi-daemon[1963]: Received response from host 192.168.xxx.yyy with invalid source port 39506 on interface 'eth0.0' ... }}} = Sicherheit = DNS-SD kann zur Ausspähung und zur Sabotage missbraucht werden. Dazu muss der Angreifer Zugang zu dem Netzwerk mit DNS-SD haben und aus diesem IP-Pakete empfangen und in dieses senden können. Diese Situation ist beispielsweise gegeben bei öffentlichen WLANs oder wenn auf dem Router zum Internet Freigaben ins interne Netz bestehen. Der Angreifer hat die Wahl: 1. Bereits durch rein passives Abhören des Multicast-Netzwerkverkehrs gewinnt man Erkenntnisse über vorhandene Rechner und lernt deren Rechnernamen, deren IP-Adresse(n) und die auf ihnen laufenden, über das Netzwerk errreichbaren Dienste inkl. deren Portnummer. Diese Informationen können Basis für weitergehende Angriffe sein. 1. Der Zeitbedarf für einen Angriff gemäß vorherigem Punkt verringert sich drastisch auf wenige Sekunden, wenn der Angreifer eine regelgerechte Anfrage ins Netzwerk sendet. Erst eine solche Anfrage ermöglicht grundsätzlich eine Erkennbarkeit des Angriffs; eine Erkennung bleibt aber höchst unwahrscheinlich, weil es sich ja um völlig regelgerechten Gebrauch handelt. 1. Der Angreifer kann auf eine nicht für ihn betimmte Anfrage antworten und mit der gefälschten Antwort z.B. die Kontaktaufnahme zu einem Dateiserver auf sich selbst umleiten. Wenn der Angreifer dann den Benutzer zu einer Anmeldung verleitet, kann er Benutzername und Passwort abgreifen und soch somit selbst einen illegalen Zugang zum Server verschaffen. 1. Der Angreifer kann im Namen seines Angriffsziels gefälschte Anfragen senden und darauf hoffen, dass viele andere Rechner dem ahnungslosen Angriffsziel antworten. Dies ist das Prinzip eines Denial-of-Service-Angriffs und erfolgt in der Absicht, das Angriffsziel zu überlasten und dadurch in seiner normalen Funktion zu beeinträchtigen. Gegenmaßnahmen: * Gegen passives Abhören kann man nichts unternehmen. * Gegen aktives Abhören hilft nur der Vezicht, DNS-SD zu benutzen; mindestens sollte man vermeiden, ein offenes Relais für mDNS-SD zu betreiben, siehe den [#Links Hinweis des BSI]. * Phishing-Angriffe (Typ 3 oben) kann man auch nicht verhindern, aber in ihren Auswirkungen begrenzen, indem man keine Anmeldung mit Klartext-Passwort, sondern bereits bei der Anmeldung asymetrische Kryptographie verwendet. * Gegen DoS-Angriffe aus dem eigen Netz sollte man bei umfangreichen Netzen durch Segmentierung Möglichkeiten vorsehen, den Störer zu isolieren und einen kundigen und robusten Sicherheitsdienst bereit halten. * Zur Verbesserung dr Erkennbarkeit von Angriffen kann man Honigtöpfe und Teergruben einsetzen. Empfehlungen: Wer seinen Laptop, Notebook, Tablet oder Handy nicht nur im Netz daheim betreibt, sondern auch unterwegs in fremden Netzen, sollte sich im Klaren sein, dass er damit zum Ziel von Angriffen wird. Vorsichtshalber sollte man daher in unsicheren Netzen per mDNS gar keine Informationen veröffentlichen. Dabei muss jedes Netz, bei dem man selbst den Zugang nicht kontrollieren kann, als unsicher gelten. Darunter fallen alle WLANs, die mit "free WLAN" beworben werden, unabhängig davon, ob sie Verschlüsselung verwenden oder nicht, also beispielsweise WLANs im ICE, an Bahnhöfen und Flughäfen, im Hotel, im Vereinsheim, in Gaststätten und auch im Hörsaal der Uni. Der Betrieb von Avahi auf dem eigenen transportablen Gerät beim Aufenthalt im Hetz daheim kann sehr sinnvoll sein, aber man sollte das abstellen, bevor man sich mit einem fremden Netz verbindet. Dies kann auf dem eigenen Geräta auch über ein Paketfilter mit dieser Regel (und der entsprechenden für IPv6) erfolgen: [[Vorlage( Befehl, 'sudo iptables -I OUTPUT -p udp --dport 5353 -j REJECT' ) ]] = Links = * [https://www.rfc-editor.org/info/rfc3927/ RFC 3927] {en} – Dynamic Configuration of IPv4 Link-Local Addresses * [https://www.rfc-editor.org/info/rfc6762/ RFC 6762] {en} – Multicast DNS * [https://www.rfc-editor.org/info/rfc6763/ RFC 6763] {en} – DNS-Based Service Discovery, dieser RFC behandelt vordringlich Unicast-DNS, die Formate der Resource-Records für mDNS entsprechen aber denen für Unicast-DNS * [https://www.rfc-editor.org/info/rfc6763/ RFC 8553] {en} – Fixing Specifications That Use Underscored Node Names * [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Reaktion/CERT-Bund/CERT-Bund-Reports/HowTo/Offene-mDNS-Dienste/Offene-mDNS-Dienste.html Offene mDNS-Dienste] – Sicherheitshinweis des BSI #tag: Netzwerk, System, Übersicht, Zeroconf