Wie filtert man Multicast-Traffic mit der netcup-Firewall?

    Zitat von Zierleiste

    Ich komme auf 73 GB/m / (30 x 24 x 60 x 60) x 8 = 225 kbit/s oder ein bisschen mehr, wenn man mit 74 GB und 28 Tagen rechnet.

    Aber unabhängig davon macht es also durchaus Sinn, Multicast in der lokalen Firewall zu sperren.

    Er hat wohl nicht den ganzen Monat "durchgespammt", ansonsten wären fast 900 GB drin gewesen. Es geht mir auch nicht wirklich um die tatsächliche Menge, die bei Vielen sicher im Grundrauschen untergeht, sondern mehr um die Suche nach der Ursache und deren Lösung. :)

    Zitat von terence

    Ich habe daher den Eindruck, dass man Multicast mit der Firewall nicht blockieren kann (im Wiki habe ich keinen Hinweis dazu gefunden). Oder habe ich noch irgendwo einen Fehler drin?

    Die Firewall ist wahrscheinlich weiter oben in den Switches aktiv.

    Mit tcpdump -e sind viele ARP und ICMPv6 133/135 Pakete von anderen Servern im Netzwerk zu sehen.

    Ich erhalte bspw. das gleiche Grundrauschen über Server, die im selben /16 Präfix, aber in verschiedenen /24 Subnetzen liegen und über dasselbe BGP /22 angekündigt werden.

    Die NC Firewall blockiert aktiv zwischen den Servern, wie es im selben /24 ist, kann ich leider nicht sagen ;(, bezweifle aber, dass es anders ist.

    Ersetzt trotzdem keine Firewall auf dem System, welche incoming standardmäßig ablehnt.

    Weiter filtern arp, icmp6[0]=… vereinzelte Server, die irgendeinen mDNS oder UPnP Dienst haben, der Multicast schickt.

    Unter anderem 224.0.0.251, 224.0.0.252, 239.255.255.250 etc aber das ist zwischen BGP Subnetzen unterschiedlich.

    Sofern mit iptraf, conntrack, ss keine aktiven Verbindungen angezeigt werden oder der eigene Server das Ziel ist, solltest man sich keine Sorgen machen müssen.

    Zitat von terence

    Ja, Brodcast und Multicast kommt auch beim Interface an, wenn es keine IP-Adresse zugewiesen hat.

    ARP und ICMPv6 lassen sich leider nicht wirklich verhindern, sonst verlierst du die Verbindungen auf dem jeweiligen Interface (außer es ist so von dir gewollt und das gilt auch für Dinge im SCP wie VNC, also hab ich gehört).

    Generell Multicast von anderen im VXLAN zu unterbinden erfordert glaub ich IGMP snooping oder Änderungen daran, wie die KVMs bereitgestellt werden.

    Wenn du Multicast für das Interface deaktivierst, landen sie weiterhin noch auf deinem NIC, weil sie jeder Hypervisor im selben virtuellen Netzwerk erhält.

    Hatte selber mal vor einiger Zeit danach gesucht und das waren relevanten Themen, die ich gefunden hatte:

    ARP Flut auf eth0 - netcup Kundenforum
    Hallo, ich hab heute durch Zufall bei einem tcpdump auf meinem Netzwerkinterface recht häufige ARP Anfragen entdeckt, mehr als 100 pro Sekunde. Die…
    forum.netcup.de
    seltsamer periodischer traffic - netcup Kundenforum
    Seit einigen Tagen habe ich einen seltsamen periodischen traffic auf einem meiner Server, den ich in dieser Form noch nicht hatte. Ein Intervall von exakt zwei…
    forum.netcup.de

    Im Endeffekt ist es eine Fehlkonfiguration von den Kunden oder die hatten das Glück auf Server im gleichen Subnetz. :S

    UDP Traffic zu Bogon IPs ist mMn etwas für private LAN und kein shared Hosting.

    Mehr als das Sie Dienste und Namen für tcpdump racer preisgeben, passiert auch nicht viel. Bin mir ziemlich sicher, die von netcup wissen, was Sie tun und alle MAC-Adressen bleiben genau da, wo sie hingehören.

    Spoofing oder poisoning würde ich nicht austesten, sonst klingelt noch irgendwo ein Glöckchen.

    Das ist so mein Euro dazu aber bei mehr als 2-3 GB pro Monat würde ich darüber nachdenken, den Support zu kontaktieren. :/

    Zitat von terence

    Sollte sowas nicht eigentlich standardmäßig von netcup rausgefiltert werden? Ich finde es ja auch komisch, dass mein IPv6-only-Server IPv4-Traffic bekommt. Würde ich nun auch nicht unbedingt erwarten.

    Denke mal, dass es seitens KVM nur Konfigurationssache ist, ob dir vom Hypervisor v4/v6/vLAN eingerichtet werden soll. Drum herum können Kunden mit anderen Produkten liegen, die sowieso gleichermaßen wie deine Instanz über alles fähige vSwitches verbunden sind.

    Zitat von Zierleiste

    bin mal gespannt, ob sich das abstellen lässt.

    Stille bekommst du nur über einen Cloud vLAN only.

    Zitat von Zierleiste

    Zuordnung private LAN / shared Hosting

    Multicast wird hauptsächlich zur Service Discovery genutzt, um anderen im Netzwerk Dienste zum Verbinden zu signalisieren.

    Das Many to Many im Vergleich zum Point to Point von Unicast, unabhängig davon, dass anschließend Anfragen an den Advertiser als Unicast gestellt werden müssen für einen direkten Datenaustausch.

    Im Heimnetzwerk mag es bei Drucker, Smartphones und Kühlschränken gewollt sein, aber in der Cloud sollten umliegende VMs nicht wissen, was auf dem Server für Dienste sind.

    In den Paketen finden sich meistens Metadaten wie Hostname, Protokoll, Port, User Agent oder sonstiges, abhängig vom Dienst oder ob es etwas eigenes ist.

    Um wirklich was damit anfangen zu können, müssten sensible Daten drin stehen oder Anfragen keine Authentifizierung erfordern, ist dann aber Anwendungsebene.

    Zitat von Zierleiste

    welche Folgen Du siehst bzgl. Firewall-Regeln

    Mit iptables, nftables, firewalld, ufw oder der Firewall im SCP kann nichts gegen das Eintreffen von Multicast getan werden, da die Pakete aus dem Inneren des VXLAN bspw. der anderen Seite des Raumes stammen.

    Solange die VM keine Sockets auf dieser Adresse geöffnet hat, verwirft der Kernel die Frames auch direkt wieder.

    Avahi, Bonjour und Standardkonfigurationen sind meist die Übeltäter oder hardcoded, was dann mit outgoing Regeln in der VM direkt gedroppt werden sollte.

    Kritisch wird es eigentlich nur bei großen Payloads, welche die Bandbreite anderer im Netzwerk belasten und Leakage aus dem eigenen VPN, in denen Pakete verbundener Endgeräte auftauchen.

    Clients müssen einer Multicastgruppe nicht unbedingt beitreten, um die Pakete vor die Tür gestellt zu bekommen. Das ist abhängig vom Switch und was er mit dem TTL Frame anstellt.

    Ohne IGMP oder snooping wird es so gesehen an jeden Hypervisor geflutet und landet auf seinem vSwitch, weil es laut VXLAN Verpackung nie einen Router gesehen hat.

    Mit snooping wird Multicast nur an KVMs geleitet, deren vSwitch danach gefragt bzw. geantwortet haben. Abhängig vom Host landen die dann trotzdem bei allen VMs derselben physischen NIC.

    Als Kontrast haben Hyperscaler tiefere Strukturen und bieten Routes in isolierte VPC zur IP-Vergabe an andere Dienste im selben Subnetz.

    Wie ein eigenes Internet im Rechenzentrum, deshalb gibt es mehr Gateways/ACLs zum Einstellen.

    Also wäre es doch Aufgabe von netcup, für eine bessere Isolierung ihrer Kunden zu sorgen, indem beispielsweise Multicast-Traffic ausgehend prinzipiell geblockt wird.

    Den Begriff Bogon IP-Pakete kenne ich eigentlich als Bezeichnung für IP-Pakete, die ungültige Quelladressen verwenden, dazu würden dann Multicast-Zieladressen m. E. nicht zählen.

    Ich sehe

    * Simple Service Discovery Protocol

    UDP -> 239.255.255.250:1900

    urn:dial-multiscreen-org:service:dial

    in denke das sind Browser, nicht sinnvoll auf VPS

    * Link-local Multicast Name Resolution

    UDP -> 224.0.0.252:5355
    fragen ihren eigenen Namen ab - nicht sinnvoll,

    oder sogar wpad - Sicherheitsrikiko

    * Multicast Domain Name System

    UDP 224.0.0.251:5353

    Name: WIN-KBA3NQOKTFK.local
    Name: _googlecast._tcp.local
    Name: tablex-jauker._dosvc._tcp.local
    auch Blödsinn

    * ws-discovey

    UDP -> 239.255.255.250:3702
    Microsoft Windows Server XML
    natürlich Blödsinn

    * Local Service Discovery

    UDP -> 239.192.152.143:6771?

    Header: BT-SEARCH * HTTP/1.1
    Host: 239.192.152.143:6771
    Port: 22551
    Infohash: 36b06f223aece67ddcd6ce8d220d9dcb22c42120
    cookie: 109aedd4
    sollte auch nicht auf VPS laufen

    * UDP -> 239.6.7.8:46655

    unklar was das ist, "ISPN"?

    Bin mir nicht sicher ob ich den VPS-Eigentümern Tipps schicken sollte.

    Zitat von Zierleiste

    Also wäre es doch Aufgabe von netcup, für eine bessere Isolierung ihrer Kunden zu sorgen,

    Das kommt auf die Bereitstellung der KVMs an und ob es nicht Probleme bei Kunden auslösen würde.

    Kann auch zu viel Verwaltungsaufwand sein, der bei Fehlersuche schnell unübersichtlich wird.

    Im Prinzip sind es explizit Server mit öffentlicher Anbindung zum Internet, wo die Isolation auch etwas von der eigenen Seite aus kommen sollte.

    Zitat von Zierleiste

    indem beispielsweise Multicast-Traffic ausgehend prinzipiell geblockt wird.

    Theoretisch ja, ebtables könnte im Hypervisor ausgehenden Multicast blockieren, ob das in der Praxis mit zehntausenden VMs einfach ist, eine andere Sache.

    Zitat von Zierleiste

    Den Begriff Bogon IP-Pakete kenne ich eigentlich als Bezeichnung für IP-Pakete, die ungültige Quelladressen verwenden, dazu würden dann Multicast-Zieladressen m. E. nicht zählen.

    Zugegeben habe ich den Begriff weit ausgelegt. Die Adressen sind zwar IANA registriert, aber ich finde sie in einem öffentlichen Subnetz deplatziert.

    Vgl. https://ipinfo.io/bogon

    Ist mehr oder weniger ein Feature.

    Es wird leider unnötiger Traffic produziert, der ja alle "Nachbarn" betrifft, die in der selben Broadcast-Domäne liegen. Die DNS-Namen werden von Tools wie iptraf (die Namensauflösung muss erst aktiviert werden) oder auch iftop (die Namensauflösung ist per Default aktiv) automatisch ermittelt (sofern möglich) - ganz interessant, wer da so die "Nachbarn" sind.

    Zitat von Veit_Kannegieser

    Bin mir nicht sicher ob ich den VPS-Eigentümern Tipps schicken sollte.

    Ich glaube, das wäre ein Kampf gegen Windmühlen. Erst einmal stelle ich mir die Kontaktaufnahme schwierig vor und ob die betroffenen "Nachbarn" überhaupt wissen, wo sie Hand anlegen müssten?

    Ich hatte mit

    Code
    nohup tcpdump -c 1000000 -w ens3_$(date +%Y-%m-%d_%H.%M.%S).pcap -i ens3 &

    auf dem VPS, nach einer Stunde dann abholen und dann Zuhause mit Wireshark nachgesehen,

    das löst die Namen auch auf.

    Und in den Paketen rufen die Dienste die Namen ja meist auch laut raus.

    Die Kontaktaufnahme ist vermutlich machbar, aber ob die Betreiber dann verstehen das es ein Problem gibt?

    Wenn netcup die Pakte gleich verwerfen würde wäre allen geholfen.

    Ich glaube, dass da noch mehr fehlt, wie entsprechende Router, die Gruppen und Gruppenmitgliedschaften verwalten. Sofern da einfach beliebige virtuelle Server in einem /22-Netz einander sehen, würde da ein IGMP Snooping m. E. auch nicht helfen.