- Mitglied seit
- 11 Okt 2005
- Beiträge
- 177
- Punkte für Reaktionen
- 0
- Punkte
- 0
Hallo!
Wir sind selbst SIP Provider und haben daher bald schon täglich mit SIP Fraud in irgendeiner Form zu tun. Ich möchte eine Diskussion beginnen, wie wir und andere damit umgehen und wie man es den Hackern möglichst schwer machen kann, ihren Beruf weiter auszuüben.
Beruf?
Ja, denn eine erfolgreich gehackte SIP Anlage eines nichtsahnenden Anwenders kann viele tausend Euro an einem Wochenende einspielen! Den Betrag darf dann der Geschädigte zahlen. Zur Info: bei uns war der bisherige Highscore eines Einzelfalls rund 7.000 Euro!
Wir arbeiten bei SIP faktisch nur mit Asterisk. Ich beziehe mich selbst also nur auf Asterisk - wenngleich viele Mechanismen wohl sehr einfach auf anderen Plattformen eingesetzt werden können.
Wir arbeiten auch nur mit "plain" Asterisk (also selbst downgeloadet und installiert und dann in den Config-Files herumeditiert) und nicht mit vorgefertigten Systemen, die auf Asterisk basieren. Das hauptsächlich deswegen, weil wir nur dann genau wissen, was wann passiert und was man machen kann. Die fertigen Systeme (TrixBox, Gemeinschaft, etc.) sind teilweise nichtmehr zu durchschauen, was sie wie machen - prompt wurden auch zwei Kunden von uns gehackt, die mit so einem Ding gearbeitet haben, weil [zumindest damals] die simpelsten Sicherheitsvorkehrungen gefehlt haben und sich jeder Hacker eine Kopie davon holen und die Schwachstellen darin ausstöbern kann.
Der typische Hack
...beginnt um die Zeit, wo ich das schreibe, also Freitag Nachmittag/Abend, wenn die Firmen den Laden dicht machen. Warum? Dann merkt hoffentlich bis Montag Früh keiner, dass eine Asterisk hijacked wurde und der Hacker kann ungestört Geld verdienen.
Wie verdient man damit Geld?
Auf zwei Arten: erstens kann man Mehrwertnummern anrufen und kommt damit zu Geld. Der Eigentümer der Mehrwertnummer ist zwar natürlich höchst verdächtig, aber solange man ihm nicht nachweisen kann, dass er hinter der Sache steht, bekommt er das Geld ausgezahlt und seilt sich ab. Meist sind die Typen schneller von der Bildfläche verschwunden, als man braucht, um bei der Telekom eine Auskunft zu erhalten, wer überhaupt hinter einer Nummer steht.
Die einfachere Variante ist aber, dass man die gehackten Telefonminuten verkauft. Es gibt eine "Telefonminutenbörse", bei der jeder etwas anbieten oder suchen kann. Jemand kann z.B. 50.000 Minuten nach Namibia zwischen Freitag 18 Uhr und Montag 8 Uhr für x Euro anbieten. Das ist nichts Unübliches! Das kaufen dann ganz renomierte Telcos (die Telekom, Skype, Sprint, MCI, ...) und schicken an dem Wochenende dann die Gespräche ihrer Kunden nach Namibia über diesen Anbieter.
Dieser Anbieter schickt die Calls (oft noch über einen Sub-Anbieter) aber über eine gehackte Aster9isk. Die telefoniert ganz brav per ISDN Karte oder SIP Provideruplink ins PSTN nach Namibia. Zahlen darf dass dann am Monatsende der Eigentümer der gehackten Asterisk. Der Hacker selbst streift die Kohle vom Verkauf der Telefonminuten ein und nach einigen Dutzend dieser Aktionen verschwindet er sicherheitshalber udn macht unter anderer Identität weiter.
Wir können das aus den Logfiles gut mitverfolgen, weil bei fast allen Hacks sämtliche Calls immer dieselbe Landesvorwahl hatten. Eben 50.000 Minuten nach Namibia...
Üblicherweise nehmen Hacker natürlich auch die teuersten Destinationen, weil damit das Meiste rauszuholen ist. Wie auch Geldfälscher wohl kaum 1-Cent-Stücke nachmachen würden, sondern eher Hunderter.
Wie läuft der Hack technisch ab?
Oft schon Wochen vorher sucht ein Scanner alles durch, was auf SIP reagiert (also 5060/udp). Dann versucht er, sich als regulärer Teilnehmer (Nebenstelle) anzumelden. Nachdem die meisten SIP Systeme keine eingebauten Massnahmen gegen Missbrauch haben, geht das sehr bequem für den Hacker per "Brute Force Attack", also indem der Scanner einfach wahllos und so schnell wie möglich Benutzer-Passwort-Kombinationen ausprobiert.
Bei Asterisk ist es üblich, den Usern als Benutzername die Durchwahlnummer zu geben, weil sich's dann sehr einfach programmiert. Dazu noch ein Passwort, dass sich der User gut merken kann und fertig ist die Misere.
Der Scanner probiert als Benutzername also mögliche Durchwahlen aus - Zahlen von 10 bis 99, dann von 100 bis 999, 1000 bis 9999 und manche sogar schon den fünfstelligen Breich, also 10000 bis 99999. Zu jeder Durchwahl gehen sie eine endlose Liste von Passworten durch, mit denen sie dann Anmeldeversuche durchführen. So ein Scan dauert Stunden oder oft sogar Tage!
Logins bei Betriebsystemen (Windows, Unix, Apple, ...) sind üblicherweise gegen Brute Force Verfahren gesichert, denn ab dem 3. falschen Login beginnen sie mit Konsequenzen: das Login wird künstlich verzögert, der User wird für einige Zeit gesperrt, die Verbindung wird getrennt, u.v.a.m. Asterisk kennt davon gar nichts. Man kann bei einer halbwegs schnellen Internetleitung durchaus 30 oder mehr Loginversuche pro Sekunde machen!
Klappt ein Login, wird der Server mit den Logindaten in die Liste der geknackten Systeme aufgenommen. Hier ist meines Ansicht nach Handarbeit fällig, denn nun muss ein Mensch herausfinden, ob der Account brauchbar ist: hat er Amtsberechtigung? Kann ich auch ins Ausland wählen? WIE kann ich rauswählen? Manche brauchen eine Amtsnull - in Amerika ist es meistens die 9 für eine outside line. In vielen Ländern wählt man 00 vor dem Landescode (0049=Deutschland), in Norwegen(?) und derTürkei ist es 99 (9949=Deutschland), in den USA ist es 011 oder 0011 (001149=Deuschland). Da kommen schon einige Kombinationen zusammen, die man durchtesten und sich anhören muss, was passiert. Ich bin ziemlich sicher, dass viele Hacker gar nicht wissen, in welchem Land die Asterisk mit der IP 1.2.3.4 überhaupt ist! Es wird ihnen auch egal sein...
Hat der Hacker alle nötigen Infos (IP, Login, Vorwahl), wird die Asterisk am nächsten Wochenende vergewaltigt und die Telefonminuten verkauft.
In den Logfiles findet man oft bereits Wochen vor dem eigentlichen SIP Fraud ein paar Testcalls, die vom Zeitverhalten her auf menschliche Bedienung schliessen lassen und nicht auf einen Robot. Auch vergehen oft viele Wochen zwischen dem Ausspionieren und dem Fraud. Entweder, weil die Hacker wissen wollen, wie aufmerksam die Systeme überwacht werden, oder, weil sie für die nächsten Wochenenden für die verkauften Telefonminuten eh schon genügend andere Server vorbereitet haben. Denn sobald ein Hack auffliegt und die Calls nichtmehr durchgehen, müssen sie ja gleich 'ne andere Maschine parat haben, um die verkauften 50.000 Minuten auch tatsächlich absetzen zu können! Sonst gibt's Beschwerden von den Endusern.
Was also kann man dagegen tun?
Ganz wichtig scheint mir, in der sip.conf bei den Usern richtige Passworte zu verwenden! Nachdem man die eh meist per Copy&Paste ins Webinterface des Endgeräts einträgt (oder per Mass-Deployment), können die ruhig kompliziert und un-merkbar sein. Ich empfehle unter Linux zumindest `pwgen -s 20´ oder besser `pwgen -sy 50´. Provider sollten es den User nicht ermöglichen, eigene Passworte für den SIP Account einzustellen. Ein Button [neues Zufallspasswort] ist aber nicht schlecht, denn es kann ja mal vorkommen, dass das bisherige Kennwort nichtmehr sicher ist.
Dann weise ich auf mögliche IP Restriktionen hin. Da braucht's gar keine komplizierten Firewallregeln, sondern ebenfalls in der sip.conf generell und/oder pro User:
deny = 0.0.0.0/0.0.0.0
permit = 192.168.0.0/255.255.0.0
permit = 212.236.252.0/255.255.252.0
permit = 212.236.160.224/255.255.255.224
Mit "deny" verbiete ich erstmal jegliche IP Adresse, mit den folgenden "permit" Anweisungen erlaube ich einzelne Netze oder IPs. Nur von dort dürfen sich Clients überhaupt anmelden! Eine der sichersten Sicherungen überhaupt!
Dafür ist es natürlich nötig, dass die Clients nicht an Leitungen mit dynamischer IP Adresse sitzen. Welche IP Adressen man auf einem DSL der Telekom bekommen kann, wissen die wohl selbst auch nicht.
Hat man Clients an dynamischen/unbekannten IPs (z.B. Kunden von Sipgate), muss man halt mit guten Passworten leben.
Ebenso sollte man sich überlegen, ob man den Usern wirklich, wie allgemein üblich, die blanke Durchwahl als Username gibt. Wir fügen gerne ein paar Buchstaben vorne oder hinten an. DW11 hat dann nicht den Usernamen "11", sondern "jdu11iwn", DW12 hat "jdu12iwn" usw. Im Dial Kommando an interne DWen gebe ich statt
Dial(SIP/${EXTEN});
einfach
Dial(SIP/jdu${EXTEN}iwn);
an. Das ist dann nicht wirklich komplizierter in der Programmierung, aber der reguläre Hackversuch mit Zahlen als Benutzername scheitert schon gleich kläglich!
Ebenso wichtig ist es, dass man in der [general] Section einen "context" angibt, der anders ist, als alle anderen und vor allem anders, als der, aus dem die braven User kommen. Bei viel zu vielen der gehackten Systeme gab es in [general] ein context=default und aus. Keine Erwähnung eines anderen Contexts!
Warum ist das Wahnsinn?
Weil über den generellen Context die anonymen Calls aus dem Internet kommen! Standardmässig ist bei Asterisk allowguest=yes, also nimmt die Asterisk alle SIP Calls von überall an. [Das ist ja auch ein Sinn von VoIP, dass es bald mal kein Festnetz mehr gibt, weil man eh jeden über ENUM direkt per IP erreichen kann.]
Kommen die anonymen Calls aus demselben Context, wie die von braven Usern, kann man meist schon mit einem Gespräch an die "Nebenstelle" sip:00491234567879@doof-programmierter-server ein Gespräch ins Festnetz auf Kosen des Anlagenbetreibers absezen - ganz ohne, dass man Benutzernamen und Passworte erraten müsste!
Also bitte unbedingt
[general]
context = von-absolut-nicht-vertrauenswuerdiger-quelle
...
[nebenstelle]
context = von-lokaler-nebenstelle
und in den ersten Context baut man entweder gar nix rein, oder man überlegt sich genau, was man erlaubt und was besser nicht! Amtsnullen oder Vorwahlen können recht trickreich in der SIP URL "versteckt" werden!
Weiters kann man SIP Accounts auch einen "Accountcode" zuweisen. Meist wählen wir die Nebenstelle als Accountode, weil dann haben wir alle Parameter im Programmfluss immer bei der Hand (User, Nebenstelle, CallerID). Wenn man allen Nebenstelleneinen Accountcode verpasst, kann man beim Rauswählen zum PSTN (Provider, ISDN, ...) dann eine Sicherheitsabfrage machen und Rauswählen nur erlauben, wenn ein Accountcode (also eine Verrechnungsbasis) vorliegt:
if ( "${CDR(accountcode)}" != "" ) {
Dial(...PSTN...);
}
Weiters möchte ich dringend raten:
type = friend
host = dynamic
qualify = yes
nat = no
canreinvite = no
disallow = all
allow = alaw
allow = g722
subscribecontext = subscribe
call-limit = 3
context = from-user
t38pt_udptl = no
callerid = 018899999
deny = 0.0.0.0/0.0.0.0
permit = 212.236.252.0/255.255.252.0
permit = 212.236.160.224/255.255.255.224
[hansi](nebenstelle)
accountcode = 123
secret = sldknjs
vmexten = *9123
mailbox = 123
callgroup = 1
[seppi](nebenstelle)
accountcode = 333
secret = sldknjs
callgroup = 2
permit = 192.168.x.y
callerid = 018899999333
Das waren mal die ganz einfachen Dinge, die jeder in seiner Asterisk Konfiguration beachten sollte, ohne weiter darüber nachzudenken.
Sobald ich wieder ein bissi Zeit finde, möchte ich die aufwändigeren Verfahren beschreiben, mit denen man Hackern die Suppe ganz schön versalzen kann.
tschüss,
Thomas
Wir sind selbst SIP Provider und haben daher bald schon täglich mit SIP Fraud in irgendeiner Form zu tun. Ich möchte eine Diskussion beginnen, wie wir und andere damit umgehen und wie man es den Hackern möglichst schwer machen kann, ihren Beruf weiter auszuüben.
Beruf?
Ja, denn eine erfolgreich gehackte SIP Anlage eines nichtsahnenden Anwenders kann viele tausend Euro an einem Wochenende einspielen! Den Betrag darf dann der Geschädigte zahlen. Zur Info: bei uns war der bisherige Highscore eines Einzelfalls rund 7.000 Euro!
Wir arbeiten bei SIP faktisch nur mit Asterisk. Ich beziehe mich selbst also nur auf Asterisk - wenngleich viele Mechanismen wohl sehr einfach auf anderen Plattformen eingesetzt werden können.
Wir arbeiten auch nur mit "plain" Asterisk (also selbst downgeloadet und installiert und dann in den Config-Files herumeditiert) und nicht mit vorgefertigten Systemen, die auf Asterisk basieren. Das hauptsächlich deswegen, weil wir nur dann genau wissen, was wann passiert und was man machen kann. Die fertigen Systeme (TrixBox, Gemeinschaft, etc.) sind teilweise nichtmehr zu durchschauen, was sie wie machen - prompt wurden auch zwei Kunden von uns gehackt, die mit so einem Ding gearbeitet haben, weil [zumindest damals] die simpelsten Sicherheitsvorkehrungen gefehlt haben und sich jeder Hacker eine Kopie davon holen und die Schwachstellen darin ausstöbern kann.
Der typische Hack
...beginnt um die Zeit, wo ich das schreibe, also Freitag Nachmittag/Abend, wenn die Firmen den Laden dicht machen. Warum? Dann merkt hoffentlich bis Montag Früh keiner, dass eine Asterisk hijacked wurde und der Hacker kann ungestört Geld verdienen.
Wie verdient man damit Geld?
Auf zwei Arten: erstens kann man Mehrwertnummern anrufen und kommt damit zu Geld. Der Eigentümer der Mehrwertnummer ist zwar natürlich höchst verdächtig, aber solange man ihm nicht nachweisen kann, dass er hinter der Sache steht, bekommt er das Geld ausgezahlt und seilt sich ab. Meist sind die Typen schneller von der Bildfläche verschwunden, als man braucht, um bei der Telekom eine Auskunft zu erhalten, wer überhaupt hinter einer Nummer steht.
Die einfachere Variante ist aber, dass man die gehackten Telefonminuten verkauft. Es gibt eine "Telefonminutenbörse", bei der jeder etwas anbieten oder suchen kann. Jemand kann z.B. 50.000 Minuten nach Namibia zwischen Freitag 18 Uhr und Montag 8 Uhr für x Euro anbieten. Das ist nichts Unübliches! Das kaufen dann ganz renomierte Telcos (die Telekom, Skype, Sprint, MCI, ...) und schicken an dem Wochenende dann die Gespräche ihrer Kunden nach Namibia über diesen Anbieter.
Dieser Anbieter schickt die Calls (oft noch über einen Sub-Anbieter) aber über eine gehackte Aster9isk. Die telefoniert ganz brav per ISDN Karte oder SIP Provideruplink ins PSTN nach Namibia. Zahlen darf dass dann am Monatsende der Eigentümer der gehackten Asterisk. Der Hacker selbst streift die Kohle vom Verkauf der Telefonminuten ein und nach einigen Dutzend dieser Aktionen verschwindet er sicherheitshalber udn macht unter anderer Identität weiter.
Wir können das aus den Logfiles gut mitverfolgen, weil bei fast allen Hacks sämtliche Calls immer dieselbe Landesvorwahl hatten. Eben 50.000 Minuten nach Namibia...
Üblicherweise nehmen Hacker natürlich auch die teuersten Destinationen, weil damit das Meiste rauszuholen ist. Wie auch Geldfälscher wohl kaum 1-Cent-Stücke nachmachen würden, sondern eher Hunderter.
Wie läuft der Hack technisch ab?
Oft schon Wochen vorher sucht ein Scanner alles durch, was auf SIP reagiert (also 5060/udp). Dann versucht er, sich als regulärer Teilnehmer (Nebenstelle) anzumelden. Nachdem die meisten SIP Systeme keine eingebauten Massnahmen gegen Missbrauch haben, geht das sehr bequem für den Hacker per "Brute Force Attack", also indem der Scanner einfach wahllos und so schnell wie möglich Benutzer-Passwort-Kombinationen ausprobiert.
Bei Asterisk ist es üblich, den Usern als Benutzername die Durchwahlnummer zu geben, weil sich's dann sehr einfach programmiert. Dazu noch ein Passwort, dass sich der User gut merken kann und fertig ist die Misere.
Der Scanner probiert als Benutzername also mögliche Durchwahlen aus - Zahlen von 10 bis 99, dann von 100 bis 999, 1000 bis 9999 und manche sogar schon den fünfstelligen Breich, also 10000 bis 99999. Zu jeder Durchwahl gehen sie eine endlose Liste von Passworten durch, mit denen sie dann Anmeldeversuche durchführen. So ein Scan dauert Stunden oder oft sogar Tage!
Logins bei Betriebsystemen (Windows, Unix, Apple, ...) sind üblicherweise gegen Brute Force Verfahren gesichert, denn ab dem 3. falschen Login beginnen sie mit Konsequenzen: das Login wird künstlich verzögert, der User wird für einige Zeit gesperrt, die Verbindung wird getrennt, u.v.a.m. Asterisk kennt davon gar nichts. Man kann bei einer halbwegs schnellen Internetleitung durchaus 30 oder mehr Loginversuche pro Sekunde machen!
Klappt ein Login, wird der Server mit den Logindaten in die Liste der geknackten Systeme aufgenommen. Hier ist meines Ansicht nach Handarbeit fällig, denn nun muss ein Mensch herausfinden, ob der Account brauchbar ist: hat er Amtsberechtigung? Kann ich auch ins Ausland wählen? WIE kann ich rauswählen? Manche brauchen eine Amtsnull - in Amerika ist es meistens die 9 für eine outside line. In vielen Ländern wählt man 00 vor dem Landescode (0049=Deutschland), in Norwegen(?) und derTürkei ist es 99 (9949=Deutschland), in den USA ist es 011 oder 0011 (001149=Deuschland). Da kommen schon einige Kombinationen zusammen, die man durchtesten und sich anhören muss, was passiert. Ich bin ziemlich sicher, dass viele Hacker gar nicht wissen, in welchem Land die Asterisk mit der IP 1.2.3.4 überhaupt ist! Es wird ihnen auch egal sein...
Hat der Hacker alle nötigen Infos (IP, Login, Vorwahl), wird die Asterisk am nächsten Wochenende vergewaltigt und die Telefonminuten verkauft.
In den Logfiles findet man oft bereits Wochen vor dem eigentlichen SIP Fraud ein paar Testcalls, die vom Zeitverhalten her auf menschliche Bedienung schliessen lassen und nicht auf einen Robot. Auch vergehen oft viele Wochen zwischen dem Ausspionieren und dem Fraud. Entweder, weil die Hacker wissen wollen, wie aufmerksam die Systeme überwacht werden, oder, weil sie für die nächsten Wochenenden für die verkauften Telefonminuten eh schon genügend andere Server vorbereitet haben. Denn sobald ein Hack auffliegt und die Calls nichtmehr durchgehen, müssen sie ja gleich 'ne andere Maschine parat haben, um die verkauften 50.000 Minuten auch tatsächlich absetzen zu können! Sonst gibt's Beschwerden von den Endusern.
Was also kann man dagegen tun?
Ganz wichtig scheint mir, in der sip.conf bei den Usern richtige Passworte zu verwenden! Nachdem man die eh meist per Copy&Paste ins Webinterface des Endgeräts einträgt (oder per Mass-Deployment), können die ruhig kompliziert und un-merkbar sein. Ich empfehle unter Linux zumindest `pwgen -s 20´ oder besser `pwgen -sy 50´. Provider sollten es den User nicht ermöglichen, eigene Passworte für den SIP Account einzustellen. Ein Button [neues Zufallspasswort] ist aber nicht schlecht, denn es kann ja mal vorkommen, dass das bisherige Kennwort nichtmehr sicher ist.
Dann weise ich auf mögliche IP Restriktionen hin. Da braucht's gar keine komplizierten Firewallregeln, sondern ebenfalls in der sip.conf generell und/oder pro User:
deny = 0.0.0.0/0.0.0.0
permit = 192.168.0.0/255.255.0.0
permit = 212.236.252.0/255.255.252.0
permit = 212.236.160.224/255.255.255.224
Mit "deny" verbiete ich erstmal jegliche IP Adresse, mit den folgenden "permit" Anweisungen erlaube ich einzelne Netze oder IPs. Nur von dort dürfen sich Clients überhaupt anmelden! Eine der sichersten Sicherungen überhaupt!
Dafür ist es natürlich nötig, dass die Clients nicht an Leitungen mit dynamischer IP Adresse sitzen. Welche IP Adressen man auf einem DSL der Telekom bekommen kann, wissen die wohl selbst auch nicht.
Hat man Clients an dynamischen/unbekannten IPs (z.B. Kunden von Sipgate), muss man halt mit guten Passworten leben.
Ebenso sollte man sich überlegen, ob man den Usern wirklich, wie allgemein üblich, die blanke Durchwahl als Username gibt. Wir fügen gerne ein paar Buchstaben vorne oder hinten an. DW11 hat dann nicht den Usernamen "11", sondern "jdu11iwn", DW12 hat "jdu12iwn" usw. Im Dial Kommando an interne DWen gebe ich statt
Dial(SIP/${EXTEN});
einfach
Dial(SIP/jdu${EXTEN}iwn);
an. Das ist dann nicht wirklich komplizierter in der Programmierung, aber der reguläre Hackversuch mit Zahlen als Benutzername scheitert schon gleich kläglich!
Ebenso wichtig ist es, dass man in der [general] Section einen "context" angibt, der anders ist, als alle anderen und vor allem anders, als der, aus dem die braven User kommen. Bei viel zu vielen der gehackten Systeme gab es in [general] ein context=default und aus. Keine Erwähnung eines anderen Contexts!
Warum ist das Wahnsinn?
Weil über den generellen Context die anonymen Calls aus dem Internet kommen! Standardmässig ist bei Asterisk allowguest=yes, also nimmt die Asterisk alle SIP Calls von überall an. [Das ist ja auch ein Sinn von VoIP, dass es bald mal kein Festnetz mehr gibt, weil man eh jeden über ENUM direkt per IP erreichen kann.]
Kommen die anonymen Calls aus demselben Context, wie die von braven Usern, kann man meist schon mit einem Gespräch an die "Nebenstelle" sip:00491234567879@doof-programmierter-server ein Gespräch ins Festnetz auf Kosen des Anlagenbetreibers absezen - ganz ohne, dass man Benutzernamen und Passworte erraten müsste!
Also bitte unbedingt
[general]
context = von-absolut-nicht-vertrauenswuerdiger-quelle
...
[nebenstelle]
context = von-lokaler-nebenstelle
und in den ersten Context baut man entweder gar nix rein, oder man überlegt sich genau, was man erlaubt und was besser nicht! Amtsnullen oder Vorwahlen können recht trickreich in der SIP URL "versteckt" werden!
Weiters kann man SIP Accounts auch einen "Accountcode" zuweisen. Meist wählen wir die Nebenstelle als Accountode, weil dann haben wir alle Parameter im Programmfluss immer bei der Hand (User, Nebenstelle, CallerID). Wenn man allen Nebenstelleneinen Accountcode verpasst, kann man beim Rauswählen zum PSTN (Provider, ISDN, ...) dann eine Sicherheitsabfrage machen und Rauswählen nur erlauben, wenn ein Accountcode (also eine Verrechnungsbasis) vorliegt:
if ( "${CDR(accountcode)}" != "" ) {
Dial(...PSTN...);
}
Weiters möchte ich dringend raten:
- verwendet AEL statt der alten Asterisk-Konfigsprache mit Zeilennummern. Das ist wesentlich übersichtlicher und damit weniger Fehleranfällig!
- kommentiert Euren Dialplan! Nach Monaten oder Jahren weiss man oft nichtmehr, warum etwas so gemacht wurde. Ändert man dann etwas, öffnet man damit den Hacken ein Türchen.
- verwendet Prototypen oder wie das heisst in der sip.conf. Dazu muss man nur an einer Stelle definieren, wie eine Nebenstelle allgemein auszusehen hat, und schreibt dann nur die Unerschiede dazu. Generelle Änderungen sind dann ein Klacks.
type = friend
host = dynamic
qualify = yes
nat = no
canreinvite = no
disallow = all
allow = alaw
allow = g722
subscribecontext = subscribe
call-limit = 3
context = from-user
t38pt_udptl = no
callerid = 018899999
deny = 0.0.0.0/0.0.0.0
permit = 212.236.252.0/255.255.252.0
permit = 212.236.160.224/255.255.255.224
[hansi](nebenstelle)
accountcode = 123
secret = sldknjs
vmexten = *9123
mailbox = 123
callgroup = 1
[seppi](nebenstelle)
accountcode = 333
secret = sldknjs
callgroup = 2
permit = 192.168.x.y
callerid = 018899999333
Das waren mal die ganz einfachen Dinge, die jeder in seiner Asterisk Konfiguration beachten sollte, ohne weiter darüber nachzudenken.
Sobald ich wieder ein bissi Zeit finde, möchte ich die aufwändigeren Verfahren beschreiben, mit denen man Hackern die Suppe ganz schön versalzen kann.
tschüss,
Thomas
