Digitaal spoorzoeken

Categorieën

Beveiliging

Zie ook

Vrijwel iedereen gaat er van uit dat de informatie in een mailtje of een artikel op Usenet correct is. Vervalsingen komen helaas echter af en toe voor. Deze vervalsingen kunnen variëren van grapmailtjes die duidelijk afkomstig zijn van een nepadres, tot zorgvuldig in elkaar gezette vervalsingen onder de naam van een ander. Het opsporen van de werkelijke zender van zo'n vervalsing is lang niet altijd eenvoudig.

Headers vervalsen

De eenvoudigste manier om een e-mailtje of artikel op Usenet te vervalsen is door de instellingen van het e-mail programma te wijzigen. Deze programma's kunnen immers niet controleren of de ingevulde naam en e-mail adres echt zijn en zullen dus elke waarde accepteren. Wie dus deze gegevens wijzigt, kan nu mail versturen vanaf elk adres en onder elke naam die hij wil. Als de andere kant niet oplet, kan hij er in trappen en aannemen dat het bericht echt van die andere persoon komt. Aan deze ``truc'' is niet zo veel te doen, aangezien er ook legitieme doelen voor zijn. Mensen die bijvoorbeeld een e-mail adres bij Hotmail hebben, mogen natuurlijk dit adres in hun mail programma invullen.

Er zijn nog genoeg andere mogelijkheden om e-mail te versturen of artikelen te plaatsen onder andermans naam. Sommige sites bieden zelfs "voor de grap" deze mogelijkheid.

Headers van e-mail lezen

Om de werkelijke afzender van een bericht te achterhalen, zijn de van het bericht essentieel. De bekendste headers zijn het onderwerp, de afzender en de datum van het bericht, maar er zijn nog meer headers met belangrijke informatie over waar het mailtje vandaan komt. Deze headers worden meestal niet getoond, maar zijn wel zichtbaar te maken in het mailprogramma met een speciale optie. Dit verschilt echter per mailprogramma.

Hoe worden headers toegevoegd

Wanneer iemand een mailtje verstuurt, plaatst zijn mailprogramma een aantal headers boven de tekst van het bericht. Deze headers bevatten informatie als het onderwerp, de afzender, de ontvanger, het tijdstip van verzending en de naam van het gebruikte programma. Het bericht wordt inclusief deze informatie aan de mailserver doorgegeven. Deze voegt dan ook enkele headers toe en zorgt er voor dat het bij de mailserver van de ontvanger terecht komt.

Headers die door de zendende mailserver zijn toegevoegd zijn in principe betrouwbaar. Een gebruiker met voldoende kennis van zaken kan alle headers die een mailprogramma genereert met de hand vervalsen zodat ze niet te onderscheiden zijn van de headers van een andere persoon. Maar de mailserver die hij gebruikt zal nog steeds dezelfde informatie toevoegen.

Een voorbeeld

Hieronder staat een voorbeeld van de headers van een e-mail bericht.

Received: from terra.stack.nl (terra.stack.nl [131.155.140.128])
	by toad.stack.nl (VMailer) with ESMTP
	id 616ED9655; Thu, 12 Nov 1998 10:03:25 +0100 (CET)
Received: from fonzy.aktu.nl (ns1.aktu.nl [194.178.89.5])
	by terra.stack.nl (VMailer) with ESMTP
	id 50A73244C8; Thu, 12 Nov 1998 10:03:22 +0100 (MET)
Received: from ngw.aktu.nl (ngw.aktu.nl [194.178.89.4])
	by fonzy.aktu.nl (8.8.8/8.8.5) with SMTP id KAA13950
	for <galactus@stack.nl>; Thu, 12 Nov 1998 10:03:19 +0100
Received: from DBP41-Message_Server by ngw.aktu.nl
	with Novell_GroupWise; Thu, 12 Nov 1998 10:00:56 +0100
Message-Id: <s64ab1d8.066@ngw.aktu.nl>
X-Mailer: Novell GroupWise 5.2
Date: Thu, 12 Nov 1998 10:00:49 +0100
From: "Dick Broer" <dbroer@database.nl>
To: galactus@stack.nl
Cc: dplug@database.nl, rdejong@database.nl
Subject: Betreft: Je volgende artikel
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Zoals hierboven is te zien, bestaat een header uit twee delen: de naam en de waarde, gescheiden door een dubbele punt. Een voorbeeld is de Date header, met als waarde Thu, 12 Nov 1998 10:00:49 +0100.

De waarde van een header kan doorgaan op de volgende regel, als die begint met spaties of tabs. Dit is te zien in de Received headers hierboven.

In dit voorbeeld zijn alle headers, met uitzondering van de Received headers, door het mailprogramma van de afzender gegenereerd. Deze zijn dus in principe niet te vertrouwen als het er om gaat te achterhalen wie het bericht verstuurd heeft!

Ontrafelen van de headers

Uit de headers van een legitiem bericht is de nodige informatie over de afzender te halen. Zo staat in dit bericht bijvoorbeeld dat de afzender Novell Groupwise gebruikt. Dit kan echter eenvoudig vervalst worden en is dus voor het opsporen van de afzender niet interessant. Om hem op te sporen, zijn de Received headers interessanter. Elke mailserver die het bericht ontvangt, voegt bovenaan het bericht zo'n header toe met informatie over hoe laat en van wie hij het bericht ontving. Het pad dat het bericht aflegde is nu dus terug te traceren.

In dit voorbeeld is dus te zien dat de laatste mailserver die het bericht ontving toad.stack.nl is. Deze kreeg het bericht van terra.stack.nl, die het op zijn beurt ontving van fonzy.aktu.nl. Fonzy kreeg het bericht weer van ngw.aktu.nl. Dit is kennelijk de mailserver van de zender, aangezien de onderste Received header aangeeft dat deze server het bericht kreeg van de DBP41-Message_Server via Novell GroupWise. De afkorting ngw staat waarschijnlijk voor Novell GateWay, wat nog eens extra suggereert dat een Novell-server is gebruikt.

Het is echter mogelijk dat de afzender zelf ook een of meer Received headers heeft toegevoegd. Het is dus zaak om bij elke regel goed op te letten of de informatie klopt en of het logisch is dat deze server het bericht zou hebben ontvangen. Als er bijvoorbeeld een schakel ontbreekt in de keten van Received headers, dan is er waarschijnlijk sprake van een vervalsing.

Headers van Usenet artikelen

Een bericht op Usenet heeft ongeveer hetzelfde formaat als een e-mail bericht. Er zijn echter een paar belangrijke verschillen. Een voorbeeld van een Usenet artikel staat hieronder. Er zijn nu geen Received headers, maar er is één Path header met ongeveer dezelfde informatie. Elke Usenet server die het bericht ontvangt, voegt zijn eigen naam vooraan in de waarde van deze header toe. Het pad dat het bericht heeft afgelegd, is zo dus terug te lezen.

Path: news.tue.nl!surfnet.nl!barba.uci.kun.nl!sci.kun.nl!not-for-mail
From: charter@spam.free.net (- charter -)
Newsgroups: nl.juridisch
Subject: CHARTER: het handvest van nl.juridisch (wekelijkse posting)
Supersedes: <nl.juridisch$ch122898074137@wnnews.sci.kun.nl>
Followup-To: poster
Date: 4 Jan 1999 06:41:42 GMT
Organization: Peter den Haan posting services
Lines: 5
Message-ID: <nl.juridisch$ch010499074141@wnnews.sci.kun.nl>
Reply-To: pieterh@sci.kun.nl
NNTP-Posting-Host: wn4.sci.kun.nl
Precedence: bulk
X-No-Archive: yes

In dit geval is het pad nogal kort: het is bij de Usenet server van de TU Eindhoven aangekomen via de server van SURFnet. Die kreeg het weer van de server barba.uci.kun.nl van de KU Nijmegen, die het op zijn beurt ontving van de KU server sci.kun.nl. De laatste waarde (not-for-mail) is een standaard waarde, die aangeeft dat dit pad niet gebruikt kan worden om e-mail terug te sturen naar de afzender van het bericht (het formaat van deze header is namelijk een UUCP adres, een antiek systeem om e-mail adressen mee te noteren).

Een tweede belangrijke header is de NNTP-Posting-Host header. Deze geeft aan wat de naam is van de machine vanaf waar het artikel aan de eerste server (sci.kun.nl) is gestuurd. In dit geval is dit wn4.sci.kun.nl. Het pad dat dit bericht heeft afgelegd, is normaal voor een bericht afkomstig van de KUN, en dan is het te verwachten dat het gepost is vanaf een machine bij de KUN. Het bericht lijkt dus legitiem. Het adres van de afzender is duidelijk nep (charter@spam.free.net), maar er is een adres opgenomen waar reacties heen gestuurd kunnen worden (pieterh@sci.kun.nl). Dit is een adres op de KUN, dus alles lijkt nog steeds legitiem.

Om nu na te gaan of een bericht echt is, geldt dezelfde procedure als bij e-mail berichten. Als er in de Path header servers staan die normaal nooit aan elkaar berichten doorgeven (b.v. een server in de VS die een bericht kreeg van een server in Duitsland), dan zit er waarschijnlijk iets fout. De bron zit dan waarschijnlijk bij de plaats vanaf waar het pad onlogisch wordt.

Sturen van klachten

Als een vervalst bericht om een onschuldige reden verstuurd wordt, is er meestal geen reden om aktie hiertegen te ondernemen. Maar als het gaat om een vervalsing met de bedoeling iemand een hak te zetten, dan is een klacht bij het systeembeheer van de nepper op zijn plaats. Als bekend is bij welke server het bericht echt verzonden is, dan kan de klacht het beste naar de beheerder van die server gestuurd worden. Het e-mail adres van deze persoon is meestal postmaster@servernaam of abuse@servernaam. Let er wel op dat bij sommige providers gebruikers hun eigen domeinnaam krijgen, in dat geval komt de klacht bij gebruik van deze methode dus terecht bij de nepper zelf. De klacht kan dan beter gestuurd worden naar abuse@providernaam of postmaster@providernaam.

Een paar tips bij het versturen van klachten:

Stuur bij klachten altijd alle headers uit het bericht mee. Deze headers zijn voor de systeembeheerder noodzakelijk om te controleren of het bericht echt van hen afkomstig is, en om in zijn logfiles te kijken door welke gebruiker dat bericht verstuurd is.
Geef kort aan waarom het bericht waarschijnlijk vervalst is, bijvoorbeeld of het om een grap gaat of dat iemand bezig is een ander een hak te zetten.
Stuur bij grote berichten niet de hele inhoud mee, maar stuur deze alleen op verzoek.
Wees uiteraard altijd beleefd, de meeste systeembeheerders houden hun gebruikers niet de hele dag in de gaten en weten dus niet dat er iemand rare dingen doet totdat een ander het meldt.