Unitymedia IPtables // Firewall-Grundeinstellungen für SIP

[tobsen]

Hallo zusammen,

nach einigem hin und her, läuft das TC4400 mit einem Mikrotik Routerboard nun recht stabil.
Nun war es so, dass ich relativ schnell ziemlich viel Party im Log hatte, weil sich diverse Bots über SSH auf meinen Router verbinden wollten. Habe ich erstmal fix alles dicht gemacht, damit erstmal ruhe ist. Allerdings stehe ich jetzt vor der Frage, welche Ports ich jetzt im Speziellen für die SIP-Telefonie freigeben sollte.
Ich nutze als SIP-Client eine alte DSL-Fritzbox. Wenn ich das richtig gelesen habe, dann baut die Fritzbox die Verbindungen von "innen" (aus dem LAN) auf und hält diese dann durch ein Keep-alive offen.
Trotzdem würde ich gerne die IPtables entsprechend vorbereiten.

UM hat ja leider in dieser Beziehung überhaupt nichts dokumentiert. :gsicht:
Nach etwas googlen hatte ich folgende UDP-Ports gefunden: 5060, 5061, 7077-7110, 10000-20000
Meine IPtables sieht daher erstmal so aus. Ich habe noch keinen globalen DROP für die forward-chain gemacht, da ich ja sonst so ohne weiteres nicht mehr vom client aus z.b. Webseiten aufrufen kann

[admin@MikroTik] /ip firewall filter> print
Flags: X - disabled, I - invalid, D - dynamic 0 chain=input action=accept connection-state=established,related log=no log-prefix="" 1 chain=input action=accept in-interface-list=allow_console log=no log-prefix="" 2 ;;; SIP Accept 5060, 5061 chain=input action=accept protocol=udp dst-port=5060,5061 log=no log-prefix="sip_" 3 ;;; SIP Accept 7077-7110 chain=input action=accept protocol=udp dst-port=7077-7110 log=no log-prefix="sip_" 4 ;;; SIP Accept 10000-20000 chain=input action=accept protocol=udp dst-port=10000-20000 log=no log-prefix="sip_" 5 ;;; Drop all other Input chain=input action=drop log=no log-prefix="" 6 chain=forward action=accept connection-state=established,related log=no log-prefix="" 7 ;;; SIP Accept 5060, 5061 chain=forward action=accept protocol=udp dst-port=5060,5061 log=no log-prefix="sip_" 8 ;;; SIP Accept 7077-7110 chain=forward action=accept protocol=udp dst-port=7077-7110 log=no log-prefix="sip_" 9 ;;; SIP Accept 10000-20000 chain=forward action=accept protocol=udp dst-port=10000-20000 log=no log-prefix="sip_"

Ich würde den Thread so gestalten, dass wir gemeinsam eine "optimale" IPtables zusammenbauen, an der sich dann auch andere Nutzer orientieren können. Denke ich bin nicht der Einzige :kratz:
IPtables funktionieren ja auf jedem Linux-basierten Router. :hammer:

Wer kann helfen? :winken:

LG,
Tobsen

 

[tq1199]

Nach etwas googlen hatte ich folgende UDP-Ports gefunden: 5060, 5061, 7077-7110, 10000-20000

<i>
</i> 2 ;;; SIP Accept 5060, 5061 chain=input action=accept protocol=udp dst-port=5060,5061 log=no log-prefix="sip_" 3 ;;; SIP Accept 7077-7110 chain=input action=accept protocol=udp dst-port=7077-7110 log=no log-prefix="sip_" 4 ;;; SIP Accept 10000-20000 chain=input action=accept protocol=udp dst-port=10000-20000 log=no log-prefix="sip_" 5 ;;; Drop all other Input chain=input action=drop log=no log-prefix=""

BTW: Warum hast Du auch in der INPUT chain deiner Firewall (Router), diese Ports für SIP freigegeben? Nach der PREROUTING chain wird entschieden ob die Datenpakete für die Firewall (Router) bestimmt sind (dann INPUT chain) oder für ein Gerät (hier die FritzBox) hinter der Firewall (Router), dann geht es durch die FORWARD chain.

EDIT:

Siehe auch: https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter

 

[Benqer]

Also ich habe in meiner Firewall gar nichts freigegeben, auch kein Port Forwarding.
Das einzige was ich machen musste war ein Unbound.

Benutze OPNsense

 

[Wechseler]

Eingehend SIP-Pakete forwarden ist ein Sicherheitsrisiko und macht die eigenen SIP-Endgeräte angreifbar. Das sollte man einfach nicht machen.

Sobald ein SIP-Gerät mit dem SIP-Server anfängt zu kommunizieren, erstellt eine stateful firewall entsprechende Sessions in der State-Tabelle und damit ist dann auch der Rückweg offen. Aber eben nur zu dem Server, wo es auch hinsoll und nicht zu Hinz und Kunz mit seinem SIP-Scanner auf der Suche nach Sicherheitslücken und kostenlosen Auslandsgesprächen.

Bei störrischen SIP-Servern braucht es ggf. noch STUN, damit die ins Protokoll eingebetteten IP-Adressen auch passen. Den meisten Providern, die ich kenne, ist das aber völlig egal, bei denen funktioniert es auch so.

 

[sparkie]

Wie habt ihr eigentlich eure Firewalls/IPtables bezüglich SIP konfiguriert? UM rückt ja nicht wirklich damit raus, welche Ports bzw Ranges interessant sind.

die RTP Ports *nicht* von extern auf die internen SIP Geraetschaften weiterzuleiten kann funktionieren, muss es aber nicht. Ob es funktioniert haengt im Wesentlichen von der verwendeten Telefonanlage ab. Man kann jedenfalls nicht davon ausgehen, dass RTP Verbindungen in jedem Fall von intern->extern 'aufgemacht' werden, um so auch in umgekehrter Richtung (per connection tracking) durchgelassen zu werden.

Ich habe hier wireshark Protokolle in denen von extern RTP Pakete geschickt werden, die aber von einer (fehlerhaften) Firewall Konfiguration nicht weitergeleitet werden. Die Telefonanlage wurde in diesem Fall nicht aktiv sondern wartet nur vergeblich auf ankommende RTP Pakete. Mit dem Effekt dass es bei einem Anruf zwar laeutet aber nach Abheben keine Sprechverbindung zustande kommt.

Deswegen mache ich es so:

(3) - IP Forum - [HOWTO] Firewallregeln für VoIP
(3) - IP Forum - [HOWTO] Asterisk Konfiguration fuer Vodafone Kabel

 

[Wechseler]

die RTP Ports *nicht* von extern auf die internen SIP Geraetschaften weiterzuleiten kann funktionieren, muss es aber nicht. Ob es funktioniert haengt im Wesentlichen von der verwendeten Telefonanlage ab. Man kann jedenfalls nicht davon ausgehen, dass RTP Verbindungen in jedem Fall von intern->extern 'aufgemacht' werden, um so auch in umgekehrter Richtung (per connection tracking) durchgelassen zu werden.

Das SIP-Endgerät muß natürlich NAT-fähig sein. Ansonsten wird es Gefrickel.

 

[sparkie]

die NAT-Faehigkeit hat aber doch nichts mit dem Initiieren der RTP-Verbindung zu tun? Zumindest wuesste ich nicht wer mir garantiert (oder wo das dokumentiert ist), dass mein NAT-faehiges Geraet in jedem Fall die RTP Ports in der Firewall 'aufmacht'.

Hingegen die paar tatsaechlich verwendeten RTP Ports einfach per iptables durchzuleiten bietet kaum ein Angriffsrisiko und ist einfach zu bewerkstelligen. Und funktioniert insbesondere mit allen SIP Geraeten/Servern. Sogar mit einem Asterisk oder einer Gigaset N510 IP PRO :smile:

 

[Wechseler]

die NAT-Faehigkeit hat aber doch nichts mit dem Initiieren der RTP-Verbindung zu tun?

Doch natürlich. Wenn sowohl SIP-Client als auch Server NAT-fähig sind, sind keine Würgarounds auf zwischengeschalteten Routern notwendig.

Zumindest wuesste ich nicht wer mir garantiert (oder wo das dokumentiert ist), dass mein NAT-faehiges Geraet in jedem Fall die RTP Ports in der Firewall 'aufmacht'.

Das ist die Aufgabe von STUN, sofern es nicht ohne sowieso funktioniert.

Hingegen die paar tatsaechlich verwendeten RTP Ports einfach per iptables durchzuleiten bietet kaum ein Angriffsrisiko und ist einfach zu bewerkstelligen. Und funktioniert insbesondere mit allen SIP Geraeten/Servern. Sogar mit einem Asterisk oder einer Gigaset N510 IP PRO :smile:

Die Gigaset ist NAT-fähig. Bei Asterisk weiß ich es nicht.

 

[sparkie]

es ist nie verkehrt moeglichst wenig erwuenschte Eigenschaften bei kommerziellen Geraeten oder Dienstleistungen vorauszusetzen

deswegen verlagere ich prinzipiell moeglichst viele Funktionen auf meine Seite (in diesem Fall die Firewall). Die Seite also, die ich eben unter Kontrolle habe.

 

[tobsen]

Ich habe die SIP-Ports wieder aus der Input und Forward Chain rausgenommen und nur related und established Packete zugelassen.
Allerdings ist ja dann bei eingehenden Anrufen nicht sichergestellt, ob auch alle Packete ankommen.

Ich nutze als SIP-Client wie gesagt eine alte DSL-Fritte. Einen STUN-Server gibt es bei UM ja soweit ich weiss nicht. Den Keep-Alive Intervall in der Fritte habe ich mal auf 30 Sekunden herabgesetzt, in der Hoffnung, dass der Mikrotik dann die Verbindung offen lässt.
Seit etwa 3 Stunden ist auch mein Registrar komplett verschwunden und antworte nicht mehr. Da muss ich morgen erstmal zum dann insgesamt viertel mal für neue SIP Daten sorgen. :wand:

 

[Exiver]

Die ankommenden Pakete, welche z.B. nicht über conntracking über deine anderen forwarding Regeln erlaubt werden kommen aber wahrscheinlich alle vom gleichen Host? Im Prinzip könnte man ein Script schreiben, welches deinen SIP-Host auflöst und die IP in einer Firewall-Regel oder in einer Firewall address-list hinterlegt, z.B. https://wiki.mikrotik.com/wiki/Use_host_names_in_firewall_rules

 

[Andreas1969]

Seit etwa 3 Stunden ist auch mein Registrar komplett verschwunden und antworte nicht mehr.

Das kommt öfters vor, kann man im Log der Fritte schön sehen (Ausfall der Telefonie, meistens Nachts).
Am nächsten Tag geht's dann wieder. Hatte ich auch sehr oft. Manchmal ist Tagelang Ruhe, dann mal wieder alle 2-3 Tage.
Die Fritte verschickt ja immer schön diese Push Meldungen, daher bekommt man das ja immer sofort mit. Das betrifft aber nur die UM Nummern.
Sipgate und Co laufen immer stabil durch.

 

[Wechseler]

Einen STUN-Server gibt es bei UM ja soweit ich weiss nicht.

Du kannst auch einen anderen STUN-Server nehmen, z. B. stun.dus.net. Den stört das nicht. :zwinker:

 

[Exiver]

Einen STUN-Server gibt es bei UM ja soweit ich weiss nicht.

Du kannst auch einen anderen STUN-Server nehmen, z. B. stun.dus.net. Den stört das nicht. :zwinker:

Hatte ich mir auch als Vorschlag überlegt, fände ich persönlich aber nicht so toll. Man leitet seinen Voice-Traffic somit erstmal über einen anderen Provider aus. Ohne STUN außerhalb des Unity-Netzes bleibt der Stream zumindest mal von außen nicht mitschneidbar. Aber muss jeder für sich selbst wissen, wie wichtig ihm das erscheint.

 

[Wechseler]

Einen STUN-Server gibt es bei UM ja soweit ich weiss nicht.

Du kannst auch einen anderen STUN-Server nehmen, z. B. stun.dus.net. Den stört das nicht. :zwinker:

Hatte ich mir auch als Vorschlag überlegt, fände ich persönlich aber nicht so toll. Man leitet seinen Voice-Traffic somit erstmal über einen anderen Provider aus. Ohne STUN außerhalb des Unity-Netzes bleibt der Stream zumindest mal von außen nicht mitschneidbar. Aber muss jeder für sich selbst wissen, wie wichtig ihm das erscheint.

STUN "leitet" nichts "aus", es hilft dem NAT-Clienten nur, seine Portmappings zu erkennen und so dem SIP-Server die korrekten Adressen und Ports mitzuteilen. Deshalb ist es auch egal, welchen STUN-Server man benutzt. Im Falle von UM braucht man den sowieso nur, wenn VoIPv4 zusammen mit Native DualStack verwendet werden soll, bei VoIPv6 ist es unnötig.

 

[Exiver]

Einen STUN-Server gibt es bei UM ja soweit ich weiss nicht.

Du kannst auch einen anderen STUN-Server nehmen, z. B. stun.dus.net. Den stört das nicht. :zwinker:

Hatte ich mir auch als Vorschlag überlegt, fände ich persönlich aber nicht so toll. Man leitet seinen Voice-Traffic somit erstmal über einen anderen Provider aus. Ohne STUN außerhalb des Unity-Netzes bleibt der Stream zumindest mal von außen nicht mitschneidbar. Aber muss jeder für sich selbst wissen, wie wichtig ihm das erscheint.

STUN "leitet" nichts "aus", es hilft dem NAT-Clienten nur, seine Portmappings zu erkennen und so dem SIP-Server die korrekten Adressen und Ports mitzuteilen. Deshalb ist es auch egal, welchen STUN-Server man benutzt. Im Falle von UM braucht man den sowieso nur, wenn VoIPv4 zusammen mit Native DualStack verwendet werden soll, bei VoIPv6 ist es unnötig.

Lesen bildet! Danke für die Aufklärung.

 

[y0r]

Der SIP Client sollte gar nichts vom NAT wissen und "dumm" sein. Ich habe auf meinem Bintec Media Gateway kein STUN und keine NAT Option aktiviert. Auch gibt es eingehend kein NAT auf den Bintec. Raus darf er mit allen Ports. Die Firewall darf nur die UDP Ports nicht verwürfeln. (Consistent NAT muss aktiviert sein.)
Das war's auch schon.

 

[sparkie]

Der SIP Client sollte gar nichts vom NAT wissen und "dumm" sein

genauso mache ich es auch.

Damit kommen dann sogar die bescheuertsten Provider noch zurecht :super: