Hacker in meinem Asterisk Server

(niemals default nehmen zum raustelefonieren am besten default weglassen)

Würde ich so nicht empfehlen!

default als ersten Kontext anlegen und eine Ansage machen lassen.

Wenn mal ein Fehler in einem context ist, oder die Asterisk-Programierer wieder mal was umgebaut haben, bekommst du "deine" Ansage und weist was los ist.


Ausserdem ist es höflicher, einem Hacker "good bye" zu sagen. Sein Suchscript freut sich zudem über den Erfolg.
 
kannst du mal bitte so was posten :-D echt gute idee
 
Was ist so schwierig daran?
Code:
[general]
context=default
Code:
[default]
exten=>_X.,1,Playback(vm-goodbye)

Wenn Dir das zu unpersönlich ist, nimm selber eine Ansage auf und konvertiere sie nach GSM, sofern Dein Asterisk kein WAV abspielen kann.
 
@mario2006, verwende bitte CODE statt QUOTE, dann nehmen deine Logs weniger Platz ein. Danke.
 
Hi!

fail2ban ist zwar recht nett, aber noch besser ist es erst gar keine Angriffe zu bekommen. Da diese stupiden "Hacker" scheinbar alle die selben Skripts verwenden, die nur auf Reaktionen am Port 5060 reagieren, liegt nichts näher als den * einfach (unter Berücksichtigung aller anderen Sicherheitsfeatures der Konfiguration) auf einen anderen Port zu binden. Somit ist 5060 zu und das Skript geht nach dem ersten - erfolglosen - Verbindungsversuch zum Nachbarn im Web ohne weiter meine Bandbreite oder meinen Router zu belasten.

Bisher hatte ich weder mit Clients noch mit VoIP Providern Probleme und schon seit Monaten kein Log eines Angriffsversuchs.

schufti
 
Zuletzt bearbeitet:
Da diese stupiden "Hacker" scheinbar alle die selben Skripts verwenden, die nur auf Reaktionen am Port 5060 reagieren,

Vorgestern wurde der V-Server eines Bekannten gehackt, nicht der Asterisk. Wie ist unklar, da der Zugang nur über Putty-Key möglich ist.

Es wurden die Konten leertelefoniert, verschiedene Änderungen im ssh-Verzeichnis vorgenommen und die Passwörter verschiedener Voip-Konten gestohlen.

Angerufen wurde vorwiegend 00886941366157, was eigentlich ein taiwanesisches Handy sein sollte, aber 6 oder 7 gleichzeitige Gespräche annimmt.

Das ganze ist nach etwa 1 Stunde aufgefallen, da ein Konto sich als leer meldete. Der Schaden beläuft sich auf unter 100 Euro.

Es blieb nur, den Server komplett neu aufzusetzen.
 
Das kann man auch mit einer Fritzbox. Solange mir die Kentnisse fehlen das alles sicher genug zu machen ist es für mich keine gute Idee einen Asterisk mit gleicher IP zu betreiben.

Ach, die closed source firmware von AVM wo keiner weiss was drin ist soll sicherer sein?

Da sind die cracker auch schon dran und da gibts keine SIP verbose logs die einen warnen, man will ja die Kunden schliesslich nicht verunsichern.

Ganz schön viel Vertrauen in eine Firma die die Software-Qualitätssicherung an Internetforen ausgelagert hat :)
 
@kombjuder:

Ja, das ist aber eine ganz andere Geschichte. Das hat nix mit sicherem Betrieb und verhindern des Misbrauchs vom Asterisk zu tun. Und da hilft fail2ban auch nicht, wenn es aufs * log guckt.

schufti
 
Das hat nix mit sicherem Betrieb und verhindern des Misbrauchs vom Asterisk zu tun.

Hallo schufti,

na, ich weiss nicht so ganz. Da wurde gezielt versucht in Server einzubrechen um den Asterisk zu missbrauchen bzw. an seine Daten zu gelangen.
 
Ach, die closed source firmware von AVM wo keiner weiss was drin ist soll sicherer sein?

Da sind die cracker auch schon dran und da gibts keine SIP verbose logs die einen warnen, man will ja die Kunden schliesslich nicht verunsichern.

Ganz schön viel Vertrauen in eine Firma die die Software-Qualitätssicherung an Internetforen ausgelagert hat :)

Ich denke dass die Fritzbox sicherer ist als der Durchschnitts-Asterisk-Server eines IPPF-Users.
 
Ausserdem ist es höflicher, einem Hacker "good bye" zu sagen. Sein Suchscript freut sich zudem über den Erfolg.

Ein freundliches "*uck off!" tut es auch!

Vorgestern wurde der V-Server eines Bekannten gehackt, nicht der Asterisk. Wie ist unklar, da der Zugang nur über Putty-Key möglich ist.

Deinem Bekannten empfehle ich den Rechner komplett neu aufzusetzen, wer weiß was die alles veraendert haben. Change PW, send PW per mail [email protected], usw.
Deshalb Vorsicht mit einer PW-Aenderung der servers ist es nicht getan.

Ich bin kein Linux Crack. Aber das ist einfach Basic. Sudo heisst das magische Wort.

1. Neuen SSH user anlegen
2. User als Sudo user mit root Rechten hinzufuegen
3. SSH conf. file, permanent root login=no
4. SSH Port auf xxxx abaendern
5. SSH neu starten

Und dann ueber sudo zu root rechten kommen.

Und Ruhe ist.


Gruesse
Mario
 
Deinem Bekannten empfehle ich den Rechner komplett neu aufzusetzen,

Hallo Mario,

da uns nicht bekannt ist, was da an backdoors hinterlegt wurde, ist der V-Server komplett neu aufgesetzt, mit einem aktuelleren Debian.

Passwort-login ist generell untersagt. Nur der eingerichtete User kommt mit einem key an den Server und kann dann via sudo...
 
Ich darf etwas beitragen und mich damit auch outen

:newbie:

Heute - genauer gesagt vor 30 Minuten, habe ich wartungsarbeiten am Asterisken gemacht und hatte die CLI auf dem zweiten Schirm, zum Glück. Denn da durfte ich mitlesen wie sich "89.32.214.236" (IP existiert jetzt sogar noch) auf einer "einfachen internen Nebenstelle" mit der sehr intelligenten Nummer "10" angemeldet hat, da "10" ein lokales Gerät ist hatte mich das etwas verdutzt - ich habe schnell für 10 die Rechte auf ein minimum reduziert (bei mir habe ich alle Kontexte die etwas von "Rechten" abgeben per include in die einzelnen Anmeldekontexte gelegt - das war damals "state of the art".

So - nun hatte sich also ein Fremder im Server angemeldet, er tat nichts, ich wartete.

Nach gefühlten 5 Minuten habe ich dann schlichtweg die "10" einfach mal angerufen und es ging ein (nur nach dem Gespräch zu urteilen) - ca. 40 jähriger, gebrochen englisch sprechender Herr sofort an den Apparat, er wirkte verwirrt und ich denke er wusste nicht was der Grund meines Anrufes war, ich erklärte das er sich in einem deutschen Geschäftsserver angemeldet hat - das man so etwas als Hacking bezeichnen könnte und bat ihm seine Konfiguration zu überprüfen.

Der mir angezeigte Useragent war "Zoiper rev.6848" - also ein Softphone, man könnte annehmen das es kein Zufall war das er sich damit verbunden hat.

Meine ganze Sicherheit bisher bestand seit 2005 aus diesen Maßnahmen :

Code:
alwaysauthreject=yes            
allowguest=no
Die externen Nutzer haben ein "starkes" Passwort bekommen, jedoch die internen hatten - wie es damals eben üblich war schlichtweg "Nutzer 10, Passwort 10" bekommen.

Was ich nun die letzte Stunde getan habe - Firewall enger geschlossen, alle Passwörter auf den "extern und starken" Standard mit +12 Zeichen und LowerUpperCase gesetzt. Den DefaultContext nochmals durchgesehen - war aber okay. Sobald eine Fernverbindung gewünscht wird, kommt eine von 5 Rotationsabfragen, PLZ wird abgefragt u.a. - einfache Fragen die jeder im Unternehmen kennen sollte.

Eine permit/deny Regel kann ich leider ohne weiteres nicht setzen ... :

interne Nebenstellen müssen von extern nicht erreichbar sein, daher macht es meiner Meinung nach durchaus Sinn, zulässige IP-Adressen abzugrenzen.
Muss eine externe Nebenstelle mit wechselnder IP eingebunden werden, so würde ich ernsthaft über VPN nachdenken. Snom bietet dafür beispielsweise eine spezielle Firmware an.
Ich darf also über VoIP über VPN nachdenken - ob es dazu kommt kann ich hier noch nicht eingrenzen.

So! Ich denke die Zeit in der man Asterisk ohne Fremdanmeldungen und böse Menschen nutzen konnte sind somit auch für mich vorbei.

Links zu diesem Thema (kann man im ganzen Thread finden - hier nochmals an einer Stelle) :

7 Sicherheitstipps von Digium
Fail2Ban aus VoIP-info.org

Ist das nicht doof sich outen zu müssen ?

:-Ö

LG Stefan

EDIT :

Nach dem durchsehen der Logs musste ich so etwas hier finden - das war bisher unentdeckt geblieben ... :

Code:
[Aug  8 10:50:19] NOTICE[9311] chan_sip.c: Registration from '"2991787367"<sip:[email protected]>' failed for '196.37.28.196' - No matching peer found
[Aug  8 10:50:19] NOTICE[9311] chan_sip.c: Registration from '"2488249130"<sip:[email protected]>' failed for '196.37.28.196' - No matching peer found
[Aug  8 10:50:20] NOTICE[9311] chan_sip.c: Registration from '"test"<sip:[email protected]>' failed for '196.37.28.196' - No matching peer found
[Aug  8 10:50:20] NOTICE[9311] chan_sip.c: Registration from '"100"<sip:[email protected]>' failed for '196.37.28.196' - No matching peer found        
[Aug  8 10:50:20] NOTICE[9311] chan_sip.c: Registration from '"101"<sip:[email protected]>' failed for '196.37.28.196' - No matching peer found

[...]

[Aug  8 10:52:40] NOTICE[9311] chan_sip.c: Registration from '"9997"<sip:[email protected]>' failed for '196.37.28.196' - No matching peer found
[Aug  8 10:52:40] NOTICE[9311] chan_sip.c: Registration from '"9998"<sip:[email protected]>' failed for '196.37.28.196' - No matching peer found
[Aug  8 10:52:40] NOTICE[9311] chan_sip.c: Registration from '"9999"<sip:[email protected]>' failed for '196.37.28.196' - No matching peer found
Soll heissen - es lief schon ein wenig an Vorbereitung von anderen IPs aus....

EDIT 2

Es kommt noch besser - der besagte Herr (s.o.) hat eine statische IP und versucht das ganze seit 3 Tagen, gescannt wird von einer anderen IP (bisher immer wechselnd), aber angemeldet immer von 89.32.214.236...

EDIT 3

Noch mehr gefunden - es ist oftmals angerufen worden - wen wunderts (es gab aber ein Call-Limit je Nebenstelle) - jedoch auch hier - immer die gleiche Rufnummer von der gleichen IP, also auffindbar. Zugehörigkeit Sambia, Afrika. Ermittlungswahrscheinlichkeit gegen 0 ;)

Und noch einer - dann ist die Liste aber leer, ein User des BWC Photo Imaging mit der IP 74.208.43.147 hat sich ebenfalls angemeldet bekommen, ebenfalls die gleiche Sicherheitslücke, Nutzer 32 Pwd 32 - ein interner Apparat ohne Rechte Ferngespräche zu führen.

Mensch Markus - da würde ich behaupten nochmal Glück gehabt zu haben, alle Gespräche summiert sind ~60 ¤ wert...das geht noch als Lerneffekt durch.

EDIT 4

So ziemliche alle Logfiles durchgesucht und es kommt noch mehr - der nette Herr mit der IP 89.32.214.236 - welche sich ja nicht verändert (oder aber eine TOR IP oder sowas ist) hat sich doch glatt noch bei "mopay" seine spielekarte aufgeladen, je anruf kann man 20¤ aufladen - er kam auf 11 Anrufe ... hat aber auch seine persönlichen Daten hinterlegen müssen ... mal schauen.

Ich denke so langsam wird es etwas für die Polizei - will mal hoffen das die statische IP auch einen echten Nutzer hat...
 
Zuletzt bearbeitet:
Hi!

Warum kommen für dich für lokale Geräte keine permit/deny Regeln in Frage? Gerade für die lokalen mit NULL security, worauf die Skriptkiddys ja speziell abzielen, hätte das alleine dein Problem schon vermieden. Wechselt ihr eure lokale IP-Konfig regelmäßig?

Dass er bei dir nur "no matching peer found" bekommt wundert mich, denn du hast ja "allwaysauthreject=yes" gesetzt; bei mir sah es (seit der Umstellung auf 'nicht 5060' keine Attacken mehr) meist so aus:
[Jul 14 17:34:58] NOTICE[502] chan_sip.c: Registration from '"3030495992"<sip:3030495992@my-IP>' failed for '173.224.216.197' - Not a local domain
[Jul 17 23:26:55] NOTICE[791] chan_sip.c: Registration from '"9117"<sip:9117@my-IP>' failed for '85.120.71.17' - Not a local domain
[Jul 18 06:17:22] NOTICE[791] chan_sip.c: Sending fake auth rejection for user "Unknown"<sip:54826ca313c4@my-IP;transport=UDP>;tag=7823f356
[Jul 18 06:17:25] NOTICE[791] chan_sip.c: Registration from '"Unknown"<sip:54826ca313c4@my-IP;transport=UDP>' failed for '92.83.236.3' - Not a local domain
[Jul 20 07:53:46] NOTICE[791] chan_sip.c: Sending fake auth rejection for user "Unknown"<sip:54826ca313c4@my-IP;transport=UDP>;tag=c00b4551
[Jul 20 07:53:50] NOTICE[791] chan_sip.c: Sending fake auth rejection for user "Unknown"<sip:54826ca313c4@my-IP;transport=UDP>;tag=c00b4551

offensichtlich sind da noch nicht alle "security features" aktiv (zu alter *?), bzw. zu viele sicherheitsrelevante Einstellungen auf default Werten...

VPN für VoIP ist für mich administrativer Overkill solange es genug offene VoIP-Systeme (* ist nicht alleine) auf 5060 für die "Bösen" zu finden gibt ...

schufti
 
Zuletzt bearbeitet:
Warum kommen für dich für lokale Geräte keine permit/deny Regeln in Frage? Gerade für die lokalen mit NULL security, worauf die Skriptkiddys ja speziell abzielen, hätte das alleine dein Problem schon vermieden. Wechselt ihr eure lokale IP-Konfig regelmäßig?

Ich habe es so verstanden das man permit/deny nur in den "general" Kontext setzen kann - wenn dem so ist, erzeuge ich mir ja autom. Probleme da sich noch einige HomeOffice Nebenstellen über dynamische IPs anmelden..

Hab ich da etwas missverstanden und man kann permit/deny für jede Nebenstelle setzen?

Dass er bei dir nur "no matching peer found" bekommt wundert mich, denn du hast ja "allwaysauthreject=yes" gesetzt; bei mir sah es (seit der Umstellung auf 'nicht 5060' keine Attacken mehr) meist so aus:

Asterisk ist 1.4 - der Eintrag war auch da - er sollte also eigentlich gezogen haben...hat er leider aber nicht. Versuch macht kluch - ich habe das ganze nochmals sauber nachbearbeitet - verändert im eigentlichen Sinne aber nichts (keine Schreibfehler in der Variablen..)

VPN für VoIP ist für mich administrativer Overkill solange es genug offene VoIP-Systeme (* ist nicht alleine) auf 5060 für die "Bösen" zu finden gibt ...

Ich habe fast alle Nebenstellen mit VPN, jedoch lasse ich VoIP nicht darüber laufen, das ganze machte bis dato ja auch keinen Sinn...

LG Stefan
 
Hi!

Also ich mache das immer so, dass ich in den config samples der Hersteller nachsehe ob es was und wo gibt,
in deinem Fall wäre das dzt. hier und ein Blick darauf sagt mir:

JA, permit/deny ist per Peer/User möglich


alwaysauthreject: ev. ist da ja nur das 1.4er log ungenau ...

ok, wenn es nur softphones sind und VPN schon läuft ....

ev. solltest du auch mal 'ne Domainliste definieren und allowexternaldomains=no verwenden...

schufti
 
Zuletzt bearbeitet:
Danke schufti,

ich nutze auch immer die SuFu - jedoch schaue ich gerade mehr oder weniger parallel 2 Logfiles durch :-/

permit/deny habe ich dann direkt mal nutzerbezogen eingesetzt - es läuft wundervoll - wie dieses Beispiel einer "extra falschen" Konfiguration schön zeigt :

Code:
    -- Unregistered SIP '44'
[Aug  9 14:00:54] WARNING[15610]: chan_sip.c:8412 parse_register_contact: Host 'IP.IP.IP.IP' disallowed by rule
[Aug  9 14:00:54] WARNING[15610]: chan_sip.c:9021 register_verify: Failed to parse contact info
Sehr schön.

Problem nochmals gebannt, neue - bessere Passwörter, Ip Rules, nicht (mehr) zu parsen (per falschem passwort authreject) - sieht schon besser aus.

EDIT - der gleiche Hacker (nach IP) versucht es nunmehr wieder, diesmal wieder von vorne, nach Kontakt suchen, brute-force und dann anmelden, aktuell läuft das Kontakt suchen (sieht aber auch anders aus)

Ich prüfe gerade ob es ggf. auch noch Zugriffe aufs System selber gab.

EDIT - keine Zugriffe aufs System.
Ich habe alle Daten die ich hier habe an die Landespolizei gegeben - bin mal gespannt ob es dort wirklich Interesse an solch einem Fall gibt. Der Hacker kommt lt. whois aus Rumänien, oder besser gesagt - da kommt seine IP her...


LG STefan
 
Zuletzt bearbeitet:
Hi!

Klingt ja schon wesentlich besser. In dem Fall, wenn du nicht auf ein alternativ Port umstellen willst, würde ich fail2ban wirklich überlegen (auch ohne email Meldung). Das sollte genügen, lästigen Scannern die IP zu vermiesen. Schließlich kann je nach Anbindung und Ausdauer so ein Angriff (habe schon mal Fälle über Stunden mit mehreren 100 / Minute gesehen) schon mal anderen Nutzern deiner Netzanbindung Probleme bereiten; und wenn's die Anbindung schafft, bringt es ev. den * außer Tritt .... abgesehen davon, dass das Log überläuft und ev. wichtige Logs untergehen.

bzgl. Polizei mach dir da mal nicht zuviel Hoffnung .... selbst wenn unsere aktiv würde, in Rumänien gibt's Gegenden, da fährt nichtmal deren Polizei ohne milit. Geleitschutz hin ....

schufti
 
@Polizei

Ich sehe das nicht viel anders - bin allerdings bzgl. der EU "Großschnauzerei" wiederum bzgl. Internetpiraterie (Hacker) im Geschäftsleben gespannt.
Als Privatmann würde ich es erst gar nicht versuchen, da es hier aber um Gewerbe und auch Gewerbeanbindungen geht - mal sehen. Die EU hatte vor ca. 2 Jahren da sehr viel versprochen - Rumänien ist EU...

@Fail2Ban

Liest sich nützlich und hätte in meinem Fall auch sicherlich geholfen...mache ich gleich nach meiner eigentlichen AUfgabe - ein schlichtes distri-upgrade :) Das war bevor ich wirre Meldungen über ein "peer not found" bekam

Danke :groesste:
 
Hacker kommt lt. whois aus Rumänien, oder besser gesagt - da kommt seine IP her

Verstehe nicht warum bannt ihr nicht die IP/8 via IPtables aus Rumaenien? Oder hast/moechtest du in Zukunft Kunden aus Rumaenien?
Was spricht dagegen?

Ich habe die ganzen Laender wie, China, Rumaenien, Bulgarien, Indien, Japan alle gebannt. Fail2ban sendet mir ne mail, dann ueberpruefe ich die IP und je nach dem fuege ich die IP hinzu.

Nachtrag: Wir koennten einen Beitrag aufmachen und jeder fuegt die IP Adresse des Hackers hinzu mit Landesangabe.

Gruesse
Mario
 
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.