Hallo zusammen,
Ich habe einen 1723 mit Firmwarestand 8.50.0214RU welcher mit einer statischen public IP Adresse am Internet Router hängt. An diesem habe ich jeweils einen SIP Trunk zu meiner Asterisk (192.168.1.6) und einen SIP Trunk zu meinem Provider der es mir ermöglicht über VOIP Telengespräche zu führen. Das Routing für diese zwei SIP Trunks wickle ich über den callrouter ab indem ich entsprechend den DDI route.
Nun möchte ich aber gerne die Firewall so einstellen, dass der 1723 nur SIP anfragen (Signalisierung Port 5060) und RTP (Port Range UDP 16000 - 30000) zwischen der Public IP Adresse des 1723 (WAN) und der Public Adresse 81.7.253.100 (Session Border Controller Provider) zulässt. Sämtliche anfragen die nicht von WAN zu 81.7.253.100 und umgekehrt sind sollen verworfen werden.
Asterisk --- SIP Trunk --- Lancom1723 --- SIP Trunk --- Router --- Session Boarder Controller Provider
Astersik
192.168.1.6
192.168.1.1 LAN 1723
1723 WAN statische public IP Adresse
Session Boarder Controller Provider 81.7.253.100
Habe letztens mal die Deny-ALL Regel in der Fireall implementiert musste dann jedoch feststellen, dass der 1723 auf SIP Port UDP 5060 immer noch anfragen aus der ganzen Welt beantwortet :(
Wäre euch für Tips und Tricks sehr wie ich dies bewerkstelligen kann sehr dankbar.
Gruss
migu
1723 SIP/RTP Einschränken auf Public IP Adresse
Moderator: Lancom-Systems Moderatoren
Hi migmig
das geht letztendlich gar nicht... Die Firewall im LANCOM enthält nur den Forwarding-Zweig - für deinen Fall wäre aber ein Inbound-Regelsatz nötig...
Letztendlich mußt du aber nur ein genügend sicheres Paßwort für die SIP-Leitungen, damit niemand von "aussen" unerlaubt dein Gerät nutzt...
Gruß
Backslash
das geht letztendlich gar nicht... Die Firewall im LANCOM enthält nur den Forwarding-Zweig - für deinen Fall wäre aber ein Inbound-Regelsatz nötig...
Letztendlich mußt du aber nur ein genügend sicheres Paßwort für die SIP-Leitungen, damit niemand von "aussen" unerlaubt dein Gerät nutzt...
Gruß
Backslash
Hallo backslash,
Was verstehst du unter sicheres Passwort für die SIP Leitungen? Meinst du für die zwei SIP Trunks, einmal vom 1723 zum Provider und einmal vom 1723 intern zur Asterisk?
Da habe ich ein kleines Problem den der SIP Trunk zum Provider ist authentisierungfrei, sprich meine statische Public IP Adresse wird auf dem SBC "Session Boarder Controller" via einer ACL "access control list" freigeschalten und lässt dann somit nur meine IP zu.
Das würde also bedeuten, dass sobald man auf dem 1723 den Voice-Call-Manager (VCM) aktiviert der 1723 auf alle Anfragen welche auf Port UDP 5060 kommen Antwortet.
Es gibt also keine Lösung den 1723 so zu schützen das er nicht auf alle Anfragen aus der ganzen Welt antwortet?
Da ich in der glücklichen Lage bin einen zweiten Anschluss zu Hause zu haben welcher über einen anderen Anbieter geht habe ich mir mal erlaubt von dem aus einen Angriff auf den 1723 zu starten
Ich bringe es also locker fertig mit meinem Test den Prozessor der 1723 um + 20% damit auszulasten, wohlgemerkt mein zweiter Anschluss hat gerade mal einen upload von 800k. Möchte ja nicht wissen was passieren würde wenn ich einen Upload von 2Mbit hätte. Zudem kann ich damit locker herausfinden um was für ein Gerät es sich handelt, welchen Firmwarestand das Gerät hat und den Hostnamen. Denn dies gibt alles der 1723 bekannt auf eine simple SIP OPTIONS anfrage bekannt aus dem Internet.
Ich denke in der heutigen Zeit mit den vermehrten VOIP Angriffen aus dem Internet, speziell aus den Ländern welche sich im Osten befinden
wäre es sehr sinnvoll wenn man anhand einem Inbound Regelsatz (Regelsatz auf Port und source/destination IP Adresse) unterbinden könnte.
Wenn schon Firewall und VOIP in einem Gerät integriert dann auf einer sinvollen "state of the art". Vorallem wenn man SIP Trunks zur Verfügung stellt.
Bin ich der einzige auf dieser Welt welcher einen 1723 im Einsatz hat mit SIP Trunks welcher ein solches Bedürfniss hat?
Wäre der Firma Lancom sehr dankbar, wenn Sie sich auch etwas Gedanken darüber machen könnte wie Sie ihren geschätzten Kunden es ermöglichen kann sich auch vor Hackern zu schützen.
Evt. gibt es ja bereits einen Feature request's für mein Anliegen
Gruss
migmig
Was verstehst du unter sicheres Passwort für die SIP Leitungen? Meinst du für die zwei SIP Trunks, einmal vom 1723 zum Provider und einmal vom 1723 intern zur Asterisk?
Da habe ich ein kleines Problem den der SIP Trunk zum Provider ist authentisierungfrei, sprich meine statische Public IP Adresse wird auf dem SBC "Session Boarder Controller" via einer ACL "access control list" freigeschalten und lässt dann somit nur meine IP zu.
Das würde also bedeuten, dass sobald man auf dem 1723 den Voice-Call-Manager (VCM) aktiviert der 1723 auf alle Anfragen welche auf Port UDP 5060 kommen Antwortet.
Es gibt also keine Lösung den 1723 so zu schützen das er nicht auf alle Anfragen aus der ganzen Welt antwortet?
Da ich in der glücklichen Lage bin einen zweiten Anschluss zu Hause zu haben welcher über einen anderen Anbieter geht habe ich mir mal erlaubt von dem aus einen Angriff auf den 1723 zu starten
Ich bringe es also locker fertig mit meinem Test den Prozessor der 1723 um + 20% damit auszulasten, wohlgemerkt mein zweiter Anschluss hat gerade mal einen upload von 800k. Möchte ja nicht wissen was passieren würde wenn ich einen Upload von 2Mbit hätte. Zudem kann ich damit locker herausfinden um was für ein Gerät es sich handelt, welchen Firmwarestand das Gerät hat und den Hostnamen. Denn dies gibt alles der 1723 bekannt auf eine simple SIP OPTIONS anfrage bekannt aus dem Internet.
Ich denke in der heutigen Zeit mit den vermehrten VOIP Angriffen aus dem Internet, speziell aus den Ländern welche sich im Osten befinden
wäre es sehr sinnvoll wenn man anhand einem Inbound Regelsatz (Regelsatz auf Port und source/destination IP Adresse) unterbinden könnte. Wenn schon Firewall und VOIP in einem Gerät integriert dann auf einer sinvollen "state of the art". Vorallem wenn man SIP Trunks zur Verfügung stellt.
Bin ich der einzige auf dieser Welt welcher einen 1723 im Einsatz hat mit SIP Trunks welcher ein solches Bedürfniss hat?
Wäre der Firma Lancom sehr dankbar, wenn Sie sich auch etwas Gedanken darüber machen könnte wie Sie ihren geschätzten Kunden es ermöglichen kann sich auch vor Hackern zu schützen.
Evt. gibt es ja bereits einen Feature request's für mein Anliegen
Gruss
migmig
Hi migmig,
sorry, ich meinte das Paßwort für die Benutzer (VoIP-Call-Manager -> Benutzer -> SIP-Benutzer), denn die SIP-Leitungen sind ja "abgehend" zum Provider. Dort kannst du auch einstellen, ob der User über das WAN reinkommen darf.
Desweiteren kannst du ja auch eine sehr komplexe interne Domain (VoIP-Call-Manager -> Allgemein -> lokale VoIP-Domäne) verwenden - wenn die wie ein sicheres Paßwort aussieht, dann wird es kaum jemand schaffen, sich beim LANCOM anzumelden...
Gruß
Backslash
sorry, ich meinte das Paßwort für die Benutzer (VoIP-Call-Manager -> Benutzer -> SIP-Benutzer), denn die SIP-Leitungen sind ja "abgehend" zum Provider. Dort kannst du auch einstellen, ob der User über das WAN reinkommen darf.
Desweiteren kannst du ja auch eine sehr komplexe interne Domain (VoIP-Call-Manager -> Allgemein -> lokale VoIP-Domäne) verwenden - wenn die wie ein sicheres Paßwort aussieht, dann wird es kaum jemand schaffen, sich beim LANCOM anzumelden...
Gruß
Backslash
Hi,
wenn ein SIP User angelegt ist, dann kann dieser sich auch aus dem WAN anmelden.
Ab dem LCOS 8.60 RC2 kann nun fuer die SIP-User die Anmeldung aus dem WAN/VPN/LAN konfiguriert werden und es gibt eine konfigurierbare "Brute-Force" Sperre, mit der nach x fehlgeschlagenen Anmeldeversuchen das weitere Login fuer eine Zeit y nicht mehr moeglich ist.
Ciao
LoUiS
wenn ein SIP User angelegt ist, dann kann dieser sich auch aus dem WAN anmelden.
Ab dem LCOS 8.60 RC2 kann nun fuer die SIP-User die Anmeldung aus dem WAN/VPN/LAN konfiguriert werden und es gibt eine konfigurierbare "Brute-Force" Sperre, mit der nach x fehlgeschlagenen Anmeldeversuchen das weitere Login fuer eine Zeit y nicht mehr moeglich ist.
Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
Morgen zusammen,
Verbeisst euch nicht an den Benutzern den wie ich am Di 21 Feb, 2012 08:41 geschrieben habe sind auf dem 1723 keine Benutzer erfasst. Ich reiche den DDI range via callrouter vom eingehendem SIP Trunk (Provider) über den internen SIP Trunk zur Asterisk weiter wo die Benutzer erfasst sind. Also keine Benutzer auf dem 1723, alle Benutzer sind auf der Asterisk erfasst welche mit einer privaten IP Adresse am LAN des 1723 hängt.
Ich möchte eigentlich nur verhindern, dass der 1723 Antwort auf SIP Ebene (UDP Port 5060) der ganze Welt gibt. Er sollte WAN seitig eigentlich nur mit dem Session Boarder Controller 81.7.253.100 kommunizieren und sonst mit niemanden auf dieser Welt. In der heutigen Zeit wo es ausgeklügelte Scripts gibt wo man Public IP Adress Bereiche in kurzer Zeit nach VOIP Geräten durchsuchen kann macht es Sinn den 1723 davon abzuhalten eine Antwort an unerwünschte IP Adressen zu geben. Zudem kommt noch hinzu, dass sobald jemand im Internet eine Antwort vom 1723 bekommt dieser sich daran verbeissen wird den 1723 zu hacken. Also eine Sinnlose Flut an Attacken vom Internet her auf den 1723 welche nicht sein sollte wenn man im 1723 via Firewall die VOIP Kommunikation einschränken könnte.
Gruss und einen schönen Tag wünscht
migmig
Verbeisst euch nicht an den Benutzern den wie ich am Di 21 Feb, 2012 08:41 geschrieben habe sind auf dem 1723 keine Benutzer erfasst. Ich reiche den DDI range via callrouter vom eingehendem SIP Trunk (Provider) über den internen SIP Trunk zur Asterisk weiter wo die Benutzer erfasst sind. Also keine Benutzer auf dem 1723, alle Benutzer sind auf der Asterisk erfasst welche mit einer privaten IP Adresse am LAN des 1723 hängt.
Ich möchte eigentlich nur verhindern, dass der 1723 Antwort auf SIP Ebene (UDP Port 5060) der ganze Welt gibt. Er sollte WAN seitig eigentlich nur mit dem Session Boarder Controller 81.7.253.100 kommunizieren und sonst mit niemanden auf dieser Welt. In der heutigen Zeit wo es ausgeklügelte Scripts gibt wo man Public IP Adress Bereiche in kurzer Zeit nach VOIP Geräten durchsuchen kann macht es Sinn den 1723 davon abzuhalten eine Antwort an unerwünschte IP Adressen zu geben. Zudem kommt noch hinzu, dass sobald jemand im Internet eine Antwort vom 1723 bekommt dieser sich daran verbeissen wird den 1723 zu hacken. Also eine Sinnlose Flut an Attacken vom Internet her auf den 1723 welche nicht sein sollte wenn man im 1723 via Firewall die VOIP Kommunikation einschränken könnte.
Gruss und einen schönen Tag wünscht
migmig
"Ich möchte eigentlich nur verhindern, dass der 1723 Antwort auf SIP Ebene (UDP Port 5060) der ganze Welt gibt."
Selbst wenn du keiner weiterleitung/forwarding vornimmst wird der connect moeglich sein, diese erkentniss hat uns sehr viel geld gekostet weil wir auch dachten, wenns nicht geforwarded ist und auch sonst nicht publiziert ist waere es sicher, ein teurer trugschluss.
Selbst wenn du keiner weiterleitung/forwarding vornimmst wird der connect moeglich sein, diese erkentniss hat uns sehr viel geld gekostet weil wir auch dachten, wenns nicht geforwarded ist und auch sonst nicht publiziert ist waere es sicher, ein teurer trugschluss.