PhonerLite mit Sipgate über Vodafone Kabelrouter: Eingehende Anrufe funktionieren nur gelegentlich

Ich muss gestehen, dass ich dir nicht ganz folgen kann, bzw. nicht verstehe, was dir noch fehlt?

Dein letzter Absatz liest sich so, als würdest du nur Menschen als Quelle oder Beleg akzeptieren, die den Standard zum jeweiligen Thema verfasst, oder grundsätzlich einen größeren Einfluss haben. Das trifft auf mich nicht zu. Diese Einstellung, so sie denn stimmt, halte ich aber auch für falsch.

Es gibt halt hier diese zwei Standpunkte oder Herangehensweisen: Deinen (Achtung: wertfrei gemeint) "Quick and Dirty" Ansatz mit der Portweiterleitung, oder meinen, wie man es ohne hinbekommt. Also erst gucken, dann machen.
 
Zum Thema Portforwarding:
An einem Standort wo ein Asterisk (mit alternativem SIP Port 54321) von mir lief, hat der EDV Dienstleister meine Instruktionen mal falsch verstanden. Ich bat ihn, den Traffic auf diesem UDP Port zu erlauben, er dachte ich will ein Portforwarding und hat es eingerichtet. Ein Missverständnis, dass mir erlaubt hat die Bedrohungslage dann rückblickend in den Logs zu erkennen nachdem ich es bemerkt habe.
Erwartungsgemäß, da es ja ein nicht-standard SIP Port ist, war mal die erste Zeit Ruhe. Aber schon nach 2 Tagen haben die REGISTER und INVITE Versuche sowie die Friendlyscanner von allen möglichen internationalen IPs begonnen. Ich vermute mal, dass der eigentlich recht exotische Port durch Portscanning entdeckt wurde. Es schaukelte sich immer mehr hoch, bis die Angriffsversuche ein Niveau erreicht haben wie es wohl auch auf dem Standard 5060 gewesen wäre.

Aufgrund ACLs und starker Kennwörter ist nichts passiert, letztendlich weiß man aber nie ob mal ein Bug oder ein Buffer Overlfow im SIP Stack der eingesetzten Software ist. Und ich weiß seitdem dass alternative Ports, wenn sie ins Internet offen sind, auch nur geringfügig schützen.
Wenn ich mir jetzt vorstelle dass all dieser bösartige Traffic aufgrund eines Portforwardings an einer Freeware Software auf einem Windows Rechner aufschlägt, wird mir richtig mulmig. (Nichts gegen Phonerlite, ich erlebe es stets als sehr robuste Software, dennoch ist auch diese nicht gegen Sicherheitslücken immun)

Das gefährliche an Portforwardings ist, dass man sie (insbesondere im Heimumfeld) im Alltag vergisst wenn alles funktioniert. Die Zeit vergeht, die Software an die die Ports weitergeleitet werden veraltet, das Betriebssystem ist vielleicht nicht immer up-to-date und eines Tages kommt man von der Toilette zurück zum Rechner und die Kiste ist verschlüsselt.

Daher ist auch meine Meinung dass ein Portforwarding ganz allgemein (temporär für die Fehlereingrenzung ausgenommen) vermieden werden sollte. Das ist für mich keine Frage von RFCs oder ähnlichem, sondern hat mit meiner Vorstellung eines IT Grundschutzes zu tun.
 
  • Like
Reaktionen: chrsto
Suchmaschinen wie Shodan machen eine Verlegung des Ports ohnehin sinnlos.
 
@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):
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):


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".
 
Zuletzt bearbeitet:
Was meinen Beitrag angeht, so bitte ich darum Dinge wie "Freeware auf einem Windows Rechner" nicht auf die Waagschale zu legen. Das habe ich nur im Bezug auf den Threadstarter so formuliert, der eben phonerlite auf (mehr als höchstwahrscheinlich) Windows einsetzt.
Natürlich kann man hier jedes OS und jede Software einsetzen. PJSIP selbst hatte ja erst vor kurzem ein paar unerfreuliche Sicherheitslücken https://jfrog.com/blog/jfrog-disclo...lities-in-pjsip-a-popular-multimedia-library/ - wenngleich jene Zwecke für das unsereins es üblicherweise einsetzt dieses Mal nicht oder kaum betroffen waren.

Ich mach halt einfach den ganzen Kram schon verhältnismäßig lange. Und ich hab schon viel Mist gesehen der passiert ist. Oft waren Kollegen betroffen und ich konnte meine Lehren aus "sicherer Entfernung" daraus ziehen, manchmal - gott sei dank nicht oft - war auch ich betroffen. Und das brauch ich nicht mehr. Daher fahre ich eine "only the paranoid survive" Strategie. Wo immer ich etwas zu melden habe und man auf mich hört, gibt es kein Portforwarding. Egal ob der Dienst jetzt SIP heißt oder anders. Wenn er nicht wirklich wirklich öffentlich zugänglich sein muss, gibt es ipsec, openvpn, wireguard, zerotier etc. (wobei bei letzterem meine Paranoia auch schon ein bisschen anschlägt)
Wenn er doch öffentlich zugänglich sein muss, dann ab in ein Rechenzentrum damit, aber nicht in mein LAN.
 
Mir ist gerade zum Thema: "Phoner Lite und SIP-Stack" noch eingefallen, daß ich ja auch einfach mal ins Installationsverzeichnis schauen könnte ... da gibt's dann eine (signierte) sipper64.dll (also zumindest keine "einzelnen" DLLs, die man einem OSS-Projekt "zuordnen" könnte - schon dem Namen nach), die ich jetzt nicht in die "Einzelteile" zerlegen will. Anhand der reinen Dateinamen kann man also NICHT entscheiden, ob das jetzt eine eigene Implementierung oder ein (freier oder "gekaufter") SIP-Stack ist.

Aber wirft man dann einen Blick in die Lizenz-Datei (ich muß zu meiner Schande gestehen, daß ich das (aktuell !!) nicht getan habe, weil ich das schon vor vielen Jahren machte), findet man da dann auch die Angaben, womit der SIP-Stack offenbar arbeitet:
Copyright der benutzten Bibliotheken:
oSIP: Copyright (C) 2002 Aymeric MOIZARD, http://www.osip.org
iLBC: (c) 2000-2003 The iLBCfreeware.org Project, http://www.ilbcfreeware.org
Speex: © 2002-2003, Jean-Marc Valin/Xiph.Org Foundation, http://www.speex.org
libSRTP: Copyright (c) 2001-2005 Cisco Systems, Inc.
OpenSSL: Copyright (c) 1998-2018 The OpenSSL Project, http://www.openssl.org
Da kann also zumindest mal hinsichtlich der Sicherheit der verwendeten Komponenten auch so weit "Entwarnung" gegeben werden, daß Phoner Lite dort (immer vorausgesetzt, sie werden richtig verwendet - für gegenteilige Annahmen gibt es m.W. keinen Grund) nicht verwundbarer sein sollte, als andere Projekte, die ebenfalls mit diesen Komponenten arbeiten.
 
Da kann also zumindest mal hinsichtlich der Sicherheit der verwendeten Komponenten auch so weit "Entwarnung" gegeben werden, daß Phoner Lite dort (immer vorausgesetzt, sie werden richtig verwendet - für gegenteilige Annahmen gibt es m.W. keinen Grund) nicht verwundbarer sein sollte,

Kommt (unter anderem natürlich) auf die eingesetzten Versionen an.

oSIP hatte offenbar 2017 mal mit einigen Overflows zu kämpfen https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-37079/GNU-Osip.html

und bei OpenSSL weiß jeder der ab und zu mal Security News liest, dass das in den letzten Jahren öfter mal brannte.

"Entwarnung" gibt es daher aus meiner Sicht nie. Aber wie gesagt, ich bin der Paranoide hier ;-)
 
Wenn er doch öffentlich zugänglich sein muss, dann ab in ein Rechenzentrum damit, aber nicht in mein LAN.
DA sehe ich dann auch wieder Probleme ... ich mache das eben auch schon "ein paar Jahre".

Denn wenn ich das alles - so wie Du es beschreibst oder wie ich es zumindest verstanden habe und auch oft genug schon GESEHEN habe - über VPN-Verbindungen miteinander vernetze und DARAUS dann die Sicherheit ableiten will, dann steht einem erfolgreichen Angreifer auf meinen Server in einem RZ auch alles das offen, was über (meist ja automatisch gestartete) VPN-Verbindungen OHNE zusätzliche Schutzvorkehrungen mit diesem Server verbunden ist. EDIT: Und dann ist mein eigener Server in einem RZ bei einem Provider (mithin in einem AS, wo Angreifer besonders gerne auf die Suche nach Schwachstellen gehen) auch deutlich mehr "exponiert", als wenn er irgendwo in meinem eigenen LAN über ein paar wenige freigegebene Ports in der Firewall des Edge-Routers zu erreichen ist.

Da KANN (nicht MUSS, das ist auch immer eine Abwägung zwischen Kosten und Nutzen - sowohl beim "Betrieb" als auch bei der "Sicherheit", wobei man heutzutage einen Server im eigenen LAN i.d.R. auch wirklich "teuer bezahlt", schon wegen des Energieverbrauchs) unter dem Aspekt "Sicherheit" sogar wieder das eigene Hosting im LAN von Vorteil sein - zumal man bei einen "dedicated server" (oder auch einem virtuellen) ja in aller Regel auch nur noch die Möglichkeit hat, den DIREKT auf dem Gerät mit dort installierter und konfigurierter Software, vor Angriffen zu schützen ... im "Heimnetz" kann das problemlos auch ein getrenntes Gerät sein und schon die Tatsache, daß man dem eigenen Server beim geringsten Verdacht einer "Übernahme" einfach den Stecker ziehen kann (und das meint den vom Netzwerk und NICHT den vom Strom - ich betreibe eben auch gerne Forensik), KANN ein Vorteil sein, den man bei einem Server in irgendeinem RZ eines Providers nicht mehr hat.

Wie ICH ja meinerseits nur versuche zu vermitteln, ist eine ENTSCHEIDUNG am Ende immer ein Abwägen von Vor- und Nachteilen (oder zumindest sollte das so sein) und hinsichtlich solcher Fragen wie "Ist Portforwarding hier vielleicht eine Lösung?" kann man ja auch ein "Besser nicht." als EINEN Punkt in einer "Gesamtbewertung" sehen - solange das kein "Nein, das geht GAR NICHT." ist, was einem dann den Blick auf diese (manchmal eben auch "einfache") Lösung verstellt. Wenn man "KISS" als (ständiges) Menetekel für die Suche nach einer Lösung sehen will (bei @chrsto steht das zumindest als Link, vermutlich also auch als Erklärung, was er "bevorzugt" - durch den "eigenen Absatz" dafür und fehlende "Einleitung" oder andere Hinweise, fehlt da etwas der Kontext), dann ist eben eine solche (Lösung), die sehr viel zusätzlichen Aufwand erfordert, NUR weil man um JEDEN Preis keine Portweiterleitung machen will, nach meinem Verständnis wieder das komplette Gegenteil dieses Prinzips.

Aber wie gesagt, ich bin der Paranoide hier ;-)
Und Paranoia ist ja auch noch kein Grund dafür, daß da jemand NICHT hinter Dir her sein könnte.

Ich bin ja nun durchaus auch ein SEHR vorsichtiger Mensch und ich lebe auch von der Beschäftigung mit diesen Themen - aber ich habe AUCH gelernt, daß ich nicht mehr alles alleine machen KANN (dafür sind die Themen dann mittlerweile doch zu komplex und in zu vielen Bereichen des Lebens zu finden - ich tanze per se schon (für heutige Verhältnisse) auf viel zu vielen Hochzeiten) und daher kommt bei mir dann doch hin und wieder das Bedürfnis auf, anderer Software auch einfach ZU VERTRAUEN.

Beim Phoner Lite geht das dann so weit (ich habe eben auch noch nichts erlebt, was da einen "Verdacht", es könnte anders sein, rechtfertigen würde), daß ich unterstelle, daß bei einem "letzten Update" im März 2022 auch die jeweils aktuellen Versionen der genutzten Komponenten verwendet wurden.

Vielleicht habe ich da auch einen etwas "naiven" Blickwinkel ... aber so, wie ich meinerseits erwarte, daß die Leute von mir programmierte Software auch erst einmal "prüfen" (dazu haben sie die Gelegenheit, WEIL sie die Quellen einsehen können und wo immer es geht, versuche ich das dann auch so zu halten, daß da nichts kompiliert oder installiert werden muß, was auch einigermaßen durchzuhalten ist, solange es mit Shell-Code oder anderen Skript-Sprachen zu lösen ist), bevor sie meine "Seriosität" oder auch nur meine Sorgfalt (und damit ein vorheriges Reflektieren der Konsequenzen meiner Handlungen) in Frage stellen, so erhalten andere Autoren von mir auch erst mal einen Vertrauensvorschuß, daß sie ebenso wie ich versuchen, gewissenhaft zu arbeiten und wenn ich dann doch einmal das Gegenteil erleben mußte, dann lebe ich auch mit meiner "Enttäuschung" (die dann natürlich auch ihre Konsequenzen nach sich zieht).
 
Zuletzt bearbeitet:
@PeterPawn

Stattdessen würdest Du eine Port-Freigabe für einen Port auf eine interne IP-Adresse aufmachen. Folglich bist Du nicht nur für Deinen VoIP/SIP-Anbieter sondern für die ganze Welt erreichbar (auf diesem Port). Das ist mehr, als Du willst. Will man nicht.

Sicherheitsbedenken.

Es widerstrebt mir unnötigerweise Zugriffe unkontrolliert und dauerhaft von außen zuzulassen.

Das haben @sonyKatze und ich geschrieben. Und erst bei dem Beispiel von @IEEE mit den fremden REGISTER und INVITES wird für dich ein Schuh draus? Komm, dass ist doch was für die Goldwaage, oder? ;)

Ich muss zugeben, dass das jetzt viel Text ist, den ich da durchzugehen habe.

Nochmal: Ich habe keine großartigen Referenzen. Ich bin selbstständig, Einzelkämpfer und stehe bei meinen Kunden in der Verantwortung. Danach richtet sich bei mir alles. Es muss funktionieren und von vorne herein möchte ich auf Sicherheit (bzw. das, was ich dafür halte) achten. Dazu gehört halt auch, dass ich (im Falle von VoIP) keine Portweiterleitungen möchte oder benötige, da ich nicht davon ausgehen kann, dass "meine" Telefonanlage Traffic von außen sicher aussortiert.

Ich weiß auch, dass das viele nicht so sehen. Es gibt Firmen, da bin ich nur für den Telefonie-Part zuständig. Dann kommt es häufig vor dass die IT (externer Dienstleister, oder interne eigene) mir schonmal Ports weitergeleitet hat, weil "ich die ja eh brauche". Die Verwunderung ist dann groß, wenn ich das gar nicht will. Vor allem, weil die externen Dienstleister das von anderen Firmen, die Telefonanlagen bauen so gewohnt sind

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

Für diese Fälle gäbe z.B. VPN oder ein SBC in der DMZ. Manche Hersteller bieten auch Cloudlösungen an. Da gibt es dann eine App fürs Handy, die sich beim Server des Herstellers meldet. Aus der Sicht "meiner" Telefonanlage wäre das dann wieder nur Traffic nach extern.

Und ganz ehrlich - an der Stelle hast Du Dich dann (für mich jedenfalls) auch nicht wirklich mit Ru(h)m bekleckert.

Korrekt. Diese ist ein sehr harter Standpunkt, aber im Job der einzig für mich gangbare. Ich möchte mir etwas anderes gar nicht erst antrainieren. Wenn etwas passiert, klingelt bei mir das Telefon.

Und warum sollte so ein Standpunkt für andere nicht hilfreich sein? Anderes Beispiel:

Jemand hat abgefahrene Bremsbeläge.
Ich sage: "Damit fährst du jetzt nicht mehr einkaufen. Erst neu machen."
Er sagt: "Ja aber dann hab ich heute Abend keine Marmelade!"
Ich sage: "Pech gehabt!"

War mein Standpunkt jetzt hilfreich, oder nicht? Natürlich kann man so einkaufen fahren. Natürlich wird er keine Vollbremsung machen müssen, weder auf dem hin- noch auf dem Rückweg. Aber was wenn doch?
 
Komm, dass ist doch was für die Goldwaage, oder?
Sehe ich anders ... was GENAU steht denn bei @sonyKatze im Zitat? Da steht:
Port-Freigabe für einen Port auf eine interne IP-Adresse aufmachen
Das STIMMT vielleicht wieder in einen NAT-Kontext, wo eine derartige Freigabe dann auf eine interne Adresse erfolgen würde.

Im Szenario in #1 geht es aber um einen "geöffneten" Port für eine (öffentliche) IPv6-Adresse - das IST (gerade angesichts dessen, daß @sonyKatze immer "frisch, fromm, fröhlich, frei" die IP-Protokolle durcheinander wirft und Mechanismen von einem Protokolll automatisch auch auf ein ganz anderes übertragen will) etwas anderes und dafür brauche ich auch keine Goldwaage.

Da ist der PC hinter dem Router per se nur noch durch die IPv6-Firewall geschützt (die man auch - bei besserer Firmware - NUR für den kompletten Client (und nicht alle anderen ebenfalls) ausschalten KANN - das müßte eigenlich sogar der TG3442DE wieder können, wobei ich nicht weiß, wie Vodafone da die Firmware beschneidet/beschneiden läßt) und je nach Router gibt es erst gar keine solche IPv6-Firewall auf einem (SOHO-)Router - auch das ist nichts wirklich neues.

Das kann sich jeder selbst ansehen, wieviele Tipps und Tricks und Verweise darauf, daß dann eben bei IPv6 DIE GERÄTE eine ordentliche Firewall implementiert haben und nutzen müssen, man "im Internet" findet (manchmal leider eben auch nur "halbgar" bei den Erklärungen, was mich ja an den Aussagen von @sonyKatze in allererster Linie auch stört). Es IST hier eine Freigabe auf eine ÖFFENTLICHE Adresse (ich hoffe mal nicht, daß irgendein IPv6-fähiger Router eine Freigabe auf "link-local"-Adressen bei IPv6 zuläßt - DER müßte dann natürlich auch wieder NAT6 machen, aber das ist m.W. ein Szenario, was im SOHO-Bereich (schon lange) nicht mehr auftritt.

Und zu Deiner "Einlassung":
Was soll man denn aus dem "Stichwort" herauslesen, wenn Du nur "Sicherheitsbedenken" schreibst? Schon dafür mußte ich - nach:
Ja, ich halte Portweiterleitungen bei VoIP für falsch.
Dich erst um eine "Begründung" bitten und dann so etwas?

Auch die eher "schmale" Ergänzung danach (im Gespräch würde ich so etwas "maulfaul" nennen (in der Hoffnung, daß Du das kennst und Dich nicht dadurch angegriffen fühlst - ansonsten ersetze es durch "einsilbig", was aber auch nicht ganz stimmt, weil das ja eher für "Ja" und "Nein" gilt) erklärt mir noch nicht wirklich, warum das nun plötzlich "unkontrollierte Zugriffe" sein sollen, solange die von Punkt A auf der WAN-Seite der Firewall nach Punkt B an der Firewall eines IPv6-Clients im LAN gehen.

Danach kam dann auch schon der Teil, wo Du dann eben andere Technik verwendest. Das nach der "KISS"-Zeile zählt für mich nicht mehr zu den "Erklärungen", denn da nimmst Du ja nur denkbare Alternativen "aufs Korn" und erklärst, warum DIE auch keine Lösung sein könnten. Das sehe ich tatsächlich nicht als "Erklärversuch", was GENAU Dich nun an Portfreigaben (offensichtlich ja dann auch wieder nicht nur auf VoIP/SIP begrenzt, oder?) so stören sollte und vor allem auch nicht, was denn dann bitte "Portfreigaben" überhaupt sind, über die da geredet wird.

Wie ich versucht habe zu zeigen, geht es OHNE Portfreigaben an sich gar nicht - wenn das also am Ende (auch bei Dir, oben habe ich das ja schon mal versucht zu "definieren") nur um manuell von einem Benutzer eingerichtete, permanente Portfreigaben auf ein Gerät mit interner Adresse (wo dann ja auch D-NAT gemacht werden muß, was bei IPv6 NICHT der Fall ist) in einem vorgelagerten Router geht und eines der (Haupt-)Argumente wäre, daß die irgendwann "vergessen" werden und dann "immer noch offen" sind, dann gibt es auch dagegen etwas von Ratiopharm.

Auch DA gilt nun einmal, daß solche Pakete OHNE passenden IP-Endpoint auch keinen Schaden anrichten sollten. Es ist also eigentlich EGAL, wo diese Pakete dann blockiert werden (immer noch bei IPv6 und bitte auch ohne "generelle Probleme" im IPv6-Stack des Zielgerätes), sie können an der WAN-Seite der Firewall schon zerschellen, sie können erst gar kein Ziel im LAN finden (weil die MAC-Adresse zur IP-Adresse nicht aufgelöst werden kann - auf der WAN-Seite kommen sie ja ohne L2-Adressierung an, die muß der Router erst mal hinzufügen bzw. seine eigene durch die richtige ersetzen), sie können an der Firewall des Gerätes scheitern (und JEDES Gerät mit IPv6-Support sollte seine eigenen Firewall haben) und sie können schlußendlich noch daran scheitern, daß auf dem Gerät am Zielport gar kein Prozess "lauscht". Wenn sie es dann doch bis in einen Prozess geschafft haben, muß der obendrein noch irgendwie "verwundbar" sein - was er für Zugriffe auf der LAN-Seite der Firewall (des Routers) dann aber üblicherweise ohnehin wäre (nicht alle Dienste kommen eben ausschließlich mit "ausgehenden" IP-Verbindungen aus, die hinter einer eigenen Firewall gestartet werden).

Und wie auch schon geschrieben ... wenn einem "vergessene Freigaben" solche Sorgen bereiten, dann kann man dafür auch "modernere" Lösungen finden. Einer der Punkte beim PCP-Protokoll (das auch nicht NUR dafür da ist, bei DS-Lite eingehende IPv4-Verbindungen zu ermöglichen) ist es ja auch, daß diese "Freigaben" regelmäßig "erneuert" werden müssen und das in Zeiträumen, wo nur ein "laufender Prozess" dann auch dafür sorgen kann, daß solche Weiterleitungen am Leben gehalten werden. Im Prinzip sind das "ausgehende Verbindungen" (die auch sehr schnell wieder "verfallen"), nur eben nicht mit einer definierten Gegenstelle, identitifiziert durch die IP-Adresse in einem ausgehenden IP-Paket, sondern "offen" für eingehende Daten von irgendeiner Adresse. Wenn das irgendwie weiter eingeschränkt werden soll, wer da "senden" darf, dann ist es eigentlich die Aufgabe des "Empfänger" (auf Layer5 und ggf. noch darüber), seine eigene "application firewall" auch passend zu implementieren.

Und auch das sind dann eben "Portfreigaben" oder auch "Portweiterleitungen" - wenn man das also "etwas" differenzierter bzw. expliziter beschreibt, WAS davon man eigentlich genau meint, dann (und erst dann) kann man sich auch mit entsprechenden Argumenten auseinandersetzen und sie - wie beispielhaft für das "Vergessen"-Argument - versuchen zu entkräften bzw. Alternativen aufzuzeigen.

Denn auch Vorschläge mit VPN funktionieren eben nur dann, wenn die Anzahl der "berechtigtermaßen Zugreifenden" überhaupt determiniert ist und das auch noch handhabbar bleibt. Spätestens wenn 20 verschiedene berechtigte Nutzer (die sich auch noch einmal mit einem eigenen Account, starkem Kennwort und TOTP-Secret authentifizieren MÜSSEN, bevor sie Zugriff erhalten - meinetwegen auf einen SAP-Client in einer Citrix-Umgebung) auf einen "Dienst" zugreifen sollen, wird das "Verwalten" von VPN-Verbindungen (im Router) zur Herausforderung (und jetzt mal bitte VPN-Verbindungen, die von einem Edge-Router "nebenbei" behandelt werden - meinetwegen von bintec-Routern, damit man mir keine zu sehr ausufernde Affinität zu AVM-Geräten nachsagen kann) oder man legt sich gleich auch noch einen LDAP-Server zu ... hier wären dann wohl 20 Clients wieder etwas zu wenig, um den zusätzlichen Aufwand zu rechtfertigen. Aber was löst diese Problem quasi im Vorbeigehen? Richtig - ein TLS-Tunnel von einer Portfreigabe am Edge-Router zur Anmeldeseite für diesen Dienst. Es ist nun mal IMMER auch eine Abwägung zwischen Aufwand, geforderter (bzw. hier "erforderlicher") Sicherheit (wenn sich der EP selbst "verteidigen" kann, dann MUSS ich ihn auch nicht bevormunden - im Extremfall ist sogar er der Erste und Einzige, der einen solchen "Angriff" auch zuverlässig erkennen kann und OHNE zusätzliche Sicherungsmaßnahmen (wie das erwähnte Login) würde hoffentlich auch niemand MIT einer VPN-Verbindung einen solchen Dienst betreiben.

Das ist auch so ein kleines Problem mit VPN-Verbindungen ... einerseits predigen wir immer, daß mehr und mehr Dienste auf ihrer eigenen Protokollebene entsprechende Sicherheit implementieren sollen (z.B. HTTPS im Browser oder auch SIPS bei VoIP) und andererseits packen dann viele selbst solche Daten, die bereits verschlüsselt und damit sicher sind, noch einmal in ein VPN und lassen sie da erneut verschlüsseln ... häufig eben auch nur, weil sie entweder keine andere/bessere Art der Adressierung kennen (so ein Transport-Protokoll im VPN nimmt einem natürlich auch alles andere hinsichtlich dieser Adressierungen ab) oder weil sie damit "ein besseres Gefühl" haben.

Spätestens dann, wenn es irgendwann mal um ein paar Prozent Durchsatz geht. Das kann bei einem Remote-Backup schon ganz schön "ins Geld gehen", ob das nun 10 oder doch 11 Stunden läuft bzw. 2 oder doch 2,5 TB Traffic braucht. Und da kann man bei Backups dann sogar noch eine "Verschlüsselungsebene" hinzufügen, wenn das Backup-Programm die Daten seinerseits auch noch einmal verschlüsselt - was spätestens dann, wenn die Daten irgendwo an ihrem Ziel gespeichert werden, auch keine so ganz schlechte Idee mehr ist ... DAS ist also genau die Ebene der Verschlüsselung, die man NICHT so ohne weiteres einsparen sollte.

Aber dann merkt man auch, daß solche "Mehrfachverschlüsselungen" (und es ist dann natürlich auch nicht wirklich eine Lösung, wenn man stattdessen (generell) auf den TLS-Layer verzichtet, zumal das auch gar nicht immer so ohne weiteres möglich ist) mit einer VPN-Lösung nicht IMMER wirklich hilfreich sind und nicht nur aufgrund des zusätzlichen Ressourcenbedarfs beim Ver- und Entschlüsseln, sondern auch wegen des zusätzlichen Platzbedarfs in Netzwerkpaketen und daher ihrer Beeinträchtigung der max. möglichen Bandbreite, in manchen Fällen auch nicht zur "Aufgabenstellung" passen.

DA kann man dann auch wieder eigene Flexibilität zeigen und aus den gegebenen "Bausteinen" etwas erstellen, was eben NICHT zwei- oder dreimal verschlüsselt, sondern nur einmal - dann aber eben richtig und auch an der richtigen Stelle in der "Pipeline". Wenn ich dazu dann in einer entfernten Firewall (über einen "Steuerkanal" oder auch nur über "port knocking") auch erst noch einen Port für das "Ziel", wo die Backupdateien am Ende landen sollen, freigeben muß und den nach meiner (unverschlüsselten) (HTTP-/WebDAV-)Übertragung der (verschlüsselten) Backup-Daten wieder schließen lasse (oder der geht sogar von alleine zu, weil ich das gleich mit zeitlicher Limitierung für die Verbindungsaufnahme mache - nicht zu verwechseln damit, daß der Port per se nur für eine Absenderadresse aus dem Internet freigegeben wird), dann kitzele ich damit leicht 5% mehr Durchsatz heraus.

In der Regel sogar deutlich mehr, weil die 5% schon nur Overhead des VPN-Tunnels sind - WireGuard-MTU ist 1420 (oder 1412 bei PPPoE) wenn's gut läuft - das sind bereits 5% der Bandbreite, die ggü. einer MTU von 1500 verloren gehen durch ein WG-VPN. Da ist also "Performance-Gewinn", weil die Daten nicht nochmals verschlüsselt werden müssen (egal, ob da nun VPN + TLS oder nur VPN verwendet werden), noch gar nicht dabei. Aber das ist eben auch nicht "08-15", so wie man das "jeden Tag" macht - und ja, das ist dann vielleicht auch keine "echte" Portfreigabe (wobei soo sicher wäre ich mir da auch wieder nicht). Und auch eine Erklärung, wie ich das gegen Zugriffe Dritter schütze (auch wenn ich HTTP/WebDAV "angerissen" habe), nicht "komplett" ist. Aber ich fände dafür eine Lösung ... eine einmalige HTTP-Anmeldung (mit Digest-Authentifizierung auch einigermaßen sicher gegen "eavesdropping") und ein Backup-Programm, was dateiweise und verschlüsselt direkt auf dem WebDAV-Server speichert (meinetwegen lokal vorher komprimiert und de-dupliziert), ist jetzt auch nichts so Exotisches. Solche "sinks" beherrschen viele aktuelle Angebote ... ich wollte ja auch eigentlich nur ein Beispiel vorbringen (und auch eines, was "realistisch" ist als Anforderung), warum auch VPN NICHT IMMER die erste Wahl sein kann - wie mehrfach betont: Alles eine Frage der Abwägung von Vor- und Nachteilen.

Ich habe keine großartigen Referenzen.
Schon die Tatsache, daß Du das auch beruflich machst, IST Referenz - auch wenn das für mich IMMER NOCH NICHT erklärt, warum sich @sonyKatze nun gerade auf ein Zitat von Dir, das obendrein noch in einem eigenen Beitrag steht (wo man ja wohl eher erwarten würde, daß eine Bitte um eine Quellenangabe mit einem Link auf ein "Original" erfüllt wird und nicht, daß der "Beleg" jetzt ein eingebettetes Zitat sein soll, von dessen Richtigkeit man sich ohnehin erst wieder selbst überzeugen müßte), berufen hat, als ich danach gefragt habe, warum Portfreigaben bei VoIP/SIP nun ein "Workaround" und "keine Lösung" sein sollen.

Was genau mag jetzt der Grund sein, warum da DU und nicht ein anderer (es gibt ja auch noch mehr Leute, die Portfreigaben GRUNDSÄTZLICH ablehnen - das ist mir AUCH bekannt) zur "Unterstützung" gerufen wurdest? DAS war es, was ich nicht verstanden habe und warum ich DICH gefragt habe, was dafür vielleicht Gründe sein könnten. Wenn Du z.B. bei der T-Systems in DA jetzt in dieser Sparte tätig gewesen wärst, dann wäre das u.U. "halboffiziell" gewesen und man hätte einer EINZELNEN Ansicht vielleicht größeres Gewicht einräumen können. Wenn Du hingegen gar nicht beruflich mit IT (speziell dann auch mit Netzwerken und NGN) zu tun gehabt hättest, wäre das noch einmal etwas anderes gewesen (ohne damit "begründete" Aussagen und Theorien von "Quereinsteigern" abtun zu wollen), weil dann gute Kenntnisse, auch von Zusammenhängen, eben auch nicht mehr automatisch durch Berufserfahrung und berufliche Fortbildung entstehen. Ich würde weder einem Hirnchirurgen, noch einem Schweißer "mein Netz" anvertrauen - vielleicht verdeutlicht DAS ja besser, warum ich Dich danach gefragt habe.

Für diese Fälle gäbe z.B. VPN oder ein SBC in der DMZ. Manche Hersteller bieten auch Cloudlösungen an. Da gibt es dann eine App fürs Handy, die sich beim Server des Herstellers meldet.
Du merkst aber schon, daß Du auch hier wieder nicht mit der VORHANDENEN Technik eine Lösung umsetzen willst, sondern "Zusätze" brauchst?

Was machst Du denn, wenn das alte, aber "liebgewonnene" SIP-Telefon selbst kein VPN beherrscht? Wenn es vielleicht gar keinen "Router" gibt am Arbeitsplatz im Home-Office (in den letzten zwei Jahren sicherlich auch nicht so selten gewesen, das "Home-Office"), sondern nur ein altes, gammeliges Smartphone, was gerade so noch niedrige LTE-Geschwindigkeit bringt, aber wo die "Sekretärin" jetzt das Telefon, was ansonsten im Büro auf ihrem Schreibtisch steht und mit dem lokalen Swyx-Server als SIP-Client arbeiten würde, mit nach Hause nimmt, damit sie in den "üblichen Bürostunden" auch daheim den Telefonbetrieb sicherstellen kann?

Das alte Smartphone KANN nicht direkt mit der Swyx-Anlage arbeiten (warum, ist völlig egal - ich will nur das nächste "Schlupfloch" stopfen - meinetwegen gibt es für dieses Modell keine passende App), einen VPN-Server, auf dem eine VPN-Verbindung terminieren könnte (die dann auch wieder das Smartphone aufbauen müßte, wozu es auch erst dieses Feature bieten muß - dann auch noch passend zum VPN-Gateway), gibt es auch noch nicht und der vorhandenen Telefonanlage (die ohnehin nicht direkt am Internet hängt, wo man aber von der vorhandenen Firmware-Firewall zumindest für einen definierten Pool von Adressen (die vom MoFu-Betreiber hinter der SIM-Card des Telefons verwendet werden) ein Portforwarding einrichten könnte, damit das SIP-Telefon (über die Tethering-Funktion des Smartphones - und wenn's sein muß, finde ich auch noch ein altes iPhone 3, wo für Tethering erst mal Cydia bemüht werden mußte) mit der Telefonanlage dennoch arbeiten kann. Einen SBC GIBT es bisher gar nicht - für entsprechende Lizenzen bei "passend zur Anlage" will der Hersteller auch gutes Geld sehen und die Frage, auf welchem zusätzlichen Gerät (oder auf welchen Gerät als Zusatz) man den dann installiert, ist auch "ungeklärt".

Jetzt kann man sich zwar hinstellen und sagen: "Geht nicht." oder auch "Mach ich nicht." ... aber das ist es dann, was ich wieder als "wenig hilfreich" bezeichnen würde. Es ist zwar gut, wenn ein IT-Dienstleister "seine Prinzipien" hat und wenn er die sauber begründet und der Kunde dann sagt: "OK, überzeugt ... will ich haben, pfeif auf die Mehrkosten, wenn's dann 'länger hält'." (wobei das "lange halten" ja auch oft genug nur ein leeres Versprechen ist), ist das etwas vollkommen anderes, als wenn man nur dann eine Lösung bieten will, wenn sie unbedingt mit den eigenen Vorstellungen übereinstimmt.

Das erinnert mich dann frappierend an den TK-Anlagenvertrieb der Telekom. Den kenne ich von 2000 bis 2012/2013 - ich habe früher mal für vier Jahre "angestellt" in einer Firma gearbeitet (nach der "Dotcom-Blase"), die einigermaßen enge Kontakte zur T-Systems hier in Berlin hatte (daher auch eine Zweigstelle in Berlin aufmachte, obwohl sie in Stuttgart saß) und wo wir noch mit "full-size"-AT-Karten von Dialogic/Intel für PMX und Spracherkennung von Nuance dann "intelligente" Telefonanlagen gebaut haben (bzw. die Software dafür implementiert haben und damit dann die Systeme zusammengestellt wurden) - auch da faßte man sich (wenn ein Auftrag dann "rein kam") so manches Mal an den Kopf, was den Leuten da alles aufgedrängt wurde, obwohl es viel einfachere Lösungen gegeben hätte - nur halt nicht so "umsatzstarke". Später hatte ich dann auch (wieder als Freelancer) noch einige Kontakte mit der T-Systems in Darmstadt, damals war ich mit "Mehrwert-Diensten" befaßt - teilweise auch noch auf der "alten" Dialogic/Intel/Nuance-Plattform, wobei das eben auch zu SIP "migriert" wurde ... aber eben über einen gewissen Zeitraum und nicht immer gleich als "big bang" (das ist das auch nur noch in Anführungszeichen eine "Mígration" für mich).

Vielleicht ist das ja auch eine "fast vergessene Kunst", aus dem vorhandenen Material noch eine Lösung zu formen (auch wenn die nicht immer "schön" ist), bei der der Kunde auch in einem Jahr noch mal etwas gemacht haben will, weil er nicht durch die ganzen, unnötigen Investitionen in den Ruin getrieben wurde. Wenn man tatsächlich nur "aus dem Vollen schöpfen" kann (oder nur dann auch will), DANN kann man das natürlich auch so machen, daß man es selbst wieder "lieb" hat. Ansonsten sollte man (meine Ansicht) auch immer etwas die Belange des Kunden im Auge haben und die FÜR IHN beste Lösung projektieren - oder man macht's eben so, wie man es "immer macht".

Damit hat man dann NATÜRLICH auch die wenigsten Probleme (schließlich macht Übung ja auch den Meister und nach der fünften Installation einer Software oder einer TK-Anlage, sollte man die Einstellmöglichkeiten tatsächlich im Schlaf beherrschen), aber damit wird man als "Dienstleister" dann (wieder: nach meiner Ansicht) auch entsprechend unflexibel und man nimmt sich auch selbst ein wenig den Spaß daran, neue Wege und Möglichkeiten zu erkunden. Vielleicht will ich auch deshalb lieber Probleme lösen, Fehlerquellen und Sicherheitslücken finden und implementierte Algorithmen analysieren, als irgendwelche "mechanischen" Aufgaben (und da gibt es ja nun so einige, von der OS-Installation bis zu "Drucker druckt nicht") zu übernehmen. Ich muß zwar auch nicht täglich "rausgeklingelt" werden, aber WENN das dann mal der Fall ist, dann bemühe ich mich halt auch (schon im eigenen Interesse) um eine GRÜNDLICHE Lösung, damit morgen nicht das nächste Klingeln meine Nachtruhe unterbricht.
 
Zuletzt bearbeitet:
Im Szenario in #1 geht es aber um einen "geöffneten" Port für eine (öffentliche) IPv6-Adresse

Ich verstehe jetzt hier den Unterschied nicht. Du machst einen bestimmten Dienst (in diesem Fall SIP) von extern erreichbar. Dabei ist es egal, ob es über IPv4 oder IPv6 erfolgt. Erreichbar ist erreichbar. Eine potentielle Sicherheitslücke in der dort erreichbaren Software wird in den seltensten fällen nur mit IPv4 funktionieren.

Ich verstehe auch die Ergänzung mit der Firewall nicht. Wenn da ein Port offen ist, ist für den Port an dem Endgerät die Firewall aus. Sonst käme da kein Traffic rein.

Vielleicht erklärst du mir den Unterschied zwischen

80.90.90.100:5060 (WAN IPv4) -> 192.168.0.100:5060 (LAN IPv4 PC1) Portweiterleitung

und

[2003::27]:5060 (Öffentliche IPv6 PC1) Portfreigabe

Auch die eher "schmale" Ergänzung danach

Standpunkt: Haustüren müssen abgeschlossen werden
"Maulfaule" Ergänzung: Damit kein Fremder rein kommt
Du: Reicht mir nicht
@IEEE: Damit kein Fremder rein kommt und Schmuck und Bargeld klaut.
Du: nach endlich

Ich sehe da von meiner Seite aus echt keinen weiteren Erklärungsbedarf.

Wenn sie es dann doch bis in einen Prozess geschafft haben, muß der obendrein noch irgendwie "verwundbar" sein

Das ist eine sehr gefährliche Einstellung. Das passiert schneller als man denkt. Daher: von vorne herein direkt ausschließen.

wird das "Verwalten" von VPN-Verbindungen (im Router) zur Herausforderung

Das ist Arbeit, das machen wir nicht. Das kann doch kein valides Argument sein.

Richtig - ein TLS-Tunnel von einer Portfreigabe am Edge-Router zur Anmeldeseite für diesen Dienst.

Nein, einfach nur nein. Man hängt nichts mit dem nackten Hintern ins Netz, wenn es nicht sein muss.

Frag mal die Kirchengemeinde, wo kürzlich nachts die Glocken leuteten. Da ist jetzt plötzlich auch ein VPN.
Frag mal Kunden von QNAP Nas Systemen, deren Daten verschlüsselt wurden, weil die (mit TLS) Anmeldeseite von extern erreichbar waren. Da wird plötzlich ein VPN empfohlen.

und andererseits packen dann viele selbst solche Daten, die bereits verschlüsselt und damit sicher sind, noch einmal in ein VPN und lassen sie da erneut verschlüsseln

Nochmal nein. Es geht zwar auch im Verschlüsselung, aber vor allem geht es darum den Dienst durch das VPN nur einem bestimmten, berechtigten Nutzerkreis zugänglich zu machen (du schreibst weiter unten etwas von Freigabe bestimmter Adresse des MoFU Betreibers. Das ist zwar ein bestimmter Nutzerkreis, aber nicht jeder ist berechtigt, also auch schlecht).
Wenn ein Dienst öffentlich erreichbar ist, dann kann da jeder irgendwelche Daten gegen werfen und auf einen Buffer Overflow oder sonstwas hoffen, wo dann hinten eine Remote Execution Vulnability rausfällt. Das willst du nicht.

Noch was anderes: Was ist denn, wenn es nicht nur um einen Dienst geht, sondern um mehrere und der Mitarbeiter verlässt das Unternehmen?
Man kappt den VPN Zugang ist sich sicher, dass der Mitarbeiter draußen ist. Du brauchst nicht sofort x Accounts abzustellen und hoffen, dass du an alle gedacht hast.
Hat der Mitarbeiter vielleicht Zugangsdaten von Kollegen herausbekommen? Ohne VPN hast du jetzt ein Problem.

DAS ist also genau die Ebene der Verschlüsselung, die man NICHT so ohne weiteres einsparen sollte.

Und die Ebene der Transportverschlüsselung ebenfalls nicht. "Ups, das Backup wurde mit einer älteren SSL Bibliothek, die verbuggt war, verschlüsselt und unverschlüsselt übertragen. Das kann jetzt jeder, der den Traffic mitgeschnitten hat entschlüsseln"

Netzwerkpaketen und daher ihrer Beeinträchtigung der max. möglichen Bandbreite

Ach bitte, ernsthaft jetzt?

Was genau mag jetzt der Grund sein, warum da DU und nicht ein anderer zur "Unterstützung" gerufen wurdest?

Weil ich diesen Standpunkt vertrete und damit noch im Gedächtnis war. Reicht das als Erklärung?

SIP-Telefon selbst kein VPN beherrscht? Wenn es vielleicht gar keinen "Router" gibt am Arbeitsplatz im Home-Office

Ersteres ist dann die private Entscheidung des Nutzers, mit den entsprechend möglichen Konsequenzen.
Letzteres liegt in der Verantwortung der Firma bzw. deren IT. Es gibt VPN Softclients und USB Telefone zum Anschluss an den Arbeitsplatz. Die Telefonanlage kann das nicht und müsste komplett neu? Gib dem Mitarbeiter ein Diensthandy und arbeite für die Zeit mit Rufumleitungen.

Natürlich gibt es die Situation, dass plötzlich Homeoffice kommt und die nötige Lösung ist nicht da.
Das ist halt eine Veränderung auf die man reagieren muss.

Das kann man jetzt so sehen wie du: Wir haben das und das gegeben und damit machen wir das jetzt, die Sicherheit blenden wir erstmal aus bzw. uns reicht es so. Mögliche Konsequenzen stehen weiter oben.

Oder man plant, investiert und verändert sich. Ja das kostet Geld, aber vielleicht lohnt es sich, weil die Mitarbeiter von zu Hause produktiver sind?

Sicherheit ist kein Zustand, sonder ein Prozess.

Wenn man tatsächlich nur "aus dem Vollen schöpfen" kann (oder nur dann auch will)

Wenn ich so arbeiten würde, wie du es hier vorschlägst, ausschließlich bestehendes Nutzen, würde ich wesentlich mehr verdienen, da das aus meiner Sicht wartungsintensiver ist und ich nach Stunden abrechne.
 
Zuletzt bearbeitet:
Sorry, daß es etwas gedauert hat, bis ich die Muße für eine Antwort gefunden habe.

EDIT: Zu früh der falsche Button ... geht bald neu los.

(zusammengeführt)


Vielleicht erklärst du mir den Unterschied

D-NAT im Router erforderlich, IPv4-Stacks problemlos auch in vielen älteren (sogar in neueren) Geräten ohne "eigene Firewalls" - sieh Dir beliebige IoT-Gadgets an und auch weit verbreitete OpenSource-Projekte wie Tasmota haben m.W. bisher keine IPv6-Funktionen in den Images enthalten, die "automatisch" bereitgestellt werden und die daher in der Mehrzahl all dieser Geräte (häufig auch noch ungeschützt) laufen dürften. Man kann aber mittlerweile IPv6 selbst beim Kompilieren einbauen lassen, soweit ich weiß.

Bei IPv4 hat man es daher auch deutlich öfter mit Geräten OHNE eigene (modernere) Sicherheitsmaßnahmen zu tun - da VERLÄSST sich viel zu viel Software dann tatsächlich noch darauf, daß das LAN automatisch ein Hort des Guten ist - das WAR dann bei der Implementierung der meisten IPv6-Stacks schon bekannt, daß es sich dabei um Wunschdenken handelt, daher sind auch die beim Entwurf des Protokolls berücksichtigten Probleme schon besser "durchdacht" und (vieles) gelöst.

Für eine solche "Weiterleitung" bei IPv4 stimme ich sogar zu, daß man sie vermeiden(!) sollte (was immer noch nicht heißt, daß man sie GAR NICHT nutzen darf) - erst recht dann, wenn da noch andere, gerne genutzte Techniken in SOHO-LANs verwendet werden, wie DHCP (wo bei einem /24-Netz mit "full DHCP range" ja tatsächlich eine Chance von 1:253 besteht, eine "gebrauchte Adresse" abzubekommen) ... da kann es dann tatsächlich zu "unerwünschtem Vertauschen" von Clients kommen, wenn der Router (bzw. dessen Firmware) nicht vernünftig programmiert ist. Das hat man auch alles schon erlebt, daß tatsächlich (nur) anhand der IP-Adresse weitergeleitet wird - zumindest bei Geräten ohne Protocol Processing Engine im Chipsatz, wo dann praktisch auch immer die L2-Adressierung gleich von der PPE eingetragen wird; weil die Pakete dort ja gar nicht erst "ins Routing" gehen.

Die Gefahr besteht bei IPv6 aber gar nicht wirklich (außer man führt solche Situationen selbst herbei) - solange der Client seine Interface-ID aus der eigenen MAC-Adresse bildet (EUI-64) und den Subnetz-Präfix von seinem Router lernt (egal ob per DHCP oder SLAAC), geht bei IPv6 eine Befürchtung: "wird irgendwann vergessen und landet dann am Ende an der falschen Stelle" (möglich, daß ich da jetzt die Opponenten durcheinander würfele) nicht auf.

Höchstens noch die Befürchtung, daß später mal ein Gerät dieselbe Interface-ID (ab jetzt nur noch IID) benutzen könnte - angesichts von 64 Bit "Vorrat" (selbst wenn da noch 16 wegfallen würden, weil die bei MAC-basierten IIDs ja "fix" sind, sind das 2**40 mal mehr Möglichkeiten als bei IPv4 mit /24 - selbst bei einer /8-Maske ist es noch ein Faktor 2**24) auch eine eher geringe Gefahr/Wahrscheinlichkeit, solange sich nicht wieder der Mensch mit seinen Unzulänglichkeiten einmischt und der Ansicht ist, ein Dienst müsse schon die Interface-ID ::1 (oder bei Dir dann ::27) verwenden, damit ER (der Mensch) das besser lesen könne.

Sicherheit lebt ein wenig (nicht überbewerten) tatsächlich auch von "Entropie" (nicht nur bei "random numbers"), wo sich Ergebnisse nicht so leicht vorhersagen lassen (das würdest Du ja vermutlich bei den Portnummern einer ausgehenden Verbindung auch "in Anspruch nehmen" wollen und da sind es nur 2**16 (-1) Möglichkeiten) und einem DNS-Server ist das vollkommen wumpe, ob er seinen DNS-Service per IPv6 jetzt mit einer Adresse anbietet, die auf ::53 endet bzw. auf ::35, wenn man die Portnummer hexadezimal zum Bestandteil der Adresse machen will - die "richtige" Portnummer kommt dann ja noch dazu und die ist auch bei IPv6-Adressen ja üblicherweise dezimal anzugeben.

Als ich noch "unerfahren" mit IPv6-Adressen war (nein, jung war ich da auch schon nicht mehr), habe ich es - nebenbei bemerkt - auch so gemacht (teilweise ist das heute noch aktiv), bis ich dann gemerkt habe, daß eine Adresse [<SP>::35]:53 für einen DNS-Server und eine andere Adresse [<SP>::1bb]:443 für einen HTTPS-Server auch ZWEI zu konfigurierende Adressen für das Interface sind und das dann mit steigender Anzahl von Services auch schnell "viel" wird. Es gibt aber eigentlich gar keinen (funktionellen) Unterschied zu einer Konfiguration mit EINER Adresse [<sp>:1.2.3.4]:<port> (außer man braucht weitere auch zur Unterscheidung des "Ziels") und anstelle von 1, 2, 3 und 4 kann da NATÜRLICH (solange ich das nicht alle fünf Minuten eintippen muß - und dann habe ich dafür ein Tastatur-Makro) auch einfach nur die EUI-64 stehen.

Die wenigsten DNS-Server werden sich weigern, auch für www.foobar.com eine IPv6-Adresse "rauszugeben", wo die Interface-ID NICHT dazu geeignet ist, daß ein Mensch sie sich problemlos merkt. Das verlangt ja auch keiner - am besten nicht mal für "Notfälle", falls der DNS-Server mal nicht funktioniert (dafür hat man eine hosts-Datei in der Schublade, die man dann aktivieren kann).

Denn wer jetzt nicht gerade eine /16-Maske für sein IPv6-Präfix hat (wie in Deinem Beispiel - oder einen Präfix, wo dann die nächsten 48 Bits Null sind), der wird (so er nicht das Netz ständig "administriert" und der IPv6-Präfix auch tatsächlich "statisch" ist) schon mit den ersten 48 oder 52 oder 62 Bit der Adresse ein Problem bei der Eingabe haben und auch die irgendwo "nachschlagen" müssen. Da ist das Hinzufügen der EUI-64 als IID dann auch nur noch ein kleiner zusätzlicher Aufwand - zumal auch hier ja wieder "spezielle Umstände" vorliegen müssen, wenn ein DNS-Server nicht funktioniert. Gibt's den gar nicht (extern ja eher unwahrscheinlich), sollten es im LAN dann halt andere Mechanismen (z.B. mDNS) sein.

Wobei das bei einem "freigegebenen Dienst" natürlich auch eine feste IPv6-Adresse (bzw. IID, wenn sich der Präfix ändern kann - wie bei Anschlüssen mit dynamischem IPv6) sein sollte und keine, die regelmäßig durch die IPv6-Privacy-Extensions gewechselt wird. Aber man kann auch hier schon wieder am verwendeten Mechanismus zum "Auswürfeln" so einer wechselnden IID erkennen, daß die nutzbaren 64-Bit schon ausreichen, um "Kollisionen" nahezu auszuschließen (m.W. gibt es auch keine DAD-Abfragen an dieser Stelle an andere Netzwerk-Teilnehmer, ob eine (neue) IID schon in Benutzung ist - im Gegensatz zur "Initialisierung" am Beginn - das soll/muß nur mit den bereits selbst genutzten IIDs verglichen und bei (unwahrscheinlicher) Übereinstimmung eben wiederholt werden) - das RFC dazu ist 8981 und die Ermittlung solcher IIDs ist hier: https://datatracker.ietf.org/doc/html/rfc8981#section-3.3.2 spezifiziert. [Aber vielleicht gibt es ja doch noch NS-Messages (Neighbor Solicitation) für DAD (Duplicate Address Detection), auch bei neu "ausgewürfelten" IIDs für die "Privacy Extensions" - spätestens wenn sich zwei Geräte bei NS für die Ermittlung der L2-Adresse gleichzeitig melden für dieselbe IPv6-Adresse, merkt man ja, daß da etwas im Argen liegt.]

Nur macht so ein Mechanismus wie PE (Privacy Extensions) für "von außen erreichbare" Dienste eben keinen Sinn - das "Offenlegen" einer MAC-Adresse (die als L2-Adressierung über den Router ja niemals hinaus geht) ist auch nur ein sehr geringes Risiko - da ist jedes Smartphone und jeder WLAN-Router schon "offenherziger" und die wären dann sogar noch auf L2 angreifbar, weil eben kein Austausch der L2-Adressierung erfolgt. Wenn also nicht ein potentieller Angreifer aus der EUI-64 in einer IPv6-Adresse schon auf vorhandene Schwachstellen schließen kann (was eher unwahrscheinlich ist), ist deren "Veröffentlichung" auch kein Sicherheitsproblem, sondern eher "privacy" - bei einem "Server" (bzw. "Dienst") nicht wirklich ein Problem, weil der ja nicht selbst irgendwo "Spuren hinterlassen" sollte.

Langer Aufzählung verschiedener Aspekte kurzer Sinn:
IPv4 und IPv6 unterscheiden sich eben nicht nur in der Anzahl der für die Adressierung verwendeten Bits - viele haben ja auch Probleme damit, die geänderten Mechanismen dabei zu sehen und projizieren alte, bei IPv4 vielleicht gültige, Erkenntnisse/Methoden dann automatisch auch auf IPv6. Ich habe z.B. auch schon Installationen gesehen, wo jemand (obwohl der Router öffentliche IPv6-Adressen auch fürs LAN annoncierte) den DHCPv6-Server abgeschaltet hat und somit der Ansicht war, er wäre "IPv6 damit auch los" (die Ansicht bzw. den Wunsch danach trifft man ja auch noch häufiger an, weil das vielen dann "zu komplex" oder auch "zu unheimlich" wird, wenn sie es auch noch für zwei unterschiedliche IP-Protokolle verwalten sollen). Der hatte halt noch niemals etwas von SLAAC gehört oder gelesen und wunderte sich nur, warum seine Geräte dennoch IPv6-Adressen kriegten und die meisten gar nicht - wie von ihm geplant - über seine IPv4-Restriktionen stolpern wollten.

Ich habe - damit ich nicht "ganz alleine" dastehe mit meiner eingangs erklärten "Unterscheidung" zwischen IPv4 und IPv6 am "Edge-Router" - mal kurz gesucht und will nur mal (weniger als Quellenangabe, denn als "alternative Darstellung", die den Unterschied vielleicht besser "erklärt", als ich das bisher getan habe) eine "Fundstelle" hier verlinken und zitieren: https://www.elektronik-kompendium.de/sites/net/1601271.htm
Warum gibt es die globale IPv6-Adresse mit konstantem Interface Identifier, wenn es doch Privacy Extensions gibt?

Die eigentliche Frage ist, was bringt es überhaupt die MAC-Adresse in den Hostanteil zu integrieren? Mit Privacy Extensions wäre dieser Schritt doch überflüssig.

Prinzipiell macht es durchaus Sinn einen festen Interface Identifier zu haben. Damit wäre ein Host von außen mit einer festen IPv6-Adresse erreichbar, wenn diese explizit für einen Dienst benötigt wird.

Beispielsweise, weil man Dienste nach außen anbieten will oder weil man Ende-zu-Ende-Dienste nutzen will, für die eine globale, aber nicht temporäre Adresse vorteilhaft wäre, wie man es sich von IPv6 verspricht. Typischerweise für VoIP, SIP und Messaging.

Bei IPv4 besteht das Problem, wegen dem Adressmangel, dass durch private Adressen und der damit verbundenen NAT-Umgebung ein Host keine eigene öffentliche Adresse hat. Weil dadurch keine echten Ende-zu-Ende-Dienste genutzt werden können, müssen für viele Kommunikationsprotokolle Umgehungsmechanismen für NAT geschaffen werden. Bei IPv6 kann man darauf verzichten, aber nur deshalb, weil es globale IPv6-Adressen mit konstantem Interface Identifier gibt.
(Die Hervorhebung ist von mir.)



Standpunkt: Haustüren müssen abgeschlossen werden
"Maulfaule" Ergänzung: Damit kein Fremder rein kommt
Du: Reicht mir nicht
@IEEE: Damit kein Fremder rein kommt und Schmuck und Bargeld klaut.
Du: nach endlich
Ich: Auch bei abgeschlossener Haustür sollte man sich noch überlegen, WIE genau sich dann Fremde bemerkbar machen sollen, die mit einem Kontakt aufnehmen sollen. Wenn das ein Mehrfamilienhaus ist und da ist IMMER die Haustür abgeschlossen, kommt vielleicht nicht mal der Postbote bis zum HBK. Und spätestens wenn der Handwerker kommt (und die hoffentlich vorhandene Türklingel und -sprechanlage benutzen kann) und der ist kein "Bekannter", muß auch ein Fremder wieder reinkommen. Vielleicht nicht unbeaufsichtigt und unbemerkt - DAS meine ich damit, daß man irgendwelche "Kurzbeschreibungen", die man abgibt, schon noch ein wenig "ausschmücken" sollte, damit das Gegenüber auch TATSÄCHLICH verstehen kann, was man KONKRET meint und sich nicht nur "seinen Teil denken" soll.

Gegenbeispiel:
Kunde: Ich WILL keine Unterscheidung zwischen Fehlermeldungen und "sonstigen" Nachrichten anhand der Farben Rot und Grün, das muß auch anders gehen.
Dienstleister: Mache ich aber immer so - geht bei anderen ja auch. Gibt's dafür Gründe?
Kunde: Mein wichtigster Mitarbeiter, der diese Nachrichten dann lesen soll, ist "farbenblind" (bzw. hat eine Rot-Grün-Schwäche).

Erste Aussage ist "Postulat" - WARUM das so sein sollte (obwohl es auf den ersten Blick von allem abweicht, was man sonst so kennt), wird nicht erkennbar. Nach der Nachfrage und einer RICHTIGEN Erklärung (und nicht nur "weil mein Mitarbeiter das nicht will" - das wäre die "maulfaule Version" dieser Antwort) wird das (hoffentlich) jeder auch nachvollziehen können.



Wenn ein Dienst öffentlich erreichbar ist, dann kann da jeder irgendwelche Daten gegen werfen und auf einen Buffer Overflow oder sonstwas hoffen, wo dann hinten eine Remote Execution Vulnability rausfällt. Das willst du nicht.
Mit dieser Argumentation gibt es gar keine öffentlich erreichbaren Dienste mehr. Wenn einen die Furcht vor solchen Angriffen alles "verrammeln" läßt, ist man IMMER NOCH NICHT sicher. Denn so eine "undurchlässige" Firewall an der Grenze zum "öffentlichen Netz" (und wir müssen jetzt auch nicht über (echte) "demilitarized zones" reden, denn auch die entschärfen natürlich Probleme, sind aber auch GENAU DAFÜR wieder gedacht, um da öffentlich zugängliche Dienste hinter freigegebenen Ports zu betreiben, auf die dann "von zwei Seiten" zugegriffen werden kann) schützt dann ja noch lange nicht davor, daß genau so ein "verwundbarer Dienst" auch aus dem LAN heraus angegriffen werden kann. Und Du kannst ja mal selbst nach Auswertungen suchen, wieviele Sicherheitsvorfälle in Unternehmen auf "insider threats" (als Stichwort) zurückzuführen sind.

Gegen solche Angriffe hilft es aber nur, die entsprechenden Dienste SELBST so zu "härten", daß sie auch dagegen abgesichert sind. Und dann stellt sich wieder die Frage, warum so eine (funktionierende!) Absicherung gegen interne Angreifer nicht auch genauso gut gegen externe Angreifer abschirmen sollte - entweder sie hilft wirklich oder sie ist auch "von innen" eben nicht gut genug. Damit will ich auch nicht zum Ausdruck bringen, daß man irgendwelche NICHT BENÖTIGTEN Dienste "ins Internet" hängen soll - aber wenn der Endpunkt sicher IST (und wenn nicht, muß er eben sicher gemacht werden), dann hilft eine Sicherheit AN DIESER STELLE gegen ALLE Angriffe und nicht nur gegen die von außen, wie es beim "Verstecken" hinter einer Firewall der Fall wäre.



Will man dann tatsächlich einen Dienst auf einen bestimmten Kreis von Absendern(!) beschränken, dann sollte die als "Server" verwendete Software ihrerseits da auch entsprechende Möglichkeiten bieten - jedes halbwegs gute "Server-Programm" läßt auch konfigurieren, an welche Netzwerk-Adapter (bei "multi-homed devices") und an welche IP-Adressen dieser Adapter es sich für den Empfang von Daten "binden" soll. DA ist dann auch die richtige Stelle (manchmal ja auch als "application firewall" bezeichnet), wo man solche Einstellungen, wie ein Beschränken der erlaubten Kommunikationspartner, vornehmen sollte, solange nicht ETWAS WIRKLICH Wichtiges dagegen spricht.

Die Software sollte dann ja auch nur Daten von erlaubten Absendern annehmen - was per se schon die Nutzung von UDP "verbietet", denn da ist der Absender nicht bestätigt. Bei TCP durch den 3-Way-Handshake in Grenzen schon - zumindest ist da ein Fälschen einer Absenderadresse nicht so einfach wie bei UDP. Mir fallen auch aus dem Stand jede Menge Beispiele für (verbreitete) Server-Software ein, wo es genau solche Einstellmöglichkeiten auch gibt.

DA würde dann sogar ich wieder sagen: Wenn die verwendete Software das nicht leisten kann, sieht man sich nach einer anderen um oder nach einer Alternative, wie man das dennoch sicher gestalten kann. Man muß ja z.B. eine Software, die ihrerseits keine TLS-Verbindungen unterstützt (oder die neueren Verfahren nicht selbst beherrscht, aber bei "Klartext" dennoch sicher arbeitet) nicht gleich "entsorgen", wenn man sie auch noch hinter einen TLS-Tunnel-Wrapper stecken kann - selbstverständlich in ABWÄGUNG der Vorteile (geringe Investition) gegen die Nachteile (ja, ältere Software kann unsicherer sein als neue und wenn sich das nicht anderweitig kompensieren läßt (mit akzeptablem Aufwand), dann muß man sich auch "trennen" können - oder explizit weitere Komplexität (Proxies, etc.) in Kauf nehmen).

Das Auslagern auf ein weiteres Gerät (falls eine Firewall tatsächlich selbst "Quelladressen" filtern kann - nicht so häufig, zumindest nicht im SOHO-Bereich) sorgt dann ja recht erst wieder dafür, daß da früher oder später die Konfigurationen "asynchron" werden und wenn das obendrein nicht "in einer Hand" liegt, sondern noch "auf Zuruf" funktioniert (das Beispiel von @IEEE zeigt ja sehr schön, wo und wie dabei dann Mißverständnisse zum Problem werden können), wird es noch unübersichtlicher. Richtig fies wird es dann ohnehin erst, wenn ein (relativer) Laie das dann noch selbst konfigurieren soll, der sich damit ansonsten nicht auskennt - oder der Dienstleister arbeitet dann doch wieder "auf Zuruf".

Alles zusätzliche "Fehlerquellen", die eine deutlich größere Delle in der Gesamtsicherheit hinterlassen können, als ein "offener Port", dessen "Service" ordentlich arbeitet ... und im Gegensatz zu "befürchteten" Auswirkungen von weiter oben, lassen sich die Konsequenzen zu großer Komplexität im realen Leben täglich finden. Für eine unsichere Konfiguration (auch bzw. erst recht im Zusammenspiel mehrerer Komponenten) braucht es gar keinen offenen Port mehr und bei einer SICHEREN Konfiguration ist auch der offene Port mehr eine theoretische Gefahr, als eine reale. Ich weiß auch, daß so mancher gelernt hat: "Immer erst mal alles zumachen und nur das, was benötigt wird, dann öffnen." - nur schließt das eben auch ein Öffnen, wo das Sinn macht, nicht per se aus.



Theoretisch könnte man sich sogar auf den Standpunkt stellen, daß ein zusätzlicher VPN-Server, den man dann betreiben will und der NUR dazu dient, den Zugang zu einem ohnehin gehärteten Dienst zu ermöglichen, ebenso wieder ein potentielles Einfallstor für weitere Angreifer bildet. Denn woher weißt Du jetzt, daß es am Ende nicht gerade der VPN-Server ist, der einem Angreifer den Zugriff ermöglicht?

Von dem erwartest Du ja ebenfalls, daß er seinerseits nicht einfach so durch irgendwelche Sicherheitslücken angreifbar ist - wenn der dann einem erfolgreichen Angreifer aber sogar noch das "gesamte Netz" öffnet (weil es häufig auch wieder keine zusätzlichen internen Segmentierungen bzw. "trust domains" gibt - irgendwie schwanken die Beispiele (m.E. bei uns beiden) ja auch immer zwischen SOHO und SMB hin und her), hast Du Dir mit diesem zusätzlichen Dienst erst richtig einen Bärendienst erwiesen.

Aber denken wir auch noch mal in einem "SIP-Kontext" über die Sicherheit nach, die Du mit einer Firewall tatsächlich erreichen kannst, WENN es die von Dir als "Fakt" angenommenen Schwachstellen gibt und die einem Angreifer bekannt sind.

Meinetwegen ein Buffer-Overflow in einem SIP-Parser, der falsch/schlecht programmiert ist - hier gab es solche Schwachstellen ja auch tatsächlich schon, wenn ein SIP-Stack dann für den Message-Body nur die (falsch angegebene) Länge im Header nimmt, damit einen Buffer alloziert und dann dennoch die KOMPLETTE Message, deren Body NATÜRLICH länger war als im Header angegeben, in diesen zu kleinen Buffer einlesen läßt - ein geradezu "klassischer" Buffer-Overflow.

Jetzt hat der Angreifer diese Lücke gefunden, mit der er eine bestimmte Software als SIP-Endpoint angreifen kann und das so weit perfektioniert, daß er damit einigermaßen sicher eine "reverse shell" auf dem angegriffenen Gerät starten kann. Das wäre ja so ein Szenario, wie Du es oben im Zitat wohl meinst, oder?

Wer jetzt seine "Sicherheitsstrategie" nur darauf stützen will, daß er einfach dafür sorgt, daß dieser Angreifer sein Paket nicht durch eine vorgelagerte Firewall bringen wird, der staunt dann ebenso schnell, wie Du es von mir erwartest, wie WENIG ein "geschlossener" Port in einer Firewall vor einem solchen Angriff WIRKLICH schützt. Was muß ich denn für einen erfolgreichen Angriff wissen? Nehmen wir mal an, das Problem tritt auf einem Speedport-Router auf, der tatsächlich nur "ausgehende SIP-Verbindungen" nutzt und ansonsten mit Keepalives arbeitet. Da es keine "permanente Freigabe" für den Port 5060 gibt und die ausgehenden Verbindungen entweder von Port 5060 oder auch von irgendeinem zufälligen Port (dann braucht's "rport" - RFC3581) kommen, ist das ja "safe", oder?

Selbst HIER spielt es nun mal noch eine Rolle, welche weiteren Umstände GENAU zusammenkommen ... WENN das eine UDP-basierte Verbindung ist und der Angreifer erkennen (oder "erraten") kann, was da wohl die Gegenstelle sein könnte, zu der die ausgehenden Verbindungen aufgebaut wurden, dann gibt es nicht mehr so viele Permutationen aus IP-Adressen von Registraren und Zielports an einem Router, die man "durchprobieren" müßte, um mit einem gefälschten Absender seinen Angriff dennoch bis zum SIP-Stack durchzubringen ... sogar das "Durchprobieren" aller 64K Möglichkeiten (minus ein paar wenige) bei der Portnummer ist dabei ohne weiteres möglich. Weiß ich z.B., daß in D vorwiegend die Telekom diese verwundbaren Geräte im Einsatz hat, scanne ich einfach die IP-Bereiche, aus denen bekanntermaßen die dynamisch zugewiesenen IP-Adressen für Telekom-Kunden stammen.

Da schützen - in Anbetracht der "Rahmenbedingungen", die Du selbst vorgegeben hast - also auch fehlende "Portfreigaben" gar nicht wirklich vor einem Angriff ... was schützt, ist das Schließen der Schwachstelle und nicht das "über den Zaun werfen" des Problems in Richtung Firewall. Oder eben auch eine passendere Konfiguration der SIP-Verbindung (wenn der Registrar das unterstützt), ebenfalls wieder an der RICHTIGEN Stelle ... denn mit TCP anstelle von UDP ist ein SOLCHER Angriff dann tatsächlich wieder schwerer. Damit ist dann aber der entscheidende Punkt gar nicht mehr die Frage, WIE ein Angreifer jetzt den Buffer-Overflow auf das Gerät bringt, sondern WAS das Gerät damit macht.

Zu konstruiert? Das sähe ich bei diesem hier:
Und die Ebene der Transportverschlüsselung ebenfalls nicht. "Ups, das Backup wurde mit einer älteren SSL Bibliothek, die verbuggt war, verschlüsselt und unverschlüsselt übertragen. Das kann jetzt jeder, der den Traffic mitgeschnitten hat entschlüsseln"
ja genauso ... da findet sich also jetzt irgendwann später eine Verwundbarkeit in einer SSL-Bibliothek, mit der ein Backup verschlüsselt wurde? Schon da bin ich skeptisch ... solche "Verwundbarkeiten" betreffen ja in aller Regel dann einen Schlüsselaustausch (oder Angriffe auf andere "Dialoge", wo der Angreifer selbst Daten beeinflussen kann, die er an einen Service sendet), den man dann "belauschen" oder "nachvollziehen" kann - wo fände der bei einem Backup jetzt statt?

Die Daten an sich werden ja dann in aller Regel symmetrisch verschlüsselt - da gibt es zwar auch "Verwundbarkeiten" (die Verwendung eines ECB-Modes wäre da ja ein gerne genommener Fehler, der aber auf falscher BENUTZUNG durch den jeweiligen Programmierer beruht), aber da ist nur wenig zu "belauschen" und ein "Ups, war verbuggt." ist an sich recht unwahrscheinlich. Aber gut ... nehmen wir auch das noch an.

Kann ich bei weiteren Überlegungen davon ausgehen, daß diese "verbuggte" SSL-Bibliothek (oder nennen wir sie "Crypto-Library", weil ja z.B. OpenSSL - und die meisten mir bekannten TLS-Stacks ebenso - die Implementierung der kryptographischen Algorithmen von der Implementierung von Übertragungsprotokollen trennt) zum Zeitpunkt der Übertragung der Backup-Daten dann nicht auch schon "älter" war? Das versteht sich (hoffentlich) von selbst, aber ich will es dennoch explizit festhalten. Gleichzeitig muß jetzt ein Angreifer diese Übertragung auch noch "auf Vorrat" mitgeschnitten haben, damit er sie später irgendwann mal dekodieren kann. Na meinetwegen auch das noch ...

Aber jetzt komme ich zu der für mich dann spannenden Frage: Wieso ist denn dann in Deinem Szenario ein VPN und/oder eine TLS-gesicherte Verbindung IRGENDWIE sicherer als die Verschlüsselung dieses Backups? Selbst WENN es tatsächlich eine Möglichkeit gibt, die verwendete symmetrische Verschlüsselung für die Backup-Daten zu brechen, wieso ist davon dann die symmetrische Verschlüsselung, die ja sowohl bei VPN als auch bei TLS nach dem Schlüsselaustausch dann ebenso verwendet wird, nicht betroffen?

Dreimal mit einer verwundbaren Implementierung verschlüsselt ist zwar aufwändiger zu entschlüsseln, aber keinesfalls sicherer. Und selbst WENN man solche Befürchtungen hegt, daß irgendwann mal einer der aktuellen Algorithmen für symmetrische Verschlüsselung wieder "gebrochen" werden kann - dann DARF man die Daten natürlich auch doppelt verschlüsseln. Dann aber bitte auch nicht nur auf dem Transportweg - denn im Gegensatz zu einem "Mitschnitt" bei der Übertragung, der schon genau zum richtigen Zeitpunkt erfolgen muß, ist ein nicht-autorisierter Zugriff auf die übertragenen und am Zielort für längere Zeit gespeicherten Daten ja viel wahrscheinlicher (dort lagern sie eben auch länger) als ein "Live-Mitschnitt".

Jedenfalls wenn man jetzt mal nicht "den Geheimdienst" (oder andere "lawful interception"-Szenarien) nehmen will - denn dann kann man beim Backup auch eine Hausdurchsuchung und Beschlagnahme nach StPO annehmen. Da wären die Daten (wenn man der These "Zweimal verschlüsselt ist besser als einmal - zumindest mit verschiedenen Algorithmen." folgen will) mit einer verwundbaren, einmaligen Verschlüsselung dann also genauso "schutzlos", wie Du das für den Transportweg festhalten möchtest.

Das ist Arbeit, das machen wir nicht. Das kann doch kein valides Argument sein.
DAS ist gar nicht das entscheidende Argument ... das ist KOMPLEXITÄT und angesichts dessen, daß Du selbst irgendwo weiter vorne auf "KISS" hingewiesen hast, verwundert mich das dann doch.

Noch was anderes: Was ist denn, wenn es nicht nur um einen Dienst geht, sondern um mehrere und der Mitarbeiter verlässt das Unternehmen?
Man kappt den VPN Zugang ist sich sicher, dass der Mitarbeiter draußen ist. Du brauchst nicht sofort x Accounts abzustellen und hoffen, dass du an alle gedacht hast.
Hat der Mitarbeiter vielleicht Zugangsdaten von Kollegen herausbekommen? Ohne VPN hast du jetzt ein Problem.
Auch das finde ich nicht sehr plausibel ... der Mitarbeiter hat also von Kollegen Zugangsdaten erhalten, freiwillig oder "ausgespäht"? Aber hier dann auch wieder nur die für den Dienst und nicht die für das VPN? Weil das VPN ja gar nicht mit PSK arbeitet, sondern mit "persönlichen Zertifikaten" und die auch noch auf einem Crypto-Stick gespeichert sind? Dann ist das vermutlich schon mal kein WireGuard-VPN, denn da gibt es zwar private und öffentliche Schlüssel, aber keine "chain of trust" und damit auch nichts zu zertifizieren - das ist "Punkt-zu-Punkt" und wird spätestens als "Netz" sehr unübersichtlich beim Konfigurieren.

Wie eigentlich jede VPN-Lösung ohne zentrale PKI (ab einer entsprechenden Anzahl von Peers) - auch OpenVPN ist da keine Ausnahme und IPSec ist "legendär", was die Konfiguration angeht. Noch heute arbeiten viele VPN-Gateways bei CISCO-IPSec mit "Gruppenschlüsseln" (die sind dann auch "shared" - eben innerhalb einer solchen "Gruppe") und danach dann noch mit XAuth und einer (eigenen) Benutzeridentifikation. Das ist am Ende auch nichts anderes als ein "Login" und genauso von "credential sharing" gefährdet, wie das von Dir beschriebene.

Aber Du hast ja gar nicht auf ein "spezielles VPN" abgestellt - ich kann also auch nicht wirklich entscheiden, ob das von Dir präferierte und verwendete jetzt schon dabei war, welche Topologie(n) dabei genutzt werden, wieviele Benutzer es zu verwalten gilt, etc. ... ich hatte aber gleichzeitig auch schon in meinem Beispiel geschrieben, daß der Zugang zusätzlich über einen zweiten Faktor gesichert wird - nämlich über TOTP (Time-based One-Time Passwords - RFC 6238), was ein "credential sharing" schon mal deutlich komplizierter macht und auch ein Ausspähen unwahrscheinlicher, selbst wenn da jemand eine Kamera oder einen Keylogger installiert hat. Das ist ja auch das, was von vielen Diensten (die nun mal für ihre Kunden ERREICHBAR sein müssen) als "Zwei-Faktor-Authentifizierung" verwendet wird, um sich gegen gestohlene Zugangsdaten (die müssen ja nicht absichtlich geteilt werden) doch ETWAS besser zu schützen.

Und da ist es dann (wenn man jetzt nicht auch noch dabei einen "Austausch" von Zugangsdaten unterstellt und dann kann man das eben für diese Daten für VPN-Zugänge ebenso tun) genauso einfach, dem ausgeschiedenen Mitarbeiter den Zugang zu verbauen. Zumal es mir eben auch nicht einleuchtet, wieso ich zwar den VPN-Zugang des Mitarbeiters invalidieren sollte, aber seine restlichen Zugangsdaten nicht (außer es IST tatsächlich schon so komplex (wie paßt das dann zu KISS), daß ich die richtigen Stellen gar nicht mehr alle zusammen bekomme) - ist es da nicht einfacher, das für diese ebenfalls zu machen? Was passiert denn mit den alten, nicht invalidierten Credentials, wenn der ehemalige Mitarbeiter jetzt doch noch irgendwie einen Zugang zum Netz erlangt? Vielleicht reicht es ja schon, wenn er einen RasPi per LAN-Kabel an die Netzwerkdose stecken kann, während er seinen Schreibtisch ausräumt, weil er gerade gefeuert wurde (und sein VPN-Zugang ist auch schon weg)?

Jedenfalls dürfte es nicht wirklich einen Unterschied bewirken, ob ich den Key für die TOTP-Generierung (auf der Seite der Benutzerverwaltung des Dienstes natürlich) lösche oder eine VPN-Verbindung. Außer der Tatsache, daß selbst bei Verwendung einer VPN-Verbindung der Dienst NATÜRLICH auch weiterhin seine eigene Berechtigungsprüfung (aka Benutzerverwaltung, wenn es "zentral" nichts gibt) braucht - im schlechtesten Fall sind dann sogar noch die Verwaltung der Benutzer und die Verwaltung der VPN-Verbindungen getrennt, was die Wahrscheinlichkeit für "Artefakte" dann wieder erhöht (aber auch erst DURCH die höhere Komplexität des "Gesamtkunstwerks").



Reicht das als Erklärung?
Als Erklärung nicht, aber als ein verklausuliertes "Ich weiß es auch nicht und kann ebenso nur raten." habe ich das JETZT verstanden - und noch mal: Ich wollte Dir mit der Frage nach Deinem Hintergrund keinesfalls einen Tort antun.



wie du es hier vorschlägst, ausschließlich bestehendes Nutzen
Schade ... ich hätte erwartet, daß ich mit meiner (eher ausführlichen) Darlegung auch vermitteln konnte, daß es immer eine ABWÄGUNG ist und daher ein "ausschließlich" in dem zitierten Text gar nicht stimmt.

Aber das hier:
Sicherheit ist kein Zustand, sonder ein Prozess.
unterschreibe ich auch so ... ich habe auch nichts anderes behauptet. Und vor allem ist es eben (um mal wieder zu den Portfreigaben zurückzukehren) auch kein "punktueller" Prozess, bei dem jeder "nur seins" machen kann - und am Ende mit dem Vermeiden von Freigaben für benötigte Dienste an anderen Stellen eine Komplexität hinzukommt (solange sie nicht wirklich der Aufgabenstellung angemessen ist), die dann ihrerseits wieder neue Gefahren für eine sichere Gesamtlösung(!) birgt oder wo das Thema "Sicherheit" dann eben in Richtung Firewall oder auch zum VPN-Server über den Zaun geworfen wird, womit man sich um den Rest (u.a. dann auch das Beseitigen von bekannt gewordenen Schwachstellen) nicht länger kümmern muß. Wenn Du so etwas noch nie erlebt hast ("WIR haben ja eine Firewall, uns KANN nichts passieren."), dann arbeiten wir eben in unterschiedlichen Welten.

Noch mal ... ich bin absolut FÜR Sicherheit - nur eben in einem Maße, in dem sie auch wirklich einen zusätzlichen Gewinn bzw. Nutzen bringt. Leider ist das dann aber eben häufig auch so, daß die "projektierte Sicherheit" im Arbeitsalltag der Leute "hinderlich" ist (gerade auch dann, wenn sie nicht mit "Augenmaß" konzipiert wurde, sondern nur als "bei drei Kondomen übereinander ist noch nie etwas passiert" und "Zuviel Sicherheit KANN es gar nicht geben, es ist doch nur gut gemeint.") und dann werden durchaus vernünftige Mittel und Möglichkeiten nicht mehr genutzt bzw. die Leute suchen nach ihren eigenen Wegen, sich die Dinge wieder leichter zu machen. Auch bei Verschlüsselung (und Sicherheit allgemein) ist "viel hilft viel" nicht immer richtig und kann an einem gewissen Punkt dann auch wieder ins Gegenteil umschlagen.

Ein schönes Beispiel dafür WAREN doch Policies in Unternehmen, wie oft die Leute ihr Zugangskennwort zu wechseln hätten und wie komplex so ein Kennwort zu sein hätte ... das Ergebnis, was man zig-tausendfach in der Praxis erleben konnte: Unter irgendwelchen Schreibtischunterlagen, Telefonen, Blumenvasen, Tastaturen klebten Zettel mit Listen irgendwelcher Kennwörter, weil oft auch die letzten X verwendeten nicht erneut genutzt werden durften - eine wahre "Fundgrube", weil die Leute dann eben auch dazu tendier(t)en, die Passwörter zwischen verschiedenen Diensten zu "swappen" und man damit gleich noch weitere Chancen beim "Raten" hat.

Wieviele Prozent von "Einbrüchen" in geschützte Dienste sind wohl auf das eigene(!) "credential sharing" - über mehrere genutzte Dienste hinweg - zurückzuführen? Viele ... AUCH ein Grund, warum "seriöse" Dienste im Internet eigentlich nur noch mit Zwei-Faktor-Authentifizierung arbeiten, wenn die Dienste ein entsprechendes "Sicherheitsniveau" brauchen, weil es um "personal data" oder sogar finanzielle Transaktionen (aka "Einkäufe") des Kunden aus hinterlegten Zahlungsinformationen geht.

Auch ein Sicherheits-"Prozess" sollte immer das Ergebnis eines plausiblen(!) Sicherheits-"Konzepts" sein und das kann man nicht nur durch die "Schießscharte" der eigenen Zuständigkeit sinnvoll entwickeln.
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.