Howto: Werbeanrufe automatisch beenden lassen mit Freetz

creon

Neuer User
Mitglied seit
20 Jan 2005
Beiträge
107
Punkte für Reaktionen
2
Punkte
18
- Zuerst wird freetz aus dem Trunk heruntergeladen und konfiguriert, hierbei ist wichtig, dass der "callmonitor" mitsamt dem Webinterface, Phonebook-Support und den Actions aktiviert wird; sowie die weiter unten die Funktion Funktion "decrypt FRITZ!OS configs".

1.png 2.png


- Auf das Kompilieren von Freetz, die dabei u.U. auftretenden Probleme wie umask 0022 gehe ich hier ansonsten nicht weiter ein. Hierfür gibt es andere gute Quellen.

- Ebenso muss das fertige Image auf die Box gebracht werden. Auch hierauf gehe ich nicht weiter ein.

- Im Anschluss besuchen wir das freetz-Webinterface der Fritzbox auf Port 81, d.h. wir geben in den Browser ein:

Code:
fritz.box:81

Die Zugangsdaten sind standardmäßig admin : freetz
Einige Einstellungen können in Freetz jedoch noch nicht gesetzt werden, weil die Sicherheitsstufe hierfür nicht ausreicht. Wir müssen daher erst mit Telnet auf die Box, hierfür aktivieren wir unter System -> Dienste den telnetd-Dienst:


4.png

- Nun öffnen wir unser Telnet-Clientprogramm, hierfür empfehle ich putty und verbinden uns mit fritz.box.
Standardzugangsdaten sind hier root : freetz
Das Kennwort hier ist unabhängig von der Weboberfläche, d.h. das Kennwort ist auch dann noch freetz, wenn es für die Weboberfläche geändert wurde.
In der telnet-Umgebung werden wir nun gezwungen, das Kennwort für den Telnet-Zugang zu ändern. Das machen wir. Im Anschluss passen wir mit den folgenden beiden Befehlen die Sicherheitsstufe an:

Code:
echo 0 > /tmp/flash/mod/security
modsave all

Nun legen wir noch das Skript an, welches eingehende Anrufe auf den Tellow-Score prüft. Das geht am besten mit cat.
Wir schreiben

Code:
cat > /var/media/ftp/calllog

Nun fügen wir folgenes Skript ein und beenden den Vorgang im Anschluss mit STRG + C. Einfügen funktioniert in Putty z.b. mit einem Rechtsklick. Also cat > ... , dann rechtsklick um das in der Zwischenablage befindliche Skript einzufügen, dann STRG + C drücken.

Bitte die eigene Vorwahl anpassen, sofern man diese bzgl. der Durchsuchung auf Tellow ausnehmen möchte.

Skript:
Code:
#!/bin/sh

VORWAHL=0221

# Variablen für Rückruf etc. bereinigen
FROM=`echo $SOURCE | sed -e 's/^0049/0/'`

# Wenn Rufnummer übertragen wurde...
if [ "$SOURCE" ]; then
   # ... aber Telefonnummer nicht im Telefonbuch vorhanden...
   if [ ! "$SOURCE_NAME" ]; then
      # ... und nicht aus dem eigenen Vorwahlbereich ...
      if [ ${FROM:0:${#VORWAHL}} -ne $VORWAHL ]; then
         # erfrage Tellow Score und lege auf bei Score > 6
         score=`wget -qO- http://www.tellows.de/basic/num/$FROM`
         score=`echo $score | sed -n -e 's/.*<span id="score">\([0-9]\)<\/span>.*/\1/p'`
         if [ $score -ge "7" ]; then
            echo Tellow Score groesser 6! Beende Anruf ...
            echo "ATP51 ATD*09 ATH0 ATP1 ATD*09 ATH0 ATP51 ATD*09 ATH0 ATP1 ATD*09 ATH0 ATP51 ATD*09 ATH0 ATP1 ATD*09 ATH0 ATP51 ATD*09 ATH0 ATP1 ATD*09 ATH0 ATP51 ATD*09 ATH0 ATP1 ATD*09 ATH0" | nc 127.0.0.1 1011
         fi
      fi
   fi
fi
Nun müssen wir das Skript als Ausführbar markieren mit
Code:
chmod +x /var/media/ftp/calllog

9.png


Jetzt können wir die Telnet-Konsole (d.h. Putty) wieder verlassen, indem wir das Fenster schließen.

- Nun wechseln wir wieder in die Weboberfläche und besuchen nun den Unterpunkt Callmonitor. In den Einstellungen setzen wir den Starttyp auf automatisch. Das Fritzbox-Telefonbuch benötigen wir, um beim Vorhandensein im Telefonbuch das Skript abzubrechen, denn genau dann handelt es sich nicht um einen Werbeanruf.

0.png


- Dann geben wir unter Regeln eine einzige Regel ein, die für alle eingehenden Anrufe beim ersten Klingeln greift und unter Skript aufruft. Was macht das Skript? Es nutzt die übertragene Rufnummer um den Tellow-Score der Nummer herauszufinden. Sofern dieser 7 oder größer ist, wird der Anruf abgebrochen, indem viele "Anruf annehmen und Auflegen" Befehle an den internen Telefon-Dämon geschickt werden. Bei meiner 7270v3 haben wenige dieser Befehle gereicht, seit der 7390 muss ich das ganze mehrmals in Folge machen.

Code:
in:request ^ ^ /var/media/ftp/calllog

6.png

- Nun können wir die Rufnummer testen: Hierfür simuliere ich zuerst einen Telefonanruf von der Telekom unter der 08003301000. Wir sehen nur, dass das Skript augeführt wird.

a.png


- Nun testen wir nochmal, diesmal von einer als Aggressiv eingestufen Nummer, man findet eine solche, indem man in Google nach Tellow und Aggressiv schaut, u.a. 030322951891
Im Skript sehen wir hier dann, dass ganz viele "OK" Befehle als Rückgabe vom internen Telefon-Dämon zurückkommen, weil wir ihn mit "Auflegen"-Datenpaketen zugebombt haben. Es klingelt bei mir immer für ca. 0,5 Sekunden, dann ist das Telefonat weg.

Mein eigenes Tischtelefon klemmt am FON2, durch den obigen Befehl sieht man dann einen angenommenen Anruf an FON1. Dieser heißt bei mir "Spam-Catcher".

b.png


//edit stoney: von Voll- zu Minaturansicht geändert
 
Zuletzt bearbeitet:
Ebenso muss das fertige Image mit dem rukernel-Tool auf die Box gebraucht werden. Auch hierauf gehe ich nicht weiter ein.
Ich gehe dann mal noch darauf ein, damit da niemand in die Irre geführt wird ... das ruKernelTool würde auch nur für die hier verwendete 7390 (und andere NOR-Boxen) funktionieren.

Das ist aber nicht spezifisch für das Thema hier ... die Installation einer fremden Firmware bei einer FRITZ!Box kann auf verschiedensten Wegen erfolgen und die Verwendung des ruKernelTool ist da nur ein sehr spezieller, der obendrein nur für diese alten Möhren (7390 und früher bzw. die "Nebenlinien", deren Bootloader direkt in den Flash schreiben kann) auch wirklich funktioniert.

Wer eines der neueren Modelle mit VR9- oder GRX5-Prozessor verwendet, wird mit dem ruKernelTool jedenfalls (bei den meisten Modellen, die 7360 könnte eine Ausnahme bilden) Schiffbruch erleiden.
 
Zuletzt bearbeitet:
Peter! Es fehlt ein Link zur Lösung ;)
 
Es gibt so viele ... das habe ich ja erwähnt.

Ich gehe auch nicht so weit, den einen speziellen, von mir gerne aufgezeigten Weg, den man mit den Skripten aus "eva_tools" in meinem GitHub-Repository nehmen kann (die gibt es da ja sowohl für Linux als auch für Windows-Systeme) als den alleine seligmachenden anzusehen ... er mag eine Möglichkeit sein, aber wer das Prinzip verstanden hat (das ist viel wichtiger als irgendeine vorbereitete Lösung), der kann sich sogar mit dem Taschenrechner und einem normalen FTP-Client mit passiven Transfers helfen.

Nicht umsonst betone ich immer wieder, daß die Zusammenhänge das eigentliche "Lernziel" sind und nicht das stumpfe Abtippen irgendwelcher Anleitungen. Will man diese Zusammenhänge aber vermitteln, braucht das zwangsläufig ein paar Zeilen mehr als irgendeine "Liste" zum Abhaken und ich habe zwar auch dazu entsprechende Beschreibungen und Erläuterungen geliefert an verschiedenen Stellen, aber das Verlinken auf diese spare ich mir auch schon deshalb, weil es einigen "nicht kurz genug" ist (wie man auch immer wieder lesen kann).

Ich habe halt die Hoffnung, daß die eigene investierte Zeit und Mühe bei der Suche nach diesen Beiträgen ihrerseits einen Anteil daran hat, daß man die dabei gefundenen Stellen dann doch etwas gründlicher liest als bei irgendeinem anderen Vorgehen, wo einem diese Stellen nur noch "vorgesetzt" werden.
 
Als ich in der Übersicht sah, daß Peter hier geantwortet hatte, dachte ich er geht (auch) auf den Datenschutz ein.
Dann möchte ich mal ein großes VORSICHT hier anmerken!
Es sollte sich jeder genau Überlegen was er damit anstellt.

Es gibt ja noch ein ähnliches Thema:
https://www.ip-phone-forum.de/threads/callog-gespräch-mit-schlechtem-tellow-score-beenden.296114/

Danach hatte ich die Tellows-Abfrage bei mir testweise auch mal eingebaut, aber nur zum Anzeigen.
Dabei wurde mir sofort klar, daß ja mit diesem Script jeder Anruf an Tellows "gemeldet" wird.
Damit erhält Tellows ja eine komplette Anrufliste von dir, da du ja immer mit der gleichen IP anfragst.
Aber auch eine Liste deiner Freunde und Verwanden, wann die dich anrufen.
Wenn dir der Datenschutz vielleicht egal ist, aber die anderen hast du bestimmt nicht gefragt.

Und da die Abfrage ungeschützt mit http erfolgt kommen noch ganz andere an die Daten ran.

IMO müßte das Script wenigstens noch einige Erweiterungen erhalten, bevor man es einsetzen kann.
Ich z.B. hatte dann noch Bedingungen davor gesetzt, so daß Handynummern, Nummern aus der eigenen Region und Nummern von Freunden/Bekannten/Verwanden nicht abgefragt werden.
Als 2. sollte IMO, so ähnlich wie es bei der Rückwärtssuche gemacht wird, die Scorewerte für jede Nummer zwischenspeichert werden, um sie nicht jedesmal aufs neue abzufragen.
und 3. werden z.Z. sogar Anfragen ohne Nummer gestellt, was unterbleiben sollte.

So kann man das Internet und seinen eigenen Anschluß auch sinnlos auslasten und persönliche Daten ins WWW verstreuen.
 
Zuletzt bearbeitet:
Das ist doch mal richtig schöne Arbeitsteilung und so muß nicht immer ich als "Spielverderber" dastehen. :D

An anderer Stelle (bei der Anzeige des Ortsnetzes durch neuere Firmware-Versionen) hatten wir das Für und Wider solcher Online-Abfragen letztens erst zur Genüge durchgekaut (wobei AVM ja glücklicherweise keinen Online-Service verwendet) ... ich persönlich würde Tellows tatsächlich auch nur dann abfragen, wenn die Nummer nicht über das eigene Telefonbuch bereits aufgelöst werden konnte.

Auch "vermisse" ich in der Vorgehensweise in #1 noch den Hinweis, daß man dabei dann natürlich die Annahme von Anrufen ohne Absender-Rufnummer gleich komplett abschalten sollte in "Rufbehandlung" - dafür bringt ja dann auch eine Tellows-Abfrage nichts und die Abfrage bei deren Webserver würde ohnehin nur offenlegen, daß der Absender des Requests mal wieder angerufen wurde.

Auch andere "Kleinigkeiten" (man kann die Sicherheitseinstellungen des Freetz-Images ja bereits beim "make" anpassen und muß "/tmp/flash/mod/security" nicht erst nachträglich noch ändern) sind in #1 nicht aus allen Blickwinkeln beleuchtet ... das ist aber auch gar nicht notwendig, denn da sollen allem Anschein nach ja Arbeitsschritte aufgezählt werden (dann braucht es auch keine Alternativen) und nicht alle möglichen Fallstricke und Lösungsmöglichkeiten aufgezeigt werden - obwohl auch an einigen Punkten die Hintergründe gestreift werden (z.B. beim "getrennten" Kennwort).

Da wäre es also recht kleinlich gewesen, gleich wieder mit einer Aufzählung aller "Kritikpunkte" zu starten ... beim Verweis auf das "ruKernelTool" konnte ich es mir nur deshalb wieder nicht verkneifen, weil es immer wieder Leute gibt, die auch auf die aktuellen Modelle mit dem ruKernelTool losgehen wollen - was ja bekanntlich (zumindest nach meinem Kenntnisstand) nicht funktioniert.
 
Auch andere "Kleinigkeiten" (man kann die Sicherheitseinstellungen des Freetz-Images ja bereits beim "make" anpassen und muß "/tmp/flash/mod/security" nicht erst nachträglich noch ändern) sind in #1 nicht aus allen Blickwinkeln beleuchtet ...

Bzgl. Arbeitsteilung, darauf (Sicherheitseinstellung Freetz-Image) hätte ich dann eingehen können... ;) Hatte den Text schon fertig habe es mir dann aber doch verkniffen weil es eben nicht das einzige war was mir an #1 missfiel und ich auch nicht gleich wieder als Miesepeter dastehen wollte. Da das aber nun andere übernommen hatten war dieser Punkt noch offen und hätte das daher dann doch noch erwähnt. ;)


BTW:
Ich würde auch bei einer solch alten Boxen wie der 7390 nicht mit dem ruKernelTool arbeiten (aus mehreren Gründen, u.a. auch weil es unnötigerweise die Variable "my_ipaddress" verändert was später wieder für andere Probleme sorgen könnte) um die Firmware darauf aufzuspielen.
Verrückterweise bringt Freetz mit "push_firmware" bereits ein Script mit um damit die Firmware per Bootloader auf die "alten Möhren" von AVM aufzuspielen. Warum man daher ursprünglich in #1 (ist ja mittlerweile editiert von daher ist es eigentlich auch nicht nett von mir, dass ich darauf weiter "herumreite") gleich das Wort "muss" i.V.m. dem ruKernelTool in Verbindung brachte stoß mir aber dann doch schon sehr sauer auf.
Aber gut, lassen wir das. Ich hoffe nur die Kritik wird nicht falsch verstanden sondern der Ersteller dieser Anleitung berücksichtigt das um die Anleitung weiter zu verbessern.
 
- Der "ähnliche Thread" ist von mir und war von meiner 7270v3, damals noch ohne Freetz. Mit dem Callmonitor ist man nicht mehr auf eine Fritzbox beschränkt, daher hab ich meine eigene Umsetzung nochmal gepostet. Offensichtlich muss ich mich ja dafür noch hier entschuldigen, MiesePeterPawn.

- Die Abfrage ohne Rufnummer zu unterlassen ist in meinem eigenen Skript gegeben, das hab ich aber gekürzt, weil es am Ende noch eine E-Mail versendet. Ich habs nachgepflegt.
- Das Abbrechen von Anrufen ohne Rufnummer kann man auch als Rufsperre einrichten. Das ist in meinen Augen sinnvoller dort gemacht als hier über das Skript. Darüber hinaus sind Werbeanrufe von unterdrückter Rufnummer verboten und traten bei mir, der ich häufiger von Werbeanrufen geplagt wurde, auch seit dieser Gesetzesänderung nicht mehr auf. Ich halte diese Art von Rufsperren daher für sinnfrei. Von gefälschten Nummern durchaus, aber die wiederrum tauchen mit hoher Wahrscheinlichkeit auch in Tellow auf.

- Die Abfrage nur, wenn die Nummer nicht im Telefonbuch gefunden wird ist gut. Vielen Dank für das Feedback an der Stelle.
- Handynummern auszunehmen ist unsinnig, weil sich auch hinter diesen Werbeanrufe verstecken können, das habe ich mehrfach selbst erlebt. Die Nummern sind natürlich gefälscht, aber das ändert ja nichts.
- Ich finde den Vorschlag, die Tellow Abfragen zu minimieren aber dennoch sehr sinnvoll, insbesondere trifft zumindest bei mir zu, dass ich > 50% aller Anrufe von meiner eigenen Vorwahl erhalte und diese tatsächlich nie betroffen ist.

- Aus datenschutzrechtlichen Gründen ist der Einsatz dieses Tools von nicht-Verbrauchern tatsächlich vermutlich verboten, da keine Einwilligung zur Übermittlung vom Betroffenen (Anrufer) vorliegt, und sich die Nutzung auch nicht aus einem Rechtsgeschäft ergibt. Das ganze ist aber natürlich auch eher für Privatleute gedacht. Darüber hinaus muss die Abwägung der Datenschutzbeauftragte der jeweiligen Firma entscheiden. Ich – zertifizierter Datenschutzbeauftragter – würde das jedoch abnicken, weil die Schutzstufe der Daten sehr gering ist.
 
Zuletzt bearbeitet:
Offensichtlich muss ich mich ja dafür noch hier entschuldigen, MiesePeterPawn.
Du mußt Dich für gar nichts entschuldigen (und im Kontext "ähnlicher Thread" verstehe ich nicht mal, warum Du mich hier ansprichst oder war das noch einmal anders gedacht und eine "verunglückte" Verquickung meines Nicknames mit einem anderen Adressaten?) ... außer für das "beleidigte Leberwurst"-Spielen (wenn das so sein sollte - irgendwie werde ich aus Deinen Texten nicht so richtig schlau), wenn jemand etwas richtigstellt, was ihm als Ungenauigkeit aufgefallen ist oder wenn jemand Dich auf "Datenschutzsünden" hinweist (die man auch kaum wegdiskutieren kann).

Und der Punkt mit dem ruKernelTool war eben so "richtig falsch", wenn er so unpräzise niedergeschrieben wird, wie das bei Dir der Fall war ... man konnte zwar indirekt anhand des in den Screenshots ersichtlichen Modells (und mit Zusatzinformationen aus anderen Threads, die aber weitere Benutzer keinesfalls zwangsläufig auch kennen müssen) darauf schließen, daß es hier um eine 7390 geht und dabei funktioniert das ruKernelTool tatsächlich noch, aber das ist dann auch schon fast das letzte Modell in dieser "Ahnenreihe" (mit Ausnahme der 7360, die dann noch mit VR9-Prozessor und NOR-Flash für das System daherkam) der Boxen mit ARx- oder Vx18x-Prozessor, bei denen das ruKernelTool etwas bewirken kann. Auf die ausdrückliche Benennung des Modells hast Du jedenfalls verzichtet ... im Kontext des "callmonitors" ist das auch tatsächlich unnötig, weil der sich weitgehend identisch verhält über die verschiedenen Modelle.

Wenn Du allerdings in Zukunft die Nachfragen von anderen Lesern beantwortest, die mit dem ruKernelTool an ihrer 74xx- oder 75xx-Box scheitern (die 7570 bereut AVM hoffentlich selbst inzwischen als "Ausrutscher" in der Nomenklatur), dann verzichte ich künftig nach Deinen Beiträgen auch auf solche Bemerkungen, wie ich sie in #2 für notwendig hielt.

Der Rest (nach #2) war meinerseits nur noch "Konversation" mit den jeweiligen anderen Teilnehmern ... und mit dem Aufzählen von (zumindest möglichen und plausiblen) Kritikpunkten hatte ich selbst noch gar nicht richtig begonnen - da wußte ich ja auch noch nicht, daß Du ein zertifizierter Datenschutzbeauftragter bist; das macht dann aus einem "Lapsus" ja fast eine "Verfehlung", wenn man sich darauf verlassen will, daß die Leute auch gemäß ihrer Qualifikation handeln.

Der Datenschutz-Gesichtspunkt trifft hier nänlich auch wieder deutlich weniger auf den Anrufer zu (das war in der anderen Diskussion auch schon so, auch wenn man sogar diesen nicht vollkommen ausklammern kann bei einer Betrachtung), sondern auf den Anschluß (und natürlich seine Benutzer), an dem das Skript am Ende laufen soll.

Denn selbstverständlich kann man dann bei Tellows auch eine Liste aller Anrufer an diesem Anschluß (basierend auf der IP-Adresse einer Abfrage, solange nicht parallel Maßnahmen zu deren Verschleierung oder Austausch/Erneuerung getroffen werden) ermitteln (was wieder nicht für alle Gespräche des Anrufers gilt - deshalb ist der hier auch weniger der Betroffene), wenn jede eingehende Rufnummer über den Online-Service abgefragt wird und auch der Einwand von @eisbaerin, daß man das eher nicht über eine unverschlüsselte Verbindung machen sollte (solange es auch anders machbar ist), ist ja schlecht von der Hand zu weisen - ebenso die Aufzählung der anderen Schwachpunkte in #5.

Für den Datenschutz spielt es auch keine Rolle, ob man das bei Tellows nun ausführlich protokolliert oder nicht ... beim Fernmeldegeheimnis nach GG und TKG (§ 88) sind auch die "näheren Umstände" der Kommunikation geschützt und das unterliegt gar nicht der Wertung durch einen Datenschutzbeauftragten (zertifiziert oder nicht). Insofern ist das auch mit der Unterscheidung zwischen "Privatleuten" und "Firmen" recht dünnes Eis, denn ich wüßte jetzt nicht (lasse mich aber gerne dahingehend informieren von Dir), wo die gesetzlichen Bestimmungen beim Fernmeldegeheimnis da einen Unterschied machen.

Für einen zertifizierten Datenschutzbeauftragten hast Du dem Thema dann aber tatsächlich erstaunlich wenig Aufmerksamkeit gewidmet ... dann solltest Du ja eigentlich wissen, daß man so eine Lösung auch nur dann betreiben dürfte (auch im Privathaushalt), wenn alle geschäftsfähigen Mitbenutzer des Anschlusses - in Kenntnis der Tatsache, daß die Rufnummer jedes (nicht-anonymen) Anrufers an einen Dritten übermittelt wird - dieser Übermittlung auch zugestimmt haben.

Das hätte dann (gerade in Anbetracht Deiner Zusatzqualifikation, von der wir ja auch erst später erfahren haben) nach meiner Ansicht tatsächlich auch in die (beiden) Startbeiträge in den Threads gehört - ebenso wäre dann (wieder nur aus einer übersteigerten Erwartungshaltung heraus) zumindest bei der Freetz-basierten Lösung in diesem Thread die Übermittlung der Daten (deren Bedeutung einem zertifizierten Datenschutzbeauftragten eigentlich geläufig sein müßte) über eine TLS-Verbindung (die Tellows-Seite ist problemlos auch über HTTPS zu erreichen) eine Art "Mindeststandard" gewesen, damit nicht noch jeder andere auf dem Weg vom Inhalt der Daten Kenntnis erlangen kann. Das ist auch - angesichts der angebotenen Pakete in Freetz - kein Problem ... man kann sowohl das "wget" mit TLS-Support bauen lassen als auch explizit mittels OpenSSL (mit dem CLI-Tool und "s_client") eine TLS-Verbindung aufbauen oder auch mit "stunnel" arbeiten oder bestimmt noch mit vielen anderen Lösungen.

Fazit: Das Fernmeldegeheimnis umfaßt nicht nur den eigentlichen Inhalt der Kommunikation (auch der Mitschnitt eines Telefonats erfordert die Zustimmung des anderen Teilnehmers, sogar dann, wenn das ein belästigender Werbeanruf sein sollte), sondern auch die dabei anfallenden "Verkehrsdaten" - insofern ist der (obendrein automatisierte) Datenaustausch auf diesem Gebiet noch einmal "sensibler" als bei der Übermittlung irgendwelcher anderer Daten (wie Vor- und Nachname, um mal ein Beispiel zu nennen) - mal ganz abgesehen davon, daß eine Telefonnummer auch eine Person noch deutlich genauer identifizieren kann, als das ein Name (ohne Geburtsdatum/-ort oder Anschrift) macht. "Mathilde Müller" ist (trotz des seltenen Namens - und da meine ich den Vornamen inkl. Schreibweise) erheblich weniger eindeutig als "die Inhaberin der Rufnummer 0151-12345678".
 
Zuletzt bearbeitet:
Wenn Du allerdings in Zukunft die Nachfragen von anderen Lesern beantwortest, die mit dem ruKernelTool an ihrer 74xx- oder 75xx-Box scheitern (die 7570 bereut AVM hoffentlich selbst inzwischen als "Ausrutscher" in der Nomenklatur), dann verzichte ich künftig nach Deinen Beiträgen auch auf solche Bemerkungen, wie ich sie in #2 für notwendig hielt.

PeterPanwn meinst du wirklich die 7570, die ich gerade bei AVM nicht unter Produkte gefunden habe. Oder Tippfehler. Sorry das ich gerade hier störe.;)
 
Habe ich einen Schreck bekommen, dachte schon du meintest vielleicht die
7580. Jetzt aber keine Störung mehr von mir hier in diesem Threads.
 
Hallo Peter,

du hängst dich ja verdammt an diesem Datenschutzthema auf.
Ich verstehe den Grund hierfür nicht, ganz ehrlich.

Ich bin äußerst genervt durch diese Werbeanrufe und empfinde die persönliche Störung des Alltagsablaufes und die Gefahren bei erfolgreichem Gesprächsaufbau (Telefonat mit Mitarbeitern, die darin geschult sind, mich zu betrügen) als viel schlimmer als die Übermittlung von Rufnummern durch eine Abfrage.

Das Fernmeldegeheimnis spielt hier gar keine Rolle, da ich – zumindest als Privatperson – regelmäßig kein Dienstanbieter bin. Nach TKG §88 sind ausdrücklich nur Diensteanbieter zur Wahrung des Fernmeldegeheimnisses verpflichtet. Bitte verwechsel hier nicht den Diensteanbieter nach TMG §2 und den Diensteanbieter nach TKG §3 Abs. 6:

"Diensteanbieter" jeder, der ganz oder teilweise geschäftsmäßig
a)Telekommunikationsdienste erbringt oder
b)an der Erbringung solcher Dienste mitwirkt"

Siehe Hierzu http://openjur.de/u/872845.html -> Nicht einmal der Arbeitgeber ist Diensteanbieter. Diensteanbieter ist ein kommerzieller Anbieter von Telekommunikationsdienstleistungen. Er unterliegt i.d.R. auch der Meldepflicht nach TKG §6.
Weiterhin interessant, was die Bundesnetzagentur selbst über die Meldepflicht sagt:
https://www.bundesnetzagentur.de/DE...pflichten/Meldepflicht/meldepflicht-node.html

"Diese Amtsblattmitteilung dient der Klarstellung der Meldepflicht im Anwendungsbereich des "gewerblichen Erbringens" öffentlich zugänglicher Telekommunikationsdienste. Thematisiert werden Dienste, bei denen der "Anbieter" nur Mitwirkender ist und nicht selbst Erbringer am Beispiel von Callshops, Internetcafés, Hotels/Restaurants mit WLAN-Angebot. Das gewerbliche Betreiben von öffentlichen Telekommunikationsnetzen ist davon nicht erfasst. Gewerbliche Betreiber von öffentlichen Telekommunikationsnetzen sind unter den gesetzlichen Voraussetzungen ohne Ausnahme immer meldepflichtig.

Das TKG unterscheidet bei dem Begriff des "Diensteanbieters" nach § 3 Nr. 6 TKG zwischen dem

  1. Erbringen von Telekommunikationsdiensten und
  2. einer Mitwirkung an der Erbringung solcher Dienste.

Maßgebend für eine Einordnung der Telekommunikationsdienste unter die Meldepflicht ist nach dem Gesetzeswortlaut des § 6 Absatz 1 Satz 1 TKG 2. Alternative TKG, dass jemand "gewerblich öffentlich zugängliche Telekommunikationsdienste erbringt", also nicht nur an deren Erbringung mitwirkt."


Die von mir übertragenen Rufnummern sind nicht selten öffentlich einsehbar, weil sie im Telefonbuch stehen. Für Tellows ist auch nicht ersichtlich, ob es sich um einen Rufaufbau handelt, oder um eine Abfrage, die gar nicht mit einem bestimmten Telefonat in Verbindung steht. Generell wäre die Schutzstufe einer solchen Nummer ohne Kontext in Schutzstufe A oder B einzugliedern (vgl. http://www.lfd.niedersachsen.de/download/52033). Ich sehe nur einen der beteiligten Anrufer, sowie eine IP-Adresse, die täglich wechselt. Ein großes Metadatenkonstrukt lässt sich hieraus also nur schwer aufbauen.

TLS ist schön. Das ist ein berechtigter Kritikpunkt. Da die Verbindung von meiner Fritzbox via Telefonkabel erfolgt und personenbezogene Daten nur der Schutzstufe A oder B unterliegen und zum sammeln nennenswerter Daten das einmalige (kurzfristige) Mitsniffen nicht ausreicht, halte ich den Verzicht auf TLS für ... na ja, vertretbar. Bedenke: Auf meiner Fritzbox, d.h. in meinem Netz, sind die Daten ohnehin zu finden. Es geht demnach eigentlich nur darum, was bei Tellows oder auf dem Weg verloren geht.

Die DSGVO sieht vor:
- DSGVO Artikel 32 Abs 2: Bei der Beurteilung des angemessenen Schutzniveaus sind insbesondere die Risiken zu berücksichtigen, die mit der Verarbeitung [...] verbunden sind.

Beschreibe mir jetzt bitte das GAU Szenario, welches auftreten kann, wenn sich herausstellt, dass ein böser Amerikaner hinter tellows steckt. Und nicht nur irgendeiner, sondern dein schlimmster Feind. Beschreibe in 3 Sätzen, was dieser jetzt gegen dich in der Hand hat.


Weiterhin:
- Privacy by Default: T-Systeme sollen datenschutzfreundlich voreingestellt sein, so dass nur die personenbezogenen Daten verarbeitet werden, die für den verfolgten Zweck erforderlich sind.

TLS, ok, gut. Ist sinnvoll. Aber gerade eine Zwischenspeicherung der Ergebnisse ist hier in meinen Augen problematischer als das erneute Anfragen. Sinnvoll ist u.U. die Speicherung der problematischen Nummern. Denn gerade hier möchte ich ja auch beim nächsten Anruf, dass sie nicht mehr durchkommt.


Der Betroffene wird von dir fälschlicherweise als der Betreiber der Telefonanlage angegeben.
Das ist nicht der Fall, weil an tellows lediglich die Informationen des Anrufers weitergegeben werden, nicht die Destination-Number. Betroffener ist daher ausschließlich der Anrufer.

Solltest du weiterhin der Meinung sein, dass Datenschutz dir hier in diesem Skript zu klein geschrieben wird, dann würde ich dich bitten, dich lieber folgenden Themen zu widmen.
- Übertragung des gesamten Adressbuches und Chatverläufe nebst Inhalten von Messenger-Diensten an amerikanische IT Konzerne (tellows ist Deutsch); die Übermittlung in die USA ist aufgrund der fehlenden Datenschutzstandards nicht gestattet.
- Den Weiterverkauf von gültigen Adressdaten der Tochterfirma der Deutschen Post: "Post Direkt" zum Zwecke von Infobriefen ("An alle Haushalte"). Ist mit deutschem Datenschutzrecht ebenfalls nicht vereinbar. Wird trotzdem so gemacht.
- Die Protokollierung und den Verkauf von anonymisierten Positions- und Geschwindigkeitsvektordaten durch die Mobilfunkprovider zum Zwecke der Verkehrsinformationserstellung. Da die Daten mitsamt einer Uhrzeit erfolgen, sind sie prinzipiell nie vollständig anonymisierbar, weil sie immer mit etwas Aufwand einem Fahrzeug o.ä. zuortbar sind. "etwas Aufwand" bedeutet ungefähr der, den tellow hat, um meine Daten zu einem Telefonprotokoll zusammenzufügen.

Solltest du mit deiner Argumentationsweite mal ernsthaft die Position eine Datenschützers einnehmen... du würdest sehr schnell den gesamten Betrieb an die Wand fahren. Datenschutz darf den Betrieb nicht lahmlegen, er soll die Kunden schützen. Natürlich macht es einen Unterschied, ob ich Patientennamen in ein HIV-Register eintrage oder eine Telefonnummer mit einer Blacklist abgleiche. Hier beides gleichzustellen ist völlig unsinnig.
 
Zuletzt bearbeitet:
sowie eine IP-Adresse, die täglich wechselt.
Das mag in Deinem konkreten Fall so sein ... aber das Skript hast Du ja offenbar nicht nur für Dich erstellt, oder? Als persönliche Gedankenstütze ist das IPPF ja nun eher nicht geeignet - da fehlt die "Privatheit".

Es ist eben gerade nicht sichergestellt, daß der "Nachnutzer" auch täglich wechselnde IP-Adressen hat (bei Vodafone kriege ich am Kabelanschluß seit ca. 1 Jahr immer denselben IPv6-Präfix und suche krampfhaft nach einer Möglichkeit, das zu ändern - irgendwo gibt es einen Thread dazu) und dann eröffnet die (zugegebenermaßen unqualifizierte) Nachnutzung des Skripts einem Dritten die Möglichkeit einer Datensammlung.

Solange die Betroffenen zustimmen, ist das auch alles kein Problem (die Abfrage an sich) ... es wird erst dann zu einem, wenn es ohne deren Kenntnis und Einverständnis erfolgt - da sind wir uns doch vermutlich einig, oder? Die hier stattfindende Abfrage bei einem Dritten würde ich unter diesen Umständen deutlich im Konflikt zum §99 (1) TKG sehen ... zwar wird dort ausdrücklich nur auf ausgehende Verbindungen verwiesen (bzw. eigentlich auf "entgeltpflichtig", wobei im Zeitalter der Flatrates und aus der Mode gekommener R-Gespräche das wohl ohnehin nur noch sehr wenige Verbindungen betrifft), dabei aber deutlich ausgeführt, daß der Anschlußbetreiber die Mitbenutzer
[...] unverzüglich darüber informieren wird, dass ihm die Verkehrsdaten [ zur Erteilung des Nachweises ] bekannt gegeben werden.
Zu den Verkehrsdaten dürfte auch die Information über eingehende Verbindungen gehören ... auch wenn die in einem EVN nicht auftauchen werden.

Hier meine ich mit "Betroffene" also noch einmal die Mitbenutzer am Telefonanschluß (der Anrufer interessiert mich nur am Rande, der hätte mit der Unterdrückung seiner Rufnummer eine eigene Schutzmöglichkeit) ... es mag ja sein, daß solche Mitbenutzer bei Dir gar nicht existieren oder "nicht geschäftsfähig" sind (z.B. minderjährige Kinder, wobei das jetzt auch nur als Analogie/Beispiel zu verstehen ist, denn auch beim Persönlichkeitsschutz hätten Kinder eigene Rechte), aber auch das wird nicht für alle Nachnutzer Deines Skripts gelten. Insofern sehe ich auch nicht den Betreiber der Telefonanlage als Betroffenen (bzw. er stimmt mit der Einrichtung so eines Automatismus ja für sich selbst zu), sondern die anderen Anschlußbenutzer - hier irrst Du also mit Deiner "Zuordnung", wen ich als betroffen ansehe.

Der "Betreiber" wird hier u.U. auch zum "Dienstanbieter" für die anderen Teilnehmer, wenn er sie darüber telefonieren läßt (auch ein Arbeitgeber ist eher selten ein Dienstanbieter, darf trotzdem nicht ohne weiteres alles aufzeichnen) - aber mein Verweis auf GG und TKG hatte eigentlich auch nur den Zweck, noch einmal zu verdeutlichen, daß es hier sogar um ausdrücklich formulierte "Grundrechte" geht (das Recht auf Datenschutz wurde ja vom BVerfG mehr oder weniger "nur" aus Art. 1 und 2 GG abgeleitet bzw. eigentlich ja aus dem APR) und um etwas mehr als den reinen Datenschutz nach BDSG (für "Datensammlungen" und deren Verarbeitung). Vielleicht hätte ich nicht so einfach "Datenschutz" und "Fernmeldegeheimnis" in einem Satz erwähnen sollen ... die Bestimmungen aus dem BDSG greifen eben erst nach dem Ende der Verbindung (eine kleine, aber feine Unterscheidung, mit der ja u.a. auch andere Regeln bei der Durchsuchung von Datenbeständen (nach ZPO und anderen Gesetzen) begründet werden).

Ich verstehe auch nicht, warum Du immer wieder bei Deinen Begründungen ausdrücklich darauf verweist, wie es bei Dir konkret aussieht ... diese Umstände hast Du weder bisher im Einzelnen geschildert (so daß ein Dritter beurteilen kann, ob seine Situation mit der Deinen vergleichbar ist), noch hast Du die Nachnutzer Deiner Lösung darauf aufmerksam gemacht. Schon der Einsatz einer FRITZ!Box mit Deiner Lösung in einem Studentenwohnheim mit Ethernet- und Telefonanschluß oder in einer WG, wäre ein - relativ leicht zu findendes - Beispiel dafür, wo eine Übertragung der Rufnummer des A-Teilnehmers bei einem eingehenden Anruf ohne Sicherung auf dem Transportweg zum "Datensammeln" verwendet werden könnte.

Es geht ja auch darum, solchen "Fehlgriffen" (und ich halte das tatsächlich für einen, wenn man so etwas für andere erstellt - macht man es sehenden Auges, sollte man das auch ausdrücklich erwähnen und davor warnen, weil die eigene Entscheidung nicht automatisch auch für andere gelten muß) vorzubeugen bzw. sie aufzuzeigen und zu einer besseren Lösung zu finden (Art. 25 DSGVO) - da kann mich die Argumentation: "Bei mir ist das kein Problem." oder gar: "Es gibt doch viel schlimmere Verstöße." irgendwie nicht vom Hocker hauen. Daß auch die Rückwärtssuche auf vielen Android-Handys eine fragwürdige Sache ist, muß einen ja nicht dazu verleiten, das "im Kleinen" noch einmal nachzubauen und dabei spielt es nun für mich auch keine zusätzliche Rolle, ob Tellows eine deutsche Firma ist oder nicht - über die Datenverarbeitung außerhalb der EU (Kap. 5 EU-DSGVO) will ich jetzt nicht auch noch nachdenken.

Dann muß ich auch nicht den (noch einmal besonderen) Schutz medizinischer Daten (vgl. §203 StGB) mit anderen Daten vermengen oder entsprechende Vergleiche bemühen (willst Du hier ernsthaft Daten der Schutzstufe D mit Deiner Abfrage vergleichen oder mir unterstellen, ich würde da keinen Unterschied erkennen können?) - solange Du tatsächlich (anonym und ohne dem Betreiber der Blacklist wiederum die Möglichkeit der Datensammlung zu eröffnen, was bei Deiner Lösung aber eben nicht sichergestellt wird) nur eine Blacklist abfragen würdest, gäbe es auch gar kein Problem.

Das machst Du aber gerade nicht (dann müßtest Du ja die Nutzungsgebühr an Tellows zahlen, damit Du deren Daten auch offline nutzen kannst) - du läßt einen Dritten (nämlich Tellows bzw. die HTTP-Anwendung dort) für Dich diese Liste abfragen (bist also der Auftraggeber der Datenverarbeitung) und gibst dabei von Beginn an zu erkennen, welche einzelne Nummer Dich interessiert. Da das auch noch vor dem Ende der Kommunikation erfolgt, greift hier (m.E.) auch das BDSG (noch) nicht (§1 (3) BDSG - und auch die DSGVO spielt zu diesem Zeitpunkt keine Rolle).

Es geht mir also mehr um die "Verantwortung" desjenigen, der hier die Verarbeitung der Daten in Auftrag gibt (Art. 24 (2) DSGVO:
Sofern dies in einem angemessenen Verhältnis zu den Verarbeitungstätigkeiten steht, müssen die Maßnahmen gemäß Absatz 1 die Anwendung geeigneter Datenschutzvorkehrungen durch den Verantwortlichen umfassen.
) und da kann die Umsetzung einer TLS-Verbindung anstelle der offenen Abfrage (was Du ja selbst als Option einräumst, aber hier für unnötig hältst - zumindest in Deiner konkreten Situation, keine Ahnung, wie Du das wieder siehst, wenn das jemand mit statischer (oder quasi-statischer) IP-Adresse verwenden würde und solche Konstellationen findet man heutzutage auch schon zuhauf, wo es gar keine "regelmäßigen Wechsel" der IP-Adresse eines Anschlusses mehr gibt) schon ein erster Schritt in die richtige Richtung sein, der praktisch nichts kostet und hier auch den Betrieb nicht wirklich (nachhaltig) lahmlegen würde (also absolut "angemessen" wäre) - was aber ohnehin (s.o.) ein weiteres, einigermaßen absurdes Argument von Deiner Seite war in meinen Augen - selbst wenn man nicht immer "buchstabengetreu" sein kann und ein gewisser Pragmatismus sicherlich notwendig ist, klingt das für mich eher nach der Einstellung: "Datenschutz findet dann statt, wenn er meine eigenen Ziele nicht weiter behindert und/oder nichts kostet.".

Zwar ist am Ende tatsächlich jeder Anschlußinhaber selbst dafür verantwortlich, wenn er Deine Lösung (bleiben wir mal bei der ursprünglichen Form, denn die war ja auch der Ausgangspunkt für die Kritik von @eisbaerin und von mir) 1:1 umsetzt, aber man hat (in meinen Augen) auch als Autor so einer Lösung dann eine gewisse Verantwortung (das will uns ja auch Art. 25 DSGVO irgendwo sagen und zu einem "Umdenken" bereits beim Entwurf veranlassen), der man zumindest dadurch nachkommen kann, daß man auf potentielle Stolpersteine hinweist - erst recht dann, wenn man bereits von ihnen weiß. Wenn Du hier die Nummer des tatsächlich eingehenden Anrufs zwischen drei, vier anderen (zufällig - aber plausibel - generierten) "verstecken" würdest, wäre das vielleicht auch schon wieder etwas anderes (parallel zur Sicherung auf dem Transportweg, die nun wirklich nichts richtig kostet) - oder wenn das gar über einen IP-Anonymisierungsdienst erfolgen würde.

Daß eine rein private Lösung ohnehin nicht unter die DSGVO fallen würde, steht dort auch schon in Art. 2 (2) Bst. c ... es geht (mir jedenfalls) hier am Ende auch weniger um die "Gesetzeslage" (inkl. Verordnungen), als vielmehr um eine bewußte Datensparsamkeit bis hin zur Datenvermeidung und um die Verringerung des eigenen "data footprints". Was man am Ende mit "data mining" anfangen kann, haben wir erst vor wenigen Tagen wieder zur Kenntnis nehmen dürfen, wenn sich US-amerikanische Militärstützpunkte am Ende anhand der Daten von irgendwelchen Fitness-Armbändern lokalisieren lassen - deren Träger haben auch nur die Voreinstellungen zum Datenschutz dort genutzt und wohl eher nicht darüber nachgedacht, daß durch passende Kombination von Daten vollkommen neue Zusammenhänge offengelegt werden könnten.
 
Vielleicht diskutierst du das weitere in einem entsprechendem Forum aus. Hier geht es primär um die technische Umsetzung.
 
sowie eine IP-Adresse, die täglich wechselt. Ein großes Metadatenkonstrukt lässt sich hieraus also nur schwer aufbauen.
Das traue ich mir sogar zu.
Ich schätze nach dem 3. Anruf habe ich deine neue IP erkannt.
Und da bin ich kein Profi-Forensiker.
 
Na dann bin ich ja safe.
Nach der Änderung, die den eigenen Vorwahlbereich und Telefonbucheinträge ausnimmt komme ich auf typischerweise 1 - 2 Anrufe pro Tag. Aber es geht nicht um mich. Ich muss für das obige Skript gleich eine Datenschutzfolgeabschätzung aller potentiellen Nutzer treffen. Klar.
Wo genau steht nochmal die Warnung, dass der Callmonitor mit einem Häkchen die Anrufe in der Rückwärtssuche nachschlägt?
 
Das "nach dem 3. Anruf" bezog sich auf deine 1. Version, wo alle Anrufe abgefragt wurden.
Die jetzige Version gefällt mir schon besser. Und "1 - 2 AnrufeAbfragen pro Tag" sind auch OK.
Ich habe bei mir die Vorwahl sogar noch um eine Ziffer gekürzt, also bei dir nur 022.
 
Zuletzt bearbeitet:
Aha. Ein erster Nutzer!

Früher hab ich halt alle Vorwahlbereiche sperren lassen. Das ging aufgrund mehrerer Rufnummern aber nur für alle eingehende Rufnummern, auch die, die potentielle Freunde nutzen. Und die kommen halt auch schonmal von weiter weg.
Amazon Rückrufservice ging nicht, auch bei einem Bewerbungsgespräch wußte ich nicht so recht, woher der Anrufer kommt und musste das alles ausschalten. Ein Kunde saß in München und rief für einen hiesigen Standort an. Er hat sich nicht beirren lassen und meine Handynummer rausgefunden. Aber grundsätzlich war das halt keine Möglichkeit.
Gewisse angrenzende Bereiche wollte man ja auch mit drin haben, und plötzlich hatte irgendwo in einer Stadt, aus der auch häufiger Kunden anrufen dann ein Callcenter aufgemacht.

Da musste halt eine andere Lösung her. Die einzige Verfehlung dieses Skripts aus organisatorischer Sicht ist es noch, dass neue Nummern nicht erkannt werden, aber die Trefferquote ist enorm.

Im Übrigen fand ich das Feedback super, weil ich die kleinen Verbesserungen sehr gut finde.

Ich würde mich jetzt noch über Vorschläge freuen, wie ich

- mit einem Sanitizer die Eingaben besser prüfen kann (nachher ruft jemand von "221;reboot" an)
- dem Telefondienst schicker zu sagen, er soll den Anruf nicht annehmen (oder gar irgendwohin weiterleiten, z.B. auf einen AB)
- ein HTML Formular der Bundesnetzagentur mit den Daten füttere
- den Anruf verzögern kann, damit das Telefon auch nicht für 0,5 Sekunden klingelt

Das wären eher so die Dinge, die ich in einem technischen Forum erwarte.
 
Zuletzt bearbeitet:
Mir fällt gerade noch ein:
Ich erkenne dich doch schon an der 1. Abfrage!

Jetzt überlege mal woran.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.