SpamAssassin regels voor ING phishing

Was vroeger postbank.nl populair om bij gebruikers naar gegevens te hengelen, maar sinds de definitieve uitfasering in 2010 van het merk Postbank is de plaats ingenomen door ING. Heel toepasselijk waar alle klanten en diensten in zijn opgegaan en waar vroeger alleen postbank.nl een SPF-record in DNS had is dat nu ook zo voor oa ing.nl. En gelukkig worden veel berichten automatisch al als spam-gemarkeerd, maar niet alles helaas.

Om de laatste paar phishing e-mails voor ING als spam te laten markeren zijn voorlopig wat custom regels nodig voor SpamAssassin. Gelukkig is dat redelijk goed te doen met behulp van SPF en na al die jaren wordt toch langzaam duidelijk waar SPF en DKIM goed voor zijn. Wat wel opvallend is dat andere Nederlandse banken geen SPF-records publiceren in DNS zover te achter halen is. Dit terwijl de belastingdienst dit wel doet heel toepasselijk.

Zomerstop 2011

Na wat bedenkingen krijgt zomerstop 2011 een iets andere invulling dan voorgaande jaren en voor mensen die vragen waar die traditie vandaan komt. De zomerstop is eigenlijk afkomstig uit de Usenet-wereld waarin vele kinderen tijdens de zomervakantie niets te doen hadden en Usenet onveilig gingen maken. Aan de andere kant is een jaarlijkse afkicksessie van Internet en computers ook wel belangrijk soms.

Maar wat is er anders aan 2011? Eigenlijk staat daar Internet en computers centraal, maar niet zoals verwacht. Want na een paar maanden een Android-telefoon is wel duidelijk geworden welke kant dingen op gaan en of het allemaal rozegeur en maneschijn is blijft de vraag, maar vandaag is het opschonen van de homedir begonnen door oude code in een Subversion repository te zetten en eens kijken welke code daar nog meer zijn weg naar toe gaat vinden. Zomerstop 2011 staat dus voornamelijk in het teken van het functioneel integreren van oa Internet in het dagelijkse leven.

Ook is de migratie van Ogg Vorbis naar FLAC bijna klaar voor de muziekverzameling en kunnen CD’s eigenlijk de fictieve zolder op en misschien voor sommige maar ook op tijd, want sommige oudere CD’s zijn slecht leesbaar geworden. Hiermee is ook de vraag gekomen hoe bruikbaar een CD/DVD over tien jaar nog als je deze voor archief doeleinden gebruikt. Hiermee komt ook de vraag hoe lang CD’s nog bruikbaar zijn als installatiemedium voor nieuwe machines bv.

Kortom de digitalisering gaat erg hard en het wordt tijd om CalDAV en CardDAV naar een ander niveau te tillen, want je agenda en adresboek bij Google is niet de meest fijne gedachte die er is. Aan de andere kant het op je desktop laten staan is ook niet handig, want dan is het niet bruikbaar. Na de Subversion wordt het tijd om daar eens serieus tijd aan te besteden, want e-mail staat al jaren op een IMAP-server en dat bevalt heel erg goed.

Met dat gezegd worden ook oudere tradities tijdens de zomerstop weer in ere hersteld. De RSS-reader wordt weer opgeruimd, INBOX.Lists bekijken of er zinloze mailinglists tussen zitten, Debian gaat weer strict de testing-release volgen nu GNOME 3 redelijk werkt de desktop, mijn e-reader voorzien van nieuw materiaal om lekker op het balkon van te genieten en uiteraard genieten van oa de Tour die over een kleine maand start. En alvast ruimte maken op de harddisk om het filmmateriaal van DebConf 2011 en Guadec 2011 te bekijken.

Database keys hergebruiken of toch niet?

Soms zie je een leuke webapplicatie en het blijkt ook nog redelijk te werken, maar dan komt de vraag is het veilig of is er ruimte voor verbetering? Veel mensen kijken bv naar injecties om zo achter informatie uit een database te komen, maar soms wordt het gewoon aangeboden. Zo ook bij deze webapplicatie welke we fubar noemen aangezien ik de patch nog moet insturen.

Fubar wil gebruikers redelijk anoniem bepaalde data laten raadplegen en het linken naar bv de favicon van die website zou dan ook niet verstandig zijn. Los van het feit dat het onnodig problemen kan geven bij de aanbieder van die data door de favicon te moeten verversen, maar ook voor de gebruiker als de webserver met die favicon soms niet beschikbaar is of geen content wenst te downloaden buiten het domein van zijn HTTPS-connectie. Dit natuurlijk een nobel streven en al snel zien we cache directory vullen met bestandjes zoals hieronder bijvoorbeeld:

-rw-r--r-- 1 www-data www-data   306 2011-04-26 02:28 20.ico
-rw-r--r-- 1 www-data www-data  3638 2011-04-26 02:28 34.ico
-rw-r--r-- 1 www-data www-data  3638 2011-04-26 02:28 56.ico
-rw-r--r-- 1 www-data www-data   460 2011-04-26 02:28 4.ico
-rw-r--r-- 1 www-data www-data   318 2011-04-26 02:29 13.ico

En hier valt gelijk wat op eigenlijk. Waarom oplopende nummers? Een snelle check in de database en met een webbrowser bevestigen wat het vermoede was. Maar is het verstandig om deze constructie te gebruiken? Want eigen vertelt nu welk website op welke tupel in de database is opgeslagen. Raden naar valide keys hoeft dus niet meer, want ze staan online. Om zeker te zijn toch maar even in de code gedoken en ja daar komen we oa het volgende tegen:

return ICONS_URL . "/$id.ico";

Met een iets uitgebreidere patch dan alleen hieronder wordt de database key niet meer gebruikt, maar de URL van de website welke dan door een MD5-functie wordt gehaald.

return ICONS_URL . "/".md5($url).".ico";

Als we daarna weer in de cache directory kijken zien we netjes bestanden verschijnen welke niet meer te herleiden zijn naar een database key:

-rw-r--r-- 1 www-data www-data  2011 2011-05-10 18:11 642e92efb79421734881b53e1e1b18b6.ico
-rw-r--r-- 1 www-data www-data   561 2011-05-10 18:12 ac627ab1ccbdb62ec96e702f07f6425b.ico
-rw-r--r-- 1 www-data www-data   650 2011-05-10 18:12 735b90b4568125ed6c3f678819b6e058.ico
-rw-r--r-- 1 www-data www-data  3638 2011-05-10 18:12 e4da3b7fbbce2345d7772b0674a318d5.ico
-rw-r--r-- 1 www-data www-data   444 2011-05-10 18:12 9a1158154dfa42caddbd0694a4e9bdc8.ico

Het risico wat hier om de hoek komt is dat de hash ook verandert als de locatie van favicon van de website verandert. Je zou dit dus dan kunnen gaan gebruiken om foutieve image bestanden te cache waar je op een gegeven moment geen erg in hebt. Dit is ook een reden waarom de huidige patch nog niet de deur uit is, want wijzigingen in de URL moeten ook betekenen dat het oude bestand wordt opgeruimd.

De vraag die nu komt is welke database gegevens worden er nog meer gelekt en bij welke applicaties? Dit doet me ook een beetje denken aan de HashKnownHosts optie in OpenSSH welke alle nodes in het bestand known_host ook hashed. Hiermee komt eigenlijk ook de vraag of cachedata wel een zinvolle naam moet hebben.

Bayesian database na ruim een jaar

Na meer dan een jaar na het op de automatische piloot zetten van een bayesian filtering oplossing voor alle inkomende e-mail begint het langzaam aan tijd te worden om de balans op te maken. Dus eerst even wat grafiekjes en eerste laat de hoeveelheid tokens in de database.
De tweede grafiek laat het aantal geleerde berichten zien en dit zijn zowel berichten die via spamtraps en hamtraps binnen zijn gekomen.
Hier komt ook gelijk het opvallende punt. Het aantal berichten blijft gelijkmatig oplopen op de kleine sprong in april na, want toen waren de spamtraps als test niet voorzien van DNSBL-filtering. Voorlopig lijkt hiermee opzet redelijk stabiel te zijn en met een plugin voor Roundcube kunnen gebruikers nu ook fouten netjes zelf melden en worden die verwerkt in de database.

Over de effectiviteit zijn op dit moment geen harde cijfers en de vraag is dan ook hoe die te meten zijn. Dus wat is er nog te verbeteren aan de opstelling? Op dit moment worden performance gegevens over hoeveelheid berichten die worden geweigerd of aangenomen nog niet verwerkt, maar ook niet hoeveel berichten als spam worden gemarkeerd en wat de gemiddelde doorloop tijd is om een bericht te verwerken. Binnenkort dus maar eens een blik werpen op een aantal logfiles om te kijken of dit mogelijk is om zo beter inzicht te krijgen.

Tux moet aan de Sonja Bakker

Waar is de tijd gebleven dat zeg 64MB nog voldoende was of dat een Pentium MMX op 233 MHz nog je hele digitale wereld kon voortduwen. Die tijd lijkt ver achter ons te liggen, maar is dat echt zo? De 8GB in mijn huidige workstation lijkt in sommige gevallen amper nog voldoende te zijn om de machine van geheugen te voorzien en het lijkt alleen maar erger te worden over de jaren.

Waar vroeger KDE 2.2 nog gerust drie maanden kon draaien lijkt het nu soms onmogelijk te zijn om KDE of GNOME gewoon een week te laten draaien zonder echte gevolgen. Helaas lijkt het bij het inloggen niet veel beter te worden, want er moeten veel caches worden nagelopen, extra daemons worden opgestart en vele andere dingen.

Misschien wordt het tijd dat Tux echt een naar de Weight Watchers gaat of een boek van Sonja Bakker voor kerst krijgt, want het “lichte” karakter is al jaren verdwenen. De vraag is misschien wat je er aan doet zonder vele vrijwilligers die hun kostbare tijd investeren voor het hoofd te stoten. Misschien een aardig punt om zo meteen 2011 mee te beginnen?