10
VLAN-Sicherheit: tagged avahi-Server ein Risiko?
Hallo,
Frage zum Thema VLAN und Sicherheit. Landscape:
Fragestellung:
Danke!
Frage zum Thema VLAN und Sicherheit. Landscape:
- Mikrotik-Router --> WAN | 5 VLAN | FW ... das übliche
- dahinter tagged Switche und AP
- in einzelnen VLAN untagged dedizierte Server (ubuntu server LTS)
- Damit sauberer Segementierung und nur einzelne Durchstiche via FW des MT
Fragestellung:
- Bedarf für übergeifenden Bonjour/mDNS-Service --> Lösungshyothese: avahi
- Bisher ohne Erfahruing zu avahi; nach meinem Verständnis muss der avahi-Server in jedem relevanten VLAN sein, damit es funktioniert wegen Hop-Limit=1.
- Der avahi-Server müsste also tagged angebunden werden mit entsprechender Anzahl Interfaces , damit Bonjour refelektieren kann in die VLANs, richtig?
- Bisher waren meine Server alle untagged und damit sauber getrennt, der MT sorgte für Trennung und Sicherheit. Abseits der Router/Switch habe ich an Clients/Servern noch keinerlei praktische VLAN-Erfahrung. Technisch sicher alles machbar/installierbar. Aber...
- Frage: Wenn ich eine avahi-Server tagged einbinde: Reiße ich mir damit hinter meiner FW ein Sicherheitsloch auf und gefährde die VLAN-Trennung des MT? Wenn auf dem avahi-Server keine FW installiert wird: Sind die Interfcaes/VLAN im ubuntu-default alle verbunden (=Risiko) oder im Default verlässlich getrennt?
- Falls problematisch: Wie kann ich auf dem avahi-Server jedweden inter-VLAN-Verkehr verhindern, der über Bonjour hinaus geht?
Danke!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 520764
Url: https://administrator.de/contentid/520764
Printed on: May 2, 2024 at 04:05 o'clock
10 Comments
Latest comment
Moin.
https://en.m.wikipedia.org/wiki/Multicast_DNS
Primär ist es dafür da FQDNs und IP-Adressen, Dienste über Multicast-Pakete (Broadcasts) in Erfahrung zu bringen.
Dazu schickt ein Client/Server/Gerät ein Multicast-Paket an die Adresse 224.0.0.251, genutzte Ports 5353 UDP.
Darin enthalten FQDN, IP, RR(Resource Record) usw.
Diese Pakete dienen zum Austausch von Address und Dienstinformationen, die Clients und Serverdienste nutzen können, aber nicht müssen. Dabei dient der AVAHI als Reflector, er leitet also alles was mDNS Pakete betrifft an alle seine konfigurierten Interfaces und deren Layer-2 Broadcast-Domains.
Routen tut er gar nichts er verteilt nur die Broadcasts, damit die Clients wissen wo sie einen Dienst/Gerät finden können.
Ergo: Es gelten weiterhin die Firewall-Regeln des Mikrotik zwischen den VLANs, denn die Clients erhalten ja erst mal nur die DNS-Information wo ein Bonjour-Gerät zu finden ist. Der eigentliche Verbindungsaufbau zwischen den Geräten findet ja dann separat übers Routing und den Mikrotik statt und nicht über den AVAHI (der ist ja nur ein Proxy der mitlauscht und reflektiert), und hier gelten weiterhin deine Firewall-Regeln zwischen deinen VLANs.
Fazit: Jedes VLAN das du an den AVAHI anbindest bekommt alle mDNS Multicast-Broadcasts (224.0.0.251) der anderen VLANs sofern in der mDNS-Anfrage nicht das Flag aktiviert ist das die Antwort über eine Unicast-Antwort stattfinden soll. D.h. heißt also im Klartext das man in jedem VLAN quasi in Erfahrung bringen kann welche Bonjour-Hosts es in den anderen Netzen gibt, die sind ja nötig wenn du Bonjour Netzübergreifend arbeiten willst. Hieße dann aber auch das ein Angreifer wenn er sein eigenes mDNS Paket erstellt und ein Client dieses Ziel via Bonjour benutzt (sofern es die Firewall erlaubt mit der entsprechenden IP zu reden) es potentiell zu Datenabfluss oder durch Sicherheitslücken in Produkten kommen könnte. Aber durch entsprechendes Einschränken der Kommunikations zwischen den Hosts in den VLANs kannst du dem schon mal einen größeren Riegel vorschieben.
Der durch mDNS zusätzlich entstehende Broadcast-Traffic in allen VLANs sollte man natürlich auch im Blick behalten.
Natürlich sollte man auf dem AVAHI Server sicherstellen das jegliches Routing über seine Interfaces generell verboten ist, das ist ja auch nicht nötig denn das Reflektieren übernimmt ja der AVAHI Daemon.
Der AVAHI selbst reflektiert nur mDNS Broadcasts, mit deaktiviertem Routing auf dem Proxy kommt da sonst nichts weiter. Natürlich gelten wie für jeden Server seine eigene Firewall für seine eigenen Dienste unabhängig vom Routing, d.h. Updates zeitig einpflegen und nur die Dienste in seiner Firewall freigeben die er selbst anbietet!
Hth.
v.
Zitat von @natuerlich:
Fragestellung:
Check.Fragestellung:
- Bedarf für übergeifenden Bonjour/mDNS-Service --> Lösungshyothese: avahi
* Bisher ohne Erfahruing zu avahi; nach meinem Verständnis muss der avahi-Server in jedem relevanten VLAN sein, damit es funktioniert wegen Hop-Limit=1.
Check, mit einem Bein in jeder Layer-2 Domain.* Der avahi-Server müsste also tagged angebunden werden mit entsprechender Anzahl Interfaces , damit Bonjour refelektieren kann in die VLANs, richtig?
Check.* Bisher waren meine Server alle untagged und damit sauber getrennt, der MT sorgte für Trennung und Sicherheit. Abseits der Router/Switch habe ich an Clients/Servern noch keinerlei praktische VLAN-Erfahrung. Technisch sicher alles machbar/installierbar. Aber...
Mach dir erst mal klar was mDNS überhaupt ist.- Frage: Wenn ich eine avahi-Server tagged einbinde: Reiße ich mir damit hinter meiner FW ein Sicherheitsloch auf und gefährde die VLAN-Trennung des MT? Wenn auf dem avahi-Server keine FW installiert wird: Sind die Interfcaes/VLAN im ubuntu-default alle verbunden (=Risiko) oder im Default verlässlich getrennt?
https://en.m.wikipedia.org/wiki/Multicast_DNS
Primär ist es dafür da FQDNs und IP-Adressen, Dienste über Multicast-Pakete (Broadcasts) in Erfahrung zu bringen.
Dazu schickt ein Client/Server/Gerät ein Multicast-Paket an die Adresse 224.0.0.251, genutzte Ports 5353 UDP.
Darin enthalten FQDN, IP, RR(Resource Record) usw.
Diese Pakete dienen zum Austausch von Address und Dienstinformationen, die Clients und Serverdienste nutzen können, aber nicht müssen. Dabei dient der AVAHI als Reflector, er leitet also alles was mDNS Pakete betrifft an alle seine konfigurierten Interfaces und deren Layer-2 Broadcast-Domains.
Routen tut er gar nichts er verteilt nur die Broadcasts, damit die Clients wissen wo sie einen Dienst/Gerät finden können.
Ergo: Es gelten weiterhin die Firewall-Regeln des Mikrotik zwischen den VLANs, denn die Clients erhalten ja erst mal nur die DNS-Information wo ein Bonjour-Gerät zu finden ist. Der eigentliche Verbindungsaufbau zwischen den Geräten findet ja dann separat übers Routing und den Mikrotik statt und nicht über den AVAHI (der ist ja nur ein Proxy der mitlauscht und reflektiert), und hier gelten weiterhin deine Firewall-Regeln zwischen deinen VLANs.
Fazit: Jedes VLAN das du an den AVAHI anbindest bekommt alle mDNS Multicast-Broadcasts (224.0.0.251) der anderen VLANs sofern in der mDNS-Anfrage nicht das Flag aktiviert ist das die Antwort über eine Unicast-Antwort stattfinden soll. D.h. heißt also im Klartext das man in jedem VLAN quasi in Erfahrung bringen kann welche Bonjour-Hosts es in den anderen Netzen gibt, die sind ja nötig wenn du Bonjour Netzübergreifend arbeiten willst. Hieße dann aber auch das ein Angreifer wenn er sein eigenes mDNS Paket erstellt und ein Client dieses Ziel via Bonjour benutzt (sofern es die Firewall erlaubt mit der entsprechenden IP zu reden) es potentiell zu Datenabfluss oder durch Sicherheitslücken in Produkten kommen könnte. Aber durch entsprechendes Einschränken der Kommunikations zwischen den Hosts in den VLANs kannst du dem schon mal einen größeren Riegel vorschieben.
Der durch mDNS zusätzlich entstehende Broadcast-Traffic in allen VLANs sollte man natürlich auch im Blick behalten.
Natürlich sollte man auf dem AVAHI Server sicherstellen das jegliches Routing über seine Interfaces generell verboten ist, das ist ja auch nicht nötig denn das Reflektieren übernimmt ja der AVAHI Daemon.
Der AVAHI selbst reflektiert nur mDNS Broadcasts, mit deaktiviertem Routing auf dem Proxy kommt da sonst nichts weiter. Natürlich gelten wie für jeden Server seine eigene Firewall für seine eigenen Dienste unabhängig vom Routing, d.h. Updates zeitig einpflegen und nur die Dienste in seiner Firewall freigeben die er selbst anbietet!
Hth.
v.
Vielen Dank schon mal, voucher! 
Auch danke für Deine Einschätzung zur Sicherheit durch avahi selber. Dazu war meine Frage aber wohl unglücklich formuliert, denn in avahi selber habe ich auch keine reales Risiko gesehen. Aber in Deiner Antwort dazu steckten trotzdem ein paar neue Infos für mich...
Meine Frage zielt eher darauf ab: Ich habe bislang noch nie auf einem Server selber (abseits Router/Switch) mit VLAN hantiert. Da dies für avahi erforderlich ist: Welches Risiko mache ich mir mit dem Server selber auf? Mal angenommen: Neues Blech, pures Ubuntu Server LTS und nur avahi drauf. Avahi ist kein Risiko, aber der Server selber? Sind im Default die VLAN durchlässig oder abgeschottet? Ich habe auf Servern mich noch nie um die FW gekümmert, weil es nicht erforderlich war (da Aufgabe des MT). Muss ich das jetzt tun, wenn ich vlan auf einem Server nutze mit 5 Interfaces zu meinen 5 VLAN? Oder kann ich unbesorgt sein, dass solange ich nichts aktiv öffne, alles gut ist?
Auch danke für Deine Einschätzung zur Sicherheit durch avahi selber. Dazu war meine Frage aber wohl unglücklich formuliert, denn in avahi selber habe ich auch keine reales Risiko gesehen. Aber in Deiner Antwort dazu steckten trotzdem ein paar neue Infos für mich...
Meine Frage zielt eher darauf ab: Ich habe bislang noch nie auf einem Server selber (abseits Router/Switch) mit VLAN hantiert. Da dies für avahi erforderlich ist: Welches Risiko mache ich mir mit dem Server selber auf? Mal angenommen: Neues Blech, pures Ubuntu Server LTS und nur avahi drauf. Avahi ist kein Risiko, aber der Server selber? Sind im Default die VLAN durchlässig oder abgeschottet? Ich habe auf Servern mich noch nie um die FW gekümmert, weil es nicht erforderlich war (da Aufgabe des MT). Muss ich das jetzt tun, wenn ich vlan auf einem Server nutze mit 5 Interfaces zu meinen 5 VLAN? Oder kann ich unbesorgt sein, dass solange ich nichts aktiv öffne, alles gut ist?
Zitat von @natuerlich:
Meine Frage zielt eher darauf ab: Ich habe bislang noch nie auf einem Server selber (abseits Router/Switch) mit VLAN hantiert. Da dies für avahi erforderlich ist: Welches Risiko mache ich mir mit dem Server selber auf? Mal angenommen: Neues Blech, pures Ubuntu Server LTS und nur avahi drauf. Avahi ist kein Risiko, aber der Server selber? Sind im Default die VLAN durchlässig oder abgeschottet?
Per Default ist das Forwarding deaktiviert, bedeutet Packet-Forwarding zwischen den VLANs kann nicht stattfinden.Meine Frage zielt eher darauf ab: Ich habe bislang noch nie auf einem Server selber (abseits Router/Switch) mit VLAN hantiert. Da dies für avahi erforderlich ist: Welches Risiko mache ich mir mit dem Server selber auf? Mal angenommen: Neues Blech, pures Ubuntu Server LTS und nur avahi drauf. Avahi ist kein Risiko, aber der Server selber? Sind im Default die VLAN durchlässig oder abgeschottet?
Ich habe auf Servern mich noch nie um die FW gekümmert, weil es nicht erforderlich war (da Aufgabe des MT).
Das ist ein Trugschluss, denk nur mal daran das wenn ein Device im Netz infiziert ist und deine Hosts im LAN alle keine Firewall aktiviert haben und auf diesen in deren Diensten eine Sicherheitslücke steckt diese alle zu Zombies mutieren. Eine grundlegende Device-Firewall gehört deswegen auf jedes Gerät.Muss ich das jetzt tun, wenn ich vlan auf einem Server nutze mit 5 Interfaces zu meinen 5 VLAN?
Es gilt immer das Prinzip, traue keinem, also auch deinem Netz erst mal nicht grundsätzlich unbeschränkt, denn Angriffe kommen nicht nur von Außen sondern vielfach von innen!Oder kann ich unbesorgt sein, dass solange ich nichts aktiv öffne, alles gut ist?
Schau dir unsere Krankenhäuser in DE an, viele haben sich in Sicherheit gewogen und nichts getan, und plötzlich macht es Peng und sie hatten den Salat.Deswegen: Vorsorge ist immer besser als Nachsorge!Also, Basisfirewall auf dem AVAHI und nur die Dienste durchlassen die dieser auch tatsächlich nutzt, und du kannst besser schlafen ;). Ubuntu hat mit ufw ja entsprechend einfach zu nutzendes Interface dafür, ansonsten geht's auch mit iptables.
Also Basis-Firewall-Kenntnisse solten immer vorhanden sein, wenn nicht würde ich mir jetzt aber Sorgen um deinen Mikrotik machen }:‑)
Ciao.
Bedarf für übergeifenden Bonjour/mDNS-Service --> Lösungshyothese: avahi
Guckst du hier:Netzwerk Management Server mit Raspberry Pi
Da steht wie es geht.
Richtige Netzwerk Hardware bietet zudem oft im Setup auch ein mDNS Gateway in der Konfig an wo man diese Dienste auf der Infrastruktur selber konfigurieren kann !
Bisher ohne Erfahruing zu avahi; nach meinem Verständnis muss der avahi-Server in jedem relevanten VLAN sein, damit es funktioniert wegen Hop-Limit=1.
Ja, das liegt daran das mDNS eine Local Link Multicast Adresse benutzt 224.0.0.251 (UDP 5353). Local Link Multicasts haben immer fest eine TTL von 1, können also nicht geroutet werden über Router.https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Lesen und verstehen...!
Der avahi-Server müsste also tagged angebunden werden mit entsprechender Anzahl Interfaces , damit Bonjour refelektieren kann in die VLANs, richtig?
Ja, es sei denn dein Switch oder WLAN AP bietet von sich aus eine mDNS Gateway Funktion im Setup wie z.B. Ruckus und andere Hersteller auch auf ihren Komponenten.
Bisher waren meine Server alle untagged und damit sauber getrennt, der MT sorgte für Trennung und Sicherheit. Abseits der Router/Switch habe ich an Clients/Servern noch keinerlei praktische VLAN-Erfahrung. Technisch sicher alles machbar/installierbar. Aber...
Ja, das ist kinderleicht und in 5 Minuten auf dem MT eingerichtet ! Siehe hier:Netzwerk Management Server mit Raspberry Pi
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Und auch hier:
https://forum.mikrotik.com/viewtopic.php?t=84155
Frage: Wenn ich eine avahi-Server tagged einbinde: Reiße ich mir damit hinter meiner FW ein Sicherheitsloch auf und gefährde die VLAN-Trennung des MT?
Nein !Du reisst da nichts auf. Allerdings nur unter einer wichtigen Bedingung !!!
IPv4 und v6 Forwarding darf NICHT aktiviert sein auf dem RasPi !!!
Sprich also das Kommando #net.ipv4.ip_forward=1 in der Datei /etc/sysctl.conf MUSS ein # vor dem Kommand haben ! Ebenso sein Pendant bei IPv6. Das macht dann wasserdicht das der RasPi/Ubuntu NICHT routet zwischen seinen Interfaces !!!
Falls problematisch: Wie kann ich auf dem avahi-Server jedweden inter-VLAN-Verkehr verhindern, der über Bonjour hinaus geht?
Siehe oben ! IP Forwarding ABSCHALTEN !
Vieln Dank, Ihr Zwei!
Für die FW im MirkoTik sehe ich mich gut gerüstet und ist sehr restriktiv. Zum MT habe ich wenig Sorgen und auch zu meinen FW-Einstellunge darauf... Folge einem Schalen-Prinzp von sehr kleinem innernen Segement mit kritischen Daten bis außen zu den beiden risikoreichsten iot (darf gar nichts außer einzelne whiteist-Regeln) und Gast (darf fast nichts, nur WAN und nur wenige Ports). Aber genau daher kamen meine Sorgen, ob ich mir mit einem avahi-Server nicht hinten herum ein Loch aufreiße, nur weil ich Geräte im inneren VLAN per bonjur im äußeren VLAN (der grauselige iot-Krams) bekannt machen möchte (hier ganz konkreter Anwendungsfall: Airplay 2).
Fazit aus Euren Antworten für mich:
Aqui habe ich aber so verstanden, dass es dazu nicht wirklich einen Bedarf gibt, sofern IP-FW unterbunden. 2 Meinungen...das verunsichert mich zugegeben etwas...
Für die FW im MirkoTik sehe ich mich gut gerüstet und ist sehr restriktiv. Zum MT habe ich wenig Sorgen und auch zu meinen FW-Einstellunge darauf...
Folge einem Schalen-Prinzp von sehr kleinem innernen Segement mit kritischen Daten bis außen zu den beiden risikoreichsten iot (darf gar nichts außer einzelne whiteist-Regeln) und Gast (darf fast nichts, nur WAN und nur wenige Ports). Aber genau daher kamen meine Sorgen, ob ich mir mit einem avahi-Server nicht hinten herum ein Loch aufreiße, nur weil ich Geräte im inneren VLAN per bonjur im äußeren VLAN (der grauselige iot-Krams) bekannt machen möchte (hier ganz konkreter Anwendungsfall: Airplay 2).Fazit aus Euren Antworten für mich:
- Grundsätzlich kein grundsätzliches Sicherheistrisiko (natürlich mit dem üblichen Maßgaben: regelmäßige Update, Hirn nicht abschalten, Kein Backup, kein Mitleid,...)
- MUSS: IP-Forwarding prüfen, ob es aus abgeschaltet ist für IPv4/v6 --> da muss ich mal schauen, wie ich es auf einem Bleche prüfe, werde dazu aber sicher selber was finden. Raspi ist nicht so meines, alle Server x86/amd64...
- Ratschlag für mich neu: Auf jedem Server FW. Hmmmm..das hatte ich bislang gar nicht auf dem Schirm, weil ich da den MT als zentrale Lsöung sah, die ich gut beherrsche. Ich verstehe den Angriffsvektor auch nicht so ganz. Wenn mir jemand auf einen Server in meinem mittleren Segment kommt...wie soll er auf meinen inneres Segement am MT vorbei. Bei dem neuen avahi-Server hat mich ja genau das Risiko umgetrieben (und sehe auch de Bedarf der FW nicht wegen avahi, sondern den 5 Interfaces zu meinen Segementen), aber bei einem Server, der durch den Port verlässlich in einem Segement steckt?
Aqui habe ich aber so verstanden, dass es dazu nicht wirklich einen Bedarf gibt, sofern IP-FW unterbunden. 2 Meinungen...das verunsichert mich zugegeben etwas...
Raspi ist nicht so meines,
War auch rein nur als Beispiel für alle unixoiden OS gedacht... Auf jedem Server FW.
Kann man machen wenn man zum Gürtel auch noch den Hosenträger will. Muss man aber nicht wenn der Rest wasserdicht ist.Du solltest die zentrale MT Firewall belassen, denn wenn du dir jetzt zig FW Baustellen aufmachst wie willst du das managen später ?!
Stelle sicher da immer wasserdicht das Forwarding deaktiviert ist dann ist das hinreichend sicher. Wie man Server richtig absichert weisst du ja hoffentlich ?!
Ich verstehe den Angriffsvektor auch nicht so ganz. Wenn mir jemand auf einen Server in meinem mittleren Segment kommt...wie soll er auf meinen inneres Segement am MT vorbei.
Ich dachte dabei ja eher an Viren Trojaner &Co die sich ein Client einfängt. Die sind dann schon drin .Die Zeiten in denen man intern aus Bequemlichkeit alles offen stehen lässt sind schon lange vorbei.
noch mal vielen Dank. Jetzt liegt der Ball bei mir - werde es wohl tatsächlich mal mit einem kleinen Raspi versuchen nur dafür - und Erfahrungen sammeln. Mit Euren Hinweisen kann ich es jetzt erheblich besser einordnen.
werde es wohl tatsächlich mal mit einem kleinen Raspi versuchen
Zum Testen ist das der richtige Weg !Viel Erfolg !
Hier findet ihr auch eine Lösung zum mDNS Repeating direkt auf einem MIkrotik Router
Mikrotik: mDNS Repeater als Docker-Container auf dem Router (ARM,ARM64,X86)
Grüße Uwe
Mikrotik: mDNS Repeater als Docker-Container auf dem Router (ARM,ARM64,X86)
Grüße Uwe
