Willkommen in der Business Community

Die Telekom Community für Geschäftskunden

Aktueller Hinweis

Digitalisierungs Box Premium offener SIP Port

Gelöst

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:

  1. Sind die Ports standardmäßig aus dem Internet erreichbar?
  2. Durch welche Konfiguration könnte ich das aus Versehen freigeschaltet haben, wie mache ich es wieder rückgängig?
  3. 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

2 AKZEPTIERTE LÖSUNGEN
Lösung
Gelöschter Nutzer

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:

Unbenannt.PNG

 

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.

Lösung in ursprünglichem Beitrag anzeigen  

Lösung

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.

Lösung in ursprünglichem Beitrag anzeigen  

Lösung

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.

Lösung
Gelöschter Nutzer

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:

Unbenannt.PNG

 

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.

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.

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

Gelöschter Nutzer

@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.

@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!

Gelöschter Nutzer

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.


@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