Hackversuche kaputte Anfragen in anon Context und versuchte SIP Registrierungen

[AdServ7]

Hallo,

ich werde massiv mit "kaputten" Anfragen vollgemüllt.

Ich habe den Standard Port UDP/5060 schon auf einen anderen Port verlegt, das hat aber nichts geholfen.
Außer das das log file vollgemüllt wird ist das ja auch so erst mal nicht tragisch. Bloß wenn es mal eine Sicherheitslücke geben sollte haben wird den Ärger.
Auch wollte ich den IP Bereich per iptables nicht unbedingt groß einschränken.

Was gibt es sonst noch für Lösungen, log iptables log asterisk per script zyklisch auswerten und kaputte IPs über iptables sperren...


[Jan 31 00:44:39] NOTICE[31792]: chan_sip.c:15124 handle_request_invite: Call from '' to extension '8701041215083158' rejected because extension not found.
[Jan 31 00:44:59] WARNING[31792]: chan_sip.c:2014 retrans_pkt: Maximum retries exceeded on transmission d6d9135e31b51c1425885e0cda71c972 for seqno 1 (Critical Response) -- See doc/sip-retransmit.txt.
[Jan 31 00:45:01] NOTICE[31686]: chan_sip.c:28066 handle_request_register: Registration from '"1699" <sip:[email protected]:5060>' failed for '212.83.160.44:5073' - Wrong password

 

[koyaanisqatsi]

Moins


Asterisk absichern und gegebenenfalls selber auf Schwachstellen scannen.
Wahrscheinlich macht der Angreifer das mit demselben Tool welches du dafür verwenden solltest: sipvicious
Beispieldownload auf einen Linuxserver, der muss Python installiert haben...

root@osmc:~# wget https://github.com/sandrogauci/sipvicious/archive/master.zip
converted 'https://github.com/sandrogauci/sipvicious/archive/master.zip' (ANSI_X3.4-1968) -> 'https://github.com/sandrogauci/sipvicious/archive/master.zip' (UTF-8)
--2016-01-31 13:00:43--  https://github.com/sandrogauci/sipvicious/archive/master.zip
Resolving github.com (github.com)... 192.30.252.129
Connecting to github.com (github.com)|192.30.252.129|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/sandrogauci/sipvicious/zip/master [following]
converted 'https://codeload.github.com/sandrogauci/sipvicious/zip/master' (ANSI_X3.4-1968) -> 'https://codeload.github.com/sandrogauci/sipvicious/zip/master' (UTF-8)
--2016-01-31 13:00:44--  https://codeload.github.com/sandrogauci/sipvicious/zip/master
Resolving codeload.github.com (codeload.github.com)... 192.30.252.160
Connecting to codeload.github.com (codeload.github.com)|192.30.252.160|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
Saving to: 'master.zip'

master.zip                                      [  <=>                                                                                       ]  53.75K   224KB/s   in 0.2s

2016-01-31 13:00:45 (224 KB/s) - 'master.zip' saved [55043]

Entpacken geht dann so: unzip master.zip
Dann ins Verzeichnis wechseln: cd sipvicious-master
Jetzt steht einem Scan (Achtung: Python muss installiert sein) nichts mehr im Wege...
Scan im LAN

./svmap.py 192.168.178.0/24
WARNING:DrinkOrSip:could not bind to 0.0.0.0:5060 - some process might already be listening on this port. Listening on port 5061 instead
| SIP Device         | User Agent                                         | Fingerprint |
-----------------------------------------------------------------------------------------
| 192.168.178.3:5060 | AVM FRITZ!Box Fon WLAN 7113 60.04.68 (Jul 28 2009) | disabled    |
| 192.168.178.9:5060 | PiBX                                               | disabled    |
| 192.168.178.4:5060 | AVM FRITZ!Box Fon WLAN 7113 60.04.68 (Jul 28 2009) | disabled    |
| 192.168.178.6:5060 | snom320/8.7.5.35                                   | disabled    |
| 192.168.178.7:5060 | snom320/8.7.5.35                                   | disabled    |
| 192.168.178.2:5060 | AVM FRITZ!Box Fon WLAN 7112 87.04.88 (Feb  9 2014) | disabled    |
| 192.168.178.1:5060 | FRITZ!OS                                           | disabled    |

Ganz schön auskunftsfreudig, bis auf das Gerät 192.168.178.1, das schmettert solche Scans zwar nicht ab, aber gibt auch keine Infos raus.
Mal sehen was es geantwortet hat...

2016-01-31 13:47:34.706 - OUT: my=192.168.178.1%10:5060 peer=192.168.178.9 port=5061 UDP, sipiface=none tcclass=sip, netmark=0:
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 127.0.0.1:5061;branch=z9hG4bK-3150674367;rport=5061;received=192.168.178.9
From: "sipvicious" <sip:[email protected]>;tag=6330613862323031313363340131393033363831383935
To: "sipvicious" <sip:[email protected]>;tag=AD82694BE33EF538
Call-ID: 553577273365103845897718
CSeq: 1 OPTIONS
User-Agent: FRITZ!OS
Content-Length: 0

Zum Glück lass ich meinen Asterisk nicht direkt mit dem Internet kommunizieren.
Scan von/aus Internetseite

root@osmc:~/sipvicious-master# ./svmap.py XXXXXXXXX.spdns.org
WARNING:DrinkOrSip:could not bind to 0.0.0.0:5060 - some process might already be listening on this port. Listening on port 5061 instead
| SIP Device         | User Agent | Fingerprint |
-------------------------------------------------
| 93.220.XXX.XXX:5060 | FRITZ!OS   | disabled    |

Dafür benutze ich die 192.168.178.1 als Gateway zum rein/raus Telefonieren.
...ist aber mal wieder nur ein Schuss ins Grüne.

Weitere Sicherheitstips von Profis sind hier natürlich Willkommen.

Ziel sollte in jedem Fall sein, dass Asterisk auf Anfragen restriktiver, also nicht geschwätzig, oder garnicht, antwortet.

 

[rentier-s]

Ich habe den Standard Port UDP/5060 schon auf einen anderen Port verlegt

Sicher? Das schaut nämlich nicht so aus. bindport nicht mit port verwechseln. Ich verwende einen anderen bindport, auch nicht 5061 ;-) und seitdem ist komplett Ruhe.

Die fehlgeschlagenen Registrierungsversuche lassen sich im Vorfeld ansonsten kaum verhindern, wichtig sind entsprechend sichere (=lange und komplexe) Kennwörter. fail2ban hilft zumindest ein wenig bzw. schränkt bruteforce Angriffe ein.

Wie Du selbst sagst, die 404er Fälle sind nicht weiter dramatisch, so lange der default Context leer ist. Verhindern kann man die einfach durch allowguest=no im sip.conf [general], sofern Du keinen SIP Provider mit Load Balancern verwendest.

http://www.ip-phone-forum.de/showthread.php?t=212106

 

[abw1oim]

Unbeachtlich der schon gegebenen Hinweise lohnt es auch immer, die Firewall entsprechend zu konfigurieren.
Gute Ratschläge gibt es u.a. hier:

http://blog.ls20.com/securing-your-asterisk-voip-server-with-iptables/

 

[AdServ7]

Hi,
der log Auszug ist wieder von UDP5060, ich habe auch nicht den Asterisk port (#netstat -tulpen | grep asterisk) geändert sondern mit iptables nur den Zugriff von außen "verlegt".
Aber ich glaube ich bin auf irgendeiner Liste mit meinen IPs und werde seitdem nicht mehr in Ruhe gelassen, egal wo ich meinen Port hin mache. Und es ist ja nicht ein Rechner sondern ein generelles Problem.
Einmal eben auf den anon Context und dann versuchte Registrierungen, klar habe ich komplizierte Passwörter und auch keine einfachen numerischen UserIDs, aber den anon Zugang brauche ich auch für manche Sachen.

Ich werde wohl die IP Bereiche einschränken und eine GUI einrichten mit der diese einfach gepflegt werden können, oder man kann durch eine Email einen Zugang anfordern, bekommt eine Webseite die man besuchen muss und dann wird dieser Adressbereich ein wenig größer genommen und freigeschaltet.
Und die log files werden ausgewertet und eine Email als warning versendet wenn da zu viel Müll drinsteht.
Irgend so was in der Art.

Der Artikel ist ganz interessant
http://blog.ls20.com/securing-your-asterisk-voip-server-with-iptables/

Insbesondere string zu benutzen um bei den Müll Registrierungen schon bei #iptables was zu machen