CallManager angreifbar?

[Raudi]

Hallo Leute,

kann es sein, dass wir hier eine Sicherheitslücke haben? Ich habe in der Firewall eine DenyAll Regel und dann keine VoIP Ports geöffnet aber trotzdem kommen hier komische Anfragen rein:

Code: Alles auswählen

[SIP-Packet] 2015/11/22 09:18:21,472  Devicetime: 2015/11/22 09:18:19,897 [PACKET] : 
Receiving datagram with length 758 from 209.126.111.104:5070 to <IP-KABEL-200>:5060
INVITE sip:90041215083427@<IP-KABEL-200> SIP/2.0\r\n
To: 90041215083427<sip:90041215083427@<IP-KABEL-200>>\r\n
From: 8000<sip:8000@<IP-KABEL-200>>;tag=96175b80\r\n
Via: SIP/2.0/UDP 209.126.111.104:5070;branch=z9hG4bK-010d507207764356d0ca74741b5ae836;rport\r\n
Call-ID: 010d507207764356d0ca74741b5ae836\r\n
CSeq: 1 INVITE\r\n
Contact: <sip:8000@209.126.111.104:5070>\r\n
Max-Forwards: 70\r\n
Allow: INVITE, ACK, CANCEL, BYE\r\n
User-Agent: sipcli/v1.8\r\n
Content-Type: application/sdp\r\n
Content-Length: 285\r\n
\r\n
v=0\r\n
o=sipcli-Session 72683242 1367824081 IN IP4 209.126.111.104\r\n
s=sipcli\r\n
c=IN IP4 209.126.111.104\r\n
t=0 0\r\n
m=audio 5072 RTP/AVP 18 0 8 101\r\n
a=fmtp:101 0-15\r\n
a=rtpmap:18 G729/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=ptime:20\r\n
a=sendrecv\r\n

[SIP-Packet] 2015/11/22 09:18:21,473  Devicetime: 2015/11/22 09:18:19,898 [PACKET] : 
Sending datagram with length 457 from <IP-KABEL-200>:5060 to 209.126.111.104:5070
SIP/2.0 404 Not Found\r\n
Via: SIP/2.0/UDP 209.126.111.104:5070;branch=z9hG4bK-010d507207764356d0ca74741b5ae836;rport\r\n
From: "8000"<sip:8000@<IP-KABEL-200>>;tag=96175b80\r\n
To: "90041215083427"<sip:90041215083427@<IP-KABEL-200>>\r\n
Call-ID: 010d507207764356d0ca74741b5ae836\r\n
CSeq: 1 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1781EF+ / 9.10.0517 / 19.11.2015\r\n
Server: dsl-home\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2015/11/22 09:18:21,728  Devicetime: 2015/11/22 09:18:20,154 [PACKET] : 
Receiving datagram with length 760 from 209.126.111.104:5070 to <IP-KABEL-100>:5060
INVITE sip:90041215083427@<IP-KABEL-100> SIP/2.0\r\n
To: 90041215083427<sip:90041215083427@<IP-KABEL-100>>\r\n
From: 8000<sip:8000@<IP-KABEL-100>>;tag=d8ab4846\r\n
Via: SIP/2.0/UDP 209.126.111.104:5070;branch=z9hG4bK-63ef27946d0b9239e590f13820d32f7c;rport\r\n
Call-ID: 63ef27946d0b9239e590f13820d32f7c\r\n
CSeq: 1 INVITE\r\n
Contact: <sip:8000@209.126.111.104:5070>\r\n
Max-Forwards: 70\r\n
Allow: INVITE, ACK, CANCEL, BYE\r\n
User-Agent: sipcli/v1.8\r\n
Content-Type: application/sdp\r\n
Content-Length: 287\r\n
\r\n
v=0\r\n
o=sipcli-Session 2145291810 1473807293 IN IP4 209.126.111.104\r\n
s=sipcli\r\n
c=IN IP4 209.126.111.104\r\n
t=0 0\r\n
m=audio 5072 RTP/AVP 18 0 8 101\r\n
a=fmtp:101 0-15\r\n
a=rtpmap:18 G729/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=ptime:20\r\n
a=sendrecv\r\n

[SIP-Packet] 2015/11/22 09:18:21,729  Devicetime: 2015/11/22 09:18:20,155 [PACKET] : 
Sending datagram with length 457 from <IP-KABEL-100>:5060 to 209.126.111.104:5070
SIP/2.0 404 Not Found\r\n
Via: SIP/2.0/UDP 209.126.111.104:5070;branch=z9hG4bK-63ef27946d0b9239e590f13820d32f7c;rport\r\n
From: "8000"<sip:8000@<IP-KABEL-100>>;tag=d8ab4846\r\n
To: "90041215083427"<sip:90041215083427@<IP-KABEL-100>>\r\n
Call-ID: 63ef27946d0b9239e590f13820d32f7c\r\n
CSeq: 1 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1781EF+ / 9.10.0517 / 19.11.2015\r\n
Server: dsl-home\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2015/11/22 09:18:39,451  Devicetime: 2015/11/22 09:18:37,878 [PACKET] : 
Receiving datagram with length 757 from 209.126.111.104:5070 to <IP-KABEL-200>:5060
INVITE sip:0041215083427@<IP-KABEL-200> SIP/2.0\r\n
To: 0041215083427<sip:0041215083427@<IP-KABEL-200>>\r\n
From: 8001<sip:8001@<IP-KABEL-200>>;tag=860a9f90\r\n
Via: SIP/2.0/UDP 209.126.111.104:5070;branch=z9hG4bK-d4a2a3d0a45f0ab51dba3469bdaf18db;rport\r\n
Call-ID: d4a2a3d0a45f0ab51dba3469bdaf18db\r\n
CSeq: 1 INVITE\r\n
Contact: <sip:8001@209.126.111.104:5070>\r\n
Max-Forwards: 70\r\n
Allow: INVITE, ACK, CANCEL, BYE\r\n
User-Agent: sipcli/v1.8\r\n
Content-Type: application/sdp\r\n
Content-Length: 287\r\n
\r\n
v=0\r\n
o=sipcli-Session 1832064392 1655237617 IN IP4 209.126.111.104\r\n
s=sipcli\r\n
c=IN IP4 209.126.111.104\r\n
t=0 0\r\n
m=audio 5072 RTP/AVP 18 0 8 101\r\n
a=fmtp:101 0-15\r\n
a=rtpmap:18 G729/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=ptime:20\r\n
a=sendrecv\r\n

[SIP-Packet] 2015/11/22 09:18:39,454  Devicetime: 2015/11/22 09:18:37,878 [PACKET] : 
Sending datagram with length 455 from <IP-KABEL-200>:5060 to 209.126.111.104:5070
SIP/2.0 404 Not Found\r\n
Via: SIP/2.0/UDP 209.126.111.104:5070;branch=z9hG4bK-d4a2a3d0a45f0ab51dba3469bdaf18db;rport\r\n
From: "8001"<sip:8001@<IP-KABEL-200>>;tag=860a9f90\r\n
To: "0041215083427"<sip:0041215083427@<IP-KABEL-200>>\r\n
Call-ID: d4a2a3d0a45f0ab51dba3469bdaf18db\r\n
CSeq: 1 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1781EF+ / 9.10.0517 / 19.11.2015\r\n
Server: dsl-home\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2015/11/22 09:18:39,717  Devicetime: 2015/11/22 09:18:38,143 [PACKET] : 
Receiving datagram with length 756 from 209.126.111.104:5070 to <IP-KABEL-100>:5060
INVITE sip:0041215083427@<IP-KABEL-100> SIP/2.0\r\n
To: 0041215083427<sip:0041215083427@<IP-KABEL-100>>\r\n
From: 8001<sip:8001@<IP-KABEL-100>>;tag=007a4f88\r\n
Via: SIP/2.0/UDP 209.126.111.104:5070;branch=z9hG4bK-2bdcddc317adccbb3d7c317b2b4e37e4;rport\r\n
Call-ID: 2bdcddc317adccbb3d7c317b2b4e37e4\r\n
CSeq: 1 INVITE\r\n
Contact: <sip:8001@209.126.111.104:5070>\r\n
Max-Forwards: 70\r\n
Allow: INVITE, ACK, CANCEL, BYE\r\n
User-Agent: sipcli/v1.8\r\n
Content-Type: application/sdp\r\n
Content-Length: 286\r\n
\r\n
v=0\r\n
o=sipcli-Session 635289494 1131109146 IN IP4 209.126.111.104\r\n
s=sipcli\r\n
c=IN IP4 209.126.111.104\r\n
t=0 0\r\n
m=audio 5072 RTP/AVP 18 0 8 101\r\n
a=fmtp:101 0-15\r\n
a=rtpmap:18 G729/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=ptime:20\r\n
a=sendrecv\r\n

[SIP-Packet] 2015/11/22 09:18:39,717  Devicetime: 2015/11/22 09:18:38,144 [PACKET] : 
Sending datagram with length 455 from <IP-KABEL-100>:5060 to 209.126.111.104:5070
SIP/2.0 404 Not Found\r\n
Via: SIP/2.0/UDP 209.126.111.104:5070;branch=z9hG4bK-2bdcddc317adccbb3d7c317b2b4e37e4;rport\r\n
From: "8001"<sip:8001@<IP-KABEL-100>>;tag=007a4f88\r\n
To: "0041215083427"<sip:0041215083427@<IP-KABEL-100>>\r\n
Call-ID: 2bdcddc317adccbb3d7c317b2b4e37e4\r\n
CSeq: 1 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1781EF+ / 9.10.0517 / 19.11.2015\r\n
Server: dsl-home\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS\r\n
Content-Length: 0\r\n
\r\n

Das ist mir eben aufgefallen, als ich ein T.38 Fax Problem analysieren wollte und den SIP Traffic mit geschnitten habe.

Die IP kommt aus Amerika: http://whois.arin.net/rest/net/NET-209- ... 26.111.104

Also da versucht einer irgendwas zu hacken, geantwortet wird immer mit "404 Not Found", aber die Frage ist, warum nimmt der Router die Anfrage überhaupt entgegen? Auch ist bei keinem SIP Benutzer der Zugriff über das WAN erlaubt.

Viele Grüße
Stefan

[Raudi]

Nachtrag, habe mal einen Trace mit dem Filter "+sipcli" längere Zeit laufen lassen...

Nun eine andere Quell IP und immer alle 8 Minuten wird ein INVITE gesendet, erst an die eine Öffentliche IP und dann an die andere.

Also mir wäre es ja lieber wenn man das System von extern komplett dicht machen könnte.

Viele Grüße
Stefan

[cpuprofi]

Hallo,

...Also mir wäre es ja lieber wenn man das System von extern komplett dicht machen könnte....

und was soll das für eine "Sicherheit" bringen? Der Lancom weist doch die "Anfragen" mit 404 ab!

Ich würde mir viel mehr wünschen, das Lancom die All-IP Option WAN-Seitig wieder öffnen würde, so wie es mal bei den 1722-1724er Geräten war. So konnte man supereinfach externe VoIP-Clients einbinden und war nicht auf solche bandbreitenverschlingende Lösungen wie VPN angewiesen!

Und wenn irgendwelche DAU's keine sicheren Passwörter verwenden, dann sind sie selber Schuld!!! Und wer als Admin nicht in der Lage ist sichere Passwörter zu erstellen, hat seinen Beruf sowieso verfehlt...


Durch die damalige "Blödheit" einer Firma (die keine "sicheren" Passwörter für Ihren 172x Router verwendet hatte und dann sich wunderte, dass ihre Telefonrechnung auf einmal "explodierte") hatte Lancom diese WAN-Options-Möglichkeit aus den Lancoms herausgenommen (zumindest kann man den "Schalter" nicht mehr entsprechend setzen).

Das ganze Gejammer, da könnte hypothetisch, möglicherweise, eventuell mir jemand was böses tun, kotzt mich nur an. Denn durch so etwas verlieren wir dann die Möglichkeit, Lancom Geräte frei und selbst bestimmt zu konfigurieren, was ja die Lancom's im Moment noch auszeichnet. Denn dann bekommt Lancom "Angst ums Image" und entfernt/deaktiviert diese Möglichkeit der freien Konfiguration, was meinem Ansprüchen und den meiner Kunden dann nicht mehr gerecht wird.

Ich bin immer noch der Meinung, als mündiger Admin sollte man selber und eigenverantwortlich so etwas entscheiden können, alles andere ist hier fehl am Platz!!!

Wenn Du Dir alles "vorkauen lassen" möchtest, kauf Dir eine Fritzbox, denn die kann aus "Sicherheitsgründen" nicht mal mehr SSH...

Grüße
Cpuprofi

[Raudi]

Ich bin immer noch der Meinung, als mündiger Admin sollte man selber und eigenverantwortlich so etwas entscheiden können, alles andere ist hier fehl am Platz!!!

Sage ich denn was anderes?

Aber ich habe gerade gesehen, es stimmt, man kann beim Zugriff über WAN nur "verbieten" und "nur über VPN" eintragen, dann ist es ja noch schlimmer dass hier die Ports offen sind... Ich habe angenommen dass man hier auch das WAN erlauben kann, war ja bei den alten Geräten auch so...

Also ideal wäre dann folgende Konfigurationsmöglichkeit:

WAN erlauben -> Ports direkt ins WAN offen
WAN verbieten -> Ports direkt ins WAN und in die VPN Tunnel geschlossen
WAN über VPN erlauben -> Ports direkt ins WAN geschlossen und in die VPN Tunnel auf

Bei einer Mischkonfiguration natürlich erlauben vor verbieten.

Viele Grüße
Stefan

[cpuprofi]

Also ideal wäre dann folgende Konfigurationsmöglichkeit:

WAN erlauben -> Ports direkt ins WAN offen
WAN verbieten -> Ports direkt ins WAN und in die VPN Tunnel geschlossen
WAN über VPN erlauben -> Ports direkt ins WAN geschlossen und in die VPN Tunnel auf

Bei einer Mischkonfiguration natürlich erlauben vor verbieten.

Das was Du da vorschlägst, wäre der Ideal-Zustand. Ich würde dieses sofort unterstützen, zumal ich ja dann (endlich) wieder eine VoIP-Anmeldung per WAN (ohne VPN!) nutzen könnte!

Jetzt muß man Lancom nur noch dazu kriegen die VoIP-Anmeldung per WAN (wieder) zu erlauben!

Ich hoffe, dass sich hier auch mal ein paar andere Leute positiv zu diesem Wunsch-Feature (welches ja schon mal da war!) äußern.

Grüße
Cpuprofi

[garfield0815]

also mir wurde vor jahren ein 1722 gehackt
und es wurden telefonate nach spanien geführe 20.000 alle 2 min eine nacht lan

[Raudi]

Bei mir hat mich damals glücklicher weise die Telekom angerufen und meinte meine TK Anlage sei vermutlich gehackt worden, da von meinem Anschluss Rufnummern angerufen wurden die ungewöhnlich sein.

Damals haben sich welche von einer IP aus Gaza Stadt bei mir eingeloggt, die SIP Verbindung stand sogar noch. Da habe dann gleich mal deren Router (hatte Default Passwort) lahm gelegt.

Zum glück hatte ich nur geringe Kosten, da die nur gehackt und getestet hatten. Am Wochenende hätten die dann vermutlich richtig los gelegt...

[cpuprofi]

Hallo,

diese "Probleme" hatte ich nie gehabt. Ok, ich benutze auch ausreichend sichere Passwörter für Router, AP's und VoIP-Accounts. Auch bei meinen Kunden ist in dieser Richtung nie etwas passiert...

Ich denke Ihr seid alle Profis

Grüße
Cpuprofi

[Raudi]

Ich denke das Problem damals war, es war nicht bewusst, dass die Accounts auch von Extern nutzbar waren.

LANCOM hat darauf ja auch reagiert und eine entsprechende Warnungs-Mail rum geschickt.

[cpuprofi]

Ich denke das Problem damals war, es war nicht bewusst, dass die Accounts auch von Extern nutzbar waren.

LANCOM hat darauf ja auch reagiert und eine entsprechende Warnungs-Mail rum geschickt.

Dummerweise hat Lancom nicht nur "gewarnt", sondern auch gleich noch alle nicht Betroffenen bevormundet, indem sie die Auswahl "SIP-Anmeldung über WAN" gleich nicht mehr zugelassen haben!

Dieses "Verhalten" von Lancom finde ich mehr als "unschön", es ist eine Bevormundung!

Was würde Herr Koenzen dazu sagen, wenn ihm der Hersteller, seines so geliebten Flugzeugs, das Fliegen verbietet, bloß weil ein anderer "Pilot" eine Maschine zu Bruch geflogen hat...

Grüße
Cpuprofi

[garfield0815]

Dummerweise hat Lancom nicht nur "gewarnt", sondern auch gleich noch alle nicht Betroffenen bevormundet, indem sie die Auswahl "SIP-Anmeldung über WAN" gleich nicht mehr zugelassen haben!

versuch mahl n update für den 1821+ mit voip zu bekommen wo das so ist

da gibt es keines

das update nimt einfach die voip option raus
aber immerhin wurde das proplem auch behoben

[MariusP]

Hi,

Dummerweise hat Lancom nicht nur "gewarnt", sondern auch gleich noch alle nicht Betroffenen bevormundet, indem sie die Auswahl "SIP-Anmeldung über WAN" gleich nicht mehr zugelassen haben!

Dieses "Verhalten" von Lancom finde ich mehr als "unschön", es ist eine Bevormundung!

Wie hättest du es gemacht?
Über so einen Vorschlag könnten wir dann vorzüglich diskutieren.
Gruß

[Raudi]

Dummerweise hat Lancom nicht nur "gewarnt", sondern auch gleich noch alle nicht Betroffenen bevormundet, indem sie die Auswahl "SIP-Anmeldung über WAN" gleich nicht mehr zugelassen haben!

Das stimmt so ja nun nicht, sie haben es mit einem LCOS Update konfigurierbar gemacht und als Default Einstellung die Anmeldung übers WAN deaktiviert. Du konntest aber problemlos die Anmeldung wieder erlauben.

Ich denke mal das war seiner Zeit sicherlich in den Release Notes zu lesen...

Und wenn Du mich fragst ist das auch der einzige korrekte Weg gewesen.

Würdest Du keinen externen Zugriff benötigen und wärst dann später gehackt worden, nur weil da der Parameter durch das Update noch auf "WAN Zugriff erlauben" steht würdest Du sicherlich anders reden.

Aber wir schweifen ab... Wir sollten mal wieder zum eigentlichen Thema kommen...

Die aktuelle LCOS nimmt Connections aus dem WAN entgegen ob wohl man es aktuell nicht mal erlauben (nutzen) kann.

Das ist meiner Meinung nach falsch und stellt ein Risiko dar.

Alles weitere sollte dann sicherlich in den Feature-Wünschen Diskutiert werden.

[cpuprofi]

Die aktuelle LCOS nimmt Connections aus dem WAN entgegen ob wohl man es aktuell nicht mal erlauben (nutzen) kann.

Diese Aussage ist FALSCH! Der VCM bei neueren Geräten lehnt einfach alle Anfragen aus dem WAN ab, aber er nimmt nichts an. Er kann ja auch gar nichts annehmen, da die entsprechende Option ja deaktiviert wurde. Somit ist dieses ja auch kein Sicherheitsrisiko. Denn ansonsten wäre ja jedes Gerät was im WAN auf irgendwas eine Anlehnung sendet ein SICHERHEITSRISIKO. Beispiele: Telnet/S, SSH, HTTPS, VPN... usw. Diese "Anfragen" aus dem WAN werden ja auch bei falschem "Daten" abgelehnt und Du willst doch nicht ernsthaft behaupten, dass dadurch jetzt die Sicherheit ernsthaft gefährdet wäre. Denn dann dürftest Du den Router gar nicht erst ans Internet anschließen...

Ich hätte aber lieber, das der VCM auch Anfragen aus dem WAN annehmen und bearbeiten könnte.

Grüße
Cpuprofi

[Raudi]

Damit das von mir protokollierte Paket den Weg in den Router finden und eine entsprechende Antwort über das SIP Protokoll gesendet werden kann muss der Port 5060 ins Internet offen sein und es muss auf diesem auch aktiv abgehört werden.

Wozu einen Port im Internet abhören, wenn man ihn nicht nutzt?

Und was ist wenn da doch irgendein Fehler im LCOS ist und die Hacker so lange testen bis die irgendwas herausgefunden haben wo das LCOS doch drauf anspricht ob wohl es das nicht sollte? O.k. vermutlich geringes Risiko, aber ein Risiko welches nicht sein müsste.

Das Verhalten kann man doch nicht als normal betrachten. Hat man z.B. keinen Web-Server so wird auch nicht auf dem Port 80 abgehört und über den Port 80 keine Antwort raus geschickt. Spricht jemand den Port 80 an, so bekommt diese Person einen Timeout und keine Fehlermeldung über Port 80 zurück gesendet.