Debian 10 Asterisk Installation

[IpTelpert]

Hallo,
habe einen neuen Server und habe Asterisk mit #aptitude installiert.
Es sind keine config Files installiert worden.
Nehme ich config files aus einer älteren händischen Installation funktioniert es mit wenigen Anpassungen wie

[modules]
autoload=no

Macht es Sinn das mit der Standard debian Installation zu betreiben oder wäre es besser alles "händisch" zu installieren?
Welche Asterisk Version sollte man da nehmen?
Gruss

 

[sonyKatze]

Über das Package asterisk-config müsstest Du die Beispiel-Dateien bekommen. Klappt das?

Macht es Sinn das mit der Standard debian Installation zu betreiben oder wäre es besser alles "händisch" zu installieren?
Welche Asterisk Version sollte man da nehmen?

Welche Version hast Du aktuell? Ähnliche Fragen hatte wir hier … vielleicht helfen die Antworten dort. Wenn nicht bzw. noch Nachfragen sind, einfach hier in diesem Thread weiter fragen.

 

[sunnyman]

Hallo,
habe einen neuen Server und habe Asterisk mit #aptitude installiert.

Oha, das gibts noch?

Macht es Sinn das mit der Standard debian Installation zu betreiben oder wäre es besser alles "händisch" zu installieren?

Zum Starten/Rumprobieren oder wenn die Installation nicht viel leisten soll, kann man das wohl machen.
Für ein Produktivsystem würde ich aber schon zum selbst kompilierten Asterisk greifen. Man hat da viel bessere Möglichkeiten, es auf die eigenen Bedürfnisse anzupassen und statt dass man sich mit dem Deaktiveren, etc. von Modulen plagen muss kompiliert man die erst gar nicht. Ein "all-on"-Asterisk schleppt viel Ballast mit, den man für eine 08/15-VoiIP-installation nicht benötigt, z. B. selten verwendete VoIP-Protokolle (MGCP, IAX), Unterstützung für 1001 Datenbanken, etc. pp.
Das selbst kompilieren wird einem bei Asterisk schon ziemlich leicht gemacht, und im Gegensatz zu vielen anderen Produkten funktioniert das auch zuverlässig bzw. es gibt eine brauchbare Dokumentation.

Welche Asterisk Version sollte man da nehmen?

Ich würde immer mit der jüngsten LTS-Version starten, das ist aktuell Asterisk 18. Dann bekommt man zu Anfang noch das ganze Neue mit, und sobald die Installation stabil ist, hat man erstmal einige Zeit Ruhe, bekommt aber durchweg Fixes.

 

[IpTelpert]

Hi, habe Asteriskl 18 soweit händisch installiert. internes peer kann sich registrieren und internes telefonieren geht, bei Provider registrieren muss ich noch testen.

Werde aber gleich mit Anfragen auf port 5060 vollgemüllt.

[Aug 14 15:33:22] NOTICE[4103]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'INVITE' from '"500" <sip:[email protected]>' failed for '193.29.14.116:5071' (callid: fd64d1eb8e344a2
283c20e25e477f769) - No matching endpoint found

Das sind die Asterisk Prozesse

udp        0      0 0.0.0.0:35987           0.0.0.0:*                           999        495866151  3750/asterisk      
udp        0      0 0.0.0.0:5060            0.0.0.0:*                           999        495878282  3750/asterisk    ???????????
udp        0      0 0.0.0.0:XXXX            0.0.0.0:*                           999        495878285  3750/asterisk      
udp6       0      0 :::54474                :::*                                999        495866152  3750/asterisk

Den Standard port 5060 verlege ich immer, aktuell udpbindaddr=0.0.0.0:XXXX

Aber wo kommt der Prozess 495878282 her, was macht der?

.
udp        0      0 0.0.0.0:5060            0.0.0.0:*                           999        495878282  3750/asterisk      
.

Später mache ich mit #iptables port 5060 zu.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Hallo,
soll ich alles auf pjsip umstellen?

Home - Asterisk Documentation

wiki.asterisk.org

modules.conf
;load = chan_bridge_media.so
oder ;module load chan_sip.so über Console

scheint zu funktionieren, oder habe ich Probeme zu erwarten?
Gruss

 

[sunnyman]

Um Internet-Grundrauschen zu entgegen gibts eigentlich bessere Werkzeuge als RFCs missachten und Ports zu verbiegen, s. z. B. fail2ban. Schließlich kann man die Ports ja auch scannen.

 

[IpTelpert]

Scannen dauert aber viel länger, und dann habe ich noch eine Software mehr.
Aber ggbf. könntet ihr noch helfen was das für ein Prozess ist der noch auf 5060 läuft, dedswegen wäre es vielleicht besser gewesen die beiden Treads nicht zu einem zusammenzuführen

 

[sunnyman]

Scannen dauert aber viel länger, und dann habe ich noch eine Software mehr.

Auf einem Congress des CCC, der schon einige Jahre zurückliegt, haben sie den gesamten IPv4-Adressraum in ~15 Minuten gescannt, AFAIR.
Es bringt dir ja nichts, wenn du zwar ein Programm gespart hast aber der böse Hackerbube dann eines mehr einsetzt um deine Maschine aufzumachen.

Von Security through Obscurity wird halt generell abgeraten:

Security through obscurity – Wikipedia

de.wikipedia.org

Aber ggbf. könntet ihr noch helfen was das für ein Prozess ist der noch auf 5060 läuft

Asterisk, steht doch da?

Wenn Asterisk nicht auf 5060 binden soll aber es doch noch tut, ist es wohl ein Konfigurationsproblem, dann würde ich da mal mit dem Debugging einsteigen. Ich würde mal ganz stumpf mit hoher verbosity Asterisk starten und dann nach 5060 greppen.

soll ich alles auf pjsip umstellen?

chan_sip ist deprecated:

PSA: chan_sip status changed to "deprecated" & Asterisk 17.0.0-rc2 Release ⋆ Asterisk

If you download Asterisk 17 and start it up, you might be one of the people that notices the following messages: If you are using chan_pjsip, which has

www.asterisk.org

Die Antwort lautet also klar ja.

scheint zu funktionieren, oder habe ich Probeme zu erwarten?

Wir können für dich weder beurteilen, ob es funktioniert oder nur so scheint, noch können wir Tipps geben, wenn noch nicht einmal im Groben klar ist, was das System überhaupt machen soll, geschweige denn dass uns sip.conf/pjsip.conf/extensions.conf bzw. Ausschnitte davon vorlägen. Daher kann die Antwort hier nur lauten: "Kommt drauf an."

 

[IpTelpert]

Asterisk, steht doch da?

Ich hatte oben ZWEI Prozesse genannt und ich hatte gefragt was und woher der Prozess kommt der auf 5060 hört, 7173 kann man Telefone registrieren, ist gesetzt mit
udpbindaddr=0.0.0.0:7173 in sip.conf

udp 0 0 0.0.0.0:5060 0.0.0.0:* 999 758313787 27542/asterisk
udp 0 0 0.0.0.0:7173 0.0.0.0:* 999 758361399 27542/asterisk

Steht doch alles da?

 

[sonyKatze]

1. Ist das Modul chan_sip.so noch geladen? Vielleicht hast Du zwei SIP-Channel-Driver laufen, res_pjsip und chan_sip.
2. Welche Port(s) stehen in der Konfigurationsdatei /etc/asterisk/pjsip.conf?

habe ich noch eine Software mehr

Also ich kann fail2ban auch nur weiterempfehlen. Auch empfehle ich den Realm in Asterisk auf einen generischen Wert zu setzen. Wenn dort einmal Deine Domain drin steht, dann merken sich die Hacker diese und finden Dich auch dann, wenn Du die IP-Adresse wechselst.

 

[sunnyman]

Steht doch alles da?

Du zeigst uns, dass dein Asterisk 5060 aufmacht, obwohl du das nicht möchtest, anhand der Ports die es öffnet.

In #4 zitierst du eine Meldung von PJSIP, in #8 allerdings einen Ausschnitt aus der Konfig von chan_sip. Welche(r) SIP-Channeldriver läuft/laufen denn nun?

 

[IpTelpert]

In #4 zitierst du eine Meldung von PJSIP, in #8 allerdings einen Ausschnitt aus der Konfig von chan_sip. Welcher SIP-Channeldriver läuft/laufen denn nun?

Wie man oben sieht laufen zwei Prozesse, 7173 habe ich oben geschrieben wird in sip.conf definiert,
5060 weiß ich nicht wo der herkommt, das war die Frage.

udpbindaddr=0.0.0.0:7173 in sip.conf

udp 0 0 0.0.0.0:5060 0.0.0.0:* 999 758313787 27542/asterisk
udp 0 0 0.0.0.0:7173 0.0.0.0:* 999 758361399 27542/asterisk
Das ist doch wohl eindeutig.

In modules.conf
[modules]
autoload=yes
noload => res_pjproject.so
noload => res_pjsip.so
noload => res_pjsip_session.so
setzen bringt trotzdem zwei Asterisk Prozesse.
Ich meine ich habe in einem US Forum etwas in der Art dazu etwas gefunden um die Module auszuschalten, muss es nur noch testen

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Also ich kann fail2ban auch nur weiterempfehlen. Auch empfehle ich den Realm in Asterisk auf einen generischen Wert zu setzen. Wenn dort einmal Deine Domain drin steht, dann merken sich die Hacker diese und finden Dich auch dann, wenn Du die IP-Adresse wechselst.

Ihr hättet lieber diese zwei unterschiedlichen Sachen zur Diskussion nicht zusammen packen sollen.

Die Domain verbreitet sich eh wegen MX, PTR usw. Da denn mal kurz schauen ob da unter 5060 was läuft ist für den Hacker schnell getan.

 

[sunnyman]

Wie man oben sieht laufen zwei Prozesse,

Nein. Das sind nicht zwei Prozesse, sondern derselbe Prozess öffnet zwei Ports.

7173 habe ich oben geschrieben wird in sip.conf definiert,
5060 weiß ich nicht wo der herkommt, das war die Frage.

In #7 habe ich dir bereits einen Rat gegeben was du zur Fehlersuche machen kannst.

udp 0 0 0.0.0.0:5060 0.0.0.0:* 999 758313787 27542/asterisk
udp 0 0 0.0.0.0:7173 0.0.0.0:* 999 758361399 27542/asterisk

Das ist doch wohl eindeutig.

Du wiederholst ein Indiz für das Symptom, aber das macht es nicht hilfreicher, nach der Ursache zu suchen.

setzen bringt trotzdem zwei Asterisk Prozesse.

Wenn du zwei Asterisk Prozesse hast, dann hast du ein anderes Problem. Ich sehe aber keine unterschiedlichen PIDs.

In deinem Beispiel aus der modules.conf hast du eine handvoll resource-Module von PJSIP deaktiviert. Erst einmal werden das wohl nicht alle sein (auf meinem System zähle ich 43 (ls -l res_pjsip_*.so | wc -l)), und das wichtigste Modul, nämlich der eigentliche channeldriver, darf offenbar noch geladen werden. Ein Blick in die pjsip*.conf-Dateien könnte hier ebenfalls helfen (bzw. diese aus dem Weg zu räumen).

Ich meine ich habe in einem US Forum etwas in der Art dazu etwas gefunden um die Module auszuschalten, muss es nur noch testen

Es besteht eigentlich keine Notwendigkeit, "irgendwas" aus Foren auszuprobieren, die Dokumentation von Asterisk ist schon recht ordentlich.

Ich vermute, dass der PJSIP-Channeldriver einfach noch hochkommt. Ob deine Deaktivierungs-Versuche klappen oder nicht kannst du sehr einfach herausfinden indem du, wie von mir in #7 empfohlen, Asterisk verbose beim Starten zuguckst. Alternativ geht es auch noch auf der Asterisk-Konsole mit module show.

 

[gehtdoch]

Werde aber gleich mit Anfragen auf port 5060 vollgemüllt.

Der Fehler besteht darin, dass ein Listener nach außen offen ist. Das ist für die Anbindung an einen Trunk Provider wohl in den allermeisten Fällen unnötig. Daher habe ich diesen Patch (nobind.diff) bereitgestellt für Asterisk / pjsip, der es ermöglicht, dieser Unsitte von Asterisk einen Riegel vorzuschieben. Dann braucht man auch kein fail2ban und ähnliche Workarounds mehr, um Scheunentore leidlich zu sichern, die man vorher völlig sinnlos geöffnet hat.

Eine andere Variante ist, diesen Port über eine Portfilterregel zu zumachen (eingehende SIP-Verbindungen werden nur erlaubt, wenn es eine passende ausgehende Verbindung gibt / iptables Stichwort conntrack).

 

[sunnyman]

Der Fehler besteht darin, dass ein Listener nach außen offen ist. Das ist für die Anbindung an einen Trunk Provider wohl in den allermeisten Fällen unnötig.

Das mag zwar so sein, aber der Listener wird ja, wenn ich deinen Patch richtig interpretiere, dennoch auf der konfigurierten bind-Adresse erzeugt (

pjsip_tcp_transport_lis_start(temp_state->state->factory,&cfg.bind_addr,NULL);

) und nicht einfach statisch auf 5060. @IpTelpert hat den Channeldriver ja explizit von 5060 weg konfiguriert und offenbar wird chan_sip eingesetzt, während PJSIP nicht korrekt rauskonfiguriert worden ist.

 

[gehtdoch]

Sorry, nein, Du hast den Patch leider nicht verstanden. Schau Dir den Patch einfach nochmal vollständig an und nicht nur eine völlig aus dem Zusammenhang gerissene Zeile!

Das verwenden eines anderen Ports ist security by obscurity und bringt nicht sonderlich viel (Angreifer sind in der Regel nicht doof). Aber das hast Du ja oben korrekterweise schon selbst geschrieben.

 

[sunnyman]

Sorry, nein, Du hast den Patch leider nicht verstanden.

Da hast du Recht.

Schau Dir den Patch einfach nochmal vollständig an und nicht nur eine völlig aus dem Zusammenhang gerissene Zeile!

Ich habe sehr wohl die ganze Datei gelesen, aber zu oberflächlich (und zu müde).

Dennoch möchte ich betonen, dass IpTelpert sich insbesondere fragt, warum Asterisk neben dem explizit konfigurierten Port 7173 trotzdem noch 5060 aufmacht. Und nach allem (leider nicht immer eindeutigem) was hier bisher geschrieben worden ist, vermute ich, dass mit chan_sip gearbeitet wird, auf 7173, zusätzlich dazu aber ein halb de-konfigurierter PJSIP mit hochkommt.

Wenn IpTelpert seine Konfig also nicht für PJSIP neu schreiben möchte, wäre die konsequente Lösung, PJSIP komplett abzuschalten und dein Patch wäre nicht erforderlich.

Davon ab gilt das mit den Listenern ja eh nur für TCP, offensichtlich arbeitet die Konfig aber mit UDP, das müsste also auch noch umgestellt werden.

Eine Frage noch dazu: Es geht aus dem Zusammenhang nicht eindeutig hervor, aber mein Eindruck ist, dass es sich bei dem Server um einen öffentlichen Server handelt. Wenn ich daran Clients anbinden kommen will, komme ich doch um einen Listener nach außen sowieso nicht herum?

 

[IpTelpert]

Wenn IpTelpert seine Konfig also nicht für PJSIP neu schreiben möchte, wäre die konsequente Lösung, PJSIP komplett abzuschalten und dein Patch wäre nicht erforderlich.

Davon ab gilt das mit den Listenern ja eh nur für TCP, offensichtlich arbeitet die Konfig aber mit UDP, das müsste also auch noch umgestellt werden.

Eine Frage noch dazu: Es geht aus dem Zusammenhang nicht eindeutig hervor, aber mein Eindruck ist, dass es sich bei dem Server um einen öffentlichen Server handelt. Wenn ich daran Clients anbinden kommen will, komme ich doch um einen Listener nach außen sowieso nicht herum?

Ja, ich möchte jetzt den neusten Asterisk installieren und mich jetzt mit PJSIP nicht weiter beschäftigen, meine "Versuche" das auszuschalten sind erfolglos, altes SIP auf 5173 funktioniert allerdings.
Der Server steht im Internet, die Tore werden dann allerdings noch meiste Zeit mit iptables geschlossen.

Das noload wie oben von mir beschrieben funktioniert nicht, vielleicht kann mir einfach einer sagen wie ich den pjsip Kram komplett abschalte und das dann keiner mehr auf 5060 hört.
Dann wäre mir schon geholfen. Mit fail2ban möchte ich mich nicht beschäftigen, auch nicht ob man nun einen anderen Port als 5060 benutzen darf oder das Hacker meinen geänderten port sowieso finden, usw.

 

[sunnyman]

Ein noload auf chan_pjsip.so sollte eigentlich reichen.
Ich möchte mich auch nicht mit Security beschäftigen, das Problem ist, dass das im Zweifel andere für einen übernehmen. Ich drücke dir die Daumen für "Unfallfreiheit".

 

[IpTelpert]

Unnötiges Vollzitat von darüber gemäß Boardregeln entfernt by stoney

noload funktioniert leider nicht, und mit autoload= no muss ich erst einmal die ganzen Dinger durchgehen die zu laden sind
Funktioniert dann deny, permit in den peers nicht zuverlässig, das nimmt doch schon mal viel an Problemen weg

 

[gehtdoch]

Und nach allem (leider nicht immer eindeutigem) was hier bisher geschrieben worden ist, vermute ich, dass mit chan_sip gearbeitet wird, auf 7173, zusätzlich dazu aber ein halb de-konfigurierter PJSIP mit hochkommt.

Ja, irgendwas in der Art vermute ich auch. Ich finde es allerdings bedenklich, wie hier Server betrieben (ist wahrscheinlich schon zu hoch gegriffen) werden sollen. Bei mir jedenfalls funktioniert noload für chan_sip jedenfalls astrein. Vielleicht wäre es an der Stelle doch besser, FreePBX zu verwenden - da bekommt man wenigstens eine funktionierende Basiskonfig (bzw. viel mehr) geliefert, auf dessen Basis man relativ problemlos customizen kann.

Also wieder zurück zum veralteten chan_sip, von dem von vornherein klar ist, dass es qua status (legacy seit Jahren und nicht mehr belastbar betreut) kaum sicher sein kann. Gut, hat einen Vorteil (Achtung: Sarkasmus!): viele Updates (und damit Arbeit) wird es an dieser Stelle nicht mehr geben - nicht weil sie nicht nötig wären, sondern weil so gut wie keiner mehr dran arbeitet und damit (security relevante) Fehler nicht gefunden werden.

In diesem Sinne: Wenn man ein Module auf regulärem Weg nicht abgeschaltet bekommt: verschiebe einfach die chan_pjsip.so an einen Platz, wo Asterisk sie nicht findet - z.B. nach /tmp oder /root. Dann wird Asterisk beim Starten zwar massiv meckern - aber was soll's - Ziel erreicht (falls er mit dem Rest hochkommt).