Da sich mit Debian 13 die Abhängigkeiten von gnome-core etwas zu sehr erweitert haben, um in meinen Augen noch für einen minimalen GNOME-Desktop durchzugehen, habe ich mich mal darin geübt, das in Handarbeit zu realisieren. Das heißt natürlich, dass manche Dinge die vorher einfach funktionierten, nicht auf Anhieb laufen. Aber es dient ja auch der Übung und der Bastelfreude.
Eines dieser netten Dinge, ist das Anzeigen aller verfügbaren Netzwerkgeräte im Dateimanager. Gelegentlich möchte in einem lokalen Netzwerk Zugriff auf NAS bzw. Datenserver haben. Nicht immer weiß ich die IP-Adressen vorher. Soweit ich rausgefunden habe, wäre da der avahi-daemon ein komfortabler Weg, alle verfügbaren Geräte im Dateimanager gelistet zu bekommen. Allerdings scheint damit auch ein ständiges Abfragen und Bekanntgeben im Netzwerk einherzugehen. Das möchte man vielleicht auch nicht unbedingt haben, oder?
Hat sich darüber schon mal jemand Gedanken gemacht oder einen Ratschlag?
Wenn es nur schlechte Performance wäre. Tatsächlich erlaubt mDNS es trivial, falsche Endpunkte zu kommunizieren und damit alles von Denial-of-Service- bis hin zu Man-in-the-middle-Angriffen.
Wenn es mein internes Netzwerk ist, so würde ich dem NAS und dem Datenserver feste IP-Adressen vergeben.
Du hast leider nicht geschrieben, mit welchem Netzwerkprotokoll du dein NAS und dein Datenserver einbindest. Da du von Linux schreibst, gehe ich mal von nfs aus. Dann zeigt dir der folgende Befehl, welche Freigaben unter welcher IP-Adresse verfügbar sind. showmount --exports 192.168.178.36
Du musst nicht zwingend selbst veröffentlichen, nur weil Avahi läuft. Du kannst Avahi so konfigurieren, dass es nur lauscht, aber selbst keine Services veröffentlicht.
Das würde ich auch so machen. Und in diesem konkreten Fall kann ich das auch annehmen, obwohl es sich nicht um mein eigenes Netzwerk handelt (es ist ein Synology-NAS, also vermutlich über samba ansprechbar).
Mir ging es darum, welches Vorgehen am sinnvollsten ist, wenn man nichts über die IP-Adressen weiß. Vorzugsweise mit dem geringsten Overhead. Sinnvollerweise bringt man dem Netzwerk auch erst mal kein Vertrauen entgegen. Daher ist das interessant:
Kannst du erklären, wie das geht?
Ich bin bei meiner Rechnerche noch auf die Pakete cifs-utils und smbclient gestoßen. Allerdings habe ich beide noch nicht ausprobiert.
Die dienen aber nicht dem Finden sondern dem Nutzen von Diensten, und setzen dabei schon voraus, dass die Dienste gefunden werden können. Das kann auch via mDNS gehen, ich würde davon aber abraten (s.o.).
In der Avahi-Konfigurationsdatei /etc/avahi/avahi-daemon.conf muss lediglich disable-publishing=yes gesetzt werden. Danach den Daemon mittels systemctl restart avahi-daemon neu starten. Das ist die sauberste Variante.
Danke für die Anleitung! Schaut Avahi eigentlich permanent nach Netzwerkfreigaben oder nur auf Anfrage? Also wenn man im Dateimanager das Netzwerk aufruft?
Wenn du den Netzwerkbereich im Dateimanager nicht öffnest und kein anderes Programm aktiv DNS-SD nutzt, bleibt Avahi bei deaktiviertem Publishing überwiegend passiv. In diesem Zustand lauscht der Daemon nur auf mDNS-Multicast und pflegt seinen Cache. Er sendet selbst nichts zyklisch ins Netz, es findet also kein permanentes Abklappern von Freigaben statt. In diesem Sinne ist das eher ein passives Mithören als ein aktives Scannen.
Ganz spurlos bleibt es trotzdem nicht. Es gibt einige Situationen, in denen Avahi auch ohne explizite Benutzeraktion Pakete sendet. Beispielsweise beim Start des Daemons, wenn ein Netzwerk-Interface hochgefahren wird, sowie wenn Cache-Einträge auslaufen und erneuert werden müssen. Diese Vorgänge sind selten und kurz. Wenn du das Publishing deaktiviert hast, beschränkt es sich auf generische mDNS-Anfragen, ohne dass du selbst Dienste ankündigst.
Der große Unterschied entsteht erst, wenn ein Client aktiv nach Diensten sucht. Sobald du im Dateimanager die Netzwerkumgebung öffnest, löst GVFS gezielte DNS-SD-Browses aus und du wirst als jemand sichtbar, der konkret nach Diensten fragt. Auch das ist kein aggressives Scannen, sondern nur einige Multicast-Queries. Aber es ist der Moment, in dem du aktiv am Zeroconf-Gespräch teilnimmst.
In der Praxis ist das jedoch meist zu vernachlässigen, da deine Anwesenheit im Netzwerk ohnehin durch eine Fülle anderer Signale erkennbar ist. Wenn Avahi nur lauscht, also kein Publishing betreibt und kein Client browst, sendet es entweder gar keine oder nur extrem generische mDNS-Pakete. Diese Pakete enthalten keine detaillierten Systeminformationen. Typischerweise sind darin nur Dinge wie Quell-IP, MAC-Adresse (die sowieso sichtbar ist), der lokale Hostname und die Tatsache, dass mDNS gesprochen wird, enthalten. Daraus lässt sich kein sinnvoller OS- oder Distributions-Fingerprint ableiten.
wird davon abhängen, wie viel Unsicherheit Du akzeptieren willst.
Ich verwende (intern) ein Samba-Directory, das liefert DNS und Kerberos. Fast alle Kommunikation ist verschlüsselt und zumindest der Server authentifiziert. Benutzer oder Maschinen authentifizieren sich über Kerberos oder Zertifikate. Auch DNS wird teilweise mit DoT oder DoH gesichert. Spoofing egal auf welcher Ebene liefert damit nur noch DoS-Möglichkeiten, allerdings ist der Gewinn eines Angreifers dabei gering und er riskiert die Entdeckung.
Wenn Du (etwas) Sicherheit willst, und nicht an „sichere Netze“ glaubst, dann musst Du als erstes darüber nachdenken, wie Du relevante Kommunikation verschlüsselt bekommst und wie sich Benutzer oder Maschinen authentifizieren. Sonst ist das Abgreifen von Zugangsdaten trivial.
mDNS liefert dem Benutzer keine Unterscheidung zwischen einem echten aber abgeschalteten Dienst und dem falschen online Dienst, und auch in fremden Netzen kann man Dir u.U. leicht etwas unterschieben. Statische IP-Adressen sind etwas besser, aber auch nicht viel.
Das klingt fundiert. Vielen Dank für die Erläuterung!
Das ist ein guter Punkt wenn man ein eigenes Netzwerk aufbaut bzw. verwaltet.
Als Nutzer in einem fremden Netzwerk hat man darauf in der Regel ja keinen Einfluss. Meine Fragestellung zielte auf kleine, private Netzwerke ab. Und da finde ich @Cyberduck Vorschlag hilfreich.
In einem offenen oder großen Netzwerk, würde ich auch nicht auf mDNS, oder ähnliches, vertrauen, um einen Dienst zu finden. Das ist vermutlich auch allein aufgrund der Anzahl von Teilnehmern bzw. gelisteten Diensten schwierig.