Hacker in meinem Asterisk Server

Anscheinend hat derselbe Hacker sich auch an meinem Asterisk versucht.
Es sieht so aus,als ob derselbe Hacker wieder aktiv ist. Seit 2 Tagen versucht er, über meinen Asterisk wieder eine Nummer in Israel anzuwählen, allerdings ohne Registrierungsversuche. Nacheinander wählt er die Nummer +972597595449 mit verschiedenen (internationalen) Vorwahlen, um ein Amt zu erhalten (00, 000, 011, 810, 0011, 001, 0015, 9011, 900, 002). Dabei benutzt er verschiedene Extensions als Caller-ID (100, 101, 1001). In den Asterisk-Logs stehen bei diesen Versuchen nicht mal IP-Adressen.

Schaden richtet er keinen an, aber nervig ist das schon, wenn die Call Logs und natürlich auch die anderen Logs volllaufen. Ich habe mal "verbose" auf 3 gesetzt, um ein wenig besser zu erkennen, was der Typ versucht. Aber bisher bleibt er bei dem oben beschriebenen ziemlich einfallslosen Muster.
 
Warum richtest Du kein Fail2Ban ein? Das würde Dein Problem hier lösen.
 
Nicht wirklich. Fail2ban benutzt die IP-Adressen, die es in Log-Files findet. Hier gibt es aber gar keine, die im Log-File stehen. Wenn er statt +972...@meine-ip meine Telefonnummer, also +49...@meine-ip wählen würde, würde ja sogar mein Telefon klingeln, denn das habe ich für ENUM-Nutzer ausdrücklich erlaubt. Er macht ja gar keine Registrierungsversuche, so dass fail2ban ihn sperren könnte.
 
Mal angenommen man nutzt:
allowguest=no
nat=no

Auf dem Router sind keinerlei Ports forgewardet aber man kann trotzdem telefonieren weil Asterisk seine eigenen NAT Methoden hat, wäre es dann immer noch möglich von aussen über Asterisk zu telefonieren, selbst wenn der Angreifer das Passwort wüsste?

Übrigens, bei SIP Telefonen wie z.B. Cisco ist die Konfiguration und somit das Passwort über TFTP für jedermann abrufbar im LAN. Man braucht nur die MAC vom Telefon herauszufinden aber das ist ja kein Problem.
 
nein, wenn der Router zu ist, kann ja keiner rein (s.a. Post #376). Du wirst aber nat=yes einstellen müssen, damit die NAT-Methoden von Asterisk auch angewendet werden.

In Dein Lan solltest Du wohl besser niemanden lassen, dem Du nicht traust. Aber beschreib doch mal näher, wie der Passwortklau Deiner Ansicht nach möglich ist. Ich kann das hier nicht nachstellen.
 
Na ich habe eben nat=no ohne Router Einstellungen und kann keinerlei Unterschied feststellen zu nat=yes mit Portforwardings auf dem Router.
Das muss wohl damit laufen: http://www.ietf.org/rfc/rfc3581.txt

When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request.

Bei nat=no basiert das wohl auf den sip headern aber so genau kenne ich mich da auch nicht aus. Auf jeden Fall ist damit nicht gemeint das NAT komplett aus ist.

Das alles geht aber natürlich nur wenn Telefone und Asterisk im LAN sind und kein WAN dazwischen.

Das mit dem Passwortklau, nur mal angenommen Asterisk läuft bei einer Firma und ein Mitarbeiter fängt da zum spionieren an. Die configs von den Telefonen liegen ja total offen, da wäre es schon fast besser man schaltet tftp nur an wenn man neue Telefone hat.
 
In welcher Datei liegt denn das Passwort?
 
und da ist das Sip-Passwort drin? (mach doch mal einen Quote - mit verändertem Passwort)
 
Nicht wirklich. Fail2ban benutzt die IP-Adressen, die es in Log-Files findet. Hier gibt es aber gar keine, die im Log-File stehen. Wenn er statt +972...@meine-ip meine Telefonnummer, also +49...@meine-ip wählen würde, würde ja sogar mein Telefon klingeln, denn das habe ich für ENUM-Nutzer ausdrücklich erlaubt. Er macht ja gar keine Registrierungsversuche, so dass fail2ban ihn sperren könnte.

Hmm... ja, macht natürlich Sinn. Müsste dann ja ein IDS sein. Kann man das Verbose nicht soweit aufbohren, dass dennoch die IP-Adresse protokolliert wird? Eventuell zeitweise im Debug, sofern möglich, laufen lassen? Ansonsten gäbe es ja noch die Option, bestimmte Netzbereiche (China, Afrika, etc..) auszuschliessen bzw. in der Firewall zu blocken.
 
danke, interessant. Also besser Provisionieren über HTTP. Ob die alte 79xx-Reihe das kann, weiß ich aber nicht. Die SPA5xx können das aber. Der Cisco-Provisioning Guide schreibt
HTTP is recommended for provisioning as it offers greater reliability, given NAT
and router protection mechanisms. TFTP is useful for the in-house preprovisioning
of a large number of un-provisioned devices.

Vielleicht sollten wir aber zum Topic zurück kehren?
 
Hallo,

ich habe vor kurzem einen Asterisk Server bei der Telekom eingerichtet und habe nun einen Brief erhalten, dass mein Auslandsanschluss aufgrund von hoher Anruffrequenz gesperrt wurde. Ein Blick in die Master.csv konnte das bestätigen. Mein System habe ich nach diesem Thread eingerichtet: http://www.ip-phone-forum.de/showthread.php?t=248575.

Ich denke, ich war dabei zu unvorsichtig und muss jetzt daraus lernen, die Rechnung ist noch nicht da. Jedoch verstehe ich noch nicht genau was passiert ist. Ich habe drei SIP Clients eingerichtet, die sich auch von außerhalb des LANs anmelden konnten [31] [32] [33].

Dementsprechend wird es bei meinen eigenen Telefonaten auch im LOG angezeigt, z.B. "SIP/30-00000036". Alle Anrufe, die jedoch nicht bewusst von mir getätigt wurden, haben folgende Kennung: SIP/93.192.101.185. 93.192.XXX.XXX sind IP-Adressen der Telekom und die Adresse ist wohlmöglich meine eigene IP Adresse gewesen sein. Demnach hat mein Server die Anrufe getätigt, ohne dass ich einen Client benutzt habe? Da wundert es mich doch, wie der Zugriff stattgefunden hat.

Vielen Dank für eure Hilfe!
 
Ohne Deine verwendete Konfiguration wäre alles Spekulation und Rätselraten. Könnte Allow-Guests und ein offener default-context sein.
 
Ok, hier sind meine Konfigurationen (private Daten sind verändert)

sip.conf
Code:
[general]
context = default
bindport = 5060
bindaddr = 0.0.0.0

; Registrierung bei T-Online
register => XXXXXXXXXX:XXXXXX:[email protected]@tel.t-online.de/XXXXXXXXXX~240
register => XXXXXXXXXX:XXXXXX:[email protected]@tel.t-online.de/XXXXXXXXXX~240
register => XXXXXXXXXX:XXXXXX:[email protected]@tel.t-online.de/XXXXXXXXXX~240

[external-standard](!)
trustrpid=no
context=incoming
type=peer
insecure=port,invite
usereqphone=no
t38pt_udptl=no
nat=yes
disallow=all
allow=ulaw
allow=alaw
dtmfmode=rfc2833

[DTAG-IP](external-standard)
[email protected]
[email protected]
secret=XXXXXXXXXXX
host=tel.t-online.de
fromdomain=tel.t-online.de
qualify=yes

[DTAG-IP_IN1](external-standard)
host=217.0.16.26

[DTAG-IP_IN2](external-standard)
host=217.0.16.90

[DTAG-IP_IN3](external-standard)
host=217.0.16.106

[DTAG-IP_IN4](external-standard)
host=217.0.16.154

[DTAG-IP_IN5](external-standard)
host=217.0.16.170

[DTAG-IP_IN6](external-standard)
host=217.0.16.230

[30]
callerid=XXXXX <30>
domain=192.168.0.100
type=friend
secret=XXXXX
host=dynamic
nat=no
user=30
canreinvite=no

[31]
callerid=XXXXX <31>
domain=192.168.0.100
type=friend
secret=XXXXX
host=dynamic
nat=no
user=31
canreinvite=no

[32]
callerid=XXXXX <32>
domain=192.168.0.100
type=friend
secret=XXXXX
host=dynamic
nat=no
user=32
canreinvite=no

extension.conf
Code:
[general]
static=yes
writeprotect=no

[lokal]

exten => _3X,1,NoCDR()
exten => _3X,n,Dial(SIP/${EXTEN},55,Ttr)

[external-standard]
exten => _0.,1,Set(CALLERID(num)=XXXXXXXXX)
exten => _0.,n,Set(CALLERID(name)=XXXXXXX)
exten => _0.,n,Dial(SIP/${EXTEN}@DTAG-IP,60,tr)

[echotest]
exten => 600,1,Answer
exten => 600,2,Wait(1)
exten => 600,3,Playback(demo-echotest)
exten => 600,4,Echo
exten => 600,5,Playback(demo-echodone)
exten => 600,6,Hangup

[default]
include => lokal
include => echotest
include => external-standard

[incoming]
exten => XXXXXXXXX,1,Dial(SIP/30&SIP/31)
exten => XXXXXXXXX,1,Dial(SIP/32)
exten => XXXXXXXXX,1,Dial(SIP/30&SIP/31)
 
Das war vorauszusehen. Ich entdecke kein allowguest=no und über den standard Kontext kann jeder raustelefonieren. Das klassische offene Relay. Ich wünsche Dir das Du mit einem blauen Auge davon kommst, ich kenne Fälle wo da Kosten im fünfstelligen Bereich entstanden sind.
 
Mein Beilieid ebenfalls, wäre nett wenn Du uns bei Zeiten mal über die Höhe des Lehrgeldes informierst - WENN DU DAS MÖCHTEST.

Zur Vollständigkeit, so kann ein DEFAULT Kontext aussehen.
Code:
[default]           

; Hier wird nichts angeboten ausser einer Sackgasse und einem Meldung fürs Logf$

exten => _X.,1,Answer ()
exten => _X.,n,Verbose(D E F A U L T ==> ${CALLERID(num)} kam um ${STRFTIME(${E$
exten => _X.,n,Set(MIXMONITOR_FILENAME=${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}-${E$
exten => _X.,n,[COLOR=#b22222]Playback(/var/www/ansagen/keine_wahlregel)[/COLOR]
exten => _X.,n,Hangup
rot = Sprachdatei auf Option.

Ich drück die Daumen mit das die TKom mittlerweile Ihre Auslandsgrenzen tiefer hält als es damals bei mir der Fall war. Ggf. hast Du ja die Möglichkeit auf das Thema "Kulanz" zu klopfen..?

Ich bin gerade über eine Möglichkeit gestolpert seinen Asterisk "mal eben" von außen zu prüfen - der Link kann hier mM hinein, aber das letzte Wort hat der Mod...LINK zu SINOLOGIC (sehr langsam)
[Mod sagt, Link kann bleiben ;-), ist ja keine Anleitung zum hacken]

Grüsse, Stefan
 
Zuletzt bearbeitet von einem Moderator:
Hallo,

danke erst einmal für eure Auskunft. Habe gerade die OnlineRechnung bekommen, die sich auf 2180€ beläuft. Eine Auswertung der Logs zeigte, dass sich die meisten Kosten auf Anrufe nach Afghanistan und den Malediven beziehen (Moldavien war auch dabei, aber dank 20cent/min günstiger).
Ich werde natürlich mal bei der TCom anrufen und auf Kulanz hoffen, dabei wäre es vielleicht günstig zu wissen, wie hoch die realen Kosten für die TCom sind?
 
Die Höhe der Kosten der TKom lassen wir mal außer Acht. Ggf. kannst Du mit dem Argument arbeiten das Du ja treuer Kunde der Serverwelt, sowie auch der Telefonwelt bist [..] böse Hacker [..] Du hast Strafanzeige erstattet (!!) [..] Sicherheitsvorkehrungen prüfen gelassen [..]

Aber Du hast es schon oben gelesen - jetzt ist der richtige Zeitpunkt da auch eine Strafanzeige gegen unbekannt zu stellen (am besten online) - damit die Sache auch einen formellen Charakter erhält...Du wirst deshalb keinen einzigen Cent zurückbekommen. Sichere die IPs der Angreifer, die Uhrzeiten, die Ziele. Beschreibe Deine Sicherungswege und vielleicht vergisst Du mal wie da das Tor offen stand...

LG Stefan
 
Hallo Teilnehmer des IP-Phone-Forums,
Ich hatte auch den Fehler mal gemacht das mit „allowguest“ nicht gesetzt zu haben. Es gab keine Kulanz Seitens des Telefonproviders egal ob man eine Strafanzeige gemacht hat oder nicht bei mir waren es auch 2480 €. Der Asterisk Server war 5 tage offen dieser „Hacker/Illegaler Benutzer“ hat insgesamt 24std ins Ausland telefoniert . Ich habe herausgefunden durch die Logs das die IP von einer Niederländischen Rechenzentrum kam aber der Sitz des Rechenzentrums nur eine Zweigstelle von Amerikanischen Rechenzentrumsbetreiber war. Tja Shit..Happens wie man so schön sagt. Lehrgeld das richtig weh tut.

Mein Beileid an alle die bis jetzt das gleiche hatten und es werden ...
Meine Meinung : Es muss echt mal direkt festeingetragen werden das „allowguest=no“ fest drin steht in der config von Asterisk.
Dieser Text wurde überprüft und wurde überarbeitet.
Mfg
Starwing
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

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

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