Hacker in meinem Asterisk Server

[MHi]

Heute kam meine Arcor-Rechner zu diesem Vorfall... knapp 2400 EUR Schaden. Autsch!

Autsch, war allerdings bei >=3600 Minuten zu erwarten, gibt es Schwerpunkte bezüglich der Zielländer?

 

[WrMulf]

Es sind vor allem Mobilfunkrufnummern gewählt worden:

Philippinen mobil (670 EUR)
Gambia mobil (198 EUR)
Sierra Leone mobil (186 EUR)
Eritrea mobil (173 EUR)
Mexico mobil (155 EUR)
Kuba (125 EUR)
Lybien mobil (125 EUR)
Togo mobil (105 EUR)
El Salvador mobil (82 EUR)
Eritrea (50 EUR)
El Salvador (25 EUR)
Togo (25 EUR)
Haiti mobil (23 EUR) <-- krieg ich dafür eine Spendenquittung?
...

Obige Zahlen ohne Merkelsteuer. Der Rest ist vernachlässigbar. Ich kann gar nicht soviel essen, wie ich kotzen möchte...

 

[woprr]

Es sind vor allem Mobilfunkrufnummern gewählt worden:

Das who-is-who der Armut auf der Welt. Vielleicht findeste ne Organisation die das anerkennt und Dir ne Spendenquittung ausstellt, dann kriegstes von der Steuer. Frag doch mal bei den üblichen an?

Aber die Frage ist ja erstmal wer zahlt das jetzt? Bei der Summe lohnt sich schon ein Termin beim IT/TK-Rechtsanwalt...

Interessant wäre auch da mal mit chanspy oder so reinzuhören oder aufzuzeichnen, könnte auch hinweise geben wer das war.

Ich tippe auf nen talentierten Studenten von den Philippinen im Auslandsstudium der sich seine Studienfinanzierung als Telefonladen im Studentenwohnheim aufgebessert hat.

Bei Berufsverbrechern wären auch Ziele in reichen Ländern dabei.

 

[erdnuss0815]

Hallo alle zusammen.
Hab auf einem meiner Asterisk-Server am vergangenem Sonntag und Mittwoch morgen auch mehrere Versuche gehabt sich zu registrieren.
Alle nummern ab 110-9999 wurden duchgetestet u.a. auch eine 999... Nummer. danach alle möglichen Namen u.a. auch "test" "admin" usw.

Zum Glück liegen in meinem "default"-Kontext keine DIAL sondern nur ankommende und die mit 7stellen. Das wird mir die Haut gerettet haben!

Hab jetzt seit Mittwoch Ruhe.
Änderungen: White-List und Allowguest=no
Zudem nutze ich mehrere Sipgate-nummern mit automatischer Aufladungen.

Ich glaub ich hab noch mal glück gehabt. Wenn ich das höre mit den Kosten würd ich, glaub ich durchdrehen!

Es ist einfach zum K....!!

Hab die Änderungen gleich auf allen Servern durchgeführt - vorsichtshalber.
unten mal ein Auszug der notice.log wen's interessiert:

[May 5 02:21:08] NOTICE[17849] chan_sip.c: Registration from '"481"<sip:481@2XXXXXXXX>' failed for '217.75.242.195' - No matching peer found
[May 5 02:21:08] NOTICE[17849] chan_sip.c: Registration from '"info"<sip:info@2XXXXXXXXX>' failed for '217.75.242.195' - No matching peer found
[May 5 02:21:08] NOTICE[17849] chan_sip.c: Registration from '"test"<sip:test@2XXXXXXXXX>' failed for '217.75.242.195' - No matching peer found
[May 5 02:21:08] NOTICE[17849] chan_sip.c: Registration from '"postmaster"<sipostmaster@2XXXXXXX>' failed for '217.75.242.195' - No matching peer found
[May 5 02:21:08] NOTICE[17849] chan_sip.c: Registration from '"sales"<sip:sales@2XXXXXXXX>' failed for '217.75.242.195' - No matching peer found
[May 5 02:21:08] NOTICE[17849] chan_sip.c: Registration from '"482"<sip:482@2XXXXXXXXXX>' failed for '217.75.242.195' - No matching peer found
[May 5 02:21:08] NOTICE[17849] chan_sip.c: Registration from '"483"<sip:483@2XXXXXXXXX>' failed for '217.75.242.195' - No matching peer found

Der Server steht in Spanien - aber ich glaub der weiß noch nichts von seinem Glück!

 

[rannseier]

Aufgrund der vielfältigen Ziele gehe ich mal davon aus dass da ein "Anbieter" kräftig an den aufgebauten Gesprächen spart.

Hat jemand eine Idee für einen Honeypot?

 

[mankmill]

Das ganze Thema um den Asterisk Server hat bei mir jetzt die Frage aufkommen lassen, ob solche Angriffe auch auf eine normale VOIP Box, die zu Hause steht, gehen kann? Hat man darüber auch schon so etwas gehört?

mankmill

 

[MHi]

Das ganze Thema um den Asterisk Server hat bei mir jetzt die Frage aufkommen lassen, ob solche Angriffe auch auf eine normale VOIP Box, die zu Hause steht, gehen kann? Hat man darüber auch schon so etwas gehört?

mankmill

Wenn die VoIP-Box SIP nutzt und der Dienst vom Internet aus erreichbar ist, so ist dies anzunehmen. Das ist kein Angriff auf Asterisk, sondern auf offene SIP-Dienste.

Eventuell sollte man über eine penalty für fehlgeschlagene Logins nachdenken (nach dem 1. Fehlversuch 5s Sperre für die IP, nach dem 2. 10, dann 20, dann 40, usw.), damit könnte man das Brute-Forcing gewaltig behindern. Das bräuchte aber eine Firewall die SIP versteht oder eine Änderung an Asterisk (oder dem jeweilig anderen VoIP-Dienst).

 

[erdnuss0815]

Wenn die VoIP-Box SIP nutzt und der Dienst vom Internet aus erreichbar ist, so ist dies anzunehmen. Das ist kein Angriff auf Asterisk, sondern auf offene SIP-Dienste.

Ja, der Meinung bin ich auch. Ich kann ja meine Sip-Telefone auch über die externe IP registrieren wenn alles "gut" geroutet wird. Und wo die sich registrieren können, würde ich erst mal davon ausgehen, dass andere das auch können.

Vor allem wenn die Kiste den ganzen Tag läuft. Wie einige Systeme von mir auch. (Heul)

Edit: Bin grad am analysieren wie es meine stand-alone-systeme betrifft -> dass kann aber noch etwas dauern!

 

[kombjuder]

ob solche Angriffe auch auf eine normale VOIP Box, die zu Hause steht, gehen kann?

Wenn das Teil von aussen erreichbar ist, sicher. Dann kann zumindest versucht werden die User-Accounts zu hacken.

 

[kombjuder]

Hallo,

heute Nacht hatte ich einen Angriff auf einen neu eingerichteten Asterisk. Der Angriff erfolgte auf die sip-Accounts weniger als 24 Stunden nachdem der Server online war, von verschiedenen ip aus.

Es wurden antwortende Accounts gleichzeitig von min. 2 verschiedenen IP aus gesucht. Da beide scanns paralell liefen, waren das vmtl. 2 Angreifer, sonst hätte jeder nur einen Bereich durchsucht.

Ich vermute mal, es werden die ip-Bereiche von Serverfarmen gescannt um Ziele zu finden.

 

[cmmehl]

Hat einer von euch angegriffenen denn fail2ban am laufen?

Ich will jetzt den tag nicht vor dem abend loben, und meine asterisken wurden bislang nicht angegriffen - allerdings kickt fail2ban recht zuverlaessig, und es ist dann geradezu ein freude, auf ein grep "refused" /var/log/auth.log sowas zu bekommen:

May  9 07:17:17 localhost sshd[27948]: refused connect from 208.75.83.28 (208.75.83.28)
May  9 09:08:55 localhost sshd[17453]: refused connect from host-87-99-27-177.lanet.net.pl (87.99.27.177)
May  9 09:09:01 localhost sshd[17461]: refused connect from host-87-99-27-177.lanet.net.pl (87.99.27.177)
May  9 09:09:06 localhost sshd[17552]: refused connect from host-87-99-27-177.lanet.net.pl (87.99.27.177)
May  9 09:09:11 localhost sshd[17557]: refused connect from host-87-99-27-177.lanet.net.pl (87.99.27.177)
May  9 09:09:16 localhost sshd[17558]: refused connect from host-87-99-27-177.lanet.net.pl (87.99.27.177)
May  9 09:09:21 localhost sshd[17563]: refused connect from host-87-99-27-177.lanet.net.pl (87.99.27.177)
May  9 09:09:26 localhost sshd[17569]: refused connect from host-87-99-27-177.lanet.net.pl (87.99.27.177)
May  9 09:09:31 localhost sshd[17572]: refused connect from host-87-99-27-177.lanet.net.pl (87.99.27.177)
May  9 09:09:36 localhost sshd[17576]: refused connect from host-87-99-27-177.lanet.net.pl (87.99.27.177)
May  9 09:09:41 localhost sshd[17581]: refused connect from host-87-99-27-177.lanet.net.pl (87.99.27.177)
May  9 09:09:47 localhost sshd[17586]: refused connect from host-87-99-27-177.lanet.net.pl (87.99.27.177)
May  9 10:04:21 localhost sshd[20918]: refused connect from 109.104.187.33 (109.104.187.33)
May  9 10:04:21 localhost sshd[20920]: refused connect from 109.104.187.33 (109.104.187.33)
May  9 10:04:26 localhost sshd[20921]: refused connect from 109.104.187.33 (109.104.187.33)
May  9 10:04:31 localhost sshd[20933]: refused connect from 109.104.187.33 (109.104.187.33)
May  9 10:04:36 localhost sshd[20934]: refused connect from 109.104.187.33 (109.104.187.33)
May  9 10:04:41 localhost sshd[20942]: refused connect from 109.104.187.33 (109.104.187.33)
May  9 10:04:46 localhost sshd[20944]: refused connect from 109.104.187.33 (109.104.187.33)
May  9 10:04:51 localhost sshd[20945]: refused connect from 109.104.187.33 (109.104.187.33)
May  9 10:04:56 localhost sshd[20946]: refused connect from 109.104.187.33 (109.104.187.33)
May  9 10:05:02 localhost sshd[20954]: refused connect from 109.104.187.33 (109.104.187.33)
May  9 10:05:07 localhost sshd[20958]: refused connect from 109.104.187.33 (109.104.187.33)
May  9 10:05:12 localhost sshd[20960]: refused connect from 109.104.187.33 (109.104.187.33)
May  9 11:27:31 localhost sshd[25853]: refused connect from g225090239.adsl.alicedsl.de (92.225.90.239)
May  9 11:27:36 localhost sshd[25856]: refused connect from g225090239.adsl.alicedsl.de (92.225.90.239)
May  9 11:27:41 localhost sshd[25863]: refused connect from g225090239.adsl.alicedsl.de (92.225.90.239)
May  9 11:27:46 localhost sshd[25896]: refused connect from g225090239.adsl.alicedsl.de (92.225.90.239)
May  9 11:27:51 localhost sshd[25899]: refused connect from g225090239.adsl.alicedsl.de (92.225.90.239)
May  9 11:27:56 localhost sshd[25906]: refused connect from g225090239.adsl.alicedsl.de (92.225.90.239)
May  9 11:28:02 localhost sshd[25913]: refused connect from g225090239.adsl.alicedsl.de (92.225.90.239)
May  9 11:28:07 localhost sshd[25920]: refused connect from g225090239.adsl.alicedsl.de (92.225.90.239)
May  9 11:28:12 localhost sshd[25924]: refused connect from g225090239.adsl.alicedsl.de (92.225.90.239)
May  9 11:28:17 localhost sshd[25931]: refused connect from g225090239.adsl.alicedsl.de (92.225.90.239)
May  9 11:28:22 localhost sshd[25934]: refused connect from g225090239.adsl.alicedsl.de (92.225.90.239)
May  9 12:26:51 localhost sshd[32027]: refused connect from 124-171-220-12.dyn.iinet.net.au (124.171.220.12)
May  9 12:26:57 localhost sshd[32032]: refused connect from 124-171-220-12.dyn.iinet.net.au (124.171.220.12)
May  9 12:27:03 localhost sshd[32041]: refused connect from 124-171-220-12.dyn.iinet.net.au (124.171.220.12)
May  9 12:27:09 localhost sshd[32044]: refused connect from 124-171-220-12.dyn.iinet.net.au (124.171.220.12)
May  9 12:27:15 localhost sshd[32050]: refused connect from 124-171-220-12.dyn.iinet.net.au (124.171.220.12)
May  9 12:27:24 localhost sshd[32053]: refused connect from 124-171-220-12.dyn.iinet.net.au (124.171.220.12)
May  9 12:27:29 localhost sshd[32060]: refused connect from 124-171-220-12.dyn.iinet.net.au (124.171.220.12)
May  9 12:27:35 localhost sshd[32061]: refused connect from 124-171-220-12.dyn.iinet.net.au (124.171.220.12)
May  9 12:27:44 localhost sshd[32082]: refused connect from 124-171-220-12.dyn.iinet.net.au (124.171.220.12)
May  9 12:27:50 localhost sshd[32102]: refused connect from 124-171-220-12.dyn.iinet.net.au (124.171.220.12)
May  9 12:27:56 localhost sshd[32107]: refused connect from 124-171-220-12.dyn.iinet.net.au (124.171.220.12)

Schoenen sonntag allseits
Chris

 

[mankmill]

Wenn das Teil von aussen erreichbar ist, sicher. Dann kann zumindest versucht werden die User-Accounts zu hacken.

Also sind alle Boxen, die über DynDNS registriert sind potenziell gefährdet? Somit wäre es nur eine Frage der Zeit, bis hier sich mal user melden, die über unbekannte Anrufe im log klagen. Aber ich denke solche eine mühselige Arbeit macht sich keiner, solch eine VOIP Box über DynDNS zu suchen. Aber wie kommen hacker auf die Spur einen Asterisk zu finden?

mankmill

 

[Timmbo]

Hallo,

diese Problematik wurde hier schon öfters beschrieben.
Im [default] darf erstens keine Regel sich befinden die in irgend einer weise nach draußen führt, diese wären z.B.

include=outgiongsipgate
exten => X.,1,Dial(sip/${EXTEN}@sipgate,240,t)

Außerdem bringt ein Nebenstellen Passwort wie test, "nebenstelle" oder Asterisk usw. garnichts.

@mankmill
Indem sie Portscans auf 5060 durchführen, oder eben an "jede" IP die Callinganfrage senden.


Grüße
Timm

 

[minze]

...

Ich tippe auf nen talentierten Studenten von den Philippinen im Auslandsstudium der sich seine Studienfinanzierung als Telefonladen im Studentenwohnheim aufgebessert hat.

Oder behördliche Organisationen, die ihren Mitarbeitern etwas mitteilen möchten und sich den langsamen Umweg über z.B. Number stations sparen wollen. Wobei die Gesprächsaufzeichnung eines solchen gehackten im Optimalfall Prepaid-SIP-Accounts da natürlich mehr Aufschlüsse geben würde.

 

[PsychoMantis]

Also ich meine, meinen Asterisk gut abgesichert zu haben. Einfach so kann man selbst von legal angemeldeten Nebenstellen nicht telefonieren (geht nur das, was kostenlos (Flat) ist).

Aber die Sache mit den FritzBoxen macht mir jetzt schon sorgen. Viele kennen ja die Sache mit dem reg_from_outside=yes.
Wenn also jemand per bruteforce das Passwort für meine Nebenstelle 620 rausgefunden hat, kann er wählen was ich will (z.B. *124#nummerinhaiti).
Wie kann ich mich dagegen wehren? Oder war AVM so schlau und hat da einen bruteforce-Schutz einprogrammiert (die Idee wie oben erwählt)?

Nachtrag: Diesbezüglich wurde hier ein Thread erstellt.

 

[kombjuder]

Also sind alle Boxen, die über DynDNS registriert sind potenziell gefährdet?

Das hat nichts mit dyndns zu tun. Ein Scan auf Port 5060 reicht. Wenn dort eine entsprechende Antwort kommt, kann versucht werden, einen Sip-Account zu hacken.

Aber wie kommen hacker auf die Spur einen Asterisk zu finden?

Einen Adressbereich auf Port 5060 scannen und schauen ob eine passende Antwort kommt.

 

[woprr]

Ein Scan auf Port 5060 reicht.

Nein, eine gute SPI-Firewall kann man nur schwer abscannen, die antwortet höchstens auf connect-scans und die dauern zulange um grosse Bereiche abzuscannen.

 

[gandalf94305]

:lach: ein Scan auf Port 5060 :lach:

Das muss ich jetzt aber nicht weiter kommentieren, oder? :kasper:

SCNR,
--fladnag.

 

[frindly]

Muss ich jetzt verstehen, was daran lustig ist?

 

[woprr]

Ich hab mal einen "scan" auf die Geräte von ein paar Freunden gemacht, die O2-Zyxel sind mit
nmap -v -PN -PU -sU -p 5060 <addresslist>
nicht auffindbar, eine Fritzbox
User-Agent: AVM FRITZ!Box Fon WLAN 7170 (UI) 29.04.80 (Jan 27 2010)
aber schon...