Posts by ꧁𓊈𒆜 ƁєηLυє 𒆜𓊉꧂

Quote from BlackSpy

UniFi Protect Cameras 5.5.11

https://community.ui.com/releases/UniFi…bb-c2059c2157c9

Improvements

• [G4 Doorbell Pro] Optimized LCM memory usage.

Da bin ich mal gespannt. Update läuft gerade durch

2 Tage Romantic Urlaub in Ascona

https://www.amazon.fr/dp/B0G3LDXXRP

Ich war mal ehemaliger Marzahner

UDM-SE: Firewall-Diskrepanz bei IPv6-Regeln „Accept #ICMP IPv6“ öffnet offenbar mehr als ICMPv6

Hallo zusammen,

ich möchte eine Beobachtung teilen, die bei meiner UDM-SE im Zusammenhang mit IPv6 und den neuen Zone-/Policy-Firewall-Regeln aufgefallen ist. Vielleicht hilft es anderen, die gerade IPv6 auf mehreren VLANs aktivieren oder ihre WAN->LAN-Regeln prüfen.

Ausgangslage

• UDM-SE mit mehreren VLANs/Zonen
• Dual-WAN mit IPv6 Prefixes
• IPv6 per RA/SLAAC auf mehreren VLANs aktiv
• Firewall wird über die neue Zone-/Policy-Ansicht verwaltet

Nach dem Aktivieren von IPv6 habe ich die generierten ip6tables-Regeln geprüft und dabei eine Diskrepanz gefunden.

Beobachtung in der UniFi Firewall-Ansicht

In der UniFi-Oberfläche waren mehrere Regeln sichtbar mit dem Namen:

Accept #ICMP IPv6

Die Regeln wirkten vom Namen her so, als würden sie nur ICMPv6 erlauben. In der Übersicht standen sie jedoch sinngemäß als:

Allow
IPv6
All
External → Internal

Allow
IPv6
All
External → Hotspot

Allow
IPv6
All
External → External

Allow
IPv6
All
External → VPN

Das ist aus meiner Sicht gefährlich, weil der Name „ICMP IPv6“ suggeriert, dass nur ICMPv6 erlaubt wird. Tatsächlich war der Protokollwert aber „All“.

Prüfung per MongoDB

In der alten Collection firewallrule waren die Regeln nicht zu finden. Fündig wurde ich in:

firewall_policy

Die betroffenen Objekte hatten intern ungefähr diese Struktur:

{
  "name": "Accept #ICMP IPv6 ",
  "enabled": true,
  "action": "ALLOW",
  "ip_version": "IPV6",
  "protocol": "all",
  "icmp_v6_typename": "ANY",
  "connection_state_type": "ALL",
  "source": {
    "zone_id": "External"
  },
  "destination": {
    "zone_id": "Internal / Hotspot / External / Vpn"
  }
}

Der entscheidende Punkt ist:

"protocol": "all"

Damit handelt es sich eben nicht um eine reine ICMPv6-Regel.

Runtime-Auswirkung in ip6tables

In den generierten ip6tables-Ketten tauchten dadurch sehr frühe ACCEPT-Regeln auf, zum Beispiel sinngemäß:

-A UBIOS_WAN_LAN_USER -j ACCEPT
-A UBIOS_WAN_GUEST_USER -j ACCEPT
-A UBIOS_WAN_VPN_USER -j ACCEPT

Diese ACCEPT-Regeln standen vor den späteren Drop-Regeln. Dadurch konnte WAN->LAN bei IPv6 potentiell deutlich offener sein als erwartet.

Temporärer Schutz

Ich habe als Sofortmaßnahme vor die betroffenen WAN-Zielketten eine Drop-Regel für neue und invalide Verbindungen gesetzt:

ip6tables -I UBIOS_WAN_LAN_USER   1 -m conntrack --ctstate NEW,INVALID -j DROP
ip6tables -I UBIOS_WAN_GUEST_USER 1 -m conntrack --ctstate NEW,INVALID -j DROP
ip6tables -I UBIOS_WAN_DMZ_USER   1 -m conntrack --ctstate NEW,INVALID -j DROP
ip6tables -I UBIOS_WAN_VPN_USER   1 -m conntrack --ctstate NEW,INVALID -j DROP

Das blockt neue eingehende IPv6-Verbindungen aus dem WAN zu internen Zonen, lässt aber ausgehenden Traffic und Rückverkehr über RELATED,ESTABLISHED weiter funktionieren.

Dauerhafte Korrektur

Die eigentliche Ursache waren bei mir vier Policies mit dem Namen:

Accept #ICMP IPv6 

Diese habe ich deaktiviert, weil sie intern nicht ICMPv6, sondern IPv6 „all“ erlaubten:

db.firewall_policy.updateMany(
  { name: "Accept #ICMP IPv6 " },
  { $set: { enabled: false } }
)

Danach waren die falschen Policies deaktiviert. Zusätzlich bleibt bei mir ein kleiner systemd-Sicherheitsdienst aktiv, der die Runtime-Drop-Regeln wieder setzt, falls UniFi bei Provisioning oder Neustart die ip6tables-Regeln neu generiert.

Wichtiger Hinweis

Ich würde ICMPv6 nicht pauschal blockieren. IPv6 braucht bestimmte ICMPv6-Typen, unter anderem für Neighbor Discovery, Router Advertisements und Path MTU Discovery. Das Problem ist hier nicht ICMPv6 selbst, sondern dass eine Regel mit dem Namen „ICMP IPv6“ intern als „IPv6 All“ gespeichert bzw. angewendet wurde.

Bitte um Gegenprüfung

Kann jemand mit einer UDM-SE oder UDM-Pro und aktivem IPv6 einmal prüfen, ob bei ihm ähnliche Regeln existieren?

mongo --quiet --port 27117 ace --eval '
db.firewall_policy.find(
  { name: /ICMP IPv6/i },
  { name:1, enabled:1, action:1, ip_version:1, protocol:1, icmp_v6_typename:1, source:1, destination:1 }
).forEach(printjson)
'

Interessant wäre vor allem, ob bei euch ebenfalls folgendes auftaucht:

name: "Accept #ICMP IPv6 "
ip_version: "IPV6"
protocol: "all"

Falls ja, wäre das aus meiner Sicht zumindest eine sehr missverständliche Darstellung in der UI, im ungünstigen Fall aber eine echte Firewall-Diskrepanz.

LG

Die PTZ hat doch glaub auch eine Tiererkennung, würde mich wundern, wenn nicht. Mit HA lässt sich super zeitlich Personen und Tierkennung zu gewünschten Zeit de/aktivieren.

https://makerworld.com/de/models/399099-unifi-doorbell-g4-pro-plate#profileId-300639

Moin Leute!

Um die Gemüter kurz zu beruhigen: Alles gut, kein Admin-Eingriff nötig! Da wir uns hier im Off-Topic-Kanal bewegen, läuft das Ganze unter „Fun“ und solche Diskussionen sind bei uns absolut willkommen.

Diskutiert also ruhig munter weiter über E-Autos, PV-Logiken und 3D Druck. Hauptsache, es bleibt weiterhin so ein nettes Miteinander und ihr zeigt uns nebenbei fleissig eure neuesten Anschaffungen!

Quote from Lausbub

Finde ich auch. Es sollte ja in diesem Thread um neue Anschaffungen gehen und nicht um Vor- und Nachteile und Eigenschaften von E-Autos. Das nimmt mMn zu viel Platz ein. Aber ich bin nicht der Chef, die Admins sollen das entscheiden.

Solange es nicht gerade um Politik geht, sehe ich da keine Probleme.

Quote from Erich

Nein, die Tochter bekommt ihr WLan nach wie vor über die eigene Fritzbox. Dieses Netzwerk mit Telefonie hängt nicht mit meinem zusammen. Wir teilen uns nur den DSL-Anschluss.

Sie braucht ihre Fritzbox auch wegen der Telefonie. Die Haupt-Fritzbox leitet die Telefonie ebenso weiter.

Jetzt bin ich maximal verwirrt, als würdest du zwei Verkehrspolizisten auf dieselbe Kreuzung stellen, die unterschiedliche Sprachen sprechen und sich gegenseitig ignorieren. Am Ende gibt es nur Chaos und Stau.

Quote from fred05

Ich verstehe es so, dass es weiterhin per FB noch WLAN für die Tochter geben soll, nur warum macht keinen Sinn wenn man umsteigt dann alles über die APs von Ubiquiti.

Jupp, make no sense. Die alte FB gehört fachmännisch entsorgt. Das Tochterlein bekommt eigene SSID mit sepraten VLAN, Filtern und Zeitbegrenzung wenn gewünscht ist dann kinder leicht. Ist eine Verkabelung nicht möglich, dann notfalls über Mesh laufen lassen. Hab bei mir auch 2-3 AP's über Mesh.

Erich

Quote from fred05

Die FB Box macht null wLAN mehr.

Es wird dann nur eine FB geben. Alles andere möchtest du nicht, glaub mir!

Quote from MirrorNET

Was gibts für ne alternative um Voip betreiben zu können. Bitte keine Cloudlösung.

zB: Gigaset IP mit den passenden Endgeräten

Quote from Networker

Netzteil tauschen.

Oder die Firtzbox gegen was gescheites austauschen.

Wo hängt denn in deinem Diagramm deine Fritzbox drann? Und was ist alles an der Fritzbox angeschlossen?

Dein Shelly ist nicht zufälliger Weise mit WIFI und LAN gleichzeitig verbunden?

Die primäre Zielgruppe für SIP-Telefonie dürften vor allem kleine und mittlere Unternehmen (KMU) sein, da die Technologie erhebliche Vorteile bei der Verfügbarkeit und Skalierbarkeit bietet. Zudem ermöglicht sie es, eine einzige geschäftliche Rufnummer vollkommen frei und flexibel zu konfigurieren.

Für mich persönlich bietet das Setup jedoch einen ganz praktischen, privaten Vorteil: Ich kann damit kostenlos in das jeweilige Land telefonieren. Da die Schweiz als mein Arbeitsort in meinem deutschen Mobilfunkvertrag leider nicht über das EU-Roaming abgedeckt ist, ist dies eine äußerst effiziente Lösung.

Abgesehen von Unternehmen und Grenzgängern zieht die Technologie vor allem Technikbegeisterte an, die SIP im eigenen Netzwerk ausreizen und dessen Funktionsweise besser verstehen möchten. Für den durchschnittlichen Endverbraucher ohne solche speziellen Anforderungen ist der Aufwand im Alltag allerdings meist überdimensioniert.

Quote from franzbertbua

ich für meinen teil finde es interessant, dass es immer noch so großen bedarf an "festnetz" gibt, obwohl mittlerweile jeder ein handy hat und vieles auch schon über teams und co laufen kann.

mich würde mal interessieren, was die beweggründe sind, ein "festnetz" weiter zu betreiben in zeiten wo jeder ein handy hat

Vielleicht kann mir das jemand von euch usern erläutern

Ich lebe in einer ländlichen Gemeinde in Frankreich mit rund 1.000 Einwohnern. Die Infrastruktur vor Ort ist hervorragend ausgebaut, fast jeder Haushalt verfügt über einen modernen Glasfaseranschluss (FTTH). Obwohl mein aktuelles Internet-Paket eine Festnetznummer beinhaltet, lässt sich diese leider nicht direkt über SIP konfigurieren. Da der Mobilfunkempfang in unserer Region jedoch unzuverlässig ist, habe ich nach einer flexibleren Alternative gesucht.

Fündig wurde ich bei meinem ehemaligen Provider, der SIP-Telefonie sowohl mit einer französischen als auch mit einer Schweizer Rufnummer anbietet. Dieses Setup ist für meinen Alltag ideal: Ich arbeite in der Schweiz, erledige Besorgungen sowie Arztbesuche im nahegelegenen Deutschland und halte so auch unkompliziert den Kontakt zu meiner dort lebenden Familie. Das SIP-basierte Festnetz sichert mir somit trotz schwacher Mobilfunkabdeckung eine stabile und grenzüberschreitende Erreichbarkeit.

Wie Garnitur bereits geschildert hat, wird mit dem Update behoben. Hatte das Problem kürzlich auch.

Dürfte problemlos mit Webhooks gehen. Ich selber öffne meine Garage mit den Finderabdruck über meine G4 Doorbell Pro. Meine alte Somfy Garagentüröffner ist mit einem Shelly verbunden. Einstellung und konfiguration sollte problemlos auch für deine G6 Pro Entry möglich sein.