De aanleiding voor de storing waar Rabobank donderdag 7 april 2011 mee te maken had, blijft vooralsnog onbekend. De bank is intern wel een technisch onderzoek gestart, maar weet vooralsnog niet hoe alles kon mislopen en negenhonderd klanten via internetbankieren de rekening van iemand anders voorgeschoteld kregen. Ondertussen speculeren lezers van Computable over de oorzaak.
Lezer Marcel merkt op dat onderhoud aan de website zeer waarschijnlijk niet de storing heeft veroorzaakt en dat er zeer waarschijnlijk in de achterliggende systemen iets is misgegaan. ‘Een website verzint natuurlijk niet zomaar om de gegevens van een andere klant op te halen, dat ligt waarschijnlijk in de back-office daarachter waar een query niet goed gaat.'
Check, check en dubbelcheck
‘IT-er' is het met Marcel eens. ‘Waarschijnlijk is er een verkeerde query gedraaid waardoor na inloggen de verkeerde rekeninggegevens opgehaald worden. Als dat het geval is, is de oplossing simpel voor in de toekomst: check, check en dubbelcheck nog beter je queries voordat je deze uitvoert.'
Lezer Chris denkt dat het probleem te maken heeft met kernel caching op een IIS-webserverfarm. ‘Onder grote load worden dezelfde sessionIDs verstrekt voor meerdere sessies. Dit stond standaard aan (machine.config) op IIS-servers van voor versie 6. Het zou me niet verbazen als banken nog achter zouden lopen en een boerderijtje met IIS 5-machines hebben draaien. Inmiddels heeft Microsoft deze configuratieoptie standaard uitgezet en dit probleem in de top tien gezet van application pitfalls.'
Hybride oplossing
Het idee dat het aan een IIS-server zou liggen, wordt door ‘knutsel' ontkend. ‘Ik heb als beheerder gewerkt op de afdeling waar dit fout gegaan is. Ik kan je verzekeren dat zo'n grote bank geen IIS-servertjes heeft. Ze hebben fouttolerante systemen, meerdere beveiligingslagen en uitwijklocaties.'
‘Chris' laat zich niet te snel afpoeieren door ‘knutsel'. ‘Ik zeg niet dat alle applicatieservers een IIS frontend farm gebruiken. Ik kan me voorstellen dat voor een hybride oplossing is gekozen en dat de financiële transactiesystemen strict gescheiden moet zijn qua technologie als de frontend servers. Anders kom je de audits al meteen niet door. Dus die queries waar IT-er mee komt, lijken me ook niet de oorzaak.'
Iemand anders worden
Toch denkt lezer Chris wel het probleem te herkennen. ‘Dit lijkt alles te maken te hebben met de frontend servers, die delen de sessieIDs uit. Veel architecten vinden frontend servers minder belangrijk ,zetten daar het stempel ‘niet business/mission critical' op, want deze hebben de functie om gegevens vanuit backend systemen alleen maar te tonen; wie wat mag zien wordt daar niet geregeld. Dat ze ook nog een functie hebben om het http-protcol statefull te 'laten lijken', wordt vaak vergeten of geacht dat een webserver dat automagisch regelt. Dat klopt, maar dus niet altijd! Aannemlijk is dat dat de login een sessionID heeft opgeleverd die meerdere keren is uitgegeven. Tijdens je sessie was de gebruiker eerst nog jezelf op de frontend server, maar na een aantal requests kun je dan iemand anders worden, omdat de webserver de requests niet meer uit elkaar kan halen.'
‘Chris' weet niet of dat hier ook gebeurd is, maar deze casus komt hem wel iets te bekend voor. ‘Ook omdat je dit in labtests bijna niet kunt reproduceren, omdat dit alleen voorkomt onder specifieke high-load omstandigheden. Voordat ik deze conclusie in mijn geval kon trekken, heeft mij dit een half jaar onderzoek gekost in samenspraak met Microsoft Redmond, die daarna heeft besloten deze kernel caching in volgende versies uit te zetten.'
Hetzelfde ip-adres
Lezer knutselis het met ‘Chris' eens. ‘Ik denk ook wel dat de fout in verwisseling van sessies zit. Misschien stelt iemand zich voor dat een bank draait op twee pc's en dat de hele administratie van de bank bestaat uit een paar MySQL-tabellen. Zo is het niet. Alles draait om onvoorstelbaar grote getallen en een tekening met alle betrokken hardware voor telebankieren beslaat meerdere A3'tjes. Wat denk je dat er gebeurt als alle 5 miljoen klanten van een bank kerstinkopen gaan doen? Daar zijn die systemen op berekend. Ik denk eerder dat het iets banaals is als twee machines hetzelfde ip-adres geven, na een verhuizing. Ik denk niet dat dit de schuld is van een programmeur.'
Ik weet niet wat Knutsel zoal knutselt, maar het heeft weinig met ICT te maken, vermoed ik. Chris zijn veronderstellingen worden ook volledig ondersteund door wat Peter heeft vastgesteld.
Een tijdje terug had DUO (IB-Groep) een vergelijkbaar probleem. Je kreeg als ouder of student de gegevens van iemand anders te zien. Is dezelfde programmeur of beheerder intussen actief bij de Rabobank?
Dus dit is de nieuwe manier van journalistiek bedrijven? Je schrijft een artikel op basis van de reacties op een ander artikel. Ik lees liever de reacties zelf en vorm mijn eigen mening…
Jaar geleden was er een dergelijk iets met klantgegevens bij Ziggo. Gebruikers kregen een inbox van andere personen te zien. Was toen net na de lancering van de nieuwe website.
Goed kwalitatief artikel! Hier hebben we wat aan als lezers. Worden de reacties op dit artikel nu weer gebruikt voor het volgende artikel?
Zie
http://en.wikipedia.org/wiki/Round-robin
onder Computing
of
http://en.wikipedia.org/wiki/Round-robin_DNS
en koppel dit verhaal bijv. aan de uitgifte van interne ip-adressen vs. externe ip-adressen door software.
Daar lijkt het op gezien vanaf de buitenkant.
@Richard: Round-robin DNS heeft niets met de uitgifte van ip-adressen te maken. De naam ‘resolved’ alleen steeds naar een ander adres. Je advies om dat ‘verhaal’ effe te koppelen, is lastig.
Ik sluit me aan bij Niels. Dit is journalistiek van SBS niveau. Schrijf dan geen artikel. Het enige wat nog ontbreekt is het telefoonnummer dat je kunt bellen als je familie bent van de verantwoordelijke beheerder.
Misschiem moeten ze wat meer geld gaan besteden aan de ICT i.p.v. het uit te geven aan bonussen
In reactie op veel artikelen van de laatste tijd verwacht ik eersdaags de kop “Telegraaf neemt Computable over” te zien, of iets over een Computable redactie icm kwaliteit.
Volgende keer graag random reacties aan elkaar koppelen, dan loop je tenminste nog het risico dat er per ongeluk een goed artikel uit komt volgens het Infinite monkey theorema.