Research and Development 1/^Archief/2009-2010/13/pilot/Verslag

• Property "Auteur1" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/13Gebruiker:Ramon van Sparrentak" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur2" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/13Gebruiker:Dennis Brentjes" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur3" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/13Gebruiker:Frank van der Graaff" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "Auteur4" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/13" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• "Verslag" komt niet voor in de lijst (Logboek, Planning, Projectpagina, Pilot, Fase 1, Fase 2, Groepspagina, Feedback) met mogelijke waarden voor de eigenschap "Type".

Inleiding

We hebben ons pilot onderzoek gedaan over spam preventie. Hierbij kwamen we al snel tot de conclusie dat een spamfilter een inefficiënte oplossing. Het houdt namelijk niet alle spam tegen en is in de meeste gevallen duur. Verder zijn ze ook niet permanent en hebben ze constant onderhoud nodig. Dit is bij grote bedrijven een taak op zich en kost dus ook veel geld. En alle mailtjes moeten toch ergens bewaard en bekeken worden omdat er ook nog goede mailtjes tussen kunnen zitten. Zo kwamen we er achter dat een spamfilter ontwerpen het probleem niet oplost.

We zijn toen gaan kijken naar de bron van het probleem namelijk botnets die per minuut zo'n miljoen mailtjes kunnen verspreiden. Dus wij vroegen ons af hoe dit kan, we hadden eerlijk gezegd niet verwacht dat het zo gemakkelijk zou zijn. Iedereen met een telnet client (iedere OS heeft deze standaard) kan een mailtje versturen en daarbij een nep afzenderadres opgeven. De huidige extensies (e-SMTP) op het huidige e-mail protocol (SMTP) heeft wel een aantal verbeteringen aangebracht, maar het is nog steeds mogelijk. Als het domein van de afzender maar bestaat. Dit is geen echte oplossing omdat je nu zelfs andere mensen de schuld moet geven voor het versturen van spam.

Dus we moeten het huidige protocol aanpassen sterker nog een betere ontwerpen en implementeren waarbij dit niet langer mogelijk is.

Waarom is spam een probleem?

Natuurlijk is het van belang om aan te tonen dat het product dat we nu aan het ontwerpen zijn ook echt nodig is. Voordat we dit kunnen aan tonen moeten we eerst afspreken wat wij onder spam verstaan. Meeste mensen gaan er namelijk van uit dat dit ongewenste e-mail is, maar dat is niet waar. Het gaat pas over spam als er massaal, honderdduizenden, emailtjes verstuurd worden naar een grotere groep dan de mogelijke doelgroep waarvoor de e-mail bedoeld is. Hierdoor wordt het odd mailtje uitgesloten die door mensen wordt verstuurd zoals een kettingbrief. Dit is natuurlijk ook heel vervelend maar geen spam aangezien het van je vrienden afkomt, al dan niet door een virus geinfecteerd, en je bent dan de doelgroep als vriend van deze persoon. Dus nu moeten we aantonen dat er zoiets bestaat als spam. Hier zijn veel onderzoeken naar gedaan zo komt een anti-spam bedrijf met een onderzoek van 2006 uit op een een shokkend resultaat. Namelijk dat 84% , dit percentage stijgt nog, van alle e-mails die verstuurd worden Spam zijn. Dit is een ruw percentage dus zonder aftrek van spam filters van ISP’s en of eigen mailboxes, maar deze zijn nooit 100% werkzaam en dus blijft er een klein percentage over die mensen daadwerkelijk ontvangen. Maar dit kleine percentage zijn nog steeds miljoenen mailtjes op jaarbasis, maar vergeet niet dat particulieren niet de enige kunnen zijn die last hebben van spam.

Dit wordt mooi aangetoond door onderzoeksbureau Stratix. Deze hebben namelijk in 2005 aangetoond dat het spam probleem in nederland alleen al 116 miljoen euro per jaar kost. Dit zijn kosten berekend door te stellen dat een werknemen ongeveer zoveel seconden bezig is met het verwijderen van een e-mailtje, het gemiddelde aantal spam mailtjes per werknemer en het gemiddelde uurloon. Verder komt ook nog een deel van de kosten aan het aanschaffen en onderhouden van anti-spam software. En dat is een flinke schadepost.

Ook is het erg makkelijk om veel spam te versturen. Uit een onderzoek van G-data, een van de betere anti-spam software bedrijven, zijn er fora die illegale diensten aanbieden zoals het versturen van spam. Iets wat je ongeveel 250 – 750 dollar gaat kosten voor 1 miljoen spamberichten. En stel dat er 1% daadwerkelijk reageert hoef je maar 1 dollar per product te vragen om nog steeds, weliswaar schamele, winst te maken. Ook is dit geen groot klusje een botnetwerk van zo’n 20.000 computers kan dit kunstje in 25 seconden en netwerken van 20.000 is nog niet eens zo heel veel. Aangezien er genoeg mensen zijn die, in ruil voor gratis smiley’s, een trojan horse “installeren” en vervolgens lid zijn van een bot netwerk zonder dat je het weet. Neem bijvoorbeeld het grootste bot-netwerk van afgelopen zomer. Dit was ZEUS deze had in amerika een zombie-netwerk van 3.6 miljoen computers. Nou is dit netwerk niet voor het versturen van mail, maar voor het achterhalen van bank gegevens, maar het laat wel zien hoe veel computers onwetend lid zijn van een botnetwerk. Verder hoeven spam-botnetwerken niet zo groot te zijn zoals in het rekenvoorbeeldje hierboven. Toch zijn er grotere spam netwerken zoals ook in dezelfde zomer de trojan “Tojan.Fakeavalert” deze was op zijn hoogtepunt 1.4 miljoen computers groot en werd voornamelijk gebruikt voor het versturen van spam.

Dus hier bied zich meteen de philosofie van onze oplossing aan. Het stoppen van het spam probleem door de bron aan te pakken. Namelijk het sturen van mailtjes door botnetwerken. Dit brengt zijn eigen problemen met zich mee die later zullen worden besproken.

[1]

[2]

[3]

Netwerk programming: the basics.

Natuurlijk is netwerk programming een issue als je een e-mail protocol maakt. Je moet immers een client met een server laten praten. En dit verkeer gaat niet zomaar. Dus het idee van netwerk programmeren is hoe ga ik makkelijk gegevens van hier naar daar brengen.

De programmeur van vandaag hoeft zich daar niet veel zorgen meer over te maken met de introductie van winsock. Dit is een soort van package voor de meeste programmeer talen er standaard bij zit. Deze maakt het mogelijk op 3 type sockets te maken die de basis vormen voor de communicatie tussen 2 computers. De programmeur hoeft nu alleen de beslissen welke type socket hij wil gaan gebruiken voor zijn programma.

Datagram sockets zijn sockets die packetjes data versturen en ontvangen maar door de aard van deze packetjes hoeven ze niet in de volgorde aan te komen dat je ze stuurt en ze hoeven niet altijd aan te komen. Dit betekend dat als je deze socket gebruikt je of data integriteit behoud of dat het verlies van 1 of 2 packetjes niet heel veel uitmaakt, Lees muziek of videostreams. Deze sockets gebruiken het UDP protocol waar de meeste wel eens van gehoord zullen hebben.

Steaming sockets zijn sockets die continue data versturen en waar gegarandeerd wordt door het TCP protocol dat er geen data verloren gaat, in theorie tenminste. Toch is deze socket wat dat betreft stabieler dan zijn datagram broertje.

Raw sockets zijn oude sockets die nu niet meer gebruikt kunnen worden door een hotfix van microsoft in een poging een lek in windows xp te dichten. We zullen ons dus niet verder uitweiden over deze socket.

Dus wat is het probleem geen data verlies en ook niet de moeite hoeven te nemen om dataintegrieit te garanderen, we kiezen streaming sockets. Nee niet helemaal de streaming sockets zijn namelijk veel trager dan zijn Datagram broertje en daarom minder interressant voor een server/client die veel informatie per minuut moet verwerken. Aan de andere kant allemaal controles uitvoeren over de data is natuurlijk ook niet prettig voor een server. Hier moet dus vooral naar gekeken worden in de implementatie, maar we kunnen hier denk ik weinig over zeggen aangezien onze server niet erg belast zal worden. in ieder geval niet zo erg als de gemiddelde SMTP-server.

Verder maakt het niet Heel erg veel uit welke programmeer taal we gaan gebruiken. We hebben nu kennis over c++ en genoeg java om onze kennis uittebreiden met tutorials. C++ lijkt wat technischer maar dat komt doordat er iets meer administratie bij komt kijken om een socket te maken en omdat we nog niet met klassen hebben gewerkt in onze cursus programmeren. Bij Java is met klassen werken verplicht en is dus veel intuitiever en makkelijker te bevatten door de aard van java dat iedere class een apart bestand is.

We denken nu dus ook dat we java gaan gebruiken als programmeer taal, maar dit staat nog niet vast aangezien we dit zullen merken in onze implementatie fase of dit een slimme keus was.

[4]

[5]

Ons eerste ontwerp.

Verbinding maken met de server. Dit gebeurt standaard door de client misschien kleine interface waar de gebruiker het ip van de server moet specificeren en de poort die door de server gebruikt wordt om te “listenen” tot nadere orde lijkt mij 1050 een goede poort het ligt buiten het bereik van 0-1024 die door veel programmas gebruikt worden en als het niet interfereert met andere software in de TK’s lijkt me dit een goed plan om deze even zo te laten.

Je kenbaar maken aan de server dat je wat van hem wil, in smtp was dit het “Helo” or “Ehlo” commando gevolgd door een adress vanwaar je de e-mail verstuurd (hoeft niet hetzelfde te zijn als “from” field).

Helo/ehlo relay.example.com bijvoorbeeld

In ons nog wat simpel ontwerp is dat laatste overbodig omdat we binnen het netwerk blijven en zal dus iets van “Helo” of “Ehlo” voldoende zijn.

“Mail from” is een volgend verplicht onderdeel waar in je zegt waarvan de mail komt. dus dit is waar de mail heen gaat als je deze mail beantwoord. Dit is een van de grotere problemen dat sommige smtp servers dit klakkeloos overnemen en zo dus de spammers anoniem kunnen blijven.

Dit gaan we aanpassen dat dit altijd iets meegeeft dat je kan natrekken bijvoorbeeld ip adress dit heeft wel weer nadelen zodat je alleen maar thuis mail kan versturen. Maar dit is weer op te lossen met bijvoorbeeld een vpn verbinding. Je zou dus ook weer andersom kunnen denken dat spammers naar een ander ip vpn en van op die plek iets sturen. Maar dan moeten ze eerst die verbinding hebben en dus vertrouwd zijn met de personen daar. En zo ja contacten hebben met die mensen.

Volgend probleem hiermee is het dynamisch ip adress waar nu nog veel van de spam mail wordt verstuuurd. Rcpt to is het commando waarmee je de mensen die de mail moeten ontvangen kunnen worden toegevoegd. Deze worden ook meteen aan de mail header toegevoegd zodat er niet later nog opnieuw mee geschoemeld kan worden wat in het huidige smpt protocol wel kan als je tenminste een “slechte server” weet te vinden.

Data geeft vervolgens aan wat de body van de mail is. En die wordt bijgevoegd bij het pakket dat verzonden wordt met de hier boven vastgestelde header.

Vervolgens als de gebruiker klaar is met de body van de mail te typen genereert de Server een pseudo random (hexadecimaa) getal. Waarmee de HASH code van de mail mee moet overeen komen (inclusief header) zodat er niet meer mee geprutst kan worden nadat deze stap is voltooid. Natuurlijk is dit in 99.9% van de gevallen niet zo en voegt de client random bits bij de mail gestart door een vast bit patroon zodat de ontvanger deze “garbage” er makkelijk af kan halen en dus een schoon mailtje ontvangt. Als dit eindelijk klopt wordt de mailt door de server in behandeling genomen.

We weten nu waar de mail vandaan komt en kunnen deze persoon op aan spreken als hij daadwerkelijk gespamd heeft. En door deze random gegevens toe te voegen totdat de HASH code (of deel heirvan) klopt met het door de server geleverde (hex) getal duurt het even voordat het mailtje daadwerkelijk verstuurd wordt. Natuurlijk is dit voor dagelijks gebruik geen probleem om even 2 seconden te wachten, maar als je van plan was om 10 miljoen e-mailtjes te versturen. Is dat natuurlijk iets minder prettig.

Om te voorkomen dat automatisch gegenereerde berichten worden verstuurd, zal de server van de ontvanger een Captcha geven aan de zender. Als de zender die voltooid(binnen x minuten) is het bericht verstuurd door een mens.

Omdat het niet handig is bij elke mailtje zo'n Captcha test te moeten voltooien, kunnen ontvangers white lists maken van emailaddressen. Dit is ook nodig voor bijvoorbeeld mailing lists, automatische email voor website registratie e.d.

Om de herkomst van emails te controleren moet elk emailtje een digitale handtekening hebben. Dit kan de zender zelf doen met een persoonlijke handtekening of de email server van de zender met een handtekening van de server. Zo kan de ontvanger controleren dat t echt van de zender kwam, of iniedergeval van de zenders server. Dit voorkomt spoofing van emailadressen die op whitelists staan van gebruikers.

Een gebruiker kan bijvoorbeeld instellen dat alle emails van @gmail.com en @hotmail.com nooit spam zijn, mits de handtekening correct is.

Voor een spammer is het nu praktisch onmogelijk om ongewenste spam te (blijven) versturen. Een spammer kan niet een emailaddress misgebruiken dat op een whitelist staat, omdat het de digitale handtekening niet kan zetten. Een spammers eigen emailaddress kan op de whitelist van een gebruiker komen, als deze zelf aangeeft graag de spam te ontvangen. Om een email te versturen dat niet op de whitelist staat, zal de spammer een captcha test moeten doorstaan. Dat is mogelijk, maar maakt spam sturen een fulltime job van captcha's.

Captcha[6] Digital Signature[7]

het huidige protocol

Abstract

Implementatie van LINSEP (LINSEP Is No Spam Email Protocol). Een protocol voor het sturen van emails en tegen het sturen van spam. het protocol is alleen voor het versturen van email (vanaf een client of server) naar een Email server. Dit protocol is dus een vervanging voor het oeroude SMTP.

Protocol Outline

Een client (gebruiker) begint met het sturen van een Email naar de Sender (zijn emailserver). De Sender stuurt de Email door naar de Receiver (de ontvangende emailserver). De Receiver kan dan beantwoorden met een Captcha, die de gebruiker zal moeten oplossen voordat de email echt bezorgd is. De gebruiker verstuurd daarvoor de Email opnieuw, inclusief de Captcha oplossing.

Email

Een email bestaat uit een header een body. De body bevat het daadwerkelijke geschreven bericht. De header bestaat uit verschillende onderdelen. Verplichte onderdelen zijn:

• From-, To-,CC- en BCC-addressen
• Digitale handtekeningen
• Datum en tijd
• Message ID

Mogelijke extra onderdeel is bijvoorbeeld:

• Captcha oplossing

Een onderdeel begint met zijn naam en vervolgens de inhoud van het onderdeel zelf.

Captcha

Een captcha wordt teruggestuurd vanaf de Receiver naar de Sender (server) als de Receiver zeker wilt zijn dat het bericht verstuurd is door een mens. Een captcha bestaat ook uit onderdelen:

• From- en To-,CC-,of BCC-addressen (van de Email)
• Message ID (van de Email)
• Het captcha object

Voorbeeld

De client stuurt naar haar server(example.org) de volgende Email:

-Header-
From: alice@example.org
To: bob@foo.bar
Date: 2-10-2010 18:49 UTC
ID: 143494
-Body-
Subject: Hello bob
Body: What's up?

Hoe alice zichzelf authentificeert bij de server laten we open [TODO?]. Haar server voorziet de email van een digitale handtekening dat het inderdaad van (example.org) kwam en alice@example.org ook een correcte gebruiker/emailaddress is. De server stuurt de nieuwe Email naar bobs email server(foo.bar):

-Header-
From: alice@example.org
To: bob@foo.bar
Date: 2-10-2010 18:49 UTC
Signature: example.org [binaire data....]
ID: 143494
-Body-
Subject: Hello bob
Body: What's up?

Bobs emailserver controleert de Email in de volgende stappen

• De datum: emails die ouder zijn dan 2(?) uur worden niet geaccepteerd.
• De handtekening: om er zeker van te zijn dat de email van example.org kwam en dus verstuurd is door de 'eigenaar' van alice@example.org.
• Whitelists en blacklists
  • Staat alice@example.org in bob's whitelist?
  • Staat alice@example.org in bob's blacklist?
  • Staat example.org in bob's whitelist?
  • Staat example.org in bob's blacklist?
  • Staat example.org in de servers whitelist?
  • Staat example.org in de servers blacklist?

In dit voorbeeld staat de email niet in een van de white en blacklists. Dus beantwoord foo.bar met een Captcha:

From: alice@example.org
To: bob@foo.bar
ID: 143494
Captcha: image [binaire data...]

Alices server toont de captcha aan Alice, die de oplossing invult, waarna example.org de email opnieuw verstuurt:

-Header-
From: alice@example.org
To: bob@foo.bar
Date: 2-10-2010 18:49 UTC
ID: 143494
Captcha-result: md5(appel alice@example.org)
-Body-
Subject: Hello bob
Body: What's up?

Bobs server heeft Captcha oplossing en de bijbehorende Message ID,From en To, onthouden en bezorgt de Email in Bobs emailbox. Bob kan er nu zelf voor kiezen of hij alice@example.org of example.org aan zijn whitelist wil toevoegen, waardoor Alice bij het volgende bericht niet opnieuw een Captcha moet oplossen.

Bewijs geen spam

In principe moet voor elke email een Captcha worden opgelost. Captcha's moeten worden opgelost door de verzender die daar de tijd voor neemt

• De captcha kan niet door een ander persoon opgelost worden
  • De captcha kan niet doorgestuurd door zelf een email te ontvangen. Het antwoord zelf wordt namelijk niet doorgestuurd, alleen een bewijs (md5sum) dat de oplosser ook de oplossing heeft
  • Via high traffic sites bezoekers laten oplossen. Dit is echter onwaarschijnlijk/zeer weinig [8]

Als er geen Captcha hoeft te worden opgelost is de zenderaddress op een whitelist.

• Het zenderadress is ook eigendom van de zender.
  • De versturende server is de enige die de correcte handtekening kan zetten behorende bij het domein van de emailaddress
    • Daarvoor moet de handtekening niet gekraakt zijn (afhankelijk van de handtekening die gebruikt wordt)
  • De ontvanger moet de handtekening kunnen controleren
    • Uhm?

Als de zender staat op de whitelist van de gebruiker

• Dan heeft de gebruiker zelf toestemming gegeven, om alle email van deze zender in de inbox te bezorgen

Of de zender staat op de whitelist van de server

• Dan is de server of niet goed ingesteld of heeft een fout gemaakt
  • In beide gevallen is het geen betrouwbare server en voor mensen die geen spam willen niet de server om nog te gebruiken voor email.

De zwakste schakels zijn:

• Captcha's kunnen alleen door mensen worden opgelost
• Digitale handtekeningen worden niet gekraakt
• De digitale handtekening kan correct worden geverifieerd
• Servers / mensen gaan niet ad hoc adressen op whitelists zetten