@IEEE:
DANKE - DAS ist doch mal ein Beitrag, der neben dem reinen Statement, WAS man ablehnt, auch noch eine Erklärung liefert, WARUM man das macht - immerhin eine Voraussetzung dafür, daß man sich mit vorgebrachten Argumenten der "Gegenseite" überhaupt auseinandersetzen KANN. Außerdem ist das dann auch der ERSTE Beitrag, der das in den richtigen Kontext(!) rückt (zumindest meistens), wann und warum man Portweiterleitungen gegenüber Skepsis haben KANN (meinetwegen sogar SOLLTE, wenn es andere Optionen für eine Lösung gibt).
Eingehende SIP-"Störungen" kennt sicherlich JEDER, der an einem Internet-Anschluß einen Port offen hat, hinter dem ein SIP-Stack erreichbar ist (und reagiert) - wobei eben auch der adressierte SIP-Stack entscheidet, auf welche Messages er dann reagiert. DAS ist dann auch eine Stelle, wo man Software entsprechend härten sollte/muß - denn (siehe Deine eigenen Erfahrungen) eine versehentliche oder - sogar wahrscheinlicher - eine absichtliche Konfiguration einer Portweiterleitung trifft dann vielleicht wirklich mal mit einer verwundbaren Software zusammen, wenn man das (Härten) unterläßt, weil man sich darauf verlassen will, daß schon irgendeine andere Software dafür sorgt, daß da nichts durchkommt, was "böse" sein könnte.
Spätestens wenn man sich dann mal überlegt, daß SIP-Stacks in aller Regel "dual-use" sind und in derselben Implementierung sowohl auf der UAC- als auch auf der UAS-Seite zum Einsatz kommen, wird auch glasklar, daß ein "geschlossener" SIP-Port auf der WAN-Seite eines Edge-Routers auch nur ein "Sichtschutz" für einen verwundbaren SIP-Stack, der z.B. auf dem SOHO-Router noch interne SIP-Clients bedienen könnte oder wo jemand sich eine kleine "Telefonanlage" gebastelt hat, wäre - Angriffen von "innerhalb" der Firewall wäre der dann IMMER NOCH ausgeliefert, ebenso natürlich auch der Stack bei einem UAS, der sich ohnehin nicht durch eine "Firewall" gegen eingehende Pakete von unbekannten Quellen abschirmen kann.
Da DARF dann also eine Argumentation "contra Portfreigabe" nicht am Ende dazu führen, daß damit das Thema schon erledigt ist ... der "gehärtete" SIP-Stack ist GENAUSO eine Notwendigkeit - und was passiert denn eigentlich mit dem, wenn man dessen Sicherheit (oder das Aktualisieren der Software) "vergißt", WEIL man der Ansicht ist, daß da ja schon keine "bösen" Pakete ankommen würden, da man ja eine Firewall davor hat?
Eine Firewall IST also nur EIN Teil der Lösung und hilft auch nicht "gegen alles" und "in jedem Szenario" ...
Jedenfalls nicht ohne zusätzliche Software - irgendwo hier habe ich mal erzählt, wie ich meinen Asterisk-Server (zum Verbinden von Standorten) durch dynamische Freigaben in einer iptables-Chain, wo auf ipset-Tabellen zurückgegriffen wird, nur für DIE Absenderadressen freigebe, für die eine aktuelle DynDNS-Registrierung durch eine FRITZ!Box (wobei das nur wg. der einfachen Handhabung AVM-Geräte bei den Clients sind, die Lösung ist schon "allgemeiner" ausgelegt) erfolgt ist und die Einträge in diesen Tabellen (verfallen ja bei passender Konfiguration automatisch nach einer eingestellten Zeit) werden alle 15 Minuten "aufgefrischt":
Rich (BBCode):
-A INPUT -m policy --dir in --pol ipsec --proto esp -j input_dmz
-A INPUT -p udp -m udp --dport 53 -m string --hex-string "|03697363036f726700|" --algo bm --to 65535 -j SET --add-set banned_ipv4 src --exist
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m conntrack --ctstate RELATED -j ACCEPT
-A INPUT -m set --match-set dyn_ipv4 src -j ACCEPT
-A INPUT -m set --match-set dyn_ipv4ext src,dst -j ACCEPT
-A INPUT -i tap0 -j input_dmz
-A INPUT -p udp -m udp --dport 123 -j SET --add-set banned_ipv4 src --exist
-A INPUT -p tcp -m tcp --dport 22 -j SET --add-set banned_ipv4 src --exist
-A INPUT -p tcp -m tcp --dport 137 -j SET --add-set banned_ipv4 src --exist
-A INPUT -p tcp -m tcp --dport 139 -j SET --add-set banned_ipv4 src --exist
-A INPUT -p tcp -m tcp --dport 445 -j SET --add-set banned_ipv4 src --exist
-A INPUT -p tcp -m tcp --dport 135 -j SET --add-set banned_ipv4 src --exist
-A INPUT -m set --match-set banned_ipv4 src -j DROP
-A INPUT -m policy --dir in --pol ipsec --proto esp -j input_dmz
-A INPUT -i eth0 -j input_ext
-A INPUT -i eth1 -j input_ext
-A INPUT -i tap0 -j input_dmz
-A INPUT -i ipsec0 -j input_dmz
-A INPUT -j LOG --log-prefix "SFW2-IN-ILL-TARGET " --log-tcp-options --log-ip-options
-A INPUT -j DROP
Das ist die "INPUT"-Chain (da wird tatsächlich noch iptables verwendet und es gibt natürlich auch die IPv6-Pendants der Rules) - neben den dynamischen Freigaben (grün) sieht man auch die "dynamischen Sperren" auf "well-known ports", wo die "Angreifer" erst ab Layer5 und darüber erkannt werden kännen, weil manche Ports nun mal auf sein MÜSSEN und natürlich auch einen Service dahinter haben müssen, denn ich würde schon gerne SSH auch dann weiterhin verwenden können (von beliebigen Quelladressen aus), wenn es immer wieder Login-Versuche (die kennwort-basiert ohnehin nicht funktionieren) von irgendwelchen Gegenstellen registriert werden (und das ist natürlich auch "ständig" der Fall, wie auch JEDEM anderen Server im Internet auch). Auf einem solchen Weg KANN man dann auch bei offenem Port dafür sorgen, daß "Sicherheit" eine Kombination aus mehreren Maßnahmen ist, wenn es nun mal keine Alternative zu "offenen Ports" gibt.
Gleichzeitig wird bei einer DynDNS-Registrierung auch geprüft, ob diese aus einem plausiblen AS kommt (leider KANN man sich auf Reverse-DNS auch nich mehr verlassen, weil viele Verantwortliche das nicht richtig pflegen) und nicht aus den USA, China, (Weiß-)Russland oder der Ukraine - von wo nach meinen Lags (schon seit mehreren Jahren ausgewertet) die meisten "Angriffsversuche" ausgehen.
Aber das nur am Rande ... und um zu argumentieren, daß man mit zusätzlichem Aufwand natürlich auch eine passende "Firewall" vor einen (in Maßen) UNSICHEREN SIP-Stack bauen KANN (wenn der nicht schon vor der erfolgreichen Registrierung oder für nicht authentifizierte Messages anfällig ist), wobei das meinerseits eben auch nur "Vorsichtsmaßnahmen" sind, denn konkret bei der verwendeten Software für den SIP-Server sollte auch diese schon selbst dafür sorgen, daß da nichts weiter passiert.
Eine "smarte" Firewall mag in dem konkreten Szenario nach #1 hier nicht helfen bzw. wäre Overkill, aber neben der konkreten Situation und
@81Tom ging es ja dann zunehmend nicht mehr nur um diesen konkreten Fall (ja, die konkreten "Umstände" wurden ja immer mehr ignoriert bei den Vorschlägen zum "Eingrenzen" des Problems), sondern um eine "Haltung" zu Portfreigaben (da kam dann auch
@chrsto erst ins Spiel) im VoIP-/SIP-Kontext generell.
Insofern trenne ich das auch selbst (in den Beiträgen habe ich es zumindest versucht) in "die konkrete Situation" und die sonstigen Aussagen, wo für mich schon mit dem allerersten Satz (in #3):
Sipgate schickt normal von sich aus ein Double-CRLF, ein Keep-Alive um das NAT aufrecht zu erhalten.
eine Behauptung (meinetwegen auch "Theorie") stand, die dann später noch mehrfach bekräftigt wurde, die ich so aber nicht nachvollziehen mochte (und das bei entsprechender Kontrolle auch nicht konnte).
Dennoch wurde um diese Theorie herum dann eine "Strategie" zur Fehlersuche konstruiert, die weder plausibel noch erfolgversprechend war (und das für mich immer noch nicht ist) und wo gleich noch mal bekräftigt wurde:
Aber nein, Sipgate schickt sein Double-CRLF sowohl in IPv4 als auch IPv6. Daher müsste das eigentlich tun. Ich habe ja nichts gegen Herumgerate.
Angesichts dieser "Behauptungen", die sich - zumindest bei mir in einem Test, den ich dann halt mache, BEVOR ich Aussagen anderer in Zweifel ziehe - als falsch herausstellten, frage ich mich halt, was DARAN dann kein "Herumgerate" sein sollte, wenn man aus dem Fehlen von Daten, bei denen noch nicht mal geklärt ist, ob sie überhaupt da sein MÜSSTEN, dann am Ende Schlußfolgerungen ziehen wollte:
zumal man auch mit einem Wireshark-Mitschnitt NICHT sehen würde, warum bzw. ob EINGEHENDE SIP-Pakete an der Firewall im Router scheitern
Was sieht man eigentlich, wenn da von der sipgate-Seite KEINE Pakete (die von Dir postulierten CRLF) kommen, die den Tunnel offen halten? Woran erkennt man dann die Ursache für deren Fehlen? Wie sieht man in einem solchen Mitschnitt dann, WANN genau die Firewall die UDP-Verbindung wegen des Timeouts abräumt oder ob die noch offen wäre und nur KEINE Pakete kommen? Wie könnte man aus dem Fehlen von Paketen auf die Ursachen für dieses Fehlen schließen?
Und vielleicht sollte ich auch noch mal darauf hinweisen, daß ich in #2 zunächst mal meinerseits nur versucht habe zu erklären, WIESO das Problem auftreten sollte (für meine Verhältnisse sogar in ungewöhnlich dürren Worten) und daß eine Portweiterleitung "Abhilfe schaffen dürfte". Das ist zunächst auch mal nur ein Vorschlag, WIE man das Problem eingrenzen könnte ... und WENN sich dann herausstellen sollte, daß es tatsächlich an einer "sich schließenden Firewall" liegt, dann kann man sich weitere Maßnahmen dagegen überlegen - meinetwegen auch Keepalives, sofern der Client das tatsächlich unterstützt.
Dabei jetzt darauf zu beharren, daß eine Verwendung von Keepalives hier jetzt die EINZIG MÖGLICHE Lösung sein soll, DAS ist es, was ich meinerseits so nicht stehen lassen will und worauf dann die (anschließende) Frage zielte, wieso bei VoIP/SIP (und auch hier wieder nicht auf die konkrete Situation bezogen, sondern als "allgemeine These" formuliert, generell keine Portforwardings notwendig sein sollen. Auch nicht zum ersten Mal als "These" geäußert (und IMMER so wenig differenziert - nur meinerseits dann auch ignoriert, wenn es nicht im direkten Widerspruch (ohne ausreichende Begründung) zu meinen Aussagen steht) und "pauschal" (obwohl so mehrfach niedergeschrieben, auch in anderen Threads) eben einfach FALSCH.
Kommen wir noch mal auf Deine (
@IEEE) Aussage mit der "Freeware" hinter einem offenen Port zurück (hier geht es mir dann auch nicht mehr um die konkrete Frage in #1, sondern um die (von Dir vorgebrachten) Argumenten, WARUM man keine Portweiterleitungen nutzen sollte - die ich zum Teil auch unterschreibe, wenn sie sich tatsächlich (mit vertretbarem Aufwand, denn auch den Luxus tatsächlich möglicher Alternativen (jenseits von reinen "Theorien", wie das eigentlich laufen SOLLTE), muß man sich erst einmal leisten können) vermeiden lassen, nur schließe ich sie eben nicht generell aus.
Auch eine These ("nicht gegen Sicherheitslücken immun") ist für mich (ohne zusätzliche Bedingungen) so nicht 100% zu unterschreiben, wenn man's wieder nicht nur als "Meinung", sondern als Begründung für die (generelle) Ablehnung von offenen Ports versteht (wie den letzten Absatz in #22).
Wobei hier ja zumindest noch "vermieden werden" steht im letzten Absatz und nicht "nie benutzt werden" - das erkennt ja - nach meiner Lesart - immerhin noch an, daß es Szenarien gibt, wo das eben NICHT vermieden werden KANN. Und - nebenbei - auch in der Realität gar nicht vermieden WIRD, solange man sich nicht sein gesamtes Netzwerk selbst von Hand mit OpenSource-Komponenten zusammenklöppelt, deren Quellcode man zuvor einen "review" unterzogen hat. Irgendwo MUSS man dann halt auch mal eine Grenze ziehen, wir sind nicht mehr in den 80ern und bei MS-DOS (oder einem anderen OS der damaligen Zeit, damit die sich nicht marginalisiert fühlen vom "IBM-PC"), wo man "alles unter der eigenen Kontrolle" haben konnte (und auch damals war das für die Allermeisten schon ein Trugschluß, auch ohne Netzwerk-Verbindungen). Irgendwo MUSS dann auch mal ein Vertrauen einsetzen, was man auch nicht mit "fehlender Vorsicht" gleichsetzen muß/sollte.
an einer Freeware Software auf einem Windows Rechner aufschlägt
Und warum eigentlich nur auf einem "Windows Rechner"? Windows hat - wie viele andere OS auch - mittlerweile auch seit vielen Jahren seine EIGENE Firewall, durch die auch nur dann "Löcher" gestanzt werden (sollten), wenn da ein entsprechendes Programm installiert wurde UND das von dem Benutzer freigegeben wurde ... und spätestens als "second line of defense" (in "untrusted networks" ja sogar die "first line") ist das auch ganz richtig so.
Mit der Argumentation "wird dann gerne mal vergessen und dann läuft da alte Software jahrelang weiter", könnte man die Freigabe von Ports für eingehende Verbindungen GENERELL verdammen - ich gehe jede Wette ein, daß in den allermeisten Windows-Installationen (wobei das problemlos auch für andere Systeme gilt, wo DER BENUTZER (oder ein neu installiertes Programm mit dessen Erlaubnis) eine Freigabe einrichten kann und das getan hat) noch jede Menge überflüssiger Einträge von längst deinstallierter Software vorhanden sind.
Aber auch die SIND nun mal - solange da nicht wirklich eine veraltete und/oder unsichere Software auch zum EMPFANG entsprechender Pakete bereit ist - einigermaßen "harmlos" - sprich: Eine Portweiterleitung (selbst eine vergessene) wird auch nur DANN zum Problem, wenn da noch so einiges an "Randbedingungen" gleichzeitig erfüllt ist (was auch kein Plädoyer dafür ist, generell keine Ports mehr zu filtern oder UNNÖTIGE Freigaben zu machen) - bis hin zu "alternativen Maßnahmen" der Netzwerk- und/oder Computer-"Hygiene", wie eben regelmäßige Updates und der Austausch von Software, die nicht länger gewartet wird (so man sich das auch leisten kann - sowohl ökonomisch als auch faktisch, weil es Alternativen gibt).
Der Aspekt einer "unsicheren Implementierung" eines kompletten Netzwerk-Stacks ist damit zwar auch noch nicht vom Tisch ... aber auch hier ist die Annahme, daß der NUR dann Auswirkungen haben könne, wenn es um EINGEHENDE Verbindungen geht und nicht um Pakete als Antwort in einem "ausgehenden" Tunnel durch einen Firewall, ja unzulässig bzw. von der Realität widerlegt. Daraus wird ja auch keiner ableiten, daß man jetzt generell Netzwerkverbindungen "vermeiden" sollte, weil durch die halt IMMER ein Potential für Angriffe entsteht.
Denn daß auch "Windows" vs. "freie/quelloffene Software" (oder meinetwegen - wenn auf OS-Ebene - auch gleich "Linux") auch KEIN Garant für 100% Sicherheit ist (selbst nicht bei offengelegten Quelltexten), hat uns (so lange ist das iirc noch gar nicht her - zwei oder drei Jahre) die SACK-Lücke im Linux-Kernel(!) (bzw. im TCP-Stack, der aber auch noch VOR einem SIP-Stack auf Layer5 sitzen würde) gezeigt - insofern ist man NIEMALS vor etwas wie:
letztendlich weiß man aber nie ob mal ein Bug oder ein Buffer Overlfow im SIP Stack der eingesetzten Software ist
gefeit - nicht mal VOR Layer5, wo dann der SIP-Stack erst ins Spiel kommt.
Das gilt (nebenbei) für viele andere Geräte auch ... und die hängen dann teilweise "direkt im Internet", wenn man nur mal über ein Smartphone (mit öffentlich erreichbaren Adressen) nachdenkt. Auch die dort verwendete Software ist (zu einem erheblichen Teil, Android basiert bekanntlich auf einem Linux-Kernel:
https://source.android.com/devices/architecture/kernel) "Freeware" ... der vielleicht entscheidende Unterschied mag dann hier (zum Phoner Lite zumindest) darin bestehen, ob die Quellen dafür auch offengelegt sind oder "einsehbar" wären (m.W. bei Phoner Lite nicht - ich habe einfach mal eine Frage dahingehend an den Autoren geschickt).
Denn damit WEISS man auch für Phoner Lite bisher gar nicht, ob da nicht vielleicht ein ebenso gut "abgehangener" SIP-Stack benutzt wird, wie bei vielen anderen Paketen - PJSIP wäre ja auch für ein Windows-Programm durchaus eine denkbare Option ... das Projekt gibt es auch mind. seit 2003.
Aber auch offengelegter Quelltext oder "gut abgehangene Komponenten" (das meint nicht alt, sondern "häufiger eingesetzt") sind ja noch keine Garantie ... außerdem gibt es da dann genügend "unsichere Kantonisten" bei der verwendeten Software (aka Apps), denen man dann ebenso kritisch gegenüberstehen müßte. Ich ziehe meinen Hut vor jedem, der DAS dann auch tatsächlich schafft - aber nach meiner Erfahrung endet eben das "alles unter Kontrolle haben wollen" in den allermeisten Fällen spätestens dann wieder, wenn damit eigene Einbußen beim "Nutzererlebnis" verbunden sind. Wer bitte KENNT denn den SIP-Client (oder die nachinstallierte App mit einem solchen) und die darin benutzte Implementierung eines SIP-Stacks näher?
Und was für ein wunderschönes Beispiel GEGEN eine Theorie, daß offengelegte Quellen und häufige Benutzung (von "Komponenten") durch andere automatisch vor Fehlern in der Implementierung (oder auch nur in der Benutzung) einer "Standardkomponente" schützen würden, war erst vor kurzem doch der Fall mit "log4shell" ... auch das ist also KEIN effektiver Grund dafür, warum man Sicherheit NUR AN EINER STELLE denken sollte ... und das dann in der Form: ALLES ABBLOCKEN.
Bei aller - zweifelsfrei auch gebotenen - Vorsicht ... ein:
dass ein Portforwarding ganz allgemein (temporär für die Fehlereingrenzung ausgenommen) vermieden werden sollte.
gilt eben auch nur DANN, wenn man das in den richtigen Kontext setzt - meinetwegen noch mit dem Zusatz "auf einem SOHO-Router in einem privaten Haushalt/Netz" (schon das reicht eigentlich nicht wirklich) und eigentlich sogar noch mit einem "manuell zu setzende, permanente Portfreigaben" ... und auch dann noch immer in dem Kontext, daß es - mit der vorhandenen "Technik", sowohl was Hard- als auch Software angeht, auch tatsächlich eine andere Lösung mit vertretbarem Aufwand gäbe.
Denn spätestens dann, wenn eine Portfreigabe von einem Client per PCP angefordert wird und dazu dieser Client auch erst einmal laufen muß, ist eine simple Bezeichnung "Portforwarding" auch nicht mehr ausreichend. Es gibt dabei (eben mit dem Port Control Protocol - RFC 6887 - und dessen Integration in das IGD-/IGD2-Interface - RFC 6970) auch AKTUELLE Standards, die sich dem Thema "Portfreigaben" hinter "stateful firewalls" und/oder "NAT routers" widmen (und es gab auch Vorläufer, wie NAT-PMP, was in RFC 6886 (unmittelbar vor PCP) noch "zur Dokumentation" hinterlegt wurde) ... es GIBT also durchaus einen Bedarf und auch Lösungen für Techniken, die Portfreigaben explizit ERMÖGLICHEN sollen.
Wenn sich alles ständig immer ohne solche Freigaben lösen ließe, bräuchte man solche Initiativen ja auch nicht, oder? Das "verbietet" es einem natürlich dennoch nicht, Portfreigaben "nicht zu mögen" und - wenn man freie Hand bei der Auswahl hat - auch zu vermeiden. Aber es gibt - in meinen Augen - eben auch Argumente DAFÜR ... den SIP-Stack, der ohnehin gehärtet sein sollte/muß, habe ich oben schon angeführt und die geringere Komplexität (auch für den SIP-Stack und den Rest der Software, in der dieser verwendet wird), wenn RFC 5626 NICHT implementiert werden müssen (das ist immer noch optional(!)), ist (wieder für mich) ein weiteres Argument GEGEN die (ständige/zwangsweise) Verwendung von Keepalive-Mechanismen nach RFC 5626, wobei sich manches eben OHNE Portfreigaben UND OHNE Keepalives nicht realisieren LÄSST.
@chrsto:
Ich hatte
@sonyKatze gefragt (
https://www.ip-phone-forum.de/threads/phonerlite-mit-sipgate-über-vodafone-kabelrouter-eingehende-anrufe-funktionieren-nur-gelegentlich.312818/post-2471604), worauf seine Behauptung, Portfreigaben seien bei VoIP/SIP generell nur ein Workaround und keine Lösung, eigentlich beruhen soll - auf die "undifferenzierte Sicht", die gar nicht erst zwischen Server (Registrar) und Client unterscheidet, braucht man dabei noch nicht mal eingehen ... es reicht schon, wenn man sich GENAU ansieht, wie die Mehrzahl(?) der SOHO-Router tatsächlich arbeitet, die (meinetwegen auch nur in D) als SIP-UAC mit dem Registrar beim Provider arbeiten.
Daraufhin hat er (oder sie - bei einer "Katze" ist das schwer zu entscheiden, spielt ja auch nicht wirklich eine Rolle) dann hier:
https://www.ip-phone-forum.de/threads/phonerlite-mit-sipgate-über-vodafone-kabelrouter-eingehende-anrufe-funktionieren-nur-gelegentlich.312818/post-2471624 auf einen eigenen Beitrag verlinkt und danach noch "nachgetragen":
Nur soviel: Der Verweis zeigt auf ein Zitat von @chrsto , der das genauso sieht wie ich.
Was genau verstehst Du denn jetzt nicht an der Frage, was Dich so aus der jeweiligen "Masse" der Proponenten oder Opponenten für die Ansicht, daß Portweiterleitungen "pfui" (für die einen ein "Werk des Teufels") oder "hui" (für andere eben doch eine Lösung - und praktisch auf Schritt und Tritt anzutreffen in deutschen Haushalten) seien, hervorhebt, daß DU (und zusammengezählt sind auch
@IEEE,
@chrsto und
@sonyKatze dann eben auch erst einmal "nur
zwei drei") (EDIT: Ja, ich kann offenbar nicht mal bis drei zählen.) nun als "Beleg" für die Korrektheit dieser Behauptung herhalten könntest.
Dazu MUSS man auch nicht an Standards mitgewirkt haben - das ist ja deutlich Blödsinn und das "verlangt" auch niemand. Aber sofern Dich nicht spezielle Kenntnisse und Fähigkeiten jetzt zu einer "Institution" in Fragen der Router-Sicherheit machen, bist Du (bitte auch nicht falsch verstehen) auch NUR eine weitere Stimme mit einer Meinung - die kann man zur Kenntnis nehmen, aber sie zählt damit dann nicht mehr (aber natürlich auch nicht weniger) als alle anderen und als "Quellenangabe" würde ich eine solche Meinung jetzt nicht direkt werten. Und um keine Mißverständnisse aufkommen zu lassen - das gilt nicht nur bei Dritten, das gilt genauso für mich selbst - ich würde mich auch nicht als "Beleg" für eine Behauptung anführen, sondern immer die "originale" Quelle - daher auch mein Verweis weiter oben, daß ICH eben nicht auf mich selbst und meine eigene "Meinung" referenziert habe.
Mag ja sein, daß Deine Meinung jetzt bei
@sonyKatze besonderen Eindruck hinterlassen hat - für mich Anlaß zur "Nachfrage", ob es dafür einen Grund hätte geben können ... die Antwort darauf hätte das ja erklären können bzw. sie hat ja jetzt so weit Licht ins Dunkel gebracht, daß das halt DEINE Meinung ist - die kann man jetzt teilen oder auch nicht.
Zählt man dann die von mir schon weiter oben verlinkten Quellen, wo Portweiterleitungen sehr wohl auch als Lösung beschrieben werden (und sei es als "ultima ratio") und meinetwegen noch meine eigenen Ansichten zusammen (die auch keinesweg IMMER "pro Weiterleitung" sind, ICH kann da je nach Notwendigkeit und/oder Komplexität der Situation differenzieren), sind das schon mal
doppelt soviele mehr "Quellen" (läßt man
@sonyKatze und mich aus der Rechnung raus, sind es
sogar dreimal soviele immer noch mehr):
NAT bezeichnet das Übersetzen von Netzwerkadressen und ist ein wichtiges Verfahren zur Verbindung eines lokalen Netzwerks mit dem Internet.
www.3cx.de
NAT (Network Address Translation) is a technology used by firewalls and routers to allow multiple devices on a LAN with 'private' IP addresses to share a single public IP.
www.voip-info.org
lite.phoner.de
und mindestens diese drei Links oben stammen ja jetzt auch nicht von Leuten (bzw. Firmen), die von der Thematik so GAR KEINE Ahnung haben und auf der "Brennsuppn" dahergeschwommen kamen. Da kommen dann noch die Leute hinzu, die an Software mitwirken, in der es SEHR WOHL auch Features wie Portfreigaben GIBT, die man eben auch für SIP benutzen kann und die in der Firmware der jeweiligen Geräte auch genau für SIP (und RTP) benutzt WERDEN.
Daher meine Frage nach Deinem "Hintergrund" - und ich denke mal, daß auch Du den Unterschied verstehen wirst, ob eine "andere Meinung" nun von jemandem geäußert wird, der sie halt hat oder ob er sie noch (plausibel) begründen kann (und will) und nachweislich mehr "Expertise" bei dem Thema haben sollte oder könnte, weil er sich z.B. beruflich damit befassen muß.
Genauso kann man natürlich auch die abgegebene Begründung "Sicherheitsbedenken" so hinnehmen - aber man kann auch dagegen argumentieren und zeigen, daß sogar sehr viele SOHO-Router, die auch noch Telefoniefunktionen bieten, genau so arbeiten und spätestens als Edge-Router gar keine Keepalives nach RFC 5626 verwenden (wenn's nichts offen zu halten gilt, braucht's auch keine Keepalives), sondern mit "open ports" ausgerüstet sind.
Ich habe gerade keinen Zugriff auf einen Speedport-Router (weil wir ja bei Argumentationen in Verbindung mit der Telekom waren, wobei da auch AVM-Geräte "zertifiziert" sind für die Benutzung an DSL-Anschlüssen der Telekom - man sollte also annehmen dürfen, daß auch deren Firmware so weit den Telekom-"Richtlinien" entspricht, daß sie diese Weihen erhalten konnten), aber ich würde wetten, daß auch da der Port 5060 aus dem "SIP-Standard" zum SIP-Stack auf dem Gerät hin freigegeben ist und erst der Stack dann wieder dafür zuständig ist, ungültige Messages auszusortieren.
Aber blicken wir doch zurück auf die Router-Software und deren Features bzw. Autoren ... es MUSS also offenbar einen Bedarf für Portweiterleitungen geben, wenn das jemand implementiert (nicht alles ist so nutzlos bzw. "rarely used", wie die LISP-Implementierung von AVM im FRITZ!OS). Und so pauschal, wie Du das dann auch selbst formuliert hast:
Ja, ich halte Portweiterleitungen bei VoIP für falsch.
stimmt es ja - offensichtlich - nicht mal für "VoIP" ... auch da gibt es ja nicht nur "eine Richtung" (vielleicht hast Du das Differenzieren ja auch nur vergessen), wo hinter einem DSL-Router nur noch UAC stehen DÜRFEN. Aber unterstellen wir mal, daß Du das halt "meintest" und es nur nicht ausformuliert war.
Denn spätestens dann, wenn ich meinen eigenen Registrar (für UAC auf der WAN-Seite eines Routers mit NAT oder auch "nur" mit einer "klassischen" Firewall, die nur definierten "ingress traffic" passieren läßt) betreiben will, MUSS ich auch entsprechende Weiterleitungen einrichten und - um wieder auf ein "UAC-Szenario" zu kommen - wenn ich Besitzer eines (meinetwegen auch älteren) SIP-Telefons bin, was eben KEIN Feature zum Offenhalten einer ausgehenden SIP-Verbindung hat (weil es vielleicht ursprünglich nur mit einem Registrar im LAN und ohne Firewall dazwischen funktionieren sollte) und weder ein SBC noch ein ALG zur Verfügung stehen und auch kein Outbound-Proxy, dann ist es schon sehr billig, einfach zu empfehlen: Besorg Dir halt vernünftige Technik oder einen anderen Anbieter.
Und ganz ehrlich - an der Stelle hast Du Dich dann (für mich jedenfalls) auch nicht wirklich mit Ru(h)m bekleckert. Ein
Deine (deine, nicht Deine) Software/Hardware unterstützt das nicht? Pech gehabt, nehme ich etwas anderes. Der Provider setzt es voraus? Nimm einen anderen.
ist zwar als "eigener Standpunkt" akzeptabel, aber kaum als Hilfe oder Handreichung für andere bei der Suche nach einer Lösung, die eben NICHT immer so einfach sein muß oder kann, wie Du das dann offensichtlich gerne "lösen" möchtest - mithin für andere auch nicht wirklich hilfreich.
Das klingt dann doch sehr nach Marie-Antoinette ... was kümmern einen die Probleme anderer, sollen sie sich halt bessere Technik oder bessere Anbieter suchen (oder eben Kuchen essen). Oft hat man eben auch keine Wahl und muß mit vorhandenen Ressourcen arbeiten und dennoch eine Lösung finden - jedenfalls solange man in der Realität unterwegs ist und nicht in einer Märchenwelt, wo auch ein kompletter Neuaufbau einer Infrastruktur "gar kein Problem" ist und ohnehin nur "optimale Lösungen" akzeptabel sind (die sich vermutlich in zwei Jahren auch schon wieder überlebt haben).
Dabei mußt DU dann zwar auch anderen nicht helfen (wollen) bei ihren Problemen, aber zumindest kann man damit dann auch besser einschätzen, wieviel Gewicht man Deiner Ansicht einräumen sollte - wenn man vielleicht nicht so ohne weiteres "aus dem Vollen schöpfen" kann.
Ein ordentlich implementierter und konfigurierter SIP-Stack kümmert sich dann aber wieder selbst darum, daß auch ein "offener" SIP-Port, der also aus dem Internet FÜR JEDEN erreichbar ist (was für viele IAD auch gilt, sofern die als Edge-Router auch noch SIP-Funktionen implementiert haben), keine wirklich große Gefahr darstellt.
Wenn der per se schon nur noch auf authentifizierte Sessions oder zumindest plausible und bei ihm auch konfigurierte URIs beim Neuaufbau einer Session reagiert und den Rest verwirft, dann ist das auch nur noch in Details etwas anderes, als wenn eine vorgelagerte Firewall alles abweist, was nicht von einer "bekannten" Adresse kommt. Ich habe mir mal den Spaß gemacht und in 1TR114 der Telekom (
https://www.telekom.de/hilfe/downloads/1tr114.pdf - Stand 12/2019) nach RFC 5626 (das hat die Referenznummer [68]) gesucht ... die Stellen, wo das tatsächlich referenziert wird (Abschnitt 4.2.7.3.5), befassen sich mit Retry-Timern für den Fall, daß zwei REGISTER-Versuche nacheinander nicht erfolgreich waren.
Aber auch zum "Reliable SIP & RTP Processing" steht in 1TR114 ja etwas (in Abschnitt 4.2.10) und zwar:
The device shall only process SIP requests, received on its WAN interface, from P-CSCF source IPs (IPv4 or IPv6) which the Telekom VoIP account of the device is successfully registered to.
Das würde ja jetzt (mal abgesehen von einem "shall" anstelle eines "must") dafür sprechen, daß nur von einer einzigen IP-Adresse bei der Telekom weitere SIP-Messages kommen soll(t)en, wenn das UE nur eine Registrierung macht und der SIP-Stack des Gerätes dann auch sicherstellen SOLL, daß er nur Messages von DIESEM Registrar verarbeitet.
Nur steht in demselben Abschnitt dann auch weiter (im Kontext der von mir weiter oben schon mal angeführten "multiple registrations", damit es keine "Lücken" in der Erreichbarkeit gibt):
In addition the device shall handle multiple registered conditions in edge scenarios, to process SIP requests from P-CSCF source.
[...]
Additionally, all P-CSCF source IPs (IPv4 or IPv6) which are successfully resolved, based on device DNS resolution e.g. via SRV / AAAA / A records, are valid for P-CSCF source IP request processing. (under consideration of the TTL).
Das verwirrt mich jetzt wieder (ich habe auch keinen Telekom-Anschluß und im Moment auch keinen Zugriff auf einen, kann also die DNS-Auflösung nicht selbst prüfen), denn das klingt ja danach, als dürfe mit einem UA (bei der Telekom bzw. ja wohl ursprünglich bei der 3GPP halt "UE" für "User Equipment") auf einem Edge-Router dann wieder ein bunter Strauß an IP-Adressen (als "P-CSCF source IP") als Absender einer SIP-Message auftreten.
Spätestens dafür bräuchte es ja ebenfalls wieder eine "ständige" Portfreigabe in einer vorhandenen Firewall (vielleicht auch wieder mit Limitierung der Source-IPs auf die "gelernten" per DNS-Abfragen - was Du ja auch als "zu komplex" ablehnst, aber vielleicht trifft das ja auch nur auf "händische" Einrichtung zu?), damit auch von anderen IPs als dem "aktuellen Registrar" für eine Session, entsprechende SIP-Messages den Stack erreichen können - denn es sollen ja "all [...] source IPs [...] valid" sein, wobei das offenbar auch nur gilt, solange die TTL in den DNS-Records nicht abgelaufen ist - was dann für eine "dynamische Konfiguration" der Portfreigabe für den SIP-Port auch eine deutlich größere Herausforderung sein dürfte, als wenn das erst der SIP-Stack prüft, wenn er eine Message validieren soll.
Oder kommt da tatsächlich immer nur exakt eine Adresse zurück? Wenn ich's richtig verstanden habe, ja wohl nicht - auf eine Abfrage für einen SRV-Record (nachdem die "Verbindungsarten" per NAPTR-Response angeboten wurden) sollen auch mehrere Antworten möglich sein (dann halt mit Prioritäten, wobei sich das UE wohl trotzdem einen DNS-Namen aussuchen darf, denn der mit der höchsten Priorität kann ja auch mal nicht erreichbar sein) und wenn die Abfrage nach den Namen aus dem SRV-Record dann mehrere IP-Adressen enthält (ggf. kann sich das UE dann auch das IP-Protokoll noch aussuchen, wobei es nach 1TR114 dann IPv6 bevorzugen soll), dann dürfen - nach dem letzten zitierten Absatz? - auch von JEDER dieser Adressen weitere SIP-Messages kommen?
Wenn ich da jetzt nicht etwas fundamental falsch gelesen habe, würde es mich sehr wundern, wenn Telekom-Router wie die Speedports am Ende tatsächlich NUR mit Keepalives arbeiten und keine Portforwardings zum SIP-Stack nutzen, der dann erst entscheidet, ob ein Paket nun gültig ist oder nicht.
Und es gibt eben immer noch Funktionen (auch bei "VoIP", selbst wenn man das auf SIP/RTP beschränken würde), die OHNE solche freigegebenen Ports gar nicht funktionieren KÖNNEN und ebenso viele Geräte als IAD, die das exakt so auch machen mit ihren "Portfreigaben". Auch wenn ich derartiges für einen SIP-Port auf einem IAD als SOHO-Router mit SIP-Funtionen nicht EXPLIZIT eintragen muß, haben diese Geräte dennoch in aller Regel auch ihrerseits Port 5060 "ins Internet" geöffnet - nur antworten sie halt "nicht jedem" und wenn sie "richtig gut" sind, blockieren sie Pakete von erkannten Angreifern (auch auf die Gefahr des "overblockings" hin, wenn da jemand Absenderadressen bei UDP fälscht) auch bei entsprechend "massiven Belästigungen".
Man kann (bei manchen IADs und da kann man dann auch in "Allgemeines" mal wieder die Geräte erwähnen, die in D in den meisten Haushalten arbeiten) sich das sogar "ansehen" (bei FRITZ!Boxen dann in der Seite "Sicherheit"), welche Ports da "offen" sind (das gilt sogar wieder für die 20 Ports, die für RTP-Verbindungen vorgesehen sind - standardmäßig Port 7078 bis 7097) und das ist dann (für mich zumindest und als "Meinung" der Entwickler bei AVM in Form der veröffentlichten Firmware) auch wieder eine weitere "Quelle" dafür, daß Portweiterleitungen AUCH BEI SIP/RTP durchaus vollkommen "normal" sind.
Wer es schafft, sich die Support-Daten einer FRITZ!Box ausgeben zu lassen (sofern er eine hat - dafür MUSS man sich jetzt nicht extra eine anschaffen), der kann da - wenn er das nur lange und/oder oft genug macht - auch sehen, daß natürlich in so einem Fall auch ständig irgendwelche "illegalen" Kontaktversuche auftreten ... solange der SIP-Stack die nur protokolliert und sie ansonsten ignoriert (es braucht für eine negative Antwort zumindest mal die Kenntnis einer gültigen SIP-URI auf der Box), sehe ich nicht wirklich, wieso eine "Portfreigabe" (ob die "extern" oder innerhalb des Gerätes wirkt, unterscheidet sich ja nur darin, wo dieser SIP-Stack letztlich zu finden ist) per se "gefährlich" sein soll "für die Sicherheit".
Liegen tatsächlich all die Entwickler der entsprechenden Firmware für diese Geräte auch so furchtbar daneben, nur weil sie es sich erlauben, ihre Software (hoffentlich jedenfalls) an der RICHTIGEN Stelle zu härten? Es dürfte auch unstrittig sein (dazu reicht schon der Blick in die Spezifikationen, zumal mit einer "Freigabe" auch mehr Szenarien abgedeckt werden, als mit Keepalive-Techniken bei "SIP-OUTBOUND"), daß weniger Komplexität in einer Software auch die Wahrscheinlichkeit für Fehler, die sich ansonsten aus ebendieser Komplexität ergeben, senkt - daher lieber eines richtig machen (nämlich einen sicheren SIP-Stack, ggf. noch mit einer Traffic-Limitierung, um Floodings zu vermeiden - der kann üblicherweise auch gleich für UAC- UND UAS-Features genutzt werden, wenn "interne Clients" noch an einem Registrar auf dem IAD angemeldet werden sollen), als irgendwelche Features implementieren, die man eigentlich gar nicht wirklich braucht.
Auch wer Router mit einer passenden Software (die PCP implementiert hat) kaskadiert (speziell wieder AVM-Geräte, weil es nicht so viele andere mit einigermaßen ausgereiftem PCP-Support gibt, soweit ich weiß) und an einem Gerät in dieser Kaskade dann Telefonie-Funktionen aktiviert, wird (sofern die automatische Einrichtung von Portfreigaben erlaubt ist - auch und GERADE für IPv6-Adressen auf oder HINTER dem kaskadierten Router) auch automatisch eingerichtete Freigaben entdecken ... da jucken die jeweiligen Entwickler dann offenbar die "Sicherheitsbedenken" einiger Kunden (selbst wenn jemand die Geräte vielleicht genau deshalb NICHT nutzen will) auch nicht so sehr, daß man stattdessen nun Keepalives nach RFC 5626 implementieren würde (zumindest wüßte ich nicht, daß AVM das bisher veröffentlicht hat). Und auch so eine automatisch eingerichtete Portweiterleitung (oder "Freigabe" in einer IPv6-Firewall auf dem Edge-Router) in einer Router-Kaskade ist immer noch eine Portweiterleitung ... nur halt keine, die man manuell eingerichtet hat.
PS: Heute habe ich weder Lust noch Zeit, da irgendwo noch "Korrektur zu lesen". Sollten sich also mehr Fehler in Orthographie und/oder Grammatik finden, als man bei einem längeren Text ansonsten erwarten würde, bitte ich zwar um Entschuldigung - aber auch um "Verständnis".
