Abwehr von Direct Spam over Internet Telephony mittels Anrufer Pre-Validierung

Transkript

1 Abwehr von Direct Spam over Internet Telephony mittels Anrufer Pre-Validierung Jürgen Müller, Michael Massoth Fachbereich Informatik, Hochschule Darmstadt, Deutschland {juergen.mueller, Kurzfassung Voice over Internet Protocol gewinnt stetig an Bedeutung. Es ermöglicht umfassende Kosteneinsparungen für Dienstanbieter und Endkunden, jedoch auch für Spammer. Durch den Einsatz von Voice over Internet Protocol wird das Medium der Telefonie für sie erstmals kostengünstig zugänglich. Spam over Internet Protocol bezeichnet die Übertragung unerwünschter Nachrichten mittels Sprache über das Internet. Durch die temporäre Adresse des Session Initiation Protocol ist es zusätzlich möglich, den Teilnehmer Peer to Peer auf seinem Endgerät zu kontaktieren. Die Signalisierungsnachrichten werden hier direkt an das Endgerät des Angerufenen gesendet. Das dadurch entstehende und als am gefährlichsten einzustufende Direct Spam over Internet Telephony kann bisher nicht effektiv abgewehrt werden. Der in diesem Papier vorgestellte Anrufer Pre-Validierungs-Mechanismus geht auf dieses Problem ein. Dabei wird die Existenz des Anrufers bei dessen Betreiber sowie des anrufenden Telefons validiert. Stimmen beide Angaben überein, ist mit diesem Mechanismus sicher gestellt, dass der Anrufer wirklich existiert und unter der angegebenen Adresse registriert ist. Somit kann ihm ein gewisses Vertrauen gegenüber gebracht werden, da er von seinem Dienstanbieter sanktioniert werden kann, sollte er Spam versenden. 1 Einleitung Spam over Internet Telephony (SPIT) ist eine immer bedeutender werdende Betrohung. Anders als beim Spam ist der Störfaktor durch SPIT deutlich höher. Wenn Spam in einem Postfach eintrifft, wird der Teilnehmer in der Regel nicht direkt gestört, da er das Spam erst beim Abruf der s wahr nimmt. Klingelt jedoch das Telefon, ist der Teilnehmer direkt gestört. Die Störung wird gravierender, wenn das SPIT mitten in der Nacht eintrifft, falls es beispielsweise aus dem Ausland versendet wird. Des Weiteren ist SPIT deutlich schwerer zu detektieren und filtern als Spam. Das größte Problem ist hierbei der Echtzeitcharakter der Telefonie. Die Nachricht ist erst verfügbar, nachdem das Telefon geklingelt und der Teilnehmer abgenommen hat. Da dieser dann bereits gestört wurde, kann nicht von einer erfolgreichen Abwehr gesprochen werden. Solange SPIT nur ein geringes Ausmaß aufweist, wird diese Störung von den Teilnehmern vermutlich nicht weiter beachtet werden, da sie bereits Telefonwerbung aus dem Festnetz kennen. Allerdings ist die Festnetztelefonie deutlich teurer und wird daher kaum für Spam genutzt. Voice over Internet Protocol (VoIP) reduziert die Kostenhürde jedoch deutlich. Des Weiteren hat McAfee ermittelt, dass Spam auch ein ökologisches Problem ist. Deren Studie zufolge wurden im Jahr 2008 rund 62 Billionen Spam s versandt [9]. Daraus resultierte rund 33 Milliarden Kilowattstunden Abwärme. Das entspricht dem Stromverbrauch von ungefähr 2,4 Millionen Haushalten. Laut einem Bericht des Bundesamt für Sicherheit in der Informationstechnik waren 2008 durchschnittlich nur 1,5 % der empfangenen s erwünscht [2]. Erreicht SPIT ein ähnliches Ausmaß, werden die Teilnehmer vermutlich von VoIP-Nutzung absehen. Bei Spam ist es wichtig die Aufteilung des finanziellen Schadens zu beachten. Bild 1 zeigt eine Einschätzung von Ferris Research, wonach der größte finanzielle Schaden durch den Produktivitätsverlust entsteht [8]. Der Mitarbeiter wird durch den Eingang des Spam von seiner Tätigkeit abgelenkt und muss sich anschließend wieder einfinden. Dieser Effekt wird bei SPIT vermutlich deutlich gravierender sein, da hier der Mitarbeiter bei jedem Spameingang gestört wird und nicht erst, wenn er seine s abruft. Kosten aus Produktivitätsverlust Kosten für den Helpdesk Soft- und Hardwarekosten 10 % 5 % 85 % Bild 1: Aufteilung des finanziellen Spamschadens.

2 2 Spam over Internet Telephony Durch die Umstellung der Festnetztelefonie auf VoIP ergeben sich umfassende Kosteneinsparungen. Davon profitieren jedoch auch Spammer, die nun in der Lage sind kostengünstig Spam über das dieses Medium zu senden. 2.1 Übertragungsformen Beim Spam gibt es zunächst nur die Möglichkeit, das Spam über die reguläre E- Mail Adresse zuzustellen. Da das Session Initiation Protocol (SIP) zwei Adresstypen pro Teilnehmer vorsieht, ergeben sich hier analog zwei Übertragungsformen [6]: 1. Schritt 2. Schritt 3. Schritt Adressen sammeln Verbindung herstellen Nachricht übertragen SPIT via Proxy: Das SPIT an die permanente SIP URI adressiert. Dadurch wird die Nachricht über die reguläre Infrastruktur der Dienstanbieter gesendet. Bild 2: Die drei Schritt des SPIT [6]. Wie Bild 2 zeigt, besteht der SPIT-Prozess nicht nur aus der Nachricht selbst [8]. Um das SPIT überhaupt zustellen zu können, muss der Angreifer in einem ersten Schritt zunächst die Adressen seiner Opfer ermitteln. Der Angreifer kann diese Adressen auf die folgenden Art und Weise erlangen [3][4][6]: Handel: Der Angreifer erwirbt eine fertige Liste von einem anderen Kriminellen. Harvesting: Bots werden dazu eingesetzt, das Internet automatisch nach Adressen zu durchsuchen. Aktiver Scan: Bei diesem Verfahren probiert der Angreifer automatisiert die SIP URIs beim gewünschten Ziel-Dienstanbieter aus. Erhält er eine Response Nachricht vom Typ, 480 Temporarily Unavailable, 486 Busy Here, etc. speichert er die URI in einer Liste. Dabei muss er den Verbindungsaufbau nicht zu Ende führen, erhält aber eine Liste mit gültigen Zieladressen. Passiver Scan: Will der Angreifer nicht entdeckt werden können, kann er die Technik des passiven Scans einsetzen. Hierbei stellt er selbst einen registrierungspflichtigen Service oder eine VoIP Hotline bereit. Anschließend speichert er jede SIP URI, die registriert wird oder mit der angerufen wurde in einer Liste. Indem der Angreifer davon abgehalten wird, in Besitz der Adressen zu gelangen, kann das SPIT stark eingeschränkt werden. Anhand der ersten Beschaffungsmöglichkeit ist klar, dass sobald die SIP URI in den Händen der Spammer ist, nichts mehr dagegen unternommen werden kann, dass sie verbreitet wird. Nachdem der Spammer gültige Adressen gesammelt hat, kann er beginnen eine Verbindung zu seinen Opfern aufzubauen. Erst wenn diese Verbindungen erfolgreich aufgebaut sind, kann das SPIT übertragen und somit der Prozess beendet werden. Direct SPIT: Hier wird das SPIT mittels der temporären SIP URI übertragen. Diese ermöglicht ein direktes Ansprechen des Teilnehmerendgerätes. Dadurch müssen keine weiteren SIP Netzelemente mehr an der Übertragung beteiligt sein. Da die Nachrichten beim SPIT via Proxy regulär über die Infrastruktur der Diensteanbieter gesendet werden, können sie dort bereits auf SPIT überprüft werden. Beim Direct SPIT wird diese Instanz jedoch umgangen, womit nur das Endgerät des Angerufenen das SPIT noch abwehren kann. Die meisten Endgeräte verfügen jedoch nur über sehr geringe Rechenkapazitäten, wodurch sie kaum in der Lage sind effektive Schutzmechanismen auszuführen. Daher wird Direct SPIT als die gefährlichere Form von SPIT angesehen. 2.2 Abwehrmaßnahmen Eine Vielzahl von Maßnahmen, die sich in der Abwehr von Spam bewährt haben, lassen sich auf SPIT übertragen. Ungünstiger Weise können die beim Spam effektivsten Inhaltsfilter bei SPIT nicht direkt zur Abwehr eingesetzt werden. Anders als bei s ist die eigentliche Nachricht bei einem Telefonat im Voraus nicht bekannt. Des Weiteren kommt es bei einer nicht darauf an, ob sie direkt zugestellt oder kurzzeitig zur Untersuchung auf Spam zurückgehalten wird. Im Fall von SPIT gilt es jedoch bereits als erfolglose Abwehr, sobald das Telefon klingelt und somit bevor die Nachricht überhaupt übertragen wird. Daher sind Inhaltsfilter für die direkte Abwehr von SPIT nicht anwendbar und werden folglich nicht betrachtet. Wie Bild 3 zeigt, lassen sich die Maßnahmen zur Abwehr von SPIT in drei Gruppen unterteilen, die im Folgenden kurz vorgestellt werden.

3 Identitäts-basiert Maßnahmen gegen Spam over Internet Telephony Interaktiv Präventiv Reputation Systems [14]: Die Vertrauenswürdigkeit eines Teilnehmers wird bei diesem Ansatz durch einen Wert repräsentiert. Dieser Wert wird durch Bewertungen anderer Teilnehmer gebildet. Ein Verbindungsaufbau wird durchgeführt, sobald dieser Wert über einer definierbaren Schwelle liegt. Whitelisting Blacklisting Graylisting Device Fingerprinting Reputation Systems Intrusion Detection Payments at Risk Turingtests Computational Puzzle Honeypot Addressen verbergen Addressen verteilen Teilnehmerverhalten schulen Bild 3: Abwehrmaßnahmen gegen SPIT. Die erste Gruppe von Abwehrmaßnahmen, filtert auf Basis Identitäts-basierter Merkmale. Das sind in der Regel Verfahren, die den Anrufer oder sein System in irgend einer Weise charakterisieren. Zu den bekanntesten und ressourcensparendsten zählen sogenannte Listenverfahren. Whitelisting: Dieses Verfahren bestimmt, welcher Teilnehmer die Erlaubnis hat anzurufen. Dazu werden in einer Liste die befugten Absendeadressen eingetragen. Befindet sich der Anrufer in dieser Liste, wird sein Telefonat durch gestellt. Blacklisting: Blacklisting arbeitet konträr zum Whitelisting. Hier wird definiert, welcher Teilnehmer automatisch abgewiesen wird. Graylisting [7]: Bei den bisherigen Listenverfahren muss der Anrufer im Voraus bekannt sein. Daher wird bei diesem Verfahren ein initialer Anrufversuch eines Teilnehmer abgelehnt und die Adresse des Teilnehmers in die Graylist geschrieben. Ruft dieser Teilnehmer innerhalb einer definierbaren Zeit erneut an, wird sein Anruf durch gestellt. Device Fingerprinting [16]: Bei diesem Verfahren wird der Nachrichtenaufbau oder das Nachrichtenverhalten des anrufenden Endgerätes überprüft. Ein Anruf wird nur durch gestellt, wenn diese Merkmale mit einem SIP Phone überein stimmen. Identitäs-basierte Abwehrmaßnahmen eigenen sich besonders gut, um in einem Endgerät eingesetzt zu werden, da sie meist kaum Rechenleistung benötigen. Problematisch gestaltet sich jedoch die Umsetzung von Device Fingerprinting im Endgerät, da hierfür zu viele aktuelle Informationen über die anrufenden Soft Phones benötigt werden. Ähnliche Probleme ergeben sich beim Black- und Whitelisting. Da es relativ unwahrscheinlich ist, dass ein Spammer zwei mal die selbe Adresse angreift. Da dieser für die Filterung aber im Voraus bekannt sein muss, empfiehlt sich der Einsatz dieser Verfahren eher in den SIP Proxys. Ein anderer Ansatz besteht darin, die Kosten für einen Spammer zu erhöhen um somit den Dienst für diesen unrentabel zu gestalten und somit einzudämmen. Diese interaktiven Abwehrmaßnahmen werden meist direkt durch die Überweisung von Geld oder durch die Erhöhung der Verarbeitungszeit des Rufaufbaus realisiert. Im Folgenden wird eine kurze Beschreibung dieser Verfahren gegeben. Intrusion Detection [5]: Ein Intrusion Detection System überwacht das Netzwerk und reagiert, sobald ein anormales Nachrichtenverhalten auftritt. Was anormal ist, wird vom Administrator vorher definiert. Beispielsweise könnte SPIT durch die Übertragung vieler INVITE Request charakterisiert werden. Befindet das Intrusion Detection System eine Nachricht für schadhaft, wird sie aus dem Netzwerk entfernt. Payments at Risk [1]: Der Anrufer muss dem angerufenen Teilnehmer einen kleinen Betrag überweisen, damit er telefonieren kann. Befindet der Angerufene das Telefonat im Anschluss für erwünscht, bekommt der Anrufer sein Geld zurück. Somit werden die Kosten für die Übertragung von SPIT direkt erhöht. Turingtests [15]: Bei diesem Verfahren muss der anrufende Teilnehmer eine Aufgabe lösen, die nur schwer von einer Maschine gelöst werden kann. Kann er sie korrekt beantworten, wird er signalisiert. Bei VoIP kommen hier Audiobotschaften zum Einsatz, die beispielsweise mit Störgeräuschen und Dialekt aufgenommen wurden. Computational Puzzle [14]: Ähnlich zum Turingtest wird hier dem Endgerät eine rechenintensive Aufgabe übermittelt. Berechnet es die

4 korrekte Antwort, wird der Anrufversuch bearbeitet. Dieses Verfahren dient ausschließlich zur Verlängerung der Verarbeitungsdauer. Honeypot [14]: Honeypots sind SIP Server, die einen Anrufversuch besonders langsam verarbeiten und nie durchstellen. Es sollte sicher gestellt werden, dass kein normaler Teilnehmer eine solche Adresse anwählt. Interaktive Verfahren benötigen gegenwärtig zu viel Rechenleistung, um effektiv in einem Endgerät eingesetzt zu werden. Des Weiteren bietet beispielsweise das Computational Puzzle keinen direkten Schutz vor SPIT, Turingtests sind gegen SPIT mit menschlichen Anrufern wirkungslos. Die dritte Kategorie der Abwehrmaßnahmen gegen SPIT zielen auf das Verhalten der Teilnehmer. Somit beinhaltet sie keine Mittel, die seitens des Endgerätes eingesetzt werden können und somit für die präsentierte Arbeit irrelevant sind. 3 Anrufer Pre-Validierung Da beim Direct SPIT kein SIP Proxy am Nachrichtenaustausch beteiligt ist, muss die Pre-Validierung beim angerufenen Endgerät selbst erfolgen. Ungünstiger Weise verfügen die meisten Telefone über sehr wenig Rechenleistung, sodass keine komplexen Berechnungen durchführbar sind. Der initiale INVITE Request des Anrufers beinhaltet jedoch Informationen, die für eine Pre-Validierung genutzt werden können: Der Teilnehmername (z. B. alice ). Der Namen oder die IP Adresse des Dienstanbieters (z. B. beispiel.de ). Wie Bild 4 zeigt, wird beim SIP Three Way Handshake direkt nach dem Eingang des INVITE Request das Endgerät zum klingeln gebracht. Somit bleibt keine Zeit weitere Schritte einzuleiten, um die Störung des Teilnehmer zu verhindern. Alice INVITE 100 Trying 180 Ringing ACK Bob Bild 4: Ablauf eines regulären Verbindungsaufbau. 3.1 Konzept Bevor eine Pre-Validierung durchgeführt werden kann, muss das direkte Aussenden des 180 Ringing Response unterbunden werden. Da es sich um eine optionale Nachricht handelt, ist das unproblematisch. Wie Bild 5 zeigt, kann anschließend die Pre-Validierung, auf Basis der Informationen aus dem INVITE Request, beginnen. Um die Existenz des Teilnehmernamens zu prüfen, kann eine Nachricht an dessen Betreiber gesendet werden. Wird diese Nachricht von ihm korrekt beantwortet, ist dieser Schritt erfolgreich beendet. Zur Überprüfung der Existenz des anrufenden Endgerätes, kann eine SIP Nachricht an dieses gesendet und auf eine passende Antwort gewartet werden. Diese Überprüfung ist notwendig, da ein möglicher SPIT- Angriff darin bestehen könnte, das Endgerät des Opfers klingeln zu lassen, um diesen zu stören. Alice Dienstanbieter Bob Anrufversuch Wird bearbeitet Existiert Alice? Existiert das Telefon von Alice? Antwort Das Telefon klingelt Anruf angenommen Antwort Bild 5: Änderungen im Verbindungsaufbau. 3.2 Machbarkeitsstudie Das Konzept wurde im Rahmen einer Machbarkeitsstudie prototypisch implementiert. Die konkrete Umsetzung der im Konzept definierten Anfragen werden in Bild 6 gezeigt. Anrufer Dienstanbieter Bob INVITE 100 Trying OPTIONS 486 Busy Here / 180 Ringing ACK SUBSCRIBE NOTIFY Bild 6: Sequenzdiagramm der Implementierung. Zur Verifizierung des Teilnehmernamens wird ein SUBSCRIBE Request an den Presence Server [12][13] des Dienstanbieters gesendet. Verneint dieser die Existenz des Teilnehmers, wird der Anruf abgelehnt. Anschließend wird die Existenz des anrufenden Endgerätes überprüft. Dazu ermittelt der Prototyp die Funktionen des anrufenden Endgerätes durch das Versenden eines OPTIONS Request an dessen temporäre

5 SIP URI. Wird auch diese Nachricht erfolgreich beantwortet, kann davon ausgegangen werden, dass der Anrufer unter der vorgegebenen Adresse registriert ist und existiert. 3.3 Evaluation der Performanz Zur Evaluation des Verfahrens wurde der Prototyp mittels Sipdroid [10] auf dem Betriebssystem Android 1.6 [11] einem Performanztest mit 100 Durchläufen unterzogen. Android wurde auf einem System mit 1.66 GHz Dual Core Prozessor, 2048 MB Arbeitsspeicher und 6 Mbps Internetverbindung innerhalb des Android Emulators ausgeführt. Zusätzlich wurde ein unmodifiziertes Sipdroid auf dem selben System betrieben. Der verwendete SIP Proxy befand in Denver (USA) und die beteiligten Soft Phones in Darmstadt (Deutschland). In diesem Test sollte ermittelt werden, wie sich die zusätzlichen Nachrichten auf die Dauer des Antwortverhaltens auswirken. Die Messung des Test begann mit dem Eingang des INVITE Requests im angerufenen Endgerät und endete mit dem Versand des 180 Ringing Response. Die Latenz der verbleibenden Nachrichten wurde nicht gemessen, da diese für die Ermittlung des Performanzunterschiedes irrelevant sind. Wie Bild 7 und Tabelle 1 zeigen, hat sich die Verarbeitungsdauer um etwa 2,500 s höht. Weiter ist deutlich zu erkennen, dass der Prototyp genau wie die original Sipdroid Software nach oben hin zu Ausreißern neigt. Sipdroid 2,405 s 2,531 s 2,837 s 3,000 s 3,538 s Prototyp Minimum 1. Quartil Median 3. Quartil Maximum 4,759 s 5,016 s 5,186 s 5,417 s 6,003 s 25 x 20 x 15 x 10 x 5 x 0 x Lower Mittelwert Upper Sipdroid 2,764 s 2,821 s 2,879 s Prototyp 5,181 s 5,240 s 5,298 s Tabelle 2: Werte zum 95 % Konfidenzintervall Sipdroid 2,500 s 3,000 s 3,500 s 4,000 s 4,500 s 5,000 s Prototyp 5,500 s 6,000 s Bild 8: 95 % Konfidenzintervall der Messungen. 3.4 Schwachstelle Wie Bild 9 zeigt, kann das in diesem Papier vorgestellt Verfahren in einem speziellen Szenario getäuscht werden. Dazu benötigt der Angreifer lediglich ein zweites Dummy Teilnehmerkonto bei einem vertrauenswürdigen Betreiber. Dieses Konto wird vom Angreifer nicht aktiv eingesetzt, zum Zeitpunkt des Angriffs muss jedoch ein Endgerät darauf registriert sein. Tabelle 1: Messergebnisse der Performanztests dummy@beispiel.de beispiel.de Sipdroid 1. Registrieren Prototyp 0,000 s 1,000 s 2,000 s 3,000 s 4,000 s 5,000 s Bild 7: Boxplot der Messergebnisse. 6,000 s 7,000 s Diese Vermutung erhärtet sich bei der Betrachtung des 95 % Perzentils. Der Prototyp validiert 95 % der Anrufe unter 5,806 s, während das unmodifizierte Sipdroid 3,316 s benötigt. Demnach sind die Ausreißer bei beiden Varianten rund 0,200 s über diesen Werten. Bild 8 in Ergänzung zur Tabelle 2 bestätigt die bereits aufgestellte Vermutung. Der Erwartungswert für die Messung liegt bei beiden Versionen in einem Bereich gleicher Breite. Einziger Unterschied ist die Verschiebung um rund 2,500 s. Somit konnten zusätzlich keine negativen Auswirkungen auf die Stabilität der Software ermittelt werden. spammer@ Anrufversuch 4. Validierung des Endgerätes 5. Das Telefon klingelt 3. Validierung beim Provider bob@beispiel.de Bild 9: Aufbau eines erfolgreichen Angriffs. Um den Angriff durchzuführen, gibt der Angreifer im initialen INVITE Request die permanente SIP URI seines Dummy Kontos an. Da der Dummy real existiert und zum Zeitpunkt des Angriffs registriert ist, wird der erste Schritt der Pre-Validierung erfolgreich abgeschlossen. Anschließend kommt es auf die Implementierung des Presence Servers beim Dienstanbieter an. Im Contact Header der Antwort kann beispielsweise die temporäre

6 SIP URI des Dummy oder die URI des Presence Servers enthalten sein. Ist die temporäre SIP URI enthalten, würde der Prototyp direkt den Anrufversuch ablehnen, da diese Adresse nicht mit der des anrufenden Endgerätes überein stimmt. Andernfalls wird die Pre- Validierung mit der temporären SIP URI aus dem IN- VITE Request durchgeführt. Diese Überprüfung wird jedoch zu einem positiven Ergebnis kommen, da das Endgerät des Anrufers existiert. 4 Fazit und Ausblick SPIT wird sehr wahrscheinlich eines der wichtigsten Endkundenprobleme bei VoIP. Mit der Qualität der SPIT-Bekämpfung steht und fällt der Erfolg von VoIP. Denn sollte SPIT nicht effektiv eingedämmt werden, bleibt die Verwendung des bisherigen Festnetzes für viele Teilnehmer angenehmer, da hier kein Direct SPIT möglich ist. Eine effektive Abwehr kann jedoch nicht nur rein durch Server-basierte Verfahren gewährleistet werden. Der Spammer ist nämlich in der Lage sein Opfer direkt über die temporäre SIP URI anzurufen. Daher gehört zu einer ganzheitlichen Lösung auch die Abwehr von SPIT im Endgerät. Die meisten Endgeräte verfügen heutzutage nicht über die nötige Rechenleistung, um komplexe Abwehrmaßnahmen durchzuführen. Daher ist der in diesem Papier vorgestellte Mechanismus zur Anrufer Pre-Validierung, ein wichtiger Schritt in Richtung effektiver SPIT-Abwehr. Letzten Endes kann SPIT auch von existierenden und legal registrierten Teilnehmern versendet werden. Da die Dienstanbieter das Versenden von Spam jedoch untersagen, können diese die Versender von SPIT anschließend sanktionieren. Wie der Performanztest des Prototyps zeigt, lässt der Mechanismus noch weitere Verbesserungen zu. Dies betrifft beispielsweise die zusätzliche Zeit beim Verbindungsaufbau, obwohl diese ausschließlich für den Anrufer spürbar ist, da das Telefon des Angerufenen erst im Anschluss beginnt zu klingeln. Des Weiteren soll der Mechanismus vor dem beschriebenen Angriff geschützt werden. Daher wird an einer Performanz- und Sicherheitsoptimierung der Software gearbeitet. Insbesondere soll die Pre-Validierung der beiden Existenzmerkmale parallel durchgeführt werden. Gegenwärtig befindet sich an der Hochschule Darmstadt bereits eine Teststellung des Prototypen, die hinsichtlich der oben beschriebenen Verbesserungen stetig optimiert wird. Literatur [1] ABADI, M. ; BIRRELL, A. ; BURROWS, M. ; DA- BEK, F. ; WOBBER, T.: Bankable Postage for Network Services. In: ASIAN 03: Advances in Computing Science. Heidelberg : Springer, 2003 [2] BUNDESAMT FÜR SICHERHEIT IN DER INFOR- MATIONSTECHNIK: Die Lage der IT-Sicherheit in Deutschland Januar 2009 [3] CENTER FOR DEMOCRACY & TECHNOLOGY (Hrsg.): Why Am I Getting All This Spam? Center for Democracy & Technology, März 2003 [4] EGGENDORFER, T.: No Spam! Wie Spam gar nicht erst entsteht. 1. Auflage. Frankfurt : S&S, 2005 [5] EL BAKER NASSAR, M. ; STATE, R. ; FESTOR, O.: Intrusion detection mechanisms for VoIP applications. In: VSW 06: Third Annual Security Workshop. New York : ACM, 2006 [6] EL KHAYARI, R. ; KUNTZE, N. ; SCHMIDT, A. U.: SPAM over Internet Telephony and how to deal with it. In: ISSA 08: Proceedings of the Innovative Minds Conference. Johannesburg : University of Johannesburg, 2008 [7] HARRIS, E.: The Next Step in the Spam Control War: Greylisting. erstellt am , besucht am , [8] JENNINGS, R.: Cost of Spam is Flattening. erstellt am , besucht am , [9] MCAFEE (Hrsg.): The Carbon Footprint of Spam Report. McAfee, April 2009 [10] MERLE, P.: Project Hosting on SIP/VoIP Client for Android. besucht am , [11] OPEN HANDSET ALLIANCE: Android.com. besucht am , [12] ROACH, A. B.: Session Initiation Protocol (SIP)- Specific Event Notification. RFC 3265, IETF, Juni (RFC 3265) [13] ROSENBERG, J.: A Presence Event Package for the Session Initiation Protocol (SIP). RFC 3856, IETF, August 2004 [14] ROSENBERG, J. ; JENNINGS, C.: The Session Initiation Protocol (SIP) and Spam. RFC 5039, IETF, Januar 2008 [15] TSCHOFENIG, H. ; LEPPANEN, E. ; NICCOLINI, S. ; ARUMAITHURAI, M.: Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA) based Robot Challenges for SIP, Februar Internet-Draft

7 [16] YAN, H. ; ZHANG, H. ; SRIPANIDKULCHAI, K. ; SHAE, Z.-Y. ; SAHA, D.: Incorporating Active Fingerprinting into SPIT Prevention Systems. In: VSW 06: Third Annual Security Workshop. New York : ACM, 2006