Nachgefragt: Wie sicher ist Voice over IP?

[traxanos]

http://www.avm.de/de/index.php3?News/artikel/newsletter/voip_sicherheit.html

Der hat aber wohl selbst keine Ahnung.
Er behauptet das die Daten per RTP übertragen werden und nicht
per TCP/IP. RTP ist ja richtige aber TCP/IP ist die Grundlage für RTP

Aber auch in anderen Bereichen labbert er nur Müll.

 

[tscoreninja]

Er behauptet das die Daten per RTP übertragen werden und nicht
per TCP/IP. RTP ist ja richtige aber TCP/IP ist die Grundlage für RTP

Ich dachte, RTP läuft über UDP, und nicht TCP?! Ja, der Artikel ist viel Marketing-Gebrabbel, aber in dem Punkt solltest Du an Deiner Ahnung arbeiten

 

[crusader]

Ich dachte, RTP läuft über UDP, und nicht TCP

Da sind wir schon zu dritt (incl. AVM-Produktmanger).
Aber warum sollte sich ein UDP-Datenstrom (wie z.B. VoIP=RTP/UDP) schwieriger abhören lassen als ein TCP-Datenstrom (wie z.B. e-mail=SMTP/TCP) ?

 

[Maik]

Aber warum sollte sich ein UDP-Datenstrom (wie z.B. VoIP=RTP/UDP) schwieriger abhören lassen als ein TCP-Datenstrom (wie z.B. e-mail=SMTP/TCP) ?

TCP ist verbindungsorientiert. Du kannst also an den Paketen direkt erkennen, wo eine Uebertragung anfaengt und wo sie endet. Ausserdem kannst du alle TCP-Pakete eindeutig einer Verbindung zuordnen. Bei UDP ist das nicht moeglich. Da kann man nur anhand von Absender- und Empfaenger-Addresse/-Port Vermutungen anstellen. Anfang und Ende kann man eigentlich nur daran erkennen, dass vorher und nachher lange Zeit nix mehr auf den gleichen Ports kommt.

 

[britzelfix]

@Maik

Bei UDP ist das nicht moeglich.

Ich glaube schon, daß Abhören möglich ist. Es gibt bei RTP (RFC 3550)
auch Sequenz-Nummern, Timestamps und Source (IP) (wer Target
ist sagt Dir IP). Diese kann man auch nachträglich chronologisch sortieren und abspielen.

Am einfachsten stelle ich mir eine modifizierte Soft wie
Asterisk, die im promisc-Modus am Netz hört und wiedergibt
was der zuvor eingestellte Target sendet oder empfängt.

Wenn es das noch nicht gibt, dann aber nicht lange,
denn VoIP entwickelt sich rasend schnell.

Ich behaupte sogar, daß man mit so einer Soft eine Menge Geld verdienen kann.



Ich halte diesen Artikel übrigens auch für ziemlich schwach. Besonders
der letzte Absatz: Rechner sollen immer eine Firewall haben. Viren
und Würmer können auch über das SIP Protokoll reinkommen.
Daher hat die F!B auch eine vom TÜV geprüfe Firewall. blah. blah.

Leider steht da nicht, das der SIP-Port offen ist, weil man sonst
nicht telefonieren könnte.

Also typisch wieder mal: ein Verkäufer verspricht die totale Sicherheit.


Gruß
britzelfix

 

[Maik]

Ich glaube schon, daß Abhören möglich ist. Es gibt bei RTP (RFC 3550)
auch Sequenz-Nummern, Timestamps und Source (IP) (wer Target
ist sagt Dir IP). Diese kann man auch nachträglich chronologisch sortieren und abspielen.

Klar geht das. Aber bei TCP ist das alles schon gleich mit drin. Bei RTP wird es erst auf einem anderen Layer implementiert. Es ist also zumindest theoretisch schwieriger. Wenn man natuerlich sowas wie Ethereal verwendet, kann einem das egal, weil das schon automatisch filtert und sortiert.

 

[traxanos]

Ich dachte, RTP läuft über UDP, und nicht TCP?!

Das Stimmt zwar aber TCP/IP ist derübergeordnete Name für eine Protokollsammlung.

Hier mal ein Beispiel der Schichten

TCP/IP - Protokollfamiliy
- ICMP - Steuerungsprotocoll
- TCP - Verbindungsorientiert
--- SIP - Session Protokoll
- UDP - Zustanslos
--- RTP - Realtime Protokoll
- GRE - VPN
- u.s.w

RTP ist ja richtige aber TCP/IP ist die Grundlage für RTP

Daher ist diese Ausage komplett richtig


UDP oder TCP Verbindungen sind beide gleich abhörbar!!!
RTP beinhaltet Sequenznummern nicht in UDP. Das wird benötigt
damit man die AudioTeile wieder zusammen setzten kann.
UDP Pakete können in unterschiedlicher Reihenfolge eingehen
und werden erst durch RTP sortiert.

Allerdings müsste man zum Abhören auf den Gateways sitzen und dort mithören bevor der Gateway die Daten an unterschiedlichen Routern weitersenden.

Allerdings gäbe es nich eine Möglichkeit. Man könnte als SIPProxy statt eine DirectVerbindung (ReInvite) auch eine Verbindung zu einem Astersik ausbauen. Der leitet per Passthruht die Daten an dern Clienten.

Vorraussetzung ist aber das der SIP-Provider mitmacht und Schnittstellen anbietet. In einer älteren Diskussion mit Purtel scheint es für den Staat solche Schnittstellen zu geben.

 

[Scheinwelt]

Abhören .. mit einfachen Mitteln

Hallo,

der AVM-Mensch sollte wirklich mal in die RFCs schauen, und versuchen, die TCP/IP-Suite und VoIP-Protokolle zu verstehen...

und weiter oben lese ich noch SIP mit TCP...

... SIP wird übrigens generell AUCH über UDP übertragen (UDP/5060).

Am einfachsten stelle ich mir eine modifizierte Soft wie
Asterisk, die im promisc-Modus am Netz hört und wiedergibt
was der zuvor eingestellte Target sendet oder empfängt.

Wenn es das noch nicht gibt, dann aber nicht lange,
denn VoIP entwickelt sich rasend schnell.

Ich behaupte sogar, daß man mit so einer Soft eine Menge Geld verdienen kann.

glaube ich nicht: Nimm Ethereal und schreibe den RTP Stream einfach in eine Datei... Dann mit sox ein AU oder WAV-File draus machen ... fertig.

Oder nimm "rtpdump".

Oder noch besser: "rtpscan" kann als Network-Sniffer arbeiten, und schreibt jede Konversation separat automatisch mit, erzeugt von jedem Telefongespräch eine eigene WAV-Datei, die Teilnehmer sogar schön in Stereo nach Kanal getrennt... Logfile inklusive.

Und um Cisco SCCP (Skinny) anzugreifen: nimm "vomit". Dort kann man auf dem Signalisierungskanal gleich die Telefonnummer mitschreiben.

Mit ein wenig Wissen und Google und einem Linux-PC bekommst Du alles was Du brauchst...

Herzliche Grüße

Schein w e l t

 

[Maik]

Re: Abhören .. mit einfachen Mitteln

... SIP wird übrigens generell AUCH über UDP übertragen (UDP/5060).

Die SIP-Signalisierung kann ueber UDP oder TCP uebertragen werden. Nur die Audio-Daten werden generell ueber UDP uebertragen.

 

[Scheinwelt]

Re: Abhören .. mit einfachen Mitteln

... SIP wird übrigens generell AUCH über UDP übertragen (UDP/5060).

Die SIP-Signalisierung kann ueber UDP oder TCP uebertragen werden. Nur die Audio-Daten werden generell ueber UDP uebertragen.

o.k. Mit "Generell" meinte ich "üblicherweise". Schlechte Wortwahl...

Klar geht SIP auch über TCP. Aber: nutzt das irgendwer? Ich kenne nur Implementationen, die UDP benutzen.

Gruß
Schein w e l t

 

[britzelfix]

@Scheinwelt

Lesen was Maik geschrieben hat und verstehen.
ggf. auch das SIP RFC lesen.

Im Übrigen: wieso sollte ich das machen was Du vorschlägst wenn
Du selbst sagst, daß es nicht funktioniert und von dem ich
nie beahauptet habe, daß es so gehen könnte?

Gruß
britzelfix

 

[Scheinwelt]

@Scheinwelt
Im Übrigen: wieso sollte ich das machen was Du vorschlägst wenn
Du selbst sagst, daß es nicht funktioniert und von dem ich
nie beahauptet habe, daß es so gehen könnte?

Hallo Britzelfix,

ich sage nicht, dass es nicht funktionert, sondern dass ich nicht glaube, damit viel Geld verdienen zu können.

Und die Tools habe ich erwähnt, da diese eben funktionieren, und das ganze komplett passiv im Netz.

RTPScan habe ich auf Linux nach einigen Schwierigkeiten zum Laufen bekommen, da es sehr schwierig ist an die Sourcen ranzukommen (steckt sogar die G.729-Source der ITU drin, deshalb ist es wohl fast überall vom Netz genommen. Aber es läuft fast perfekt (außer der G.729-Dekodierung, da stimmen noch irgendwelche Parameter nicht, die Stimmen hören sich alle wie Micky Maus an).

Wenn ich den Rechner an mein Testnetz hänge, finde ich kurze Zeit später viele WAV-Dateien mit den Gesprächen. Ein kleiner Nachteil: die SIP-Signalisierung wird separat in ein Log geschrieben, d.h. ich muss User-Agent und WAV-Datei noch manuell zueinander zuordnen.

Getestet mit SIPgate, Nortel MCS, und Web.de.

Die Lösung existiert also und funktionert. Und mit Ethereal oder den anderen Tools habe ich schon ein Diagnoseinstrument, welches aber nicht automatisch funktionert, aber für Debugging gute Dienste leistet. Deshalb meine ich, dass Du mit einem weiteren Tool wahrscheinlich nicht viel Geld machen kannst.

Das ganze Abhören wird wohl in Zukunft -- zumindest für die Carrier -- viel einfacher. Ich bin mir sicher, dass das bei uns so wie in der Schweiz gemacht wird (nach den Anschlägen in London sicher noch schneller als gedacht): In der Schweiz müssen alle Gespräche immer über einen Mediagateway im Carriernetz, da ein Gesetz vorschreibt, dass der Staat auch VoIP-Gespräche abhören können muss. Und die Gespräche gehen immer über ein Mediagateway, da dieses Abhören von den Teilnehmern nicht bemerkt werden darf.

Also gehen die Media-Daten immer durchs Carriernetz.

Lesen was Maik geschrieben hat und verstehen.
ggf. auch das SIP RFC lesen.

Erklär's mir: Üblicherweise wird SIP über UDP gemacht. Klar geht TCP. Kennst Du SIP-Implementationen auf TCP? Ich nicht. Ansonsten verstehe ich Deinen Kommentar bezüglich RFC lesen nicht...

Herzliche Grüße

 

[britzelfix]

@Scheinwelt

ich sage nicht, dass es nicht funktionert, sondern dass ich nicht glaube, damit viel Geld verdienen zu können.

Und die Tools habe ich erwähnt, da diese eben funktionieren, und das ganze komplett passiv im Netz.

ach so.

...
die Stimmen hören sich alle wie Micky Maus an

Wenn man wav->gsm konvertiert, dann muß man auch die richtige
Samplerate einstellen.
http://www.voip-info.org/tiki-index.php?page=Convert+WAV+audio+files+for+use+in+Asterisk

Aber es ist doch schon schön zu hören, daß es doch so einfach geht.

Erklär's mir: Üblicherweise wird SIP über UDP gemacht. Klar geht TCP. Kennst Du SIP-Implementationen auf TCP? Ich nicht. Ansonsten verstehe ich Deinen Kommentar bezüglich RFC lesen nicht...

Hast Du Dir die Frage nicht jetzt selbst beantwortet?

Gruß
britzelfix

 

[britzelfix]

@Scheinwelt

und? Schon das RFC durch? Ist auch ein ziemlicher Hammer,
eines der längsten RFC's die es gibt.

Im RFC 3261 steht, daß TCP zwingend erforderlich ist.
Die meisten UA's haben noch RFC 2543 implementiert.

Eben sehe ich auch, daß der SER auch TCP kann,
wenn man es auswählt.

Gruß
britzelfix