SIP-Attacken: Angriffe kommen aus der Amazon-Cloud

[Redaktion]

Amazon Elastic Cloud ist Ursprung von massiven DDOS Attacken

In den letzten Tagen sind vermehrt Klagen über Brute Force Attacken auf SIP-Systeme bekannt geworden. Die verwendeten IP-Adressen sind eindeutig dem Amazon Hosting System EC2 Bereich zuzuordnen.

Die Berichte wurden unter anderen von tecchannel.de aufgenommen. Deren Artikel beruft sich auf die Blogs VoIP Tech Chat und Building The Net. Die Reaktionen des Hosters sind leider so gut wie gar nicht vorhanden. Ausser allgemeinen Standardmails werden weitere Auskünfte lapidar verweigert. Das wird nicht nur aus den Blogs sondern auch aus Tweets bei Twitter deutlich. Immerhin gibt es inzwischen einen Eintrag im RSS-Feed des AWS Security Bulletins.

Tecchannel zitiert Links zu Seiten, die aufzeigen wie man sich vor Angriffen schützen kann.

Quellen:
tecchannel.de
VoIP Tech Chat
Building The Net

 

[woprr]

Stimmt hier nicht, nur 1 von 10 Angriffen kam hier von Amazon an und deren Abuse-NOC antwortet zwar mit Formmails aber wenigstens überhaupt und das Webformular zum Melden stellt die Korrekte Form des nützlichen Reports auch für Amateure sicher, auf meine anderen 9 Test-Abusereports kam keine Antwort, liegt wohl an meinem Freemailer als Absender.

Deren Artikel

Hmm, einige Tips von digium schränken die Funktionalität für viele Anwendungen sicher zu sehr ein:
http://blogs.digium.com/2009/03/28/sip-security/

1) Don’t accept SIP authentication requests from all IP addresses.

"Mein code ist gut nur das Netz ist böse"

5) Allow only one or two calls at a time per SIP entity, where possible.

Das dürfte selbst Heimanwendern zuwenig sein und für Firmenanlagen kaum "possible".

http://www.teamforrest.com/blog/171/asterisk-no-matching-peer-found-block/

With this script we are blocking any host after the 4th failed attempt.

...4E4. Wenn da ein Kunde in seinen * aus versehen falsche Daten einträgt isser für immer raus und wird sich freuen, * macht REGISTER-Neuversuche mit so kurzen Pausen dass man das auch schon als Brute-Force-Cracking ansehen könnte, der Begriff ist schwer abzugrenzen.

Und dafür bräuchte man bei grösseren Anwendungen schon eine richtige Datenbank ansonsten läuft iptables da ggfs. über, chains dürfen sicher nicht unendlich lang werden:

$action = `iptables -I asterisk -s $ip -j DROP`;

Man sollte den Hahn daher in diesem Fall nur soweit zudrehen wie nötig, 1+ Minute Blockierzeit nach 20 hits reicht völlig um einen Brute-Force-Angriff wegen megastark verlängerter Durchführungsdauer gefährlich (Erreicht die Reaktionszeit des NOC des Providers auf Meldungen) oder in der Regel unmöglich zu machen und das System verfügbar zu halten und deswegen bleib ich vorerst bei meiner Lösung:
http://www.ip-phone-forum.de/showthread.php?t=213193

@Redaktion
Deine Unterüberschrift

Amazon Elastic Cloud ist Ursprung von massiven DDOS Attacken

stimmt hier nicht, die bezieht sich auf eine andere Pressemeldung die nichts mit SIP-Brute-Force Attacken zu tun hat, es sei denn der Host wird durch den Scanner überlastet und kann die legitimen Anfragen dann nicht mehr oder nur noch zu spät bedienen und eine Brute-Force-Attacke auf den jeweiligen Host dürfte "distributed" nur schwer zu koordinieren sein.

 

[rollo]

Hier noch ein Kommentar zum Thema aus dem Blog [URL="http://www.mgraves.org/voip/2010/04/amazon-responds-about-sip-attacks-from-ec2/"]Graves On SOHO VoIP[/URL]

 

[Hero2138]

Nur mal als Frage, kamen die Angreifer aus der Cloud mit einer IP und massiv Rechnen Power ähnlich einer DoS Attacke oder kommen die mit vielen verteilten IPs ähnlich einer DDoS Attacke ?

Gruß
Hero

 

[woprr]

Hier von einer und die cracker sind weiter in der Amazon cloud aktiv:

May  1 23:54:18 NOTICE[3051584400] chan_sip.c: Registration from '"2302891885"<sip:2302891885@xxxxxxx>' failed for '184.73.102.246' - Username/auth name mismatch
May  1 23:54:18 NOTICE[3051584400] chan_sip.c: Registration from '"1854148134"<sip:1854148134@xxxxxxx>' failed for '184.73.102.246' - Username/auth name mismatch
May  1 23:54:18 NOTICE[3051584400] chan_sip.c: Registration from '"1000"<sip:1000@xxxxxxxx>' failed for '184.73.102.246' - Username/auth name mismatch
May  1 23:54:18 NOTICE[3051584400] chan_sip.c: Registration from '"1"<sip:1@xxxxxxxxx>' failed for '184.73.102.246' - Username/auth name mismatch
May  1 23:54:18 NOTICE[3051584400] chan_sip.c: Registration from '"2"<sip:2@xxxxxxxxx>' failed for '184.73.102.246' - Username/auth name mismatch
May  1 23:54:18 NOTICE[3051584400] chan_sip.c: Registration from '"1100"<sip:1100@xxxxxxxxx>' failed for '184.73.102.246' - Username/auth name mismatch

Firewall hält (noch).

 

[simfes]

Ich denke, bei mir wird es auch Zeit, ein wenig was zu tun. Wir haben eben mal knapp 36 Stunden des neuen Monats rum, die Werte sind auf den 01.05.2010 gemünzt und dafür ist es schon ordentlich:

Start Date / Time: 	  Sat May 1 00:00:00 2010
Outgoing Traffic Volume: 	  21 (MB)
Incoming Traffic Volume: 	1641 (MB)
Total Traffic Volume: 	        1662 (MB)
Average per day: 	        1662

FW hält auch hier. Was mir eher Sorgen macht, ist die Menge des Gesamttraffics. Irgendwann macht auch der kulanteste Provider mal dicht; immerhin ist das nur ein LAN-Port mit einer Maschine.

Die meisten "Angriffe" (über 98%) kamen in der Zeit zwischen 20100501-01:13:35 und 20100501-07:58:35. Und wie inzwischen wohl üblich aus dem bereich AMAZON-EC2-7.
Das wieder sieht für mich so aus, als wäre ein automatisches Zeitfenster gewählt worden, denn danach waren es nur noch die übliche Menge und verteilte sich auf die üblichen Verdächtigen (Schurkenstaaten halt )


-------
Tante Edith meldet sich am 06. Mai 19:18 Uhr mit einem kleinen Update:

Start Date / Time: 	Sat May 1 00:00:00 2010
Outgoing Traffic Volume: 	 167 (MB)
Incoming Traffic Volume: 	6142 (MB)
Total Traffic Volume: 	        6309 (MB)
Average per day: 	        1261

Ich bin inzwischen von der Qualität der FW und den Passwörtern überzeugt und lasse es beinahe bewusst geschehen. Ein Dank auch nach München zum Konrad-Zuse-Platz.

 

[Hero2138]

Ok sieht so aus als ob da Idioten am Werk sind.

Sowie ich es aus deinem Eintrag gesehen habe, kommt so ein Angriff immer von einer IP auf "wahlfreie" Accounts.

Was schickt Ihr dem Angreifer den als Antwort zurück wenn es den Account gar nicht gibt?
(SIP - 604 "Does not exist anywhere") ?

Denn das wäre ja ein evtl. Anhaltspunkt für den Angreifer es weiter zu versuchen nur mit anderen Passwortkombinationen. Oder auf einen anderen Account auszuweichen.


Ich denke das Zeitfenster ist so gewählt da Nachts häufig keiner auf die Maschinen schau und evtl. ist die Rechenzeit der Cloud Nachts günstiger ?

Gruß
Hero