Hacker in meinem Asterisk Server

[woprr]

http://www.asteriskdocs.org/html/apas02.html

Das ist das O'Reilly Buch http://www.asteriskdocs.org/

 

[erdnuss0815]

Was machtn Ihr da eigentlich?
alwaysauthreject=yes in die sip.conf und gut is, dann können keine accounts mehr gefunden werden für den password-bruteforce.

Hatte das nach deinem Beitrag eingetragen.
Und: Hat gestern Mittag super geklappt!
Der Angreifer konnte nur seine erste Nummer versuchen.
Danach war Ruhe.

Danke für den Tip.

 

[MET]

Wie gesagt, bei mir wurde noch kein asterisk angegriffen, aber ich bin recht zuversichtlich, dass fail2ban derlei angriffe mit diesen regeln genauso zuverlaesig abblocken wuerde wie es das bei SSH angriffen tut. Bei mir laeuft es mittels denyhosts, mit iptables waere es vermutlich sogar noch besser (schneller).

fail2ban rulez!!!
Chris

Fail2Ban läuft jetzt bei mir seit ich auf Debian lenny stable gewechselt habe. Für manuelle Tests hatte ich in der jail.conf folgende Einträge:

maxretry = 3
findtime = 300
bantime = 600

Mit dieser Konfiguration (5 Min warten nach >=3 Versuchen 10 Min blockieren) reagierte fail2ban letzthin folgendermassen auf eine Hackattacke:

Asterisk:

[2010-05-22 16:04:05] NOTICE[29225] chan_sip.c: Registration from '"1249349713"<sip:[email protected]>' failed for '76.76.96.74' - No matching peer found
[2010-05-22 16:04:05] NOTICE[29225] chan_sip.c: Registration from '"100"<sip:[email protected]>' failed for '76.76.96.74' - No matching peer found
[2010-05-22 16:04:05] NOTICE[29225] chan_sip.c: Registration from '"101"<sip:[email protected]>' failed for '76.76.96.74' - No matching peer found
[2010-05-22 16:04:05] NOTICE[29225] chan_sip.c: Registration from '"102"<sip:[email protected]>' failed for '76.76.96.74' - No matching peer found
[2010-05-22 16:04:05] NOTICE[29225] chan_sip.c: Registration from '"103"<sip:[email protected]>' failed for '76.76.96.74' - No matching peer found
[2010-05-22 16:04:05] NOTICE[29225] chan_sip.c: Registration from '"104"<sip:[email protected]>' failed for '76.76.96.74' - No matching peer found
....
[2010-05-22 16:12:58] NOTICE[29225] chan_sip.c: Registration from '"9994"<sip:[email protected]>' failed for '76.76.96.74' - No matching peer found
[2010-05-22 16:12:58] NOTICE[29225] chan_sip.c: Registration from '"9995"<sip:[email protected]>' failed for '76.76.96.74' - No matching peer found
[2010-05-22 16:12:58] NOTICE[29225] chan_sip.c: Registration from '"9996"<sip:[email protected]>' failed for '76.76.96.74' - No matching peer found
[2010-05-22 16:12:58] NOTICE[29225] chan_sip.c: Registration from '"9997"<sip:[email protected]>' failed for '76.76.96.74' - No matching peer found
[2010-05-22 16:12:58] NOTICE[29225] chan_sip.c: Registration from '"9998"<sip:[email protected]>' failed for '76.76.96.74' - No matching peer found
[2010-05-22 16:12:58] NOTICE[29225] chan_sip.c: Registration from '"9999"<sip:[email protected]>' failed for '76.76.96.74' - No matching peer found

Fail2Ban:

2010-05-22 16:04:06,632 fail2ban.actions: WARNING [asterisk-iptables] Ban 76.76.96.74
2010-05-22 16:04:09,130 fail2ban.actions.action: ERROR  printf %b "Hi,\n
The IP 76.76.96.74 has just been banned by Fail2Ban after
11 attempts against ASTERISK.\n\n
Here are more information about 76.76.96.74:\n
`whois 76.76.96.74`\n
Regards,\n
Fail2Ban"|mail -s "[Fail2Ban] ASTERISK: banned 76.76.96.74" [email protected] returned 7f00
2010-05-22 16:04:09,130 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
2010-05-22 16:04:10,133 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
2010-05-22 16:04:11,132 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
2010-05-22 16:04:12,132 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
2010-05-22 16:04:13,132 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
2010-05-22 16:04:14,132 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
2010-05-22 16:04:15,133 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
2010-05-22 16:04:16,133 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
2010-05-22 16:04:17,133 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
...
2010-05-22 16:12:55,309 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
2010-05-22 16:12:56,311 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
2010-05-22 16:12:57,318 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
2010-05-22 16:12:58,321 fail2ban.actions: WARNING [asterisk-iptables] 76.76.96.74 already banned
2010-05-22 16:14:07,356 fail2ban.actions: WARNING [asterisk-iptables] Unban 76.76.96.74

Die Attacke produziert etwa 40 Versuche pro Sekunde. Fail2Ban reagiert etwa jede Sekunde mit einer Meldung "already banned" ohne aber die IP zu blockieren.

Fail2Ban hat die zu blockierende IP in dem File /etc/hosts.deny eingetragen.

Hat jemand von Euch eine Idee weshalb dann die IP trotzdem nicht blockiert wurde?

Die Mailnachricht funktioniert auch noch nicht. Bin dankbar für einen Tipp an was auch dies liegen könnte.

 

[MET]

Während den letzten 10 Tagen versuchte ich fail2ban für Hackattacken zu konfigurieren. Zuerst mit hostdeny (ohne iptables). Die zufälligerweise eingetroffene Attacke hat gezeigt, dass fail2ban so nicht funktioniert. Auf der Suche nach dem möglichen Grund wurde ich schliesslich hier fündig. Fazit: Mit hostdeny scheint Fail2Ban offensichtlich zu "träge" zu sein, um solche Attacken blockieren zu können. Es wurde empfohlen anstatt hostdeny iptables zu verwenden, da dies wesentlich rascher reagieren sollte. Mit iptables besteht jedoch das Problem, dass man root-Zugriff auf den Server haben muss, was leider die meisten vServer-Hoster nicht gewähren (wollen), meiner auch nicht. In dieser Liste erwähnen gerade einmal 2 Hoster, dass sie iptables auf dem vServer unterstützen. Die Preise sind denn auch ganz happig, fast 20x mehr als was ich jetzt bezahle ...

 

[PsychoMantis]

Ich habe das Problem ganz einfach gelöst: Ich habe einfach alles so gelassen wie es ist. Ins Ausland können die Gespräche eh nur landen nur von bestimmten (angemeldeten) Telefonen und nur wenn bestimmte CallerID übertragen wird und nur bis zu einem bestimmten Limit.
Sollte also tatsächlich einer mein Passwort erraten / brutforcen, wäre der jenige nicht in der Lage für paar Hundert Euro ins Ausland zu telefonieren. Da bräuchte der jenige schon das root-Passwort meines V-servers und dieses ist noch sicherer gestaltet.

Ein paar Infos: klick.

 

[thorolf]

Was machtn Ihr da eigentlich?
alwaysauthreject=yes in die sip.conf und gut is, dann können keine accounts mehr gefunden werden für den password-bruteforce.

wir haben jetzt auch einen Fall, bis heute Morgen viele TEUR :-(

Die User-ID bei uns ist immer lang (0123-4567890), ein Durchprobieren von 100 - 9999 hilft also nicht, außerdem verwenden wir als Passwort mind. eine 8-stellige, zufällige Abfolge von Zahlen, Gross- und Kleinbuchstaben, das Passwort wird vom Telefon als MD5 übertragen. Daher kann ich mir kaum vorstellen, dass das Passwort gesnifft oder erraten wurde. Einen [Default]-Kontext gibt es nicht.

Auch gab es keine hohe Anzahl von "No matching peer found" und nur eine handvoll "Wrong password" was auf einen Bruteforce-Angriff hindeuten würde (beides gibt es erst seit heute morgen nachdem wir den Asterisk neu gestartet haben).

Da jedoch das Web-Interface des SIP-Telefons per Internet erreichbar war, vermuten wir das der Angreifer darüber die Account-Daten erlangt hat.

Zuerst wurde ein neues Passwort gesetzt und per Telefon weitergegeben, nach einigen Stunden wurde jedoch wieder über den Account telefoniert.

Später haben wir den SIP-Account dann ganz gelöscht und danach ein "sip prune realtime peer" gemacht.

Das hat den Angreifer jedoch nicht im mindesten gestört, er konnte mit der Nebenstelle weiterhin telefonieren, tauchte aber nicht mehr im CLI oder messages auf, jedoch im Master.csv wie wir heute feststellen mußten.

Wie kann das denn sein???

Erst ein Neustart des Servers schloss den Angreifer aus. Der hat es dann noch mehrfach auf Nachbar-Nummern versucht, bislang ohne Erfolg.

Nun stellt sich die Frage was man grundsätzlich gegen solche Angriffe machen kann, als ersten Schritt werde ich nun erstmal ein kleines Script machen, welches regelmäßig die Master.csv nach "verdächtigen" Auslands-Vorwahlen scanned und bei Auffälligkeiten eine Meldung absetzt.

Aber das ist nur ein Würgaround denn auch da kann immer eine Nummer "durchrutschen", ein Einschränken von IP-Adressen ist hier kaum machbar, eine Beschränkung des Useragents i.d.R. auch nicht, was kann man also noch sinnvolles machen?

Vielen Dank,

Tschüß Thorolf

 

[MET]

Könnte es sein, dass hier jemand ein Insiderwissen ausgenutzt hat?

 

[rmh]

Nun stellt sich die Frage was man grundsätzlich gegen solche Angriffe machen kann, als ersten Schritt werde ich nun erstmal ein kleines Script machen, welches regelmäßig die Master.csv nach "verdächtigen" Auslands-Vorwahlen scanned und bei Auffälligkeiten eine Meldung absetzt.

Aber das ist nur ein Würgaround denn auch da kann immer eine Nummer "durchrutschen", ein Einschränken von IP-Adressen ist hier kaum machbar, eine Beschränkung des Useragents i.d.R. auch nicht, was kann man also noch sinnvolles machen?

Servus,

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.
Welche Asterisk-Version kommt zum Einsatz?

 

[thorolf]

Hallo,

Könnte es sein, dass hier jemand ein Insiderwissen ausgenutzt hat?

ich glaube nicht, denn "Insider" hätten es sich leichter machen können.

Außerdem scheint es so, das die Kriminellen die Account-Daten von dem Telefon haben, welches ungeschützt mit einer festen IP im Internet hing und wo das Web-Interface zum Hacken einlud.

Aber das haben wir nicht zu verantworten und somit ist es im Grunde nicht unser Problem, mich ärgert allerdings maßlos das man anscheinend nichts dagegen machen kann, das die Kriminellen an ihr Geld kommen :-(

Tschüß,

Thorolf

 

[thorolf]

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.

das würde beides erhebliche Einschränkungen und Mehraufwand mitbringen und wird somit nicht realisierbar sein. Wir schränken über Firewalls schon fast alle Zugriffe auf unser Netz ein, aber VoIP geht grundsätzlich von überall!

Welche Asterisk-Version kommt zum Einsatz?

1.4.20 mit einer Reihe von zurückportierten Patches.

Auch wenn ich vermute das wir nicht jede erdenkliche Sicherheitslücke geschlossen haben, gehe ich doch sicher davon aus, das die Angreifer nicht unseren Server gehackt haben!

Wenn sich jemand seine Kontokarte nebst PIN klauen läßt, ist die Bank auch machtlos wenn das Konto abgeräumt wird und beim Asterisk mit dem CDR-CSV ist es ja leider so, das ich keinen Mechanismuss kenne, mit dem man die Gebühren in Echtzeit überwachen und frühzeitig Alarm schlagen kann.


Tschüß,

Thorolf

 

[woprr]

Da jedoch das Web-Interface des SIP-Telefons per Internet erreichbar war, vermuten wir das der Angreifer darüber die Account-Daten erlangt hat.

Auweia, interne Telefone und das LAN müssen immer hinter einer guten Firewall sein da darf nichts ungefragt ins LAN kommen und kein Gerät darf vom WAN aus erreichbar sein ausser über VPN.

Solche web-interfaces haben gerne mal Sicherheitslücken und werden generell nicht sehr sicher designed weil davon ausgegangen wird das sie im LAN sind.
Unbedingt dem Hersteller melden.

Wenn das Telefon im WAN sein muss, dann web-interfaces etc abstellen und alle eingehenden ports ausser den SIP-Port und ggfs. feste RTP ports sperren.

 

[rmh]

das würde beides erhebliche Einschränkungen und Mehraufwand mitbringen und wird somit nicht realisierbar sein. Wir schränken über Firewalls schon fast alle Zugriffe auf unser Netz ein, aber VoIP geht grundsätzlich von überall!

Ich sage es mal so, bevor ich mehre tausend Euro Schaden in Kauf nehme, setzte ich mich lieber auf meinen Hintern und überlege mir eine innovative Lösung. VPN ist (imho) dauerhaft der einzig sinnvolle Weg, um IP-Telefone extern einzubinden.

 

[frindly]

Welche Einstellung ist denn nun wichtig,
das nur aus dem eigenen Netz nach aussen telefoniert werden kann.
Ich hab die Asterisk hinter einem KEN stehen, so das sie noch durch den Firewall geschützt ist. Bisher nutze ich nur ISDN. Nun möchte ich aber auch SIP nutzen, und dafür ein Loch in den Firewall bohren. Trotzdem sollen natürlich nur interne das Nutzen können.

 

[rentier-s]

IMHO eine sinnvolle Kombination aller betroffenen Parameter.

Mit bindaddr nur ans lokale Netzwerk binden, sofern sich niemand von extern registriert (hinter NAT mit Portforwarding natürlich nutzlos).
Deny/Permit möglichst restriktiv halten.
allowguest=no setzen, sofern nicht zwingend nötig.
Keine abgehenden (bzw. kostenpflichtigen) Verbindungen über den default-Context ermöglichen.
Bruteforce-Schutz.

Hab ich was vergessen?

Svenja

 

[frindly]

sind die parameter alle in der extesions.conf oder auch ini der asterisk.conf ?

 

[rentier-s]

Die ersten drei in der sip.conf bzw. deren Abkömmlingen, sip_users.conf oder was es da alles gibt. In dem anderen Thread hast Du gerade was von GUI geschrieben, da musst Du suchen, wo Du die einzelnen Parameter findest.

Context zum einen in der sip.conf, was da im general angegeben ist, und dementsprechend in der extensions.conf der Inhalt dieses Contextes.

Bruteforce Überwachung musst Du extern machen.

Steht aber eigentlich alles in der Dokumentation und wurde hier schon mehrfach behandelt.

Svenja

 

[arnysch]

Wie wird Brute-Force-gesucht? Mit INVITE-Paketen?

Frage an SIP-Protokollkenner: Mit welchen Paketen versuchen die Angreifer, reinzukommen. Sind das zwangsläufig INVITE-Pakete am SIP-Port?

Dann müsste sich eine Begrenzung der Verbindungsversuche bauen lassen rein im Kernel über Iptables/Netfilter, ohne einem Userspace-Programm. Und zwar mittels dem "String Match" und dem "Recent Match".

Also ungefähr mit diesen Iptables-Regeln:

iptables  -A chk_sip  -m string --string ! 'INVITE'  -j ACCEPT
iptables  -A chk_sip  -m recent  --set  --name SIP
iptables  -A chk_sip  -m recent  ! --update  --seconds 60  --hitcount 5  --rttl  --name SIP  -j ACCEPT
iptables  -A chk_sip  -j ULOG  --ulog-cprange 100  --ulog-prefix "Firewall4-ExcessSipInvite: "
iptables  -A chk_sip  -j DROP

 

[woprr]

Nich INVITE sondern REGISTER.

 

[tifa]

So mein server wurde auch gehackt

Was ish jetzt gemacht hab ist

- sip.config

allowguest=no
alwaysauthreject = yes

- fail2ban installiert und asterisk.config ist drin

- [default] ist jetzt komplet leer aussser im voicemail.config

- alle user die nach draussen Telefonieren können haben neue password

Ich hab 4 stellige SIP's soll ich die in 7 stellig umänder oder soll ich lassen ?

 

[IEEE]

Damit Dir jemand helfen kann, musst Du noch definieren was Du unter "gehackt" verstehst im konkreten Fall. Also was ist passiert? Gibts relevante Log Einträge?