- Beitrag abonnieren
- Beitrag stummschalten
- Beitrag als ungelesen kennzeichnen
- Beitrag als gelesen kennzeichnen
Digitalisierungs Box Premium offener SIP Port
20.11.2017 12:53
Zur Zeit konfiguriere ich die Digitalisierungs Box Premium im Modus Telefonanlage. Es funktioniert soweit auch alles.
Jedoch habe ich mittels eines Portscans (nmap -v xx.xxx.xx.xxx -p 5060,5061) von ausserhalb entdeckt das die Ports 5060 und 5061 nach außen offen/erreichbar sind.
Meine Fragen:
- Sind die Ports standardmäßig aus dem Internet erreichbar?
- Durch welche Konfiguration könnte ich das aus Versehen freigeschaltet haben, wie mache ich es wieder rückgängig?
- Selbst durch einen Eintrag in der Firewall
Quelle: ANY Ziel: ANY Dienst: sip Aktion: Verweigern
war der Port 5060 nach außen noch offen. Der Dienst: sip ist als TCP/UDP Port 5060 definiert.
Wie kann das sein?
Dankeschön
Gelöst! Gehe zu Lösung.
20.11.2017 13:58 Zuletzt bearbeitet: 20.11.2017 14:00 durch den Autor
Ich habe hier schonmal versucht, die be.ip / Digitalisierungsbox auf Port 5060/61 abzudichten.
Grund waren zeitweilig massive Versuche von extern, Schwachstellen des SIP-Servers zu finden. Im Gedenken an die Probleme, die es vor einiger Zeit mit Fritzboxen gab war ich bemüht, eine Lösung zu finden.
Ich habe derzeit die entsprechenden Regelketten am laufen - die werden nicht über die Firewall eingepflegt sondern über die Zugriffskontrolle. Problem dabei ist: Man muss die Herkunfts-IP's / Netze berechtigter Anfragen kennen. Da ist Telekom aber wenig kooperativ, wie diverse Anfragen von Asterisk-Jüngern zeigen.
Wenn nur Telekom als SIP-Provider aktiv sind die Regeln noch überschaubar:
Kommen weitere SIP-Provider dazu wird es lustig. Bei mir sind es in der Summe 19 Regeln für 3 Provider. Ändern die Provider ihre Ip-Zuordnungen hat man erstmal den Zonk, weil dann nix mehr geht. Gemäß Murphy denkt man als letztes erst an die Verbarrikadierung. Zusätzliche Hürde bei bintec: Die Reihenfolge der Regeln in der GUI entspricht nicht in jedem Fall der Abarbeitungsreihenfolge.
Also viel Fehlerpotential für so eine Konfig.
Schlussendlich habe ich aber so das Anklopfen aus China, Russland, Kanada, USA und weiß der liebe Gott woher wirkungsvoll unterbunden. Im Heise-Netzwerkscan werden die SIP-Ports bei mir als geschlossen/gefiltert angezeigt.
Hallo @Daniel21,
ohne offene Ports würden keine eingehenden Anrufe funktionieren. Sie brauchen sich aber keine Sorgen zu machen, denn die Digitalisierungsbox lässt keine Endgeräte-Registrierungen aus dem Internet zu.
Hallo @Daniel21,
ohne offene Ports würden keine eingehenden Anrufe funktionieren. Sie brauchen sich aber keine Sorgen zu machen, denn die Digitalisierungsbox lässt keine Endgeräte-Registrierungen aus dem Internet zu.
20.11.2017 13:58 Zuletzt bearbeitet: 20.11.2017 14:00 durch den Autor
Ich habe hier schonmal versucht, die be.ip / Digitalisierungsbox auf Port 5060/61 abzudichten.
Grund waren zeitweilig massive Versuche von extern, Schwachstellen des SIP-Servers zu finden. Im Gedenken an die Probleme, die es vor einiger Zeit mit Fritzboxen gab war ich bemüht, eine Lösung zu finden.
Ich habe derzeit die entsprechenden Regelketten am laufen - die werden nicht über die Firewall eingepflegt sondern über die Zugriffskontrolle. Problem dabei ist: Man muss die Herkunfts-IP's / Netze berechtigter Anfragen kennen. Da ist Telekom aber wenig kooperativ, wie diverse Anfragen von Asterisk-Jüngern zeigen.
Wenn nur Telekom als SIP-Provider aktiv sind die Regeln noch überschaubar:
Kommen weitere SIP-Provider dazu wird es lustig. Bei mir sind es in der Summe 19 Regeln für 3 Provider. Ändern die Provider ihre Ip-Zuordnungen hat man erstmal den Zonk, weil dann nix mehr geht. Gemäß Murphy denkt man als letztes erst an die Verbarrikadierung. Zusätzliche Hürde bei bintec: Die Reihenfolge der Regeln in der GUI entspricht nicht in jedem Fall der Abarbeitungsreihenfolge.
Also viel Fehlerpotential für so eine Konfig.
Schlussendlich habe ich aber so das Anklopfen aus China, Russland, Kanada, USA und weiß der liebe Gott woher wirkungsvoll unterbunden. Im Heise-Netzwerkscan werden die SIP-Ports bei mir als geschlossen/gefiltert angezeigt.
21.11.2017 15:39
Anmerkung: Der Aufwand ist unnötig, denn:
1.) Die DigiBox ist keine FB, sondern ein Gerät aus der Profi-Liga mit hohen Sicherheitsanforderungen als Grundeinstellung.
2.) Wie man im Logbuch der DigiBox sehen kann, werden unzulässige Verbindungen zuverlässig abgewiesen. Durch die Regelketteneinträge wird dann die Ablehnung nur verlagert.
21.11.2017 15:51
Mir ist der Aufwand auch zu hoch und ich vertraue der DigiBox einfach mal.
Aber es ist gut zu wissen das man etwas machen könnte, wenn man will.
Vielen Dank für die Hilfe
21.11.2017 16:16
@Kalle2014 schrieb:2.) Wie man im Logbuch der DigiBox sehen kann, werden unzulässige Verbindungen zuverlässig abgewiesen. Durch die Regelketteneinträge wird dann die Ablehnung nur verlagert.
Ich bewundere Dein Vertrauen. Protokoll-Implementationsfehler haben sich aber schon ganz andere geleistet.
Die Angriffsvektoren auf SIP sind vielfältig und ein wenig mehr Sicherheit kann nicht schaden. Wenn SIP-Anfragen nur noch aus einem kleinen Teil des Internets überhaupt bis zum SIP-Server vordringen halte ich das für sinnvoll.
Ich schließe einfach nur die Tür bis auf einen kleinen Spalt.
Natürlich wäre es einfacher, wenn die Registrare eine Liste zulässiger Serveradressen pflegen würden. Aber so geht es auch.
Leider hab ich kein Log-Beispiel mehr, aber die Angriffe zielten auf jeden Aspekt des SIP-Protokolls. Flooding hab ich nicht beobachtet, von daher weiß ich nicht, wie die Box damit umgehen kann.
Seit dieser Maßnahme ist mein Log jedenfalls frei von jeglichen suspekten Anfragen auf 5060/61.
02.01.2018 20:11
@Gelöschter Nutzer
Hallo,
irgendwie bekomme ich das ganze nicht zum Laufen, leider sperre ich alle Voip-Konten aus...:-(
Ich will nur von einem bestimmten Softswitch auf Port 5061 Sips_TCP zulassen, alles andere soll noch funktioneren.
Wie kriege ich das hin.
Ich habe eine Regel angelegt - mit der Maßgabe, nur von diesem Server auf 5061 was durchzulassen, das scheint es nicht zu sein.
Grüße und vielen Dank!
02.01.2018 20:39
Ich kann Dir jetzt zwar nicht ganz folgen, aber falls Du über die Zugriffslisten gehst brauchst Du flankierende Rgeln.
Zuerst die Regeln, was durchgehen soll.
Dann die Regel alles eingehende auf z.B. 5060/61 sperren (Für das was von vorstehenden Allow-Regeln nicht erfasst wird, Deny-All-Strategie)
Als letztes wichtig: Allow-Regel für den sonstigen Verkehr.
Die Herausforderung war die Reihenfolge herzustellen, da die korrekte Reihenfolge der Regeln erst sichtbar wird, wenn Du eine verschiebst.
Was hast Du jetzt genau vor?
Übrigens: Bei der be.ip kann in den externen Sip-Konten die Serverkontrolle aktiviert werden. Dann werden Zugriffe nur noch von den im DNS eingetragenen Servern zugelassen (Quell-IP-Adresse prüfen). Die Regel habe ich nie ausprobiert, da ich meine Variante aktiv am laufen habe. Wann das dazugekommen ist weiß ich nicht. In die SIP-Konten schaue ich eher selten rein.
19.06.2018 16:44 Zuletzt bearbeitet: 19.06.2018 16:49 durch den Autor
@Kalle2014@ schrieb:2.) Wie man im Logbuch der DigiBox sehen kann, werden unzulässige Verbindungen zuverlässig abgewiesen. Durch die Regelketteneinträge wird dann die Ablehnung nur verlagert.
Hallo Herr Schmidthaus,
dieser Aussage kann ich irgendwie nicht ganz zustimmen, seit längerem bekomme ich in unserer anlage von einer Adresse alle möglichen registrierungsversuche rein.
ich sehe auch das NACH einer prüfung der registration, die IP auf einer Blocked Peer Liste landet.
weiter ist dieser block für mich nicht vertrauenswürdig, erst wenn das paket angenommen und ausgewertet wurde, wird es verworfen, warum kommt es überhaupt so weit?
Wenn sicherheit großgeschrieben wird sollte bei einem erkannten angriff die IP in kein subsystem weiter als ip kommen dürfen (meine auffassung)
die adresse versucht es nun seit stunden jede nummer (hier inzwischen 820) wird mindestens 20 mal versucht meistens öfter, pro sekunde kommt mindestens ein versuch.
sprich der angreifer bekommt fleisig immer weiter antworten und gibt dadurch nicht auf.
besonders stört mich das ich nicht mal die firewall die kommunikation mit dieser ip komplett sperren konnte da sie wie schon erwähnt an der firewall drann vorbei kommt und nur die richtlienien greifen.
ich bin gerade an anderen fehler suchen drann und das stört imens wenn so viel unnötiger müll drinn steht der eigentlich garnicht im PXB ankommen dürfte und den angreifer eigentlich für mindestens 1-2 Stunden nicht erreichbar sein sollte.
wenn ein peer immer weiter versucht sich zu registrieren, warum wird auch bei geblockter IP dennoch die Sperre irgendwann innerhalb von Minuten aufgehoben?
2018-06-19 16:17:52.067 WARNING tal.c(1970) : Msg from 195.154.45.194 ignored due blocked peer address 2018-06-19 16:17:53.000 INFO tal.c(3292) : Rem blocked peer address: 195.154.45.194 2018-06-19 16:17:53.457 INFO tpl.c(1007) : udp:0.0.0.0:5060 (25/0/0) data event 2018-06-19 16:17:53.457 INFO tpl.c(1017) : udp:0.0.0.0:5060 (25/0/0) data event read 2018-06-19 16:17:53.457 INFO tpl.c( 910) : udp:0.0.0.0:5060 (25/0) 551 bytes from 195.154.45.194:25582,30010001 in state CONNECTED 2018-06-19 16:17:53.458 MESSAGE tpl.c( 952) : --> from <195.154.45.194:25582;transport=udp> REGISTER sip:[Feste-IP] SIP/2.0 Via: SIP/2.0/UDP [MEINE-Feste-IP]:25582;branch=z9hG4bKa6a8ee61-d482-41c3-b936-f7cc3eeebae5;rport To: "820"<sip:820@[MEINE-Feste-IP]> From: "820"<sip:820@[MEINE-Feste-IP]>;tag=phnuekbv CSeq: 1 REGISTER Call-ID: unjpqnpjmgwmqbxtvvblaklmiqreylamcsxroceanrbpnijpjo Max-Forwards: 70 Contact: <sip:820@195.154.45.194:25582;rinstance=b6edc7c7ac14a743> User-Agent: VoIP SIP v11.0.0 Content-Length: 0 Expires: 3600 Supported: 100rel Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE 2018-06-19 16:17:53.459 INFO tal.c(2014) : success decoding msg from 195.154.45.194:25582 2018-06-19 16:17:53.459 INFO tal.c(3600) : tal_store_ta(): TA[18449,idle,0,in,REGISTER,udp:195.154.45.194:25582,30010001] added 2018-06-19 16:17:53.459 INFO tal.c(3602) : TA 18449: added, now active TAs=1 2018-06-19 16:17:53.459 INFO tal_message.c( 111) : TAL: tal msg 38708 created 2018-06-19 16:17:53.459 INFO tal.c(1433) : srv_noninvite_inc(): TA[18449,idle,0,in,REGISTER,udp:195.154.45.194:25582,30010001] start 2018-06-19 16:17:53.459 INFO tal.c( 735) : tal_set_state(): TA[18449,idle,0,in,REGISTER,udp:195.154.45.194:25582,30010001] ==> trying 2018-06-19 16:17:53.459 INFO tal.c(2795) : ta with key phnuekbv+unjpqnpjmgwmqbxtvvblaklmiqreylamcsxroceanrbpnijpjo+1+REGISTER+z9hG4bKa6a8ee61-d482-41c3-b936-f7cc3eeebae5 added 2018-06-19 16:17:53.459 INFO tal.c( 484) : invoke 0. tal callback [0][5] 2018-06-19 16:17:53.460 INFO tal_message.c( 111) : TU_REGSRV: tal msg 38708 tu registrar cb 2018-06-19 16:17:53.460 INFO tu_common.c(1192) : tu_user_get_from_request(): no user found with user_tag=(null) in domgroups 2018-06-19 16:17:53.460 INFO tal_message.c( 111) : TAL: tal msg 38709 created 2018-06-19 16:17:53.460 INFO tal.c(1501) : srv_noninvite_out(): TA[18449,trying,0,in,REGISTER,udp:195.154.45.194:25582,30010001] start 2018-06-19 16:17:53.460 INFO tpl.c(1007) : udp:0.0.0.0:5060 (25/1/0) data event 2018-06-19 16:17:53.460 INFO tpl.c(1031) : udp:0.0.0.0:5060 (25/1/0) data event write 2018-06-19 16:17:53.461 INFO tpl.c( 679) : udp:0.0.0.0:5060 (25/1/0) data write 2018-06-19 16:17:53.461 INFO tpl.c( 727) : send via fd 25, key udp:0.0.0.0:5060, len 349 -> 195.154.45.194:25582,300100012018-06-19 16:17:53.461 MESSAGE tpl.c( 737) : <-- to <195.154.45.194:25582;transport=udp> SIP/2.0 404 Not Found Via: SIP/2.0/UDP 195.154.45.194:25582;branch=z9hG4bKa6a8ee61-d482-41c3-b936-f7cc3eeebae5;rport=25582 From: "820" <sip:820@[MEINE-Feste-IP]>;tag=phnuekbv To: "820" <sip:820@[MEINE-Feste-IP]>;tag=B0F779C2425736109D5F318017342222 Call-ID: unjpqnpjmgwmqbxtvvblaklmiqreylamcsxroceanrbpnijpjo CSeq: 1 REGISTER Content-Length: 0 2018-06-19 16:17:53.461 INFO tal.c( 735) : tal_set_state(): TA[18449,trying,0,in,REGISTER,udp:195.154.45.194:25582,30010001] ==> completed 2018-06-19 16:17:53.462 INFO tal.c(1550) : srv_noninvite_out(): TA[18449,completed,0,in,REGISTER,udp:195.154.45.194:25582,30010001] end 2018-06-19 16:17:53.462 INFO tal.c(3276) : Add blocked peer address: 195.154.45.194 2018-06-19 16:17:53.462 INFO tal.c(1488) : srv_noninvite_inc(): TA[18449,completed,0,in,REGISTER,udp:195.154.45.194:25582,30010001] end 2018-06-19 16:17:53.462 INFO tal.c( 529) : tal_status_cb(18449, 38709) TPL_MSG_SEND
Mit freundlichen grüßen,
Matthias Metzger