Vorige aflevering | Search TidBITS | TidBITS Home Page | Volgende aflevering

TidBITS Logo

TidBITS#442/10-Aug-98

Na het schrijven van verscheidene artikelen over de veiligheid van data en het belang van een goed back-up systeem, ontdekken Adam en Tonya op de harde manier de waarde van hun informatie nadat inbrekers een PowerBook uit hun huis hebben meegenomen. Daarnaast legt Geoff in dit nummer in detail uit hoe op spam te reageren, is WebSTAR 3.0.1 leverbaar, verkoopt Qualcomm Now Utilities aan Power On Software, brengt Connectix een update van RAM Doubler 8, en kondigen we de Chinese TidBITS mailing list aan.

Onderwerpen:

Copyright 1998 TidBITS Electronic Publishing. All rights reserved.
Information: <info@tidbits.com> Comments: <editors@tidbits.com>


Je kunt je gratis abonneren op de Nederlandse afleveringen van TidBITS door een (blanco) mailtje te sturen naar: tidbits-nl-on@tidbits.com. Je krijgt deze dan per e-mail toegestuurd.
Om je abonnement op te zeggen, kun je een mailtje sturen naar: tidbits-nl-off@tidbits.com.


Deze editie van TidBITS werd gedeeltelijk gesponsord door:


Dit nummer werd uit het Engels vertaald door:

Verder werkten mee:


MailBITS/10-Aug-98

Vertaling: [JS].

Eudora Pro Beveiligingslek alleen op Windows -- Na de waarschuwing van CIAC vorige week over het mogelijke beveiligingslek in email clients, maar dan voornamelijk op Windows, komt een nieuw beveiligingsprobleem boven in de Windows versie van Eudora Pro. In de versies Eudora Pro 4.0, 4.01, en beta versies 4.1 bestaat de mogelijkheid om Microsoft's HTML viewer te gebruiken om berichten te tonen, en deze viewer kan het toestaan automatisch bijvoegsels van een bericht op te starten, zoals Java applets. In theorie kunnen andere Windows applicaties die de Microsoft HMTL viewer gebruiken ook kwetsbaar zijn. Qualcomm heeft een updater naar versie 4.0.2 uitgebracht waardoor Eudora toestemming gaat vragen voordat het bijvoegsels opstart. Als tijdelijke oplossing kun je het gebruik van de Microsoft HTML viewer uitschakelen in de Viewing Mail instellingen in de Options dialoog in Eudora. Eudora Light is niet kwetsbaar, en Macintosh versies van Eudora zijn al jaren veilig omdat ze bijvoegsels zo behandelen dat de gebruiker specifiek ervoor moet kiezen ze uit te voeren. Echter, het verhaal blijft hetzelfde: start nooit een bijvoegsel op als je niet zeker weet dat dat veilig is. [GD]

<http://db.tidbits.com/getbits.acgi?tbart=05018>
<http://eudora.qualcomm.com/security.html>

Chinese Mailing List Beschikbaar -- Dank zij nieuwe inspanningen van ons Chinese vertaalteam is er nu een aparte lijst voor mensen die TidBITS via e-mail in het Chinees willen ontvangen, middels gebruik van de Big-5 codering standaard. Om abonnee te worden, stuur je mail naar <tidbits-b5-on@tidbits.com>, en zegt het voort bij vrienden die wellicht geïnteresseerd zijn in de Chinese versie van TidBITS. (Chinese versies van TidBITS zijn ook via het Web beschikbaar). Onze dank voor het uitstekende werk gaat uiteraard uit naar het Chinese vertaalteam, en naar de groepen mensen die TidBITS in een reeks andere talen beschikbaar maken. [ACE]

<http://www.tidbits.com/tb-issues/lang/b5/>
<http://www.tidbits.com/about/translations.html>

WebSTAR 3.0.1 Update Beschikbaar -- StarNine Technologies bracht vorige week versie 3.0.1 uit van WebSTAR. Deze gratis update van de populaire Web server, welke nieuw $499 kost bevat bug fixes, verbeteringen in de communicatie met FTP programma's, verbeterde HTTP ondersteuning, en verbeterde indexering en zoekmogelijkheden voor web sites. De download is een forse 15.3 MB groot. [ACE]

<http://www.starnine.com/webstar/webstar.html>

Now Utilities Powers On -- Qualcomm kondigde aan dat Now Utilities verkocht wordt aan Power On Software, makers van ACTION Files. Net als Super Boomerang voegt ACTION Files functies toe aan de standaard Open en Bewaar dialogen (zie "Get a Piece of the ACTION Files" in TidBITS-434). Power On zal doorgaan met de verkoop en ondersteuning van Now Utilites, dat toegevoegd zal worden aan de binnenkort beschikbare ACTION Utilities. Bezitters van Now Super Boomerang, dat niet opgewaardeerd is voor gebruik met Mac OS 8, worden naar ACTION Files gestuurd. De details van de verkoop zijn niet bekendgemaakt. [JLC]

<http://www.actionutilities.com/html/nowutilities_press_release.html>
<http://db.tidbits.com/getbits.acgi?tbart=04931>

RAM Doubler 8 Upgrade Verzorgt Snelheid en Stabiliteit -- Connectix Corporation heeft een gratis update uitgebracht van zijn geheugen-optimalisatieprogramma RAM Doubler, waarbij de snelheid verbeterd wordt en meer stabiliteit voorzien is. Deze release komt op de hielen van de RAM Doubler 8 upgrade, welke gratis is voor geregistreerde gebruikers van RAM Doubler 2.x (zie "Gratis RAM Doubler 8 Update" in TidBITS-439). Versie 8.0.1 lost problemen op die het RAM Doubler regelpaneel heeft met oudere versies van de Finder in situaties met weinig geheugen, versnelt het opstarten van applicaties op Mac's met een PowerPC en veel geheugen, en lost een zeldzaam probleem op waarbij een schrijf-beschermingsfout door andere applicaties de computer deed bevriezen. De update is een 390K grote download. [JLC]

<http://db.tidbits.com/getbits.acgi?tbart=04992>
<http://www.connectix.com/html/rd__mac__update.html>


Reageren op Spam

door Geoff Duncan <geoff@tidbits.com>. Vertaling: [DPF], [MSH] & [HB].

Bijna twee jaar geleden schreef ik een artikel in TidBITS-347 onder de titel "Those Bulk Email Blues," dat behandelde hoe je moest omgaan met ongevraagde commerciële e-mail ("spam"), en hoe je op dit soort berichten moest reageren.

<http://db.tidbits.com/getbits.acgi?tbart=00863>

Alhoewel een groot deel van dat artikel nog steeds relevant is zijn de tijden veranderd. De hoeveelheid spam neemt nog steeds toe: sinds 01-Jun-98 heb ik bijna 800 spams ontvangen, een gemiddelde van meer dan 11 per dag. Bovendien onderzoeken spammers regelmatig mijn netwerk om te zien of er mail servers zijn die ze kunnen uitbuiten - in principe zijn mijn servers afgeschermd, maar zo nu en dan zet ik een dummy server aan die een poging tot spam terugzet naar het netwerk waar het vandaan komt (en hatelijk lacht wanneer het dat doet). Ik ben bovendien partij in de rechtszaak van TidBITS om de nieuwe anti-spam wetten van de staat Washington te testen.

<http://www.tidbits.com/anti-spam/>

Wees Niet Afwachtend -- Gedurende de laatste twee jaar ben ik ervan overtuigd geraakt dat het verzuimen van het reageren op spam bijdraagt aan de verspreiding ervan. Immers, hiermee zenden Internet gebruikers een impliciete boodschap aan network providers, en daarmee aan spammers: "Dit bericht hinderde ons niet genoeg om op te reageren; het is daarom acceptabel." Als Internet gebruikers echt willen dat het spammen zal stoppen moeten ze een consistente, expliciete boodschap laten horen: namelijk, dat spammen niet acceptabel is. Gebruikers kunnen dat geluid laten horen door naar effectieve wettelijke en technologische oplossingen te werken, en door op spam te reageren.

Het probleem is in wezen hoe je spam moet rapporteren. De meest spammers proberen hun sporen te verbergen: ze gebruiken niet bestaande return-adressen, voegen namaak-headers toe en versturen de berichten via niet afgeschermde mail servers. Desalniettemin is het mogelijk om na te gaan waar je met je reactie naar toe moet. Dit vereist tijd en kennis - maar net zoals met veel andere zaken wordt het eenvoudiger naarmate je het meer doet.

Identificeren van de Server -- Allereerst moet je erachter zien te komen welke Internet server gebruikt is om de spam naar je te sturen. Dit komt naar op het doorwerken van de Received headers van het bericht. Sla return addressen of From regels over: zij zijn eenvoudig te vervalsen. Received headers staan meestal gegroepeerd aan de bovenkant van een onbewerkt e-mail bericht en staan in een bepaalde volgorde: de bovenste header is de meest recente, en in theorie zou de onderste moeten aangeven waar het bericht vandaan komt. E-mail heeft altijd op zijn minst één Received-header.

De onderste Received-header zal niet altijd overeenkomen met de herkomst van het bericht. Spammers vervalsen vaak één of meer Received-headers om het opsporen te bemoeilijken, maar dat kan niet met alle. Vervalste Received-headers staan onder de echte Received-headers en zijn vaak duidelijk anders.

De enige gegarandeerde manier om erachter te komen is vanaf de bovenste Received-header naar beneden te werken. Kijk naar de eerste Received-header die beweert dat hij het bericht naar jouw domein heeft gestuurd. Als je bijvoorbeeld een account hebt met EarthLink moet je naar de eerste header zoeken die een EarthLink systeem meldt. Hieronder staat een fictieve header die naar een locatie op mijn netwerk verwijst:

Received: from Fred (pointless.quibble.com [204.57.207.56])
  by smtp100.earthlink.net (8.8.8/8.8.8) with SMTP id MAA17789
  for <your_name@earthlink.net>; Sun, 9 Aug 1998 12:55:13 -0700

Je kan zien dat het systeem smtp100.earthlink.net een bericht ontvangen heeft van een machine die zichzelf "Fred" noemt, een naam die waarschijnlijk van de spammer komt. Echter, de mail server van EarthLink heeft die naam niet zomaar geaccepteerd en heeft een DNS lookup gedaan, en daarbij ontdekt dat de echte naam van Fred pointless.quibble.com is. Alle Internet machines hebben op zijn minst één uniek IP nummer; machines hoeven niet per sé een naam te hebben maar kunnen er ook meerdere bezitten. Er is er echter maar één de 'canonical' naam. De mail server van EarthLink heeft vervolgens pointless.quibble.com in de Received header ingevoegd samen met het IP number van de machine om het makkelijker te maken de oorsprong van het bericht na te gaan. Dat is erg goed - tegenwoordig doen gelukkig veel mail servers dat. Je weet nu dat het bericht naar EarthLink gekomen is van quibble.com, en dat is waarschijnlijk de plek waar je je spam rapport naar toe moet sturen. Laten we nu eens kijken naar een meer complex voorbeeld.

Received: from pointless.quibble.com (pointless.quibble.com [204.57.207.56])
  by smtp100.earthlink.net (8.8.8/8.8.8) with SMTP id MAA17789
  for <your_name@earthlink.net>; Sun, 9 Aug 1998 12:55:13 -0700
Received: from Fred by pointless.quibble.com id QQfbjb05104
  Sun, 9 Aug 1998 12:54:34 -0700 (PDT)

Hier kan je zien dat een machine die zichzelf Fred noemt verbonden is geweest met een machine die zichzelf pointless.quibble.com noemt. Deze machine heeft Fred niet gecontroleerd. Vervolgens heeft pointless.quibble.com contact gezocht met EarthLink die vervolgens de naam van de machine heeft bevestigd en het bericht bij jou afgeleverd heeft.

Dit tweede voorbeeld komt waarschijnlijk door "relaying,"; de spammer heeft een mail server gevonden die misbruikt kon worden, en die server bevindt zich in het quibble.com domein. Deze server is waarschijnlijk het soort machine waar een spammer van droomt omdat het niet probeert de machine die de mail heeft gestuurd te identificeren. De beheerders van quibble.com hebben waarschijnlijk niks te maken met de spammer en hebben misschien niet eens in de gaten gehad dat hun systeem misbruikt werd om spam te verspreiden. Het is echter nog steeds mogelijk om het incident aan quibble.com te rapporteren en hun aan te moedigen om de mogelijkheid om mail door te sturen via hun mail server uit te schakelen. Er is helaas niet genoeg informatie om verder te proberen de spammer op te sporen; we kunnen alleen maar hopen dat de mail server van quibble.com logs heeft die de oorsprong van de spammer zouden kunnen bevatten.

Als een deel van je mail wordt doorgestuurd vanaf een ander adres, is het mogelijk dat je een deel van de bovenste Received-headers moet negeren. Alle mail naar <geoff@tidbits.com> wordt naar quibble.com doorgestuurd. De bovenste Received regel in spam naar <geoff@tidbits.com> zegt dan altijd dat quibble.com een bericht van tidbits.com ontvangen heeft. Maar de TidBITS server was niet de oorsprong van de spam; ik moet in dit geval kijken naar de volgende Received-headers om te kunnen zien wie het bericht naar de TidBITS server heeft gestuurd.

IP Nummers & Reeksen --Zelfs een goed geconfigureerde e-mail server zal soms niet in staat zijn een juiste naam op te zoeken van de machine, die een e-mail afgeeft. Een Ontvangen Koptekst zou er zo uit kunnen zien:

Received: from 204.57.207.56 ([204.57.207.56])
  by smtp100.earthlink.net (8.8.8/8.8.8) with SMTP id MAA17789
  for <your_name@earthlink.net>; Sun, 9 Aug 1998 12:55:13 -0700

Om dit voorval te melden dien je uit te vissen wie verantwoordelijk is voor het IP nummer 204.57.207.56. Probeer eerst zelf in een DNS na te kijken of het nummer een daarmee verbonden naam heeft. Veel software gereedschap kan een DNS onderzoek verrichten. Voor de Mac beveel ik Peter Lewis's $10 Mac TCP Watcher of Peter Sichel's $20 IPNetMonitor aan. Beide bevatten ook een spoorzoek-gereedschap.

<http://www.stairways.com/mtcpw/>
<http://www.sustworks.com/~psichel/products/product_ipnm.html>

Het nakijken van 204.57.207.56 zou pointless.quibble.com moeten opleveren, wat betekent dat je de gebeurtenis aan zou moeten geven aan quibble.com. Maar laten we aannemen dat er geen naam opdook. Nu is de beste gok het raadplegen van een Whois server om erachter te komen, wie de verantwoordelijke is voor dat IP nummer. Het Whois protokol stelt je in staat een netwerk autoriteit vragen te stellen over domeinen, systemen en lokaties voor kontakt omtrent internet sites. De American Registry for Internet Numbers (ARIN) onderhoudt een goede Whois database voor domeinen geregistreerd in de USA; ARIN probeer ik altijd eerst. Andere netwerk autoriteiten zijn InterNIC, RIPE (voor Europeese domains) en APNIC (Asia Pacific). Diensten zoals Allwhois.com trachten begrijpelijk te zijn, maar zijn beter geschikt voor het bepalen of er een domein beschikbaar is, eerder dan dat ze IP nummer toewijzingen uitvissen.

<http://whois.arin.net/whois/arinwhois.html>
<http://rs.internic.net/tools/whois.html>
<http://www.ripe.net/db/whois.html>
<http://www.apnic.net/reg.html>
<http://www.allwhois.com/>

Je zal bij meerdere autoriteiten te rade moeten gaan alvorens je vindt wie verantwoordelijk is voor een IP nummer. Ook heb je misschien meer geluk als je een reeks IP nummers nagaat, met gebruik te maken van een sterretje ("204.57.207.*"), dan naar een enkel IP nummer te zoeken, al moet je voorzichtig zijn bij de interpretatie van de resultaten. Meerdere zoekpartijen via het Web zij onhandig; je kunt ook een speciale Whois client gebruiken om zo de databases rechtstreeks af te vragen. Probeer op de Mac IPNetMonitor of Peter Lewis's $10 Finger, die kunnen Whois servers onderzoeken.

<http://www.stairways.com/finger/>

Kijk je naar 204.57.207.56 of 204.57.207.* via ter zake doende Whois servers, dan vind je Northwest Nexus, dat is mijn hogere ISP. Als je een spam zou rapporteren vanuit mijn domein naar Northwest Nexus, dan zou dat vlot gaan. Echter niet alle providers zijn zo alert; als spamming van een domein of een IP nummer blijft bestaan nadat je enkele incidenten hebt gemeld, dan kun je een Whois server gebruiken om uit te vissen wie vooraf gaat aan de verantwoordelijke partij - meestal AT&T, Sprint, UUNET of een andere grote netwerk verschaffer. De meeste hoogwaardige netwerk providers hebben weinig tolerantie wat spam betreft, maar zijn mogelijk slechts in staat om klachten aan hun klanten door te geven, zoals de regionale ISP's. Volgens mijn ervaring levert het melden van spam aan netwerk providers op het hoogste niveau slechts geringe efficiëntie op.

Kun je Whois niet gebruiken om uit te zoeken wie een IP nummer controleert, dan is je laatste optie een speurroute applicatie. Speurroute zoekt in wezen het pad uit, dat pakketten aflopen tussen twee Internet machines. Dit pad zou je moeten tonen welke sites "het dichtstbijzijnd" zijn tot het IP nummer dat de spam verstuurd heeft. Realiseer je echter dat Internet routering een dynamisch iets is: al verandert het specifieke pad tussen twee machines meestal niet van het ene op het andere moment, het kan ieder ogenblik veranderen. Machines in de buurt van je doel-IP nummer hoeven niets te maken hebben met de spammer of de organisatie die verantwoordelijk is voor het IP nummer. Als je een spam incident, gebruik makend van data verkregen door speurroute meldt, doe dat dan beleefd.

Hoe spam rapporteren? -- Wanneer je een spam-incident rapporteert, vermeld dan de gehele inhoud en de header van het bericht dat je ontving: administrators(***) hebben deze informatie nodig om te incident te kunnen verifiëren. Een beleefd, professioneel bericht heeft altijd meer effect dan een venijnige scheldtirade. Ik begin mijn bericht met volgende gelikte tekst:

Ik heb de volgende ongevraagde commerciële e-mail ontvangen ("spam") die of rechtstreeks werd verzonden door een van uw gebruikers, of werd doorgestuurd door een mail server binnen uw bedrijf of netwerk, of werd verzonden vanuit een ledenlijst of onderliggend netwerk beheerd door uw organisatie. Het volledige bericht vindt u hieronder met de volledige header; gelieve ervoor zorg te dragen dat dit niet meer voorvalt.

Omdat ik in de staat Washington woon, verwijzen mijn berichten ook naar de anti-spam wetgeving van Washington en vermelden ze de schadevergoeding (per voorval) die inwoners van Washington kunnen proberen te bekomen.

Zend spam-meldingen naar de gebruikersnaam "postmaster" en, optioneel, "abuse" met de domeinnaam welke volgens jou verantwoordelijk is voor de spam. Het postmaster adres is zo goed als wereldwijd geldig voor elke domeinnaam; het abuse adres is minder gebruikelijk maar wordt soms opgericht om spam-incidenten te kunnen melden.

Voor het beste resultaat zend je best spam-meldingen naar een adres van een domein, en niet naar een specifieke computer. In de hierboven vermelde voorbeelden, kun je beter <postmaster@quibble.com> gebruiken dan <postmaster@pointless.quibble.com>. Als de spam van een site kwam met een tweeletter-landcode (zoals .us of .nl) en niet van een drieletter-toplevel-domein (zoals .com of .edu), dan zal het domein tenminste drie delen bevatten (reno.nv.us) in plaats van twee (quibble.com)

Verwijderingsdiensten -- Wat te doen met verwijderingsdiensten die vermeld worden in spam, of sites die beweren dat ze "globale verwijderingslijsten"' zijn? Twee jaar geleden heb ik deze verwijderingsdiensten aangeraden, met het idee dat serieuze bulk-mailers (er zijn er enkele) je naam verwijderden uit hun lijsten en dat diegenen die zich niet zo verantwoordelijk opstelden je e-mailadres toch al hadden; baat het niet, dan schaadt het ook niet!

Tegenwoordig kan ik geen enkele verwijderingsdienst aanraden. Hoewel er enkele zijn die doen wat ze zeggen, blijkt dat het gros ofwel niet bestaat of dat ze simpelweg adres-verzamelaars zijn. Eén ervan die ik nader onderzocht heb, bleek een gesofistikeerde methode te zijn die door verscheidene spammers wordt gebruikt: ze verzamelden alle verwijder-aanvragen en verkochten de adresssen ervan aan andere spammers als "verse adressen."

Het is niet omdat ik het zeg... -- De geschillen betreffende spam vormen dikwijls onderwerpen voor discussies. Hoewel dit artikel technische informatie en tips bevat, is dit uiteindelijk slechts mijn mening. Indien je meer wil weten - ook andere meningen wil horen betreffende het reageren op spam of de hedendaagse wettelijke en technologische initiatieven wil vernemen - zijn de verwijzingen die Adam heeft verzameld met betrekking tot TibBITS's anti-spam rechtszaak een goede start.

<http://www.tidbits.com/anti-spam/spam-info.html>

Zullen de manieren die hier beschreven zijn de stroom van ongewenste mail naar je mailbox stoppen? Neen. Is het rapporteren van spam gemakkelijk? Neen. Maar op z'n minst is het correct rapporteren van spam een alternatief voor ledenloos toezien, en je zal de voldoening hebben om te vernemen dat providers spammers opgedoekt hebben dankzij jou. Daarvoor alleen al zullen velen jou dankbaar zijn.


Bestolen!

door Adam C. Engst <ace@tidbits.com>. Vertaling [WVL] & [ED].

Sta me toe een verhaal te vertellen dat de nadruk legt op het belang van sommige artikels over back-ups en informatiebeveiliging, waarover ik het met herhaling in TidBITS heb gehad.

Een weekendje uit -- Twee weekends geleden, op een zaterdagmorgen waren Tonya en ik ons aan het klaarmaken voor een vriendenbezoek tijdens het weekend. Ik had juist een Indisch gerecht gegeten en was naar het weerbericht aan het kijken op onze "keuken-Mac" -een PowerBook 5300 die via Ethernet verbonden is met de rest van ons netwerk en tevens met Internet. Plots biepte de PowerBook en toonde een dialoog van Retrospect Client, dat zei dat ik al een heel tijdje geen back-up had gemaakt. Ik trachtte via Timbuktu verbinding te maken met onze back-up-Mac, een Centris 660AV, maar ik zag dat deze gecrasht had en ik ging naar beneden om hem terug op te starten. Even later dacht ik eraan om nog eens te gaan kijken. Oei! De crash had Retrospect's catalog file door mekaar gegooid, en Retrospect zei me die na te kijken alvorens verder te doen. Ik begon te verifiëren maar de log van Retrospect zei dat de koppen van de tape drive moesten gekuist worden. Ik begon te jammeren dat de hele wereld weer tegen mij was, stak de cleaning tape erin en plaatste daarna terug de back-up-tape om opnieuw te verifiëren. Rond die tijd kreeg ik stilaan blikken van Tonya in de aard van "We hadden al tien minuten moeten weg zijn en je zit daar nog steeds met je computer bezig", dus besloot ik dat het verificatieproces het wel alleen kon, sloot de PowerBook af, deed de deur op slot, en we waren weg.

Het weekend was vooral gemerkt door watersporten en verbranden-in-de-zon wegens een defect zonnescherm. Onze tijd was nogal Macintosh-vrij, uitzondering gemaakt van een PowerBook 165 van de zoon van onze vrienden, die diende om te communiceren via spraaksynthese en typen via hoofd-schakelaars (hij heeft een hersenverlamming en zit gekluisterd in een rolstoel). Zondagavond op de weg terug hadden wij avondeten met Geoff Duncan, die wist te vertellen dat onze 56K frame relay verbinding was uitgevallen. Ik keek het na van bij hem, en hoewel de router antwoordde op pings, was er geen enkele machine op ons netwerk dat antwoordde. Vreemd.

Terug thuis -- Toen wij thuiskwamen loste het mysterie zich op op een onaangename namier. De deur was niet op slot, op de keukenvloer stonden de dozen waarop onze PowerBook 5300 had gestaan, en de 10-Base2 Ethernet kabel was uit de muur getrokken. De PowerBook was verdwenen. Ik keek naar de overige computers, maar aan iets anders was niet geraakt, op uitzondering van een gebroken ruit aan de achterkant van het huis.

Beetje bij beetje maakten wij de wedersamenstelling van wat er gebeurd was. De dief had vermoedelijk eerst aangebeld, dan vastgesteld dat er geen licht werd aangestoken (onze tweede auto stond er, dus we hadden kunnen thuis geweest zijn), en had dan besloten het erop te wagen. Kijkend door het keukenraam had de dief de PowerBook en onze alarm-sticker gezien, en had besloten het snel af te maken. Langs achter sluipend had hij er een venster uitgekozen zonder sticker, had ingebroken en was dadelijk naar de keuken gegaan(langs Tonya's Mac passerend). Daar aangekomen had hij de PowerBook genomen met alle eraan aangesloten kabels, en dan had hij een postzegeldoos (alleen de doos, de postzegels niet - stel je voor) genomen uit een lade onder de Powerbook. Ik had die doos jaren geleden van Tonya gekregen. Toen alles gedaan was had hij de deur ontsloten en was verdwenen.

De inbraak vond plaats rond 1 h. 45' op zondagmorgen, vermits het Ethernet netwerk onderbroken was om 1 h. 48', door de onhandige manier waarop de dief de PowerBook had losgekoppeld. Dat verklaarde waarom de router wel de pings wel beantwoordde, maar alle andere machines dood waren. Later kwam de politie, noteerde de details en beloofde uit te kijken naar de PowerBook in lommerd-winkels. De dag erop legde ik de klacht neer bij de verzekeringsmaatschappij, die tothiertoe vrij aardig gereageerd heeft. We hebben dan wel een franchise van $1.000, maar ik zal toch de 5300 kunnen vervangen door een PowerBook G3.

De back-up lessen zelf verwaarloosd -- Nadat ik alles had opgeruimd en het netwerk had hersteld checkte ik terug de back-up. Retrospect's verificatie was gedaan, maar had voorkomen dat er back-ups werden gemaakt op Zaterdagavond. Toen ik de verificatieprocedure stopzette en de back-up server startte, begon Retrospect fouten te rapporteren met de tape. Kort gezegd, ik zal misschien nog wel gegevens van de tape kunnen recupereren, maar het blijft een ramp.

Herinner je je nog al die artikels die ik schreef over back-up? Hier zijn enkele voorbeelden van wat er foutging en van wat er fout had kunnen gaan.

<http://db.tidbits.com/getbits.acgi?tbser=1041>

Beveiligings-overpeinzingen -- In situaties als deze ga je je meteen blindstaren op beveiliging en wat je had kunnen doen. Hier zijn een paar wat meer realistische gedachten: (dat wil zeggen, gedachten die niets te maken hebben met een automatisch afweer- en afschrikgeschut op het dak.)

<http://db.tidbits.com/getbits.acgi?tbart=05020>

<http://www.bytebros.com/macsecu.htm>
<http://www2.security-solutions.com/security/ssproducttdcmac-1.html>
<http://www.usecure.com/mackits.html>
<http://www.kensington.com/products/>

<http://www.measure.com/>

Dit is niet een onderwerp waar ik hiervoor veel over heb nagedacht, dus ik sta open voor een discussie in TidBITS Talk. Als je een beveiligingssysteem hebt opgezet met Mac's (misschien via een Connectix QuickCam en DigitalRadar) stuur je verhaal dan naar <tidbits-talk@tidbits.com> en dan zal ik de beste doorsturen. Kijk naar de onderstaande URL om een abonnement te nemen op TidBITS Talk.

<http://www.connectix.com/html/digitalradar.html>
<http://www.tidbits.com/about/tidbits-talk.html>

Registratie Gestolen PowerBooks -- Ik vond een nieuwe service die wordt geleverd door de aardige mensen van O'Grady's PowerPage. O'Grady's Gestolen PowerBook Registry is een Web database waarmee je je gestolen PowerBooks kan registreren per serienummer en kan nakijken of de PowerBook die je van plan bent te kopen, gestolen is. Ik heb mijn PowerBook al geregistreerd en ik raad andere slachtoffers aan dit ook te doen.

<http://celebs.ogrady.com/larceny/>

Laptops zijn een steeds populairder doelwit, omdat ze klein en duur zijn. Ik heb getallen gezien die stellen dat 1 op de 14 laptops gestolen zijn en Safeware Insurance zei onlangs dat bedrijven die zij verzekerden een 1 miljard aan schadeclaims hadden ingezonden voor bijna 310.000 gestolen laptops in 1997, een stijging van 28 procent vergeleken met 1996. Laptops zijn nou eenmaal te aantrekkelijk voor diefstal, hetgeen ook bewezen wordt door het feit dat onze dief weinig anders heeft gestolen. Ironisch genoeg zei de claims coördinator waar ik mee werkte, dat Macs veel vaker gestolen worden dan PC's - misschien hebben we de dieven niet genoeg eer bewezen. Uiteindelijk is de moraal van dit verhaal dat je zoveel moet doen als je kan zonder af te glijden naar paranoia, zodat je je bezittingen geen ogenblik alleen durft te laten.


Niet-winstgevende en niet-commerciële publicaties en Websites mogen artikels overnemen of een HTML link maken als de bron duidelijk en volledig vermeld wordt. Anderen gelieve ons te contacteren. We garanderen de precisie van de artikels niet. Caveat lector. Publicatie-, product- en firmanamen kunnen gedeponeerde merken zijn van hun ondernemingen.

Vorige aflevering | Search TidBITS | TidBITS Home Page | Volgende aflevering