Messages

106

German - Deutsch / Re: PBX-Plugin

« on: April 17, 2018, 10:29:39 pm »

Was würdet Ihr denn von einem solchen Plugin erwarten. Oder anders, welche Funktionen sind für euch da wichtig.

Allerdings unter der Berücksichtung, das OPNsense eine Firewall Appilance ist, kein FritzBox Ersatz wird. Am Ende kein, kann viel und doch nichts richtig, bleibt.

@JeGr

Sowas wie pfDNS soll dieses Plugin nämlich nicht werden. Eine eierlegende Wollmilchsau ist ja auch nicht mein Ziel. Aber ein Plugin welches niemand nutzt möchte ich auch nicht anfangen zu entwickeln. Es bringt ja nichts an den Nutzern vorbei zu arbeiten.

107

German - Deutsch / Re: [Siproxd & VOIP Support] Problem- und Lösungsthread

« on: April 17, 2018, 10:17:23 pm »

Hallo zusammen,

Seit gestern versuche ich auf meiner OpnSense 18.1.6 VOIP einzurichten.
Leider nur mit mässig Erfolg.

Ich habe eine Basisstation TPG600 von Panasonic und ein entsprechendes Handteil dazu.
Mein Anbieter ist die "Quickline" darüber wird über die MAC Addresse der Basisstation die VOIP Geräte Konfiguriert und sollten eigentlich wenn die richtigen Ports etc. eingestellt werden erreichbar sein.

Leider blickt das gerät in einem hübschen Orange dauerhaft.
Es soll eigentlich auch laut dem Anbieter auf der Firewall "SIP ALG Deaktiviert werden" leider finde ich diese Funktion in OpnSense nicht.

Falls ich hier falsch bin an der stelle bitte ich das zu entschuldigen.
Nachdem ich den Artikel mir durchgelesen habe soll das Plugin für alle VOIP Anbieter sein oder muss für meinen Anbieter speziell was beachten?

Danke für das Feedback.

"SIP-ALG" wirst du in der OPNsense auch so niemals finden. Voll ausgeschrieben bedeutet SIP-ALG, SIP-Application Layer Gateway. Siproxd, wäre so ein "Application Layer Gateway", wenn du diesen nicht benutzt, oder installierst brauchst du den auch nicht auszuschalten. 

Dein Anbieter Quickline , ist der hinter dem Link oder? Ich müsste nur noch ein paar Infos mehr haben.  Die TPG600 von Panasonic sollte eine Konfigurationsurl (HTTP, TR069 etc.) im Webinterface eingetragen haben, darüber holt die sich dann die Konfiguration. Wenn die Station vorkonfiguriert war, einfach mal alle Ports für die Panasonic Station ausgehend offen lassen. Evtl. tut sich dann etwas. Ich kann dir zu der Station auch nicht mehr sagen, denn ich habe weder eine solche, noch komme ich da an Handbücher von Panasonic dran.

Zu deinem Anbieter: Ich weiß natürlich auch nicht ob die ein Separates VLAN für Telefonie bereitstellen, evtl. funktioniert die Autokonfiguration auch nur darüber?? Das müsstest du allerdings selber herausfinden.

Ich hoffe ich konnte dir helfen.

Gruß
NR

108

German - Deutsch / Re: PBX-Plugin

« on: April 16, 2018, 10:17:43 pm »

@fabian

Genau darum geht es den meisten, ein Plugin oder ein OpenSource Produkt kann noch so sicher sein, trotzdem wollen viele das nicht und zahlen dann lieber 6000 - 8000 € Lizenzkosten einer Firma wo sie blind auf die Sicherheit vertrauen müssen.

@JeGR

Mir geht es nur darum, würde das Plugin nur den Kamailio Proxy liefern, müsste ich ggf. ne Anleitung schreiben wie man den Konfiguriert, da das allerdings so kompliziert ist, für Zweck X, Konfiguration Y zu erklären. Mit allem wenn und aber und wieso. Wäre es doch besser ein Plugin zu bauen, was den am meisten benötigten Bereich abdeckt. Statt hinzugehen und in den Anleitungen dann noch erklären zu müssen wie Asterisk, Freeswitch, Yate, etc. über Kamailio sich beim Provider anmelden können.

Wie ich oben schon schrieb:

Sinnvolle Funktionen für Asterisk sind:
B2B = Asterisk registriert sich beim Provider und stellt über den Lokalen SIP Registrar diese Leitung zur Verfügung. Zudem Normalisierung durch Provider Templates.
Provider Templates = Einfache Registrierung bei Providern ohne Try and Error. Zur Ausarbeitung von Providertemplates muss herausgefunden werden, was Provider verändern können um inkompatibel zu einer Standard Konfig zu sein, SIP Header, Auth Header, user-agent, Rufnummern etc. Durch eingrenzen der Möglichkeiten ein Formular entwickeln die das Anpassen vereinfacht, darauf basieren dann die Templates. => Vorausgefülltes Formular. + AGI Skript im Hintergrund, welches sich um die Verarbeitung die den Wählplan betreffen kümmert.
Wahlregeln = Rufsperren, Umleitungen, einfaches Routing
Anrufliste
Interne Anrufe = Festlegen eigener Interner Rufnummern im Bereich XX.
Sicherheit = Schutz vor Missbrauch durch die oben genannten Vorkehrungen.
Konfigurierbar ohne Asterisk und Kamailio Kenntnisse = Durch die hohe Integrationsdichte aller Komponenten. Daher, ein in sich geschlossenes Plugin welches Asterisk und Kamailio in vorkompilierter Form unabhängig von einem Frei Konfigurierbaren Asterisk oder Kamailio Paket mitbringt. Das heißt, eigene Ordnerstruktur und Asterisk oder Kamailio sind nicht separat unabhängig voneinander nutzbar, eben auch wegen der Funktionseinschränkungen.

Natürlich sollte eine Firewall Appilance wie OPNsense keine Telefoniefunktionen bieten und lediglich für den Netzwerkverkehr zuständig sein. Es gibt nur einige Features, die, sobald man die weglässt, es später anfragen gibt ob nicht doch eingefügt werden können. Ich wäre mit dem Plugin schon zufrieden, wenn das Sicherheitskonzept "[Kamailio + Asterisk] mit dem Feature B2B und den Provider Templates wäre.
B2B heißt, dass sich Asterisk beim Provider über Kamailio registriert, und eine Interne PBX im LAN sich nachher am Asterisk auf OPNsense registriert um den Provider Account zu nutzen. Und mehr Features nicht. Der rest würde nur eingebaut werden damit alle die die FritzBox Features wollen auch nicht zu kurz kommen. Nach mir bräuchte ich die ehrlich gesagt nicht. Es geht sich mir da mehr darum, das der "vergewaltigte" SIP Stack der Provider damit aufgelöst wird und an der OPNsense endet. Und das Hacker und Scriptkiddys das Hacken der Asterisk Instanz auf OPNsense so schwer wie möglich gemacht wird, eben durch die Sicherheitsvorkehrungen. Was jeder nachher in seinem LAN macht und ob die Nebenstellen da Passwörter mit "1234" bekommen. Ist dann vollkommen egal. Da jeder Hacker, Cracker und Scriptkiddy so nur bis zu Kamailio kommt. Und weiter nicht mehr. Und das so zu lösen geht nur indem Asterisk eben auch auf der Sense läuft. Aber mit minimalsten Modulen.

Allerdings wie @Alphakilo schrieb, ist das nicht einfach, da jeder Provider sein eigenes Ding macht etc. Das wird noch sehr schwierig werden. Aber so gibt es natürlich dann auch die Möglichkeit, Konfigrationstemplates für SIP-Provider an Zentraler Stelle zu sammeln. Und nach Möglichkeit jedem der eine PBX im LAN betreiben möchte, durch "Plug and Play" seine PBX beim Provider über das Plugin anzumelden.

109

German - Deutsch / OpenVPN - LZ4 Support

« on: April 15, 2018, 05:27:30 am »

Hallo zusammen,

habe dazu nichts gefunden, aber villeicht weiß das ja jemand, ob in oder wenn ja wann OpenVPN LZ4 Kompressions-Support der Gui hinzugefügt wird?

Bisher gibt es ja nur comp-lzo was ja irgendwann wegfallen soll.

https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

Gruß
NR

110

German - Deutsch / Re: PBX-Plugin

« on: April 14, 2018, 11:44:37 pm »

Konferenzräume wären noch geil

Gut die habe ich auf die schnelle vergessen, aber in großem und ganzen soll das Plugin an einigen stellen mehr können als die Fritze an anderen eben weniger. Aber dafür dann richtig und vor allem sicher.

In den meisten Firmen ist es z.B. so, jemand der OpenSource einsetzt ist dann selber für die Sicherheit und im Fehlerfall Verantwortlich. Daher wollen die meistens IT-Chefs gerne nur Software einsetzen wo ihnen die Verantwortung abgenommen wird und der Hersteller dafür in die Bresche springt. Also im Endeffekt jemanden der im Schadensfall zahlt.

Daher denke ich, das dieses Plugin in Zukunft wohl trotz des durchdachten Sicherheitskonzepts, wohl kaum in Firmen genutzt werden wird und es eher Privatleute sein werden, die ihre Fritze gerne entsorgen möchten, die das Plugin dann nutzen.

111

German - Deutsch / Re: PBX-Plugin

« on: April 14, 2018, 11:23:16 pm »

Full disclosure: Mein Arbeitgeber stellt eine kommerzielle VoIP/ISDN-Lösung auf Asterisk-Basis her. Das ist aber nicht der Hintergrund warum ich dich bitte dein Vorhaben zu überdenken. Ich bin hier in privater Funktion. FOSS ist mein kink

Ich finde es gut, das du dich für dieses Projekt interessierst und du bereits aus diesem Bereich kommst. Und das im wahrsten sinne des Wortes dein "täglich Brot" ist. Denn dadurch kannst/darfst/sollst du dich, wenn du möchtest an diesem Plugin beteiligen.

Ich glaube auch du gehst davon aus, dass ich vorhabe auf Kamailio Basis einen neuen SIP-Server zu entwickeln, nein das habe ich nicht, denn ich habe neben OPNsense auch noch ein Privatleben.   

Ich habe es so Verstanden das du einen Kamalio vor einen Asterisk setzt um eine vollständige PBX (ohne DAHDI ) zu implementieren. Inklusive Provisioning von Endgeräten. Und Providertemplates. Im Kontext einer Firewall.

Ich warte auf dein Konzept, aber mein Bauchgefühl sagt mir das die Ziele sehr hoch gesteckt sind, unabhängig von deiner oder mimugmails Expertise (die ich nicht anzweifle). Es geht mir um die reinen Mannstunden. Und den Sicherheitsaspekt. Jail hin oder her, die Attacksurface vervielfacht sich. Müssen ja auch nicht direkt RCEs sein.

Das erläutere ich zusammenhängend weiter unten. Allerdings noch ohne Präsentation.

Und die Richtlinien für SIP und RTP sind nicht so lose wie du denkst[...]

Das hat nur leider niemand den Providern erzählt 

So was wie RFC3261 und 3550 / 4566 wird (meist) eingehalten. Da gebe ich dir Recht. Mir geht es eher um die Vermittlung (pots / inter-provider) und Signalisierung.

Ein Beispiel das ich gerne nehme sind Nummernformate. Welches Format soll die Zielrufnummer haben? Wie unterscheidet es sich lokal, national, international (das Unterscheidet sich auch nochmal per Provider und Zielregion)? Der Brüller: Nationale Sonderrufnummern.

In welchem Header wird die CLIP erwartet? PAI? PPI? Oder doch lieber FROM?
Wie signalisiere ich CLIR? Redirection / reflection?

¯\_(ツ)_/¯

Und dann die Fehlermeldungen... Was kommt bei Besetzt / Rejected zurück? Ungültige Rufnummer? Gesperrtem Account?
Am tollsten sind die Provider die Munter im Fehlerfall mit 200 OK antworten und eine Sprachnachricht über RTP drücken.

Ich kenne keine zwei Provider welche identische Spezifikationen befolgen. Es ist nicht mal garantiert das die Spezifikation innerhalb des selben Providernetzes konsistent sind.
SIP INVITES kommen mit führender +49... von dem einen SBC, 49... von dem nächsten und drei Tage später mit 0..., dann komplett ohne Präfix vom dritten SBC.

Das kenne ich selber, aber klar da du aus der Branche direkt kommst hast du immer damit zu tun und das es einen irgendwann in den Wahnsinn treibt, verstehe ich. Auch das du uns vor einem Projekt bewahren möchtest, welches evtl. niemals Released wird, aufgrund dauernd auftretender Probleme.

Und ein Provider hat heutzutage nichts davon, wenn ihm die Kunden weglaufen, wenn die Telefone aufgrund des SIP Protokollstacks des Providers Probleme machen.

Tun sie nicht! Warum? "Die PBX ist schuld!" Es ist immer, grundsätzlich die PBX.
"Oh. Keine Fritz- / Digitalisierungsbox? Kein Support. Ach du willst nur die Specs? Die kann ich dir nicht geben. Kauf dir lieber die supportete™ PBX©".

Selbst wenn man einen PCAP mit RFC violations (INVITE nach 407 ohne Hash wiederholt, 407 Response ohne NONCE, unilateraler Codecwechsel ohne SDP, COMEDIA ignoriert, ...) vorweisen kann wird es im besten Fall still und heimlich gefixt und ohne Ankündigung ausgerollt. Schuld bleibt *drumroll* die PBX. Es wird gelogen, getrickst und intrigiert. Bis jemand weint.
Zugegeben, es gibt Provider die sehr transparent Arbeiten. Mit denen es Spaß macht solche Fehler auszuräumen. Der staatlich geförderte Monopolist ist keiner davon.

So. Ich gehe jetzt erst mal einen Kaffee trinken um von meinem Nerdrage wieder runter zu kommen. Hoffe ich konnte meine Punkte rüber bringen. Ich will euch nichts böses.

Und das wird auch nie ein Provider zugeben, bestes Bsp. hier: https://forum.opnsense.org/index.php?topic=7483.15. Hätte der Provider jetzt zugegeben, dass er bis dato nur die Fritz Box als VOIP Endgerät anhand des Useragents am System anmelden lässt. Hätte er sich vom Zeitraum an, ab dem per Gesetz die Routerfreiheit garantiert worden wäre sich strafbar gemacht und die Bundesnetzagentur hätte dagegen vorgehen können. Klar gab es früher kein Gesetz, aber immerhin hätte der Kunde aufgrund von Diskriminierung ein Sonderkündigungsrecht. Und das möchte kein Provider. Also bleibt es gegenüber dem Kunden so, das alles funktioniert (auch wenn das nicht der Fall ist) und am Ende wenn es dann mal funktioniert niemand was an einem System geändert hat. 

Nun zu meiner Erklärung von oben, dazu zitiere ich mich ersteinmal selbst:

Naja, das es keine gute Idee ist, auf einer Firewall eine Vollwertige PBX laufen zu lassen, mal den Sicherheitsaspekt beiseite gelassen ist der, dass eine Vollwertige PBX zuallererst auch andere Dienste bereitstellt.
z.B. vollwertiges Endgerätemanagement, das heißt, Boot und Konfigurationsserver (DHCP, DNS, TFTP) sowie einen Datenbankserver für die Konfiguration sowie LDAP für ein Zentrales Telefonbuch.

Mal angenommen es gäbe für OPNsense Asterisk als Plugin, was alleine schon an Integrationsarbeit in die Weboberfläche und ins Konfig Management, eine Arbeit von mehreren Monaten wäre. Würde es nicht lange dauern und es gäbe Featurerequests in diese Richtung, diese oben genannten Features nachzureichen.

Indem Falle wäre sogar einfacher gleich direkt eine eigenständige PBX Distribution aus dem Boden zu Stampfen. Die eben nur eine Telefonanlage bereitstellt und einfach zu konfigurieren wäre.

Leider gibt es großartige keine OpenSource PBX Distributionen mehr, da die meisten alle Kommerzialisiert sind.
Dazu gehört meiner Meinung nach auch FreePBX. Sie wird zwar von vielen genutzt aber nur weil es keine alternativen gibt. Und FusionPBX ist zwar ohne Vorbehalte Frei verfügbar, aber ebenso schwer zu konfigurieren, selbst wenn man eine Anleitung hat. Das Freeswitch Wiki ist leider auch nicht wirklich gut Dokumentiert.

Wer Asterisk und Freeswitch über die Konfigurationsdateien konfigurieren kann, der braucht natürlich keine GUI, aber für alle die ihre FritzBox los werden wollen ist das wiederum keine Lösung. Eben sowenig eine Mobydick von Pascom.

Nun zu den Sicherheitsaspekten, würde Asterisk auf OPNsense als Plugin vorhanden sein, gäbe es irgendwann hier im Forum lauter Beschwerden, gehackt worden zu sein etc. Da Chan_SIP und PJ_SIP leider noch nicht ausgreift sind in Public Netzwerken zu lauschen. Und für Chan-SIP existieren Mittlerweile Scripte um Automatisiert Buffer Overflows zu erzeugen und dessen Sicherheitslücken sind ja nun weit bekannt. PJSIP soll ja in Zukunft CHAN_SIP ersetzen, ist aber leider noch nicht so ausgereift das es wirklich funktioniert.

Bei FreeSwitch gibt es diese Problematik nicht, aber dafür ist diese Software auch nicht so weit verbreitet. Es wurden dort zwar Dinge völlig neu bei der Programmierung durchdacht und dabei raus gekommen ist ansich eine gute Software, die aber leider etwas schlecht Dokumentiert ist und von Hand auch nur schlecht konfiguriert werden kann. Und leider Frisst FreeSwitch auch ziemlich viel CPU und RAM wenn man darüber viele Calls abwickeln möchte.

In FusionPBX ist Fail2Ban allerdings fest integriert. siehe hier

Man muss natürlich nicht mit dem von mir hier geschriebenen Meinungskonform gehen. Viele mögen auch eine andere Sichtweise auf die Dinge haben. Aber du kannst relativ gefahrlos Asterisk oder FreeSwitch hinter OPNsense mit dem Siproxd Plugin betreiben. Und das sollte ohnehin die einzige Aufgabe sein die eine Firewall wie OPNsense mit VOIP hat. Nämlich das Relayen von SIP und RTP. So findet zwar keine Direkte Komunikation mit den Provider Servern statt.

Aber auch eingehende Anfragen auf deine IP werden gar nicht an deine PBX weitergeleitet, sofern in Siproxd keine Information hinterlegt ist, das dies erwünscht ist. Angriffe enden also am Proxy ohne an die PBX weitergeleitet zu werden. Das heißt Ausländische Häcker könnten auch bei einem Konfigurationsfehler von Asterisk nicht teure Anrufe über deine Accounts leiten. Da Siproxd dich ja nicht bei deinem Provider registriert.

Villeicht wäre https://www.astlinux-project.org/ was für dich?

Bei Fragen bitte einfach wieder schreiben.

Und dieser Meinung bin ich auch weiterhin, auf einer Firewall oder UTM, hat keine Vollwertige PBX etwas zu suchen.
Aber was man machen kann, anstelle der Bereitstellung eines nur SIP und RTP Proxys, ein Modulares Bündel aus beidem bereitzustellen was sich durch sinnvolle Funktionen ergänzt. Soviel wie möglich, soviel wie nötig.

Daher ist Asterisk hier ideal aufgrund seiner Modulbauweise. Bei Asterisk wie auch Kamailio werden nachher alle Module entfernt die nicht gebraucht werden. Oder eher gar nicht erst kompiliert. Zudem ist PJ_SIP ein SIP Stack der nicht nur von einer Firma betreut wird, das heißt Fehler und Bugs werden hier evtl. viel schneller gefixt. Zudem ist der SIP Stack mit neueren Geräten eher kompatibel als chan_SIP. Das ist meine Subjektive Wahrnehmung.

Asterisk wird nur die Dinge bereitstellen die absolut nötig sind um sich bei einem Provider zu Registrieren, um ein Telefon an Asterisk zu Registrieren. Und einen einfachen Wählplan, mit wenigen Funktionen dafür aber sinnvollen.

Asterisk wird dabei die Externe Kommunikation nicht selbst übernehmen, sondern diesen Komplett über Kamailio abwickeln. Asterisk wird nur auf localhost horchen.

Kamailio soll hier den SIP Datenverkehr überwachen, und Asterisk Telefonen die Registrierung an Asterisk ermöglichen und Asterisk in Form eines Outbound Proxys die Anmeldung bei SIP Providern ermöglichen.

Überwachen heißt z.B. die Erkennung von DDoS Attacken und BruteForce Angriffe etc. Um Angriffe dann wirkungsvoll zu sperren soll Kamailio dann am besten von Fail2Ban unterstützt werden. Was aber nicht gehen wird, da Fail2Ban mit OPNsense so nicht kompatibel sein wird, da die Gefahr besteht das dann evtl. die Firewallregeln über den Haufen geworfen werden. Hier muss dann ein ähnliches Tool her was mit OPNsense kompatibel ist.

Kamailio selbst soll möglichst von Asterisk => Internet Stateful laufen. Während vom Privaten LAN hier ausnahmen existieren sollen, damit die Register Request von Lokalen Subnetzen auch an Asterisk weitergeleitet werden.

Asterisk wird hier also nicht im Realtime Mode mit Kamailio zusammen betrieben.

Sinnvolle Funktionen für Asterisk sind:
B2B = Asterisk registriert sich beim Provider und stellt über den Lokalen SIP Registrar diese Leitung zur Verfügung. Zudem Normalisierung durch Provider Templates.
Provider Templates = Einfache Registrierung bei Providern ohne Try and Error. Zur Ausarbeitung von Providertemplates muss herausgefunden werden, was Provider verändern können um inkompatibel zu einer Standard Konfig zu sein, SIP Header, Auth Header, user-agent, Rufnummern etc. Durch eingrenzen der Möglichkeiten ein Formular entwickeln die das Anpassen vereinfacht, darauf basieren dann die Templates. => Vorausgefülltes Formular. + AGI Skript im Hintergrund, welches sich um die Verarbeitung die den Wählplan betreffen kümmert.
Wahlregeln = Rufsperren, Umleitungen, einfaches Routing
Anrufliste
Interne Anrufe = Festlegen eigener Interner Rufnummern im Bereich XX.
Sicherheit = Schutz vor Missbrauch durch die oben genannten Vorkehrungen.
Konfigurierbar ohne Asterisk und Kamailio Kenntnisse = Durch die hohe Integrationsdichte aller Komponenten. Daher, ein in sich geschlossenes Plugin welches Asterisk und Kamailio in vorkompilierter Form unabhängig von einem Frei Konfigurierbaren Asterisk oder Kamailio Paket mitbringt. Das heißt, eigene Ordnerstruktur und Asterisk oder Kamailio sind nicht separat unabhängig voneinander nutzbar, eben auch wegen der Funktionseinschränkungen.

Soll also Asterisk oder Kamailio auf dem System für etwas anderes benutzt werden, muss das Kamailio oder Asterisk Paket installiert werden.

Was dieses Plugin nie können wird:
Anrufbeantworter, Faxsserver, Provisioning von Endgeräten und alle anderen hier nicht genannten Funktionen. z.B. Capi, Dahdi, etc.

Das Plugin stellt letztlich eine Basis dar, welche es ermöglichen soll, nachgelagerte SIP Clients im LAN sicher zu betreiben und Basisfunktionen dafür bereitzustellen. Alle Funktionen die dieses Plugin nicht kann, können daher einfach von einer Vollwertigen PBX im LAN übernommen werden. Ohne Sicherheitsbedenken für den Betreiber.

Zu den Providertemplates möchte ich noch hinzufügen, das ich dort nach Möglichkeit die Fritze auslesen werde als Arbeitserleichterung.

112

German - Deutsch / Re: PBX-Plugin

« on: April 13, 2018, 11:58:04 pm »

Genau, ich möchte aber dafür sorgen das sowohl das Plugin, als auch die Programmierung nachher "einfach" vonstatten gehen, ging bei Siproxd ja auch relativ einfach. Aber viel vorarbeit wird es allemal.

Du könntest mal herausfinden wie, SSH und Webzugriff bei Fehlversuchen geblockt werden. Da ist ja so ein ähnliches Script wie Fail2Ban hinter, sowas möchte ich gerne auch noch einbauen. Habe schon im Source Code gewühlt aber nichts gefunden. Einfach Fail2Ban nehmen wird da nämlich nicht gehen denke ich.

Achso PHP oder Python nur für AGI Skripte, weil damit mehr möglich ist als mit dem Asterisk Dialplan.

113

German - Deutsch / Re: VoIP / siproxd

« on: April 13, 2018, 10:26:59 pm »

@Alphakilo

Hätte ich nicht besser erklären können. Vielen Dank an der Stelle.


@Emma

Keine sorge, der Proxy managend keine deiner Rufnummern. Dient aber lediglich als Vermittlungsschicht.

Du brauchst den Proxy dann erst wenn deine Geräte kein NAT beherrschen oder Probleme damit haben.
z.B. hast du einen Telekom Speedport, läuft auf diesem bereits ein Siproxd Prozess, der Transparent das NAT Handling für VOIP ermöglicht. Telekom macht es hier den Kunden "einfach". Der z.B. ein Gigaset Telefon etc. an seinem Telefonanschluss einsetzen möchte. Zudem stellen die Speedports auch keinen SIP Registrar bereit, wie es z.B. deine fritzBox macht.

Noch eine Anmerkung, es wäre einfacher gewesen, du hättest alle Probleme und Fragen zu OPNsense in einen Thread geschrieben, statt mehrerer, denn es gibt durchaus Themenbereiche die du damit getrennt hast die allerdings zusammengehören: Bsp.: https://forum.opnsense.org/index.php?topic=7663.0 und dieser Thread.
Auch z.B. der Thread "PPPoE Geschwindikeit herausfinden" und "Telekom DSL sehr langsam".

Ich weiß zwar das du das unbewusst gemacht hast, aber ich habe dazwischen auch schon den Überblick verloren.

114

German - Deutsch / Re: PBX-Plugin

« on: April 13, 2018, 10:13:50 pm »

Jungs... Ich will nicht meckern. Das wäre sicher Ruhmreich. Aber ihr übernehmt euch da gewaltig.
Ich kenne Firmen die eigene Teams allein für Providerintegrationen unterhalten.

Die VoIP-Protokolle (SIP / RTP) sind für fast alle Provider eigentlich nur lose Richtlinien. Je größer der Provider desto schlimmer der Protocolabuse.

Was ich sagen will: Das einmalig zu coden ist die eine Seite. Maintainen eine ganz andere Hausnummer.

Ich finde die Idee wirklich charmant, aber ich sehe keine Möglichkeit das in irgendeiner Weise sicher und langfristig stabil zu implementieren.

Falls ihr euch doch dazu entscheidet das durchzuziehen, meldet euch doch nochmal bei mir. @mimugmail hat meine Emailadresse.

Bitte erst auf meine Präsentation warten und keine voreiligen Schlüsse ziehen. Übernehmen werden wir uns da nicht, weil die ganze Sache durchaus Struktur bekommt. Eine vollwertige PBX wird das sicher nicht (Gründe habe ich im zweiten Post genannt). Und es wird auch nichts neu gecodet, außer vielleicht das Frontend und einige Module die entweder in PHP oder Python abgearbeitet werden. Aber auf die "schnelle" geht das sowiso nicht. Planung ist hier der Schlüssel um den Weg ins Ziel zu finden.

Ich glaube auch du gehst davon aus, dass ich vorhabe auf Kamailio Basis einen neuen SIP-Server zu entwickeln, nein das habe ich nicht, denn ich habe neben OPNsense auch noch ein Privatleben.   

Und die Richtlinien für SIP und RTP sind nicht so lose wie du denkst, vor einigen Jahren hätte ich dir damit noch recht gegeben, da noch neben SIP, H323 im Raum stand. Und Mittlerweile sieht es zumindest hier in Deutschland besser mit SIP aus, als ich gedacht hätte. Wenn es mit Provider im Ausland nachher Probleme geben sollte, gibt es ja die Möglichkeit der Anpassung des Plugins daran.

Und ein Provider hat heutzutage nichts davon, wenn ihm die Kunden weglaufen, wenn die Telefone aufgrund des SIP Protokollstacks des Providers Probleme machen.

Habe hier z.B. einen Cisco 2911 Router mit Voice Gateway Funktion SIP => ISDN. Und selbst der meldet sich noch bei Telekom Deutschland LAN an. Problemlos sogar mit Firmware von 2012 (IOS 15.2.3? glaube ich).

PS: Wenn ich die Präsentation vorstelle, darf sich natürlich gerne darüber ausgelassen werden, denn jede Meinung dazu ist mir da wilkommen.

115

German - Deutsch / Re: PBX-Plugin

« on: April 10, 2018, 06:09:23 am »

Wird es auch, denn ich muss dafür ganz schön viel testen. Und ich werde mal wieder die FritzBox rauskramen und schauen ob sich die Provider Templates die AVM da eingepflegt hat nicht für dieses Projekt nutzen lassen. 1:1 übernehmen geht sowiso nicht, aber wenigstens steht dadrin welche Konfiguration welcher Anbieter erwartet. Kein Gerät ist ja mit so vielen Providern "out of the Box" kompatibel wie die FritzBox und ich fände es gut das direkt mit einzubauen.

Habe zudem in Erfahrung bringen können das PJSIP wohl endlich Produktiv nutzbar und fest in Asterisk 16 LTS gebündelt wird. Das macht die Sache dann zwar nicht einfacher, aber wird dann wohl kompatibler und sicherer sein als weiterhin mit chan_sip zu arbeiten.

Ich werde erstmal eine PDF-Präsentation mit den wichtigsten Details erstellen und mit einem Schaubild der Grundfunktionalität.

116

German - Deutsch / Re: PBX-Plugin

« on: April 09, 2018, 11:28:36 pm »

Also soweit so gut, habe aus dem Kamailio IRC die Antwort bekommen, das es ohne weiteres nicht möglich ist, nur Kamailio als einfache PBX einzusetzen. Das mag für nur WebRTC Anwendungen funktionieren, aber nicht so wie ich mir anfänglich dachte.

Ich stelle ein PDF zusammen indem ich Detailliert vorstelle, wie sich so etwas umsetzen lässt und welche Hürden das ganze noch mit sich bringt.

Eines nehme ich noch vorweg, Asterisk und Kamailio, wo Kamailio alle SIP-Funktionen übernimmt, setzt immer eine Datenbank vorraus, auf die Kamailio und Asterisk zugreifen können müssen. Das nennt sich dann Asterisk Realtime. Das kann und möchte ich aber so nicht realisieren, zuerst wegen der Datenbank und zweitens da dieses System viel zu Oversized wäre für ein paar Telefone und VOIP Provider Accounts.

Ich denke ich werde das so lösen, dass Asterisk alles macht, vom Dialplan über die Provider Registrierung sowie Extension Bereitstellung. Aber Asterisk wird nur an den localhost gebunden bsp. 127.1.0.8:5060. Sodass jede Kommunikation von und zu Asterisk über Kamailio laufen muss. Damit wird Kamilio die Schnittstelle zum WAN sowie zum LAN. Kamailio übernimmt als Proxy, alle NAT, STUN und Sicherheitsfunktion wie Anti-Spoofing, Anti-DDoS etc. Aber Kamailio bekommt hier noch Verstärkung durch Fail2BAN. Sodass es nach 3 oder 5 versuchen eine Anwendungssperre in Kamailio sowie eine Firewallsperre durch Fail2Ban gibt.

Mein ziel ist es das jeder Pluginnutzer dieses Plugin nachher so bedenkenlos einsetzen kann wie bisher seine FritzBox.

Soviel schon mal wie ich mir das gedacht habe. Detailliert gehe ich dann darauf im PDF ein, aber dafür brauche ich noch ein paar Tage, da es ziemlich viel arbeit ist, die ganzen Möglichkeiten durchzugehen.

117

German - Deutsch / Re: Anzeige des verbrauchten Datenvolumens im dashboard möglich?

« on: April 09, 2018, 09:38:13 pm »

hmm, da finde ich nichts in der Richtung. Bei was könnte sich das verstecken?

Sowas habe ich hier: https://forum.opnsense.org/index.php?topic=7457.msg33721#msg33721
auch schon gesucht. Scheint leider nicht vorhanden zu sein.

118

German - Deutsch / Re: PBX-Plugin

« on: April 08, 2018, 10:47:11 pm »

Eine Frage noch, kann Asterisk denn nicht nur auf LAN hören (für Clients) und auf WAN nur Outgoing zum SIP-(Trunk-)Provider? Das wäre doch kein großes Sicherheitsrisiko?

Ansonsten Kamailio (ohne MySQL/PGSQL), wir können es ja wieder wie bei siproxd machen?
Aber Voraussetzung xml, oder, eher wahrscheinlich, sqlite?

Ehrlich gesagt wäre mir XML, da auch am liebsten, weil Sqllite ansonsten immer als BLOB in die config.xml müsste. Allerdings weiß ich momentan ohnehin noch nicht so recht ob ich das OPNsense Konfig-Backend so richtig verstanden habe. Eher nicht, denke ich, habe den Code ja auch nur mal überflogen.

Zu deiner Frage zu Asterisk, ja und nein, denn um sich bei einem SIP Provider zu registrieren braucht man erst mal keinen eingehenden offenen SIP Port, aber wenn dieser Anrufe bei mir platzieren soll, muss der Port ja wieder geöffnet sein, sonst kann man ja nicht angerufen werden.

Das ganze ist und bleibt leider ein schwieriges Thema.
Werde das ganze mal durchdenken und dann einige Lösungansätze machen und hier vorstellen.

Bin ja sowiso seit einiger Zeit schon an der Kamailio Konfig dran die Siproxd mal ersetzen soll. Diese wird in Kombination mit Asterisk dann ebenfalls vonnöten sein. Ich werde mich allerdings mal mit den Kamailio Leuten in Verbindung setzen, den besser wäre es wenn man komplett auf Asterisk verzichten könnte.

119

German - Deutsch / Re: PBX-Plugin

« on: April 07, 2018, 11:11:29 pm »

Ich muss gestehen ich bin was Asterisk und Security betrifft kein Experte, trotzdem muss ich doch mal fragen wieso Kamailio sicherer sein soll wie Asterisk?

Also wir hier in der Firma haben ein selbst installiertes Linux mit Asterisk drauf. Wir (der Kollege gegenüber) schreiben unsere Dialplans in txt. Wenn ich da jetzt ein System mit ner GUI hätte wäre doch super?! Es muss ja nicht die Perimeter Firewall sein

Wenn ein Kunde intern im Netz einen Radiusserver braucht würde ich ihm dafür auch ne OPNsense hinstellen, weil es m.M.n. keine anständige GUI für FreeRadius gibt, ausser vielleicht noch pfSense.

Und wenn Unbound auf Forward Lookup Zonen verwalten könnte würde ich auch anfangen zu überlegen

Kamaillio ist eben ein aus Einzelmodulen bestehende SIP Anwendung. Im Grunde so etwas wie lighttpd+PHP nur für SIP und mit noch mehr einstellbaren Funktionen. Während man sich bei Asterisk nur unwesentlich ums SIP Protokoll selbst kümmern muss, kann jemand der nicht das SIP Protokoll versteht mit Kamaillio gar nichts anfangen. Und ich habe selber vor knapp 3 Jahren noch Wochen damit verbracht zu verstehen wie Kamailio den nun funktioniert.
In der Konfigurationsdatei von Kamaillio, geladene Module vorausgesetzt, ist es möglich wirklich jeden Protokollzustand einzeln auszuwerten und so z.B. auch Angriffe in Form von bestimmten SIP Messages direkt zu unterbinden. Das kann Asterisk nicht und ist dort auch nicht vorgesehen.

So sieht z.B. die bei 1und1 und vielen anderen SIP Providern genutzte Infrastruktur aus:
https://www.kamailio.org/events/2013-KamailioWorld/03-Henning.Westerholt-Large-VoIP-Deployments.pdf

In dem Zusammenhang ist auch das hier interessant:
https://www.pascom.net/de/dokumentation/pascom/server/server-installieren/
Denn Pascom rät selbst davon ab Ihr Asterisk Produkt direkt an einer öffentlichen IP zu betreiben. Wie es überall mittels Portforwarding ja gehandhabt werden müsste. Klar stelle ich mir da auch die Frage warum sie Kamaillio nicht in ihre PBX integriert haben, bei der anderen Software von denen, dem Cloudstack, ist Kamaillio dagegen die Zentrale Proxy- und SIP Routinginstanz.

Letztlich bleibt für mich aber eines, wenn selbst ein etablierter Hersteller wie Pascom seinen Kunden davon abrät  die von Ihnen Entwickelte Software so zu betreiben, wie sie normalerweise vorgesehen ist, sollte man doch nach Möglichkeiten schauen diese Probleme irgendwie vorher in den Griff zu bekommen.

Klar kann man auch wie bei dir in der Firma Asterisk so betreiben wie du es beschrieben hast, aber ich gehe mal davon aus, dass dein Kollege genau weiß was er da macht, auch Firewall spezifisch, sonst hätte eure Firma wohl schon eine ziemlich hohe Telefonrechnung bekommen mit Anrufe in Länder wo gar keine Kunden sind, und zu Zeiten in der eigentlich niemand da ist der Telefonieren könnte. 

s. hier: https://www.ip-phone-forum.de/threads/bin-gehackt-worden.295929/#post-2230608

Ist z.B. ein relativ aktuelles Bsp. dafür was ich meine. Wenn sollten die Nutzer doch etwas richtiges bekommen, und nicht etwas was ihnen mehr schaden als nutzen bringt. Zugegeben viele Leute sind als das Forum damals an einen anderen Betreiber verkauft wurde ebenfalls gegangen, daher ist es nicht ungewöhnlich wenn einem das Gefühl überkommt das in einigen Threads buchstäblich nichts los ist.
Und verlangen das jeder Asterisk mal eben konfigurieren kann, wird leider auch mit einer GUI nichts. Außer der Benutzer bekommt gar nicht mit, das Asterisk da drunter werkelt.
Alles in allem kann man aber verallgemeinern, dass jedes Asterisk Produkt, ohne entsprechende Absicherung wie ein Sip Proxy, ein gefundenes Spielzeug für Hacker ist, oder eben Leute die einfach nur kostenlos telefonieren wollen. Und wie ich bereits ähnlich im Vorpost schrieb, hat gerade der Chan_SIP driver in Asterisk viele Fehler wodurch ein Angreifer leicht einen Buffer Overflow auslösen kann. Und da nützt es dann leider auch nicht viel, das in der sip.conf die Einstellungen so gesetzt sind das das normalerweise nicht passieren dürfte.

120

German - Deutsch / Re: Opnsense und Bios Installation auf APU2C4 funktioniert nicht

« on: April 07, 2018, 10:05:00 pm »

probe0:umass-sim0:0:0:0

Ist ein Treiberproblem im Zusammenhang mit deinem USB Stick. Der nicht gestartet werden kann. Und da sich dein Board damit auch nicht flashen lässt kommt die APU wohl auch mit dem Stick nicht klar.

Zum flashen ist es auch besser einen möglichst kleinen USB Stick zu nehmen, ich benutze dafür z.B. immer alte 1-2 GB Sticks. Evtl ist nach dem Bios Flashen dann auch das Problem mit dem San Disk USB Stick gelöst.