[Frage] Fritzbox 7490: Kann man bei VoIP-Telefonaten die IP-Adressen der Gegenseite protokollieren?

[fabhoff]

Hallo,
ich bekomme mal wieder häufiger Anrufe von Leuten, die sich als Mitarbeiter von Microsoft ausgeben und letzten Endes meinen Computer fernsteuern wollen. Die Leute zeigen mir dabei immer unterschiedliche deutsche Telefonnummern an, mit denen man wahrscheinlich nichts anfangen kann.

Wenn man sich länger mit ihnen unterhält, hat man Zeit in der Fritzbox ein Capture zu starten, um den gesamten Datenstrom der Fritzbox mit dem Internet aufnehmen zu können. Aus diesen Datenströmen kann ich dann das Telefonat herausfischen und jedenfalls die Audio-Daten herauslesen, die in dem Telefonat von mir stammen (komischer Weise habe ich nie den Datenstrom finden können, der die von der Gegenseite mir gesendeten Audio-Daten enthält). Jedenfalls komme ich auf diese Weise an eine IP-Adresse heran, mit der ich dabei kommuniziert habe. Ich glaube zwar, dass diese IP-Adresse auch nur diejenige eines bots oder ähnliches ist und mich nicht wirklich die Personen identifizieren lässt, mit denen ich gesprochen habe - zumal die ihrem Akzent nach zu urteilen auch nicht in Europa zu weilen scheinen. Aber man könnte über die IP-Adresse diesen Leuten wenigstens einen bot wegnehmen, indem man die Bundesagentur Netz vielleicht tätig werden und den bot kalt stellen lässt.

Mein Problem ist nun: Ich würde gerne die IP-Adresse mit der ein VoIP-Telefonat aufgebaut wird, von Anfang von der Fritzbox protokollieren lassen, ohne den gesamten Datenstrom dauerhaft aufnehmen zu müssen. Gibt es da einen Weg, der irgend jemanden bekannt ist?

Vielen Dank im Voraus

 

[koyaanisqatsi]

Moinsen


Das Telefonat enthält die IP und die findeste...
http://fritz.box/support.lua
...in den erstellten/runtergeladenen erweiterten Supportdaten.
Das ist eine grosse Textdatei.
Such mal in dieser Datei nach: INVITE
Die echte IP steht hinter: Contact:

 

[fabhoff]

Vielen Dank, das ging ja schnell.

 

[PeterPawn]

Die Adresse steht auch im GUI: Telefonie -> Eigene Rufnummern -> Sprachübertragung

komischer Weise habe ich nie den Datenstrom finden können, der die von der Gegenseite mir gesendeten Audio-Daten enthält

Dieser Stream wird vermutlich über die Hardware-Acceleration direkt beim "voipd" abgeliefert und kommt an der Schnittstelle, wo AVM die Daten beim Paketmitschnitt abgreift, gar nicht erst vorbei. Das ändert sich allerdings auch immer mal wieder, wenn es bei AVM auffällt und man auch für diese Daten dann den Packet-Accellerator für die Dauer eines Mitschnitts deaktiviert.

Ich rate aber mal (mehr ist es also nicht, ich habe das in letzter Zeit nicht neu getestet), daß die Ursache für diese fehlenden Streams auch darin liegt, daß der Mitschnitt erst gestartet wurde, wenn ein solcher Stream schon in den Hardware-Tabellen eingerichtet war und die Deaktivierung (des Beschleunigers) sich erst auf danach eingerichtete Verbindungen auswirkt.

 

[fabhoff]

Wie die technischen Abläufe in der Fritzbox sich genau gestalten weiß ich nicht. Aber es trifft zu, dass ich die Mitschnitte immer erst gestartet habe, nach dem das Telefonat schon begonnen hat.

 

[koyaanisqatsi]

Denk daran, das die Sip Logs in den Supportdaten aus einen beschränkten Pufferspeicher kommen.
Deswegen Zeitnah erstellen, kurz nach dem Telefonat reicht aus.
2 Tage später, und es ist nicht mehr zu sehen.

Sprachübertragung
War auch mein erster Gedanke, aber wenn das Telefonat über den ITSP ( Anbieter ) kommt, ists die IPv4 oder IPv6 des ITSPs.
Das INVITE aus den Supportdaten wäre dann aussagekräftiger.
Als Beispiel nehm ich mal einen Auszug des Logs mit einem abgeschmetterten Versuch eines eingehenden SIP URI Calls, mit der Absicht weiterverbunden zu werden...

2019-08-12 16:35:20.810 - IN: my=192.168.178.1%16:5060 peer=163.172.192.210 port=49920 UDP, sipiface=none:
INVITE sip:[email protected] 2.0
Via: SIP/2.0/UDP 0.0.0.0:49920;branch=<hash>
From: <sip:009413415133:[email protected]>;tag=<hash>
To: <sip:[email protected]>
Call-ID: <hash>
CSeq: 1 INVITE
Contact: <sip:009413415133:[email protected]:49920>
Max-Forwards: 70
User-Agent: pplsip
Content-Type: application/sdp
Content-Length:   206

v=0
o=009413415133:5060 16264 18299 IN IP4 0.0.0.0
s=pplsip
c=IN IP4 0.0.0.0
t=0 0
m=audio 25282 RTP/AVP 100 6 0 8 3 18 5 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11

( Unleserliches Zeug durch <hash> ersetzt )
...bei einem misskonfigurierten Asterisk hätte er vielleicht Erfolg damit.

PS: Sowas nehm ich auch gern als Beispiel, dass nicht nur interne Anrufe nicht in der Anrufsliste auftauchen

 

[fabhoff]

Das ist der Auszug, den ich der Bundesnetzagentur geschickt habe:

2019-08-13 09:55:22.526 - IN: my=192.168.2.1%17:5060 peer=217.0.21.65 port=5060 UDP, sipiface=none:
INVITE sip:+4969######@91.5.84.156;user=phone;uniq=............................. 2.0
Via: SIP/2.0/UDP 217.0.21.65:5060;branch=........................................
Record-Route: <sip:217.0.21.65;transport=udp;lr>
From: <sip:+497506#####@dtag-gn.de;transport=udp;user=phone>;tag=....................................................................
To: "+4969######" <sip:+4969######@telekom.de;transport=udp;user=phone>
Call-ID: .....................................
CSeq: 1 INVITE
Contact: <sip:[email protected];transport=udp>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Max-Forwards: 52
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Min-Se: 900
P-Asserted-Identity: <sip:+497506#####@dtag-gn.de;transport=udp;user=phone>
Session-Expires: 1800
Supported: timer
Supported: 100rel
Supported: histinfo
Supported: 199
Session-ID: ................................
Allow: REGISTER,

(Für das Forum hier habe ich das Unleserliche mit "..." ersetzt und meine eigene Telefonnummer mit "######" überschrieben)

Ich bin mal gespannt, ob die Agentur damit etwas anfangen kann.

 

[PeterPawn]

Das INVITE aus den Supportdaten wäre dann aussagekräftiger.

Das kann man problemlos fälschen ... außerdem sollte bei den Verbindungen, wo tatsächlich die RTP-Verbindung über den Provider (und damit über irgendein Gateway bei diesem) geht, auch die SIP-Kommunikation über das Gateway beim Provider laufen (sonst weiß das auch gar nicht, welche Daten von wo nach wo verschifft werden sollen).

Wenn es tatsächlich zu "direkten Verbindungen" zwischen zwei RTP-Endpunkten kommt (das wären dann "directmedia"-Verbindungen im Asterisk), dann betrifft das eher die Audio-Verbindungen, als die SIP-Signalisierung.

Ist ja auch logisch, denn die Box als UA ist ja nur bei irgendeinem Provider registriert und die in #6 gezeigten Versuche einer direkten Verbindungsaufnahme durch irgendeinen Kasper SOLL sie abschmettern - das ist auch kein "Anruf" (und taucht daher zurecht auch in keiner Liste auf), das ist lediglich Datenmüll und ein versuchter Mißbrauch. Wenn so etwas tatsächlich noch von der Box bei jedem Versuch irgendwo (verläßlich und nicht nur in einem Ringbuffer) protokolliert würde, wäre das Faß sehr schnell am Überlaufen - solche Nachrichten treffen praktisch jeden Host mit einem offenen SIP-Port pausenlos.

Das heißt dann, daß eher die Angaben in den SIP-Headern "unzuverlässig" sind hinsichtlich der tatsächlichen Identität der Gegenstelle (bei einem stattfindenden Telefonat zumindest) ... mal abgesehen davon, daß da auch mehrere Endpunkte in einem SDP-Abschnitt eines INVITEs stehen können.

Aber die Identität einer SIP-Message läßt sich noch recht gut fälschen (bei mehreren in einem "Dialog" wird das dann auch schwerer) ... bei einer funktionierenden Audio-Verbindung "redet" man aber tatsächlich mit der Gegenstelle oder zumindest einem passenden Proxy und nicht nur mit jemandem, der sich mit falschen Absenderangaben irgendwo versteckt.

 

[fabhoff]

Ich muss gestehen, dass ich als interessierter technischer Laie nur die Hälfte von dem verstehe, was ihr als IPPF-Urgesteine schreibt. Ich will auch nicht um eine Erklärung bitten. Das wäre bestimmt sehr aufwendig und womöglich würde es mich im Ergebnis auch nicht weiterbringen, sprich etwas gegen diese Anrufer tun zu können.

Ich wüsste aber gleichwohl gerne, ob aus dem von mir oder auch in dem von koyaanisqatsi übersandten Auszug ein Datum verlässlich zu entnehmen ist, wo meine Audio-Daten während des jeweiligen Telefonats hingegangen sind und wo die Audio-Daten von dem, mit dem ich telefoniert habe, hergekommen sind. Ich gehe dabei davon aus, dass dieses Datum mir nicht den wahren Standort meiner Gegenseite verraten wird. Aber müsste daraus nicht wenigstens der Standort eine bots oder eines ähnlichen Hardware-Geräts zu entnehmen sein, das die Gegenseite genutzt hat, um seinen Standort zu verschleiern? Und wenn es so ein Datum in den Auszügen gibt, welches wäre es denn?

 

[PeterPawn]

Der Anruf kam von der Nummer 07506-48393 (irgendwo im Allgäu) und wurde über die Telekom an einen Anschluß im Vorwahlbereich von FFM (069) weitergeleitet (das dürfte Deiner sein). Angesichts des Headers "P-Asserted-Identity", der die Angaben zum Anrufer enthält, sollte die Telekom sich auch vergewissert haben, daß die angegebene Absendernummer stimmt -> siehe RFC 3325.

 

[fabhoff]

Das würde dann aber wahrscheinlich bedeuten, dass jemand einen Computer im Allgäu gekapert hat. Denn ich kann mir nicht vorstellen, dass eine Abteilung von Hackern sich ins Allgäu setzt, wobei die Hacker entweder gar kein Deutsch sprechen, das Englisch auch nur sehr radebrechend rüberkommt und soweit sie Deutsch sprechen, dieses ganz bestimmt nicht im Allgäu gelernt haben. Das wäre doch gar nicht so schlecht, wenn die Bundesnetzagentur den Anschlussinhaber im Allgäu darauf aufmerksam macht, dass etwas mit seinen am Netz hängenden Geräten vielleicht nicht stimmt.

 

[weißnix_]

Da muss nicht zwingend was "nicht stimmen" im Sinne einer forensischen Untersuchung (gekapert!?).
Eine Soft- oder Hard-PBX, welche eine anonyme Registrierung bzw. eine mit DefaultLogin von aussen zulässt dürfte so selten auch in Deutschland nicht sein.
Dem Anschlussinhaber der Absenderdaten wird man wohl keinen Strick draus drehen können. Immerhin handelt es sich möglicherweise um verbotene Computersabotage.
An meiner PBX registriere ich wechselnde Häufigkeiten von versuchten Registrierungen pro Tag.

Ist vermutlich so ähnlich, wie mit den 5 Millionen Spammails in meinem Postfach. Ob da ein forensisch nachvollziehbares Problem auf identifizierten deutschen Absendern besteht oder einfach die Zugangsdaten zu leicht zu erraten/abgphisht wurden ist mir im Endeffekt wurscht. Jegliche Mühe die ich darauf verwende ist verschwendete Lebenszeit. Vermutlich sieht das die BNetzA in Deinem Einzelfall ähnlich.

Mein Fazit: Die eigenen Systeme nach bestem Wissen (sehr begrenzt) und Gewissen absichern und die anderen sind mir egal.

 

[fabhoff]

Noch eine kurze Frage: Die Bundesnetzagentur hat mir geschrieben, dass es bei diesen Anrufen um Phishing-Angriffe handelt. Sie seien dafür nicht zuständig, weil - so die Bundesnetzagentur:

Für die vorliegende Masche werden nach hiesigen Erkenntnissen regelmäßig aufgesetzte Rufnummern verwendet. Hinsichtlich einer aufgesetzten und damit falsch angezeigten Rufnummer kann keine Abschaltung angeordnet werden, da die Anrufe tatsächlich von einem anderen Anschluss aus erfolgen. An der Fortsetzung dieser Anrufe kann auch die Abschaltung der – an den Anrufen tatsächlich – unbeteiligten bzw. einer nicht existenten Rufnummer nichts ändern.

PeterPawn hat in seinem Beitrag gesagt, dass der Anrufer mit dem Header "P-Asserted-Identity" bei mir angerufen habe. Lässt sich das dann noch mit der Annahme der Bundesnetzagentur vereinbaren, dass der Anrufer eine aufgesetzte Rufnummer verwendet habe? Oder würde es in diesem Falle doch etwas helfen, dem Inhaber des Anschlusses mitzuteilen, dass tatsächlich sein Anschluss benutzt wurde, um bei mir anzurufen?

 

[koyaanisqatsi]

Moinsen

Angesichts des Headers "P-Asserted-Identity", der die Angaben zum Anrufer enthält, sollte die Telekom sich auch vergewissert haben, daß die angegebene Absendernummer stimmt

Da würde ich ( öffentlich ) nachfragen, im Telekom hilft Forum, was sie sich dabei gedacht haben.
...da sowas eine Menge User interessiert.
Aber was ich da so lese, nach Suche auf "Phishing", lautet der Konsens wohl: "Da kann die Telekom nichts machen, wende dich an die Bundesnetzagentur"
Das erinnert mich an eines der ersten Computerspiele: Pong

 

[jodost]

Der zweite Thread ist jetzt verschwunden, während ich auf die Frage antworten wollte.

Also hier - was bedeutet das P-Asserted-Identity? In der Theorie ist das die echte Rufnummer des Anrufers. Vielleicht also ein missbrauchter Telefonanschluss.

In der Praxis kann es aber durchaus sein, dass die Angabe falsch ist. Wenn der Anruf von irgend einem anderen (womöglich ausländischen) Carrier an die DTAG übergeben wurde, kann diese der Angabe nur vertrauen, sonst nix. Sei es aus Versehen oder aus Absicht, es ist durchaus keine seltene Ausnahme mehr, dass P-Asserted-Identity Header reinkommen, die gar nicht stimmen.

Aber zumindest könnte man die Inhaberdaten dieser Rufnummer ermitteln (entweder über Deinen Carrier mit einer Anfrage zur Mitteilung ankommender Verbindungen nach 101 TKG - Fangschaltung - oder mit einer Strafanzeige wegen versuchter Computersabotage)

 

[fabhoff]

Vielen Dank. Das hilft mir weiter.

 

[KunterBunter]

Der zweite Thread ist jetzt verschwunden

Das ist ja ein Ding. Jetzt verschwinden hier schon ganze Threads.

Jetzt ist er aber wieder da.

 

[koyaanisqatsi]

Zum Glück hab ich noch ein Backup.
Einfach in meinem Post #14 beim Zitat auf den Pfeil tappen/klicken.

 

[weißnix_]

Ernsthaft? Ihr wollt gegen einen möglicherweise ahnungslosen Fritzboxbesitzer eine Strafanzeige lostreten?
Das Beispiel ist jetzt willkürlich und zielt im erweiterten Sinne auch auf andere Router/PBX mit fehlenden Sicherheitsaktualisierungen oder Fehlkonfigurationen.

Ist sicher davon auszugehen, dass es sich nicht um CallIDSpoofing handelt?

 

[RSchnauzer]

Hallo,
das Thema ist ja sehr schwer zu verstehen.
Ich bekomme im Moment mehrfach von wechselnden Lübecker Nummer die angeblichen Windows Anrufe.
Wie erklärt sich da, dass da unterschiedliche Provider angezeigt werden? Versatel.de dtag-gn.de
Hängt das vom Zufall ab über welchen Provider die Anrufe kommen, oder werden da unterschiedliche Quellen genutzt?
Kann man in der FB auch bestimmte Provider blocken, durch die wechselnden Nummern hat man keine Chance sich vor diesen Belästigungen zu schützen.
MfG Rschnauter

15.02.2021  8:14    [email protected]     >|     G.711u   125 (-)     -         0 ms     -     Secure
0:01                              217.0.134.39     <|     G.711u     2 (-)     -       138 ms     0 ms (0 %)    
15.02.2021  9:45    [email protected]      >|     G.711    125 (-)     -         0 ms     -     Secure
0:01                              217.0.134.39     <|     G.711    226 (-)     -         0 ms     0 ms (0 %)    
15.02.2021 11:06    [email protected]     >|     G.711u   351 (-)     -       350 ms     -     Secure
0:01                              217.0.134.39     <|     G.711u   136 (-)     -         3 ms     0 ms (0 %)    
15.02.2021 13:26    [email protected]     >|     G.711u   125 (-)     -         0 ms     0 ms (0 %)     Secure
0:01                              217.0.134.39     <|                0 (-)     -         0 ms     0 ms (0 %)

[Edit Novize: Nummern anonymisiert und Log in Code-Tags verpackt]