Hacker in meinem Asterisk Server

[WrMulf]

Auch mein Server ist "missbraucht" worden. Der Missbrauch fing am 18.04. an und dauerte bis 22.04. als Arcor bei 1000 EUR die Bremse reingehauen hat. Mir ist die Auslandsperre erst am 24.04. aufgefallen. Es wurden 22 verschiedene Auslandsziele angerufen, die meisten sind richtig teuer und insgesamt über 3600 Minuten. Ich habe die Forenbetreiber darauf aufmerksam gemacht, dass der Asterisk-Kurs von Betateilchen die Einrichtung eines anfälligen Asterisk-Server begünstigt. Glück haben diejenigen, die nur Prepaid-VoIP-Anbieter registriert haben, dieses Glück hatte ich leider nicht. Eine Anzeige wird nicht viel bringen, der Angriff kam aus China.

Gruß,
Robert

 

[rannseier]

Hat jemand die IPs für Denyhosts?

 

[gandalf94305]

Ich würde alle bis auf die erlaubten Hosts ablehnen. Eine Whitelist dürfte hier deutlich einfacher sein, denn die Anzahl der ISPs, von denen aus die Angriffe erfolgen können, ist recht hoch.

--gandalf.

 

[robinsonR]

[…] Eine Anzeige wird nicht viel bringen, der Angriff kam aus China.

Bei mir wurden unter anderem auch Nummern in Deutschland und England angerufen. Vielleicht ist das ein Weg; wenn man schon nicht auf den Anrufer zurückgreifen kann …

 

[IEEE]

Tschuldigung wenn ich mich hier einmische, ich möcht nur sicher gehen das ich hier nicht was falsch verstehe:

Wäre nicht der korrekte Weg um diese Sorgen los zu werden, starke Kennwörter zu verwenden, ggf. guest-calls unterbinden und dafür zu sorgen, dass nicht jeder über den Default-Kontext einfach raustelefonieren darf (sondern entsprechende Kontexte explizit bei den authentifizierten Usern zugewiesen werden)?

Oder überseh ich was?

IP-Sperren und dergleichen bringen bei groß angelegten Attacken sowieso nichts - jedenfalls nicht auf Dauer.

 

[schufti]

Hi IEEE,

neee ist schon richtig, damit sollte man anfangen und das wurde in den div. Postings zu dem Thema auch immer angeführt. Weiters wären dann eben zusätzliche Maßnahmen wie allow/deny, firewallrules, etc möglich.

und natürlich sollte man auch die Logs immer im Auge behalten, denn nicht immer ist der erste Angriff erfolgreich ... und das Thema Sicherheit kommt scheinbar immer ganz zuletzt oder erst wenn das Kind schon in den Brunnen gefallen ist....

schufti

P.S.: natürlich ist "allow" zielführender als "deny", aber bei den Angriffen aus dem Reich der Mitte ist die Häufung schon auffallend

P.P.S.: und bei vielen geht nach Änderung der Contexteinträge und guest=no gleich mal gar nix, die können mit allow/deny mal etwas Zeit gewinnen

 

[merkc]

Vorweg: Mein Asterisk läuft auf einer VPS, SuSE Linux 9.3.

Ich habe bei mir von Anfang an nur die Rufnummern frei zugelassen, die in eine Flatrate hinein"fallen" alles andere muss bei mir mit einem Code vorab gewählt werden. Dennoch versuchen Chinesische IP Adressen seit ca 4 Monate konstant meinen Server lahm zu legen. Da ich mit einer fixen IP arbeite, kann ich mich gar nicht dagegen wehren. Ich habe die SuSEFirewall2 am laufen, die meisten Ports geschlossen etc.
Nur, was soll man in einer solchen Situation machen? Die haben es schon mit mehreren DOS Attacken probiert. Da konnte ich nichts mehr machen -- nicht einmal einen einfach Bootprozess starten. Alles, was noch ging, war per Ferndiagnose das Backup vom Vormittag drauf zu spielen.....

Habt Ihr evt. einen Ansatz, wie man sich dagegen schützen kann?????

thnx,
Chris

 

[MHi]

Mich hats jetzt auch erwischt Mutmaßlich war es ein Rumäne...

Los gings mit nem Brute-Force Scan und dann der Nutzung der Leitung zwischen dem 24.4 und 29.4. Hauptziel war hier der Sudan, insgesamt etwa 300-350 Euro Telefonkosten (in verschiedenste Länder, ca 62 zustande gekommene Telefonate mit Gesamt ca 266 Minuten Gesprächsdauer).

@WrMulf hast du Anzeige erstattet?
Ich hab bei mir alle relavanten Daten zusammengekratzt und hebe diese für unsere Strafverfolgungsbehörden auf, vllt hilfts denen ja.


Bei den Accounts die Raustelefonieren dürfen habe ich jetzt erstmal die Passwörter geändert und entsprechende deny/permit-Regeln eingefügt.

 

[rmh]

Neben den genannten Möglichkeiten zur Absicherung von außen könnte man es mit Fail2Ban gegen die "Angriffe" versuchen: http://www.voip-info.org/wiki/view/Fail2Ban+(with+iptables)+And+Asterisk

 

[MHi]

Die Anfragen von der rumänischen IP haben jetzt nach knapp einem Tag aufgehört, der Port ist auch nur noch für bestimmte IPs offen. Interessant: die Brute-Force-Angriffe kamen von deutschen IP-Adressen, wobei sich UDP-Anfragen natürlich leicht spoofen lassen. Mal sehen wann sich jemand von der Polizei meldet und die Daten anfordert.

Schon das Brute-Forcen selbst ist, nach §202a, eine Straftat... bin also mal gespannt wie sich das entwickelt.

Wichtig für alle denen soetwas passiert: sichert die relevanten Logdaten und berechnet deren Hashwert.

 

[simfes]

bin also mal gespannt wie sich das entwickelt

Kleine Prognose gefällig?

...das Verfahren ist eingestellt worden,weil ein Täter nicht ermittelt werden konnte. Weitere Nachforschungen versprechen zurzeit keinen Erfolg

 

[WrMulf]

@MHi: Ich habe noch nicht Anzeige erstattet, ich wollte erst die nächste Rechnung abwarten.
Meine Hoffnung auf die Polizei ist aber äußerst gering. In einem ähnlichen Fall (gehackter Email-Account und darüber Übernahme des Ebay-Kontos) hat die Polizei sage und schreibe 9 Monate ermittelt und dann die Ermittlungen eingestellt mit der Aussage, sie hätten dem "Beschuldigten", von dessen Rechner aus die Angriffe ausgingen keinerlei Täterschaft nachweisen können.

Mein Asterisk auf dem vserver ist erstmal down und wird es vielleicht auch dauerhaft bleiben. Ich ärgere mich maßlos darüber, dass ich mich nur für die technischen Aspekte, nicht aber für die Sicherheitsaspekte des Asterisk interessiert habe und entsprechend keinerlei Vorkehrungen getroffen habe, das System abzusichern.

 

[woprr]

Ich habe die Forenbetreiber darauf aufmerksam gemacht, dass der Asterisk-Kurs von Betateilchen die Einrichtung eines anfälligen Asterisk-Server begünstigt.

Wo? Zitat aus dem Buch?

Habt Ihr evt. einen Ansatz, wie man sich dagegen schützen kann?

alwaysauthreject=yes und udp flooding schutz aktivieren in der Firewall aber das könnte auch RTP Audio blocken wenn die nicht gut ist:

Das funktioniert hier bis jetzt:
http://www.ip-phone-forum.de/showthread.php?t=213193

 

[WrMulf]

Wo? Zitat aus dem Buch?

Es geht darum, dass Betateilchen alles im [default]-Context einhängt. Wenn "allowguest=yes" eingestellt ist, was wohl auch der default-Fall ist, dann kann jeder über "00[schurkenstaat][teuererufnummer]@deine-server.ip" raustelefonieren, ganze ohne Authentifizierung. Das war bei mir das Problem.

 

[MHi]

Es geht darum, dass Betateilchen alles im [default]-Context einhängt. Wenn "allowguest=yes" eingestellt ist, was wohl auch der default-Fall ist, dann kann jeder über "00[schurkenstaat][teuererufnummer]@deine-server.ip" raustelefonieren, ganze ohne Authentifizierung. Das war bei mir das Problem.

Das ist natürlich ganz Übel... bei mir gabs immerhin vorher nen Brute-Force-Angriff auf den Account/das Passwort, praktischerweise kam dieser von einer deutschen IP-Adresse. Die IP lässt sich zwar bei UDP-Paketen einfach fälschen, aber der Angreifer will ja auch ein Feedback über die erfolgreiche Suche haben.

Btw. allowguest ist auch bei mir an, allerdings landen diese Anrufe nur im lokalen Context, ohne Möglichkeit auf irgendeinem Wege nach draußen zu telefonieren.

Edit: Am 10.4. gabs auch einen Brute-Force-Angriff, da aber von einer Amazon-EC2-IP, die haben Stundenlang auf 2 SIP-Accounts Passworte ausprobiert, die Accounts waren aber neuer und hatten sicherere Passworte (ausserdem waren sie eh nur im lokalen Context, aber das sieht der Angreifer ja vorher nicht)

 

[kombjuder]

Das war bei mir das Problem.

Dann mache einen Kontext

[default]
exten => _X.,1,Goto(Ansage,${EXTEN},1)

Unter Ansage hinterlegst du irgendeinen Text, der angesagt wird.

Das nimmt den Hackern den Spass und du erhälst im Falle einer Fehlkonfiguration meist ebenfalls diese Ansage und weisst, das du noch einen Fehler hast.

 

[jussuf]

Edit: Am 10.4. gabs auch einen Brute-Force-Angriff, da aber von einer Amazon-EC2-IP, die haben Stundenlang auf 2 SIP-Accounts Passworte ausprobiert,

... bei mir am 11./12. April das gleiche.

Das Muster ist offensichtlich: zunächst alle möglichen Endgerätenamen ansprechen, wenn dann die "richtige" Antwort kommt (falsches Passwort) stundenlang Passwörter ausprobieren.

Hab' jetzt den zugelassenen IP-Adressbereich eingeschränkt.

Übrigens haben diese Attacken auf einem vServer den unangenehmen Nebeneffekt, dass der Netzwerktraffic stark ansteigt. Wenn man dadurch zuviel Volumen verbraucht, kann es zusätzlich Geld kosten.

Die Angriffe haben pro Tag etwa 2 GB Netzwerktraffic ausgemacht.

 

[woprr]

Es geht darum, dass Betateilchen alles im [default]-Context einhängt. Wenn "allowguest=yes" eingestellt ist, was wohl auch der default-Fall ist, dann kann jeder

Da kann Betateilchen nix dafür wenn der Asterisk-Designer das IT-Grundprinzip der "geringsten Rechte" nicht umgesetzt hat, aber viele Mailserver hatten auch noch bis vor ein paar Jahren den open relay default.

Die IP lässt sich zwar bei UDP-Paketen einfach fälschen, aber der Angreifer will ja auch ein Feedback über die erfolgreiche Suche haben.

Ich hab jetzt nicht im Code nachgesehen aber die Antwort könnte auch an den Kontakt im ungefälscht belassenen SIP contact tag im header gehen obwohl die originating IP geloggt wird.

Deshalb lieber das ganze SIP-Paket oder den Verkehr anguggen bevor man den Falschen anschwärzt.

 

[MHi]

Ich hab jetzt nicht im Code nachgesehen aber die Antwort könnte auch an den Kontakt im ungefälscht belassenen SIP contact tag im header gehen obwohl die originating IP geloggt wird.

Deshalb lieber das ganze SIP-Paket oder den Verkehr anguggen bevor man den Falschen anschwärzt.

Das habe ich auch getan, und ich werde dem Beamten auch genau diese Bedenken sagen, sobald sie sich melden (bisher ist die Anzeige erst Online erstattet)

Btw. gestern gabs wieder Verbindungsversuche aus Rumänien an den Sip-Account, durch die Firewall verliefen die zwar ins leere, dennoch hab ich die Versuche (diesmal wars ne andere IP des gleichen Providers) mitgeschnitten.

 

[WrMulf]

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