OPNsense Forum
International Forums => German - Deutsch => Topic started by: Apfelbaum on March 26, 2018, 12:20:32 am
-
Hallo,
ob ich in diesem Forum richtig bin, weiß ich nicht. Falls ich hier falsch bin: Bitte - wenn möglich - weiterleiten - und: Sorry!
Ich möchte eine Firewall einrichten, welchen ebenfalls die Funktion einer PBX übernimmt. Nach einigem Lesen, glaube ich, gelernt zu haben, dass Asterisk zwar verbreitet, aber überladen und unstrukturiert ist.
Demzufolge suche ich ein Plugin für Freeswitch (https://freeswitch.org) inklusive GUI, z. B. FusionPBX (https://www.fusionpbx.com), sowie fertig implentierten entsprechenden Schutzmechanismen (z. B. FailtoBan, etc.) nebst einfacher Konfiguration.
Gibts so was?
Will jemand das mal implementieren?
Oder gibt es bessere Ideen / Alternativen? Bzw. habe ich mich bezüglich der Suche nach ner Alternative für Asterisk verrant? Wie käme ich in dem Fall zu Asterisk?
Danke
-
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 (http://fusionpbx-docs.readthedocs.io/en/latest/firewall/fail2ban.html)
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/ (https://www.astlinux-project.org/) was für dich?
Bei Fragen bitte einfach wieder schreiben.
-
Zu dem PBX Background kann ich nicht viel beisteuern - als Security Guy nicht meine Baustelle und an der Stelle gehe ich sehr konform mit Nick und sage auch: PBX hat auf einer Firewall (außer in Form von Proxy Möglichkeit weil Gateway) nichts zu suchen. Auch kein Browser, Mailserver & Antispam etc. auch wenn das noch so "praktisch" ist, sind das meines(!) Erachtens Dinge, die in eine nachgelagerte DMZ sollten und dort entsprechend auch auf eine eigene Box/Appliance etc. Schon alleine weil man sich dann nicht damit herumschlagen muss, dass man diverse Komponenten updaten muss oder andere nicht kann, weil es Querabhängigkeiten gibt.
Wenn das aus Stromspar- oder Managing-Gründen auf einer physikalischen Box laufen soll - nunja, ist ja machbar. Dann virtualisiert man gewisse Teile eben (mit den Vor- und Nachteilen bzw. Bedenken aber eben in Abwägung dessen was man braucht).
Interessant an der Stelle z.B. genau mit der gleichen Idee im Hinterkopf (jetzt eher für Unternehmen): https://www.scope7.de/hardware/scope7-proxmox-basic
Genau dafür: eine Appliance, aber durch den Hypervisor Layer eben getrennte Firewall, PBX, AntiSpam etc. Geschichten möglich.
Ansonsten würde mich noch interessieren, wo
"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."
herkommt. Rein informativ, denn ein Kollege von mir setzt gerade wieder ein Projekt mit ner FreePBX um. Das sah mir jetzt nicht so dramatisch aus. VoIP/SIP generell ist keine einfache Baustelle, dass die meisten Sachen da "schwierig zu konfigurieren sind", überrascht mit bei dem Komplexitätslevel jetzt eher weniger. Ist eben kein Klingeldraht mit Kuperader und Telefon mehr :D (manchmal: leider...)
-
OpenSource PBX Distros gibt es ja wirklich nicht mehr viele. Kommerzielle dafür umso mehr.
Damals als Azkozia aufkam als Freie PBX, wäre ich damit als Home PBX zufrieden gewesen. Leider gab es dann später keine Updates mehr. Und die Software ging in einem Unternehmen auf, welches jetzt 3CX gehört. Und die haben "AzkoziaPBX" eingestellt. Diese Software hätte ich sogar als Privatnutzer Lizenziert, weil das Konzept wirklich gut war. Alternativ gäbe es als Komerzielle noch: MobyDick von Pascom. (Lässt sich privat nur umständlich nutzen, weil die Software dafür nicht gedacht ist und auch nur 3 Nutzer inklusive sind).
Dann noch "IPTAM" und "Ansitel", "Starface" etc.
Bei den Herstellern in Übersee das gleiche (ausser FreePBX), aber da sind leider die Deutsche Sprachanpassung problematisch bis nicht vorhanden.
Das Problem ist, auch wenn es einige Hersteller so halten das sie eine kostenlose Version anbieten, ist diese meist so eingeschränkt, das sie sich auch Privat als unbenutzbar herausstellt. Die Software ist dann zwar meistens unbegrenzt lange nutzbar, aber eben mit den Einschränkungen.
Ich habe nichts dagegen, das die Firmen damit Geld verdienen wollen, darum geht es auch nicht. Aber kein Privatnutzer wird dafür Geld ausgeben, weil diese auch nicht die Zielgruppe der Firmen sind. Nur stellt keine Firma eine Software für Privatnutzer bereit, ob kostenlos oder auch nicht. Kostenlos wäre natürlich besser.
Und bei FreePBX nervt mich halt, das das erste was man nach der Installation zu Gesicht bekommt, "Choose a Plan".
=> https://youtu.be/77KzDLij8eQ?t=16m57s
Wird in dem Video gezeigt.
Wer die Software nur Privat einsetzt wird irgendwann denke ich mal davon genervt sein.
Bei einer Firma die die Software nutzt wäre das was anderes, denn die meisten Firmen setzen sowieso nur Software ein wo sie Support durch den Hersteller bekommen können. Und ob die Gui dann immer noch diese dauer hinweise zeigt weiß ich nicht.
Ich bin damals zu den Telefonanlagen gekommen, da waren sie noch Analog, und alles wurde mit Relais geschaltet. Später habe ich mich mit DeTeWe Varix Anlagen beschäftigt, da war DeTeWe allerdings schon eine Aastra Marke. Und so kam ich dann zu Asterisk und VOIP, wobei Asterisk 1.2 und 1.4 früher wirklich keinen Spaß gemacht haben und ich mir da noch nicht vorstellen konnte, das mal das ganze Telefonnetz so betrieben werden sollte.
Letztlich, auch wenn ich hier im Forum wohl hauptsächlich Fragen zu VOIP beantworte, beschränkt sich mein Tätigkeitsfeld nicht nur darauf.
-
Also ich persönlich hätte nix gegen ein Asterisk Plugin. Vielleicht runtergetrimmt auf SIP only damit nicht so viele Requests bzgl. dahdi Treiber kommen. Aber Dialplans schreiben oder besser templaten damit andere die schreiben können ist echt kein Spass. Vielleicht nach 19.1 oder so, vorausgesetzt die Prioritätenliste wächst nicht weiter mit anderen Sachen :)
-
Also ich persönlich hätte nix gegen ein Asterisk Plugin. Vielleicht runtergetrimmt auf SIP only damit nicht so viele Requests bzgl. dahdi Treiber kommen. Aber Dialplans schreiben oder besser templaten damit andere die schreiben können ist echt kein Spass. Vielleicht nach 19.1 oder so, vorausgesetzt die Prioritätenliste wächst nicht weiter mit anderen Sachen :)
Dahdi ist unter BSD ohnehin nicht gerade unproblematisch. Ich komme nur irgendwie nicht auf einen Nenner, wie ich in diesem Fall ein Konzept entwickeln kann, das dann auch "Sicher" ist. Denn diesbezüglich ist nichts unsicherer als Chan_Sip. Aber leider ist auch nichts kompatibler als Chan_SIP. Mit PJSIP und einigen Telefonen (Cisco) hatte ich schon Probleme, eine nahtloser Schwenk auf Chan_SIP hat sie gelöst. Wie ich nachher herausfand lag das an einer einzelnen Zeile im SIP Header, die Chan_SIP anders ausgibt. Die Telefone waren bei Cisco allerdings sowiso EoL, und damit ziemlich unwahrscheinlich das von denen bezgl. Firmware noch was kommt.
Das beste ist ich schaue mal was diesbezüglich Kamaillio so hergibt, ein Registrar kann man damit abbilden und das macht 1und1 zum Bsp. auch so. Wenn es möglich ist Kamaillio bei einem SIP Registrar zu Registrieren und die jeweiligen Accounts mit Virtuellen nur in Kamaillio erstellten Accounts zu verknüpfen, wäre das genau das was die meisten suchen. Ein umkonvertieren von Voice Codecs kann Kamaillio zwar nicht, aber die Basis Sip Routing Funktionalität lässt sich dafür doch nutzen.
Damit hätte dann OPNsense eine Custom PBX, den "FritzBox" Ersatz den alle suchen ohne die riesen Sicherheitslücken. Und weil das eben von Sip Providern auch eingesetzt wird, ist der Kamaillio SIP Stack als relativ sicher anzusehen.
Das größte Problem bleibt aber, das Kamaillio dafür entweder eine PostgreSQL oder MySQL Datenbank braucht. Ob mittlerweile XML oder Textfiles gehen, kann ich nicht sagen, weil es auch auf die Funktionalität der Plugins ankommt die geladen werden.
Eine andere Idee von mir wäre, OPNsense nur die Proxyfunktionaliät zu lassen und eine eigene SIP PBX Distro auf Hardened BSD Basis auf die Beine zu stellen, was Asterisk anbelangt, dürfte das wohl einfacher sein, als zu versuchen eine so umfangreiche Software als Plugin in ein vollwertige Firewall Appilance wie OPNsense zu quetschen. Ich denke zumindest deshalb so, da auch die GUI von OPNsense dann an die Grenze dessen, was man machen kann, und wirklich tun sollte, stößt. Und eine Plugin Sektion namens "Asterisk" mit über 30 Tabs stelle ich mir nicht gerade als übersichtlich vor. Denn es geht ja schließlich darum den Nutzer von den Konfigurationsdateien fern zu halten und die Konfiguration so einfach wie möglich zu gestalten.
Auf PFSense gab es damals mal Asterisk, habe das auch ausprobiert, aber es hatte schon seinen Grund weshalb das Plugin nie den "DEV" Status verlassen hat. Ob es noch existiert weiß ich nicht. Jedenfalls konnte man den SIP Port per Formular einstellen, aber den rest musste man über die Konfigdateien im Browser machen.
Das Plugin hatte ich jedenfalls nicht lange installiert. Und daher ist das leider kein leichtes Thema.
Ich hoffe zumindest dieser Post hier wird auch von den Leuten gelesen die unbedingt in einer Firewall eine Telefonanlage wollen. Um zu verstehen warum das alles nicht so einfach ist und das auch ein hoher Kosten / Nutzen Faktor ist. Klar kann man alles als Plugin in OPNsense integrieren und das das für jeden Entwickler eine menge Arbeit ist, ist klar. Nur wenn das Plugin nachher niemand nutzt wäre die ganze Zeit verschwendet. Und deshalb sehe ich das Thema so schwierig, denn gerade was VOIP und SIP angeht und vor allem weil jeder Hersteller/SIP Provider etc. seine eigene Suppe Kocht, ist das alles nicht einfach.
-
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 :P
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 :P
-
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 :P
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 :P
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 (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/ (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. :o
s. hier: https://www.ip-phone-forum.de/threads/bin-gehackt-worden.295929/#post-2230608 (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.
-
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? :P
Aber Voraussetzung xml, oder, eher wahrscheinlich, sqlite?
-
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? :P
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.
-
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.
-
Hört sich nach nem Haufen Arbeit an, ich bin dabei 8)
-
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.
-
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.
-
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. :)
-
Also UI und templating von der config mache ich, das wird kein Problem. Wenn da aber so wrapper wie Passwörter müssen in NTLM gesaved werden kommen brauch ich jmd. mit PHP/Pyhton skills, ansonsten wird das schon .. die Asterisk config hier sah jetzt nicht sooo schlimm aus .. aber das war bisher immer so, je einfacher das Plugin aussieht desto umfangreicher wirds dann. :)
-
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.
-
Fail2Ban wird schwierig, es hatte sich für mich so angehört als hätte Kamailio das schon mit integriert?
Ich frag mal Franco ob er ne Idee hat (oder du liest grad mit?) ;D
-
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 ;D
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.
Und die Richtlinien für SIP und RTP sind nicht so lose wie du denkst[...]
Das hat nur leider niemand den Providern erzählt :P
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.
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.
-
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 ;D
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 :P
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 (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 (http://fusionpbx-docs.readthedocs.io/en/latest/firewall/fail2ban.html)
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/ (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.
-
Konferenzräume wären noch geil :)
-
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.
-
Auch wenn das hier schon komplett anders abgebogen ist:
Nick hatte in einem Absatz was geschrieben wie "lieber eine eigene kleine Distro auf Basis" und auf der Sense nur ein Proxy o.ä.
Das wäre tatsächlich der Ansatz den ich auch eher vertreten würde. Warum? Klar ist das schön alles in einem Gerät zu haben aber kann sich noch jemand erinnern, warum genau man die Fritzbox bspw. loswerden wollte? Genau, kann alles aber nix so richtig. Irgendwo hat man Einschränkungen. Und nur wegen der "schönen UI" eben den Dienst zu nutzen... kann man schon machen, aber ist auch irgendwo Overkill. Dann lieber ne eigene Appliance dafür. Kennt (noch) jemand pfDNS? Das war die gleiche Idee vor X Jahren. Hey wir haben nen DNS Server, haben HA-Failover etc. alles auf der pfSense - was wäre wenn wir ne abgespeckte Version machen und die UI nur für DNS nutzen? Wäre cool gewesen - hat aber niemand mehr weiter verfolgt weils einfach zu weit auseinander lag. Da kommt dann eben ins Spiel wohin ein Produkt (OPNsense) gehen soll. Security Gateway/Firewall mit Zusatzfunktionen? Fein. Eierlegende Wollmilchsau? Eher nicht. Jedes Teil bringt wieder Unsicherheiten mit ins Spiel und die haben auf dem Border Gateway (zumindest IMHO) nichts zu suchen :) Darf natürlich jeder sehen wie er möchte, aber keine Firma wäre da jetzt mega erfreut ihren Mailserver und die Telefonanlage alles auf der gleichen Kiste wie die Firewall zu haben. Dann kann man sich irgendwann die ganze Basis sparen und nimmt ne VM / nen Server von der Stange und installiert einfach alles drauf. Datenbank noch dazu, hier noch ein Modul, da noch ne Library... allein die Security von allen Paketen halbwegs zu gewährleisten wird dann endlos.
Daher: Ich finde euer Vorhaben ambitioniert und toll, aber würde es auch eher als extra-Appliance sehen. Außer - wie Nick richtig sagt - ein paar Privatleuten wird das sonst niemand nutzen wollen. In Firmen würde das niemand so aufsetzen (wollen).
Grüße
-
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.
Würde mal vermuten, dass die das dann auch nicht zahlen, aber ne Versicherung würde das bei einem Produkt X mit Zertifikat Y ggf. tun.
-
@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.
-
> Allerdings wie @Alphakilo schrieb, ist das nicht einfach, da jeder Provider sein eigenes Ding macht etc. Das wird noch sehr schwierig werden.
Das ist leider in der Praxis ein fieses Problem. Wir haben selbst mit einer Sense Installation (pfSense aber recht minimal konfiguriert) ewig mit einem Kunden über ein halbes Jahr Dumps, Traces und Debugging Logs gesammelt um zu belegen, dass der Netzwerk & Security Part NICHT schuld an den Telefonieproblemen ist, weil ein UDP SIP Paket einfach nicht in der Art funktioniert: Hmm dich lasse ich durch, dich nicht und bei dir warte ich 5s bis es Ton gibt... Irgendwann kam dann raus, dass Telefonanlage, Konfiguration und SIP Provider nicht 100% kompatibel waren, weil der Provider seine Specs nicht offen gelegt hatte und die Anlage andere Werte angenommen hatte. Was ein Drama...
-
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.
-
Auch wenn der Thread schon etwas älter ist und das nach meinem Verständnis eh schon als Feature angedacht ist:
ich würde v.a. eine Protokollumsetzung von IPv4<->IPv6 sinnvoll finden. Dafür besteht IMO echt Bedarf:
Bisher hab ich nur bei Grandstream bezahlbare SIP-ATAs mit IPv6-Unterstützung gesehen (und bei einem anderen chinesischen Hersteller, den man kaum herkriegt und dessen Namen ich konsequenterweise schon vergessen habe). Umgekehrt gibt es Provider (M-Net), die VoIP nur über IPv6 machen; andere (easybell) bieten es zwar nur zusätzlich zu VoIP über IPv4 an, dort würde ich es aber trotzdem vorziehen, weil man dann bei DS-Lite keine VoIP-Streams über den AFTR-Tunnel leiten muss.
-
Auch wenn der Thread schon etwas älter ist und das nach meinem Verständnis eh schon als Feature angedacht ist:
ich würde v.a. eine Protokollumsetzung von IPv4<->IPv6 sinnvoll finden. Dafür besteht IMO echt Bedarf:
Bisher hab ich nur bei Grandstream bezahlbare SIP-ATAs mit IPv6-Unterstützung gesehen (und bei einem anderen chinesischen Hersteller, den man kaum herkriegt und dessen Namen ich konsequenterweise schon vergessen habe). Umgekehrt gibt es Provider (M-Net), die VoIP nur über IPv6 machen; andere (easybell) bieten es zwar nur zusätzlich zu VoIP über IPv4 an, dort würde ich es aber trotzdem vorziehen, weil man dann bei DS-Lite keine VoIP-Streams über den AFTR-Tunnel leiten muss.
Da hast du natürlich recht, als Feature ist es jetzt allerdings nicht (mehr) angedacht, weil OPNsense ansonsten zu einer Art FritzBox verkommen würde, und wenn du dir den ganzen Thread mal durchliest wirst du sehen, das es zwar schon Bedarf gibt, es aber unmöglich ist eine Vollwertige PBX oder besser Telefonanlage in OPNsense zu integrieren. Es ist natürlich ebenso ärgerlich, allen Fragenden wo das SIProxd Plugin nicht funktioniert, mitteilen zu müssen das sie für VOIP besser ihre FritzBox der OPNsense nachschalten sollen.
Bis auf weiteres habe ich zu diesem Plugin auch meine Überlegungen verworfen, denn wie @Alphakilo hier bereits schrieb ist eine Anpassung an jeden Provider extrem schwierig und Zeitaufwendig. Und das ist leider auch von 3 Leuten die dann an dem Plugin gearbeitet hätten leider so nicht möglich.
-
Ich würde das auch erst mal zurückstellen. Mir fehlt etwas die Zeit hier komplett was Neues anzufangen und paar andere Plugins haben noch Vorrang :)
-
Ich würde das auch erst mal zurückstellen. Mir fehlt etwas die Zeit hier komplett was Neues anzufangen und paar andere Plugins haben noch Vorrang :)
Geht in Ordnung, denn ich habe ohnehin momentan so viel in der ToDo Liste, das ich gar nicht weiß wie ich da noch ein Konzept für ein Plugin bewerkstelligen soll.