Telekom RTP-Ports forwarden = Sicherheitsrisiko?

[luck3rhoch3]

Moin,

habe VOIP mit einer Fritzbox in einem VLAN grundsätzlich zum Laufen gebracht, hatte aber manchmal z. B. keinen Rufton, obwohl es auf der Gegenseite geklingelt hat.

Dann habe ich mir während des Anrufs mal das Firewall-Log angesehen und gesehen, dass der RTP-Port (z. B. 7081) blockiert wird und zwar tausendfach innerhalb von Sekunden.

Meine Outbound Rule sieht folgendermaßen aus und funktioniert grundsätzlich, da vorher gar keine Telefonie möglich war:

You cannot view this attachment.

Die dann noch bestehende Probleme konnte ich mit folgender Freigabe lösen:

You cannot view this attachment.

Nun habe ich aber schon mehrfach gelesen, dass dies ein Sicherheitsrisiko darstellt und gar nicht notwendig sein soll.

Hier aber noch ein Screenshot, wie es aussieht, wenn die Rule deaktiviert ist (aber nur bei manchen Rufnummern - in diesem Fall eine Festnetznummer):
You cannot view this attachment.


Ist es tatsächlich ein Risiko oder kann ich es so belassen? Oder lässt es sich ggf. anders lösen?

Danke :-)

[meyergru]

Bei VoIP findet zunächst eine Signalisierung per SIP (Port 5060) statt, wobei dann per RTP (oft Port 7078-7100) Verbindungen für die Audio-Pakete geöffnet werden. Was sollte also passieren? Jemand schickt Dir auf den RTP-Ports Audio-Pakete, die dann verworfen werden, weil sie vom falschen Absender kommen.

Du kannst eventuell als erlaubte Quell-Ranges entweder auf das ASN 3220 der Telekom einschränken (darin sind dann aber auch alle Einwahl-IPs enthalten) oder spezifischer bestimmte IP-Bereiche für Telekom-Infrastruktur (die könnten sich aber ggf. ändern).

[luck3rhoch3]

Du meinst, es ist quasi kein Sicherheitsproblem, weil die fritzbox die Pakete verwerfen würde?

Zu erwähnen sei, dass ich noch keine Vlan-fähigen Access Points habe und die Fritzbox sich deshalb aktuell noch im Trusted VLAN befindet.

[meyergru]

Genau.

Meinst Du VLAN-fähige APs oder managed Switches? Die Fritzbox hängt doch mutmaßlich nicht per WLAN an der OpnSense? Dann kannst Du die doch in ein VLAN sperren oder an einen anderen Port der OpnSense anschließen?

VLAN-fähige APs wie Unifi o.ä. machen natürlich für IoT-Geräte oder anderes unsicheres Zeugs in jedem Fall Sinn.

[luck3rhoch3]

Ich meine schon VLAN-fähige APs oder in diesem Fall generell einfach, dass ich keinen weiteren AP habe. Denn aktuell ist meine Fritzbox mein einziger AP, den ich deshalb zwangsweise im Trusted VLAN haben muss, da ich sonst kein WLAN habe. Die Fritzbox hängt als IP-Client im Trusted VLAN.

Und diese übernimmt aktuell zwangsweise auch noch die Telefonie, weshalb ich bzgl. des port forwardings etwas Bauchschmerzen habe.

Langfristig möchte ich natürlich VLAN-fähige APs und ggf. irgendetwas anderes für die Telefonie verwenden, da die Fritzbox als reine Telefonanlage für zwei Festnetztelefone wohl etwas übertrieben ist, vor allem was auch den Stromverbrauch betrifft. Wenn es nach mir ginge, hätten wir gar kein Festnetz zuhause, aber Frau und Omi in der Einliegerwohnung sehen das anders.

[Patrick M. Hausen]

Weshalb hast du Bauchschmerzen wegen Telefonie?

[meyergru]

Tatsächlich würde ich dann die Fritzbox eher ins IoT-Netz hängen. Bei mir sind eigentlich alle WLAN-Clients auch im IoT-Netz: Cloudifizierte Geräte sowieso, TV-Appliances auch und Smartphones auch. Alles, was vertrauenswürdig ist, ist bei mir verdrahtet. Ich nutze tatsächlich eine Fritzbox nur für Telefonie - ist aber eine 7530, die nicht so viel Strom frisst wie die "Großen". Andererseits kostet ein AP nicht die Welt.

[luck3rhoch3]

Das ist langfristig auch der Plan. Die APs sollen dann von Unifi oder TP-Link kommen (Letzteres würde sich evtl. anbieten, da mein Switch bereits ein Omada-Switch ist).

Auch die IoT-Geräte sollen isoliert werden, hier muss ich mich aber einlesen, wie ich das alles trenne, sodass es nachher noch funktioniert (MQTT, APIs über verschieden VLANS, etc.). Gerade denke ich mir aber, dass es evtl. mehr Sinn macht, den Home-Assistant auch einfach ins IoT-Netzwerk zu den Smart-Relays, Amazon Echos usw. zu schieben und nur intern eine HTTP-Portfreigabe auf das Trusted-VLAN zu machen, um per App und PC Zugriff zu haben. Dann wäre ja wieder alles VLAN-intern, ohne sicherheitsrelevante Geräte im selben VLAN.

Dann wäre auch die HTTPS-Port-Freigabe von WAN auf das Home Assistant Webinterface auch nicht mehr so tragisch, denn wenn ein Hacker mir tatsächlich mal die Christbaumbeleuchtung ein- und ausschaltet wäre mir das herzlich egal, kritische Smart-Home-Geräte habe ich (noch) nicht. Wobei der Home Assistant sowieso per Fail2Ban und 2FA abgesichert ist und ich da eher optimistisch bin, dass sich kaum einer den Aufwand macht, dort einzudringen.

Smartphones ins IoT finde ich persönlich jetzt z. B. kritisch, da sich auf diesem ja auch etliche sensible Daten befinden (Onlinebanking, etc.).

[meyergru]

Smartphones ins IoT finde ich persönlich jetzt z. B. kritisch, da sich auf diesem ja auch etliche sensible Daten befinden (Onlinebanking, etc.).

Aha. Dann machst Du auch kein Mobile Internet, wenn Du das Haus verlässt? Ich mache mir eher Sorgen, dass jemand in meinem LAN rumrüsseln kann, wenn er das Smartphone übernimmt. Die Credentials für Onlinebanking sind in einem TPM und können nicht extrahiert werden, zumindest fordert das die PSD2 (damit kenne ich mich zufällig aus).