Managed hosting door True

Rabobank gaat volledig offline na storing

 

Rabobank

Onderhoud aan de website veroorzaakte bij Rabobank donderdagochtend 7 april 2011 een storing in het internetbankieren. Klanten kregen de bankrekening van een ander te zien. Rabobank haalde direct het internetbankieren offline en zegt het probleem inmiddels te hebben opgelost.

Onderhoud aan de Rabobank-website was de aanleiding van de storing. De bank zoekt nog uit wat het onderhoud precies inhield en wat er dus voor heeft gezorgd dat het fout ging bij het internetbankieren. Voor de zekerheid heeft Rabobank zowel het internetbakieren uit de lucht gehaald, als de normale website, de mobiele apps en de telefonische bankierfunctie. Voor zover bekend konden er tijdens de storing geen betalingen worden gedaan vanaf andermans rekening.

Eerdere storing

In oktober 2010 had Rabobank ook te maken met een storing. Toen kon een deel van de Rabobank-klanten niet inloggen bij het internetbankieren. Het probleem zat toen in de automatische systeemkoppeling tussen de wereldpassen en internetbankieren. Passen die op 5 en 6 augustus 2010 waren aangemaakt, kampten met het probleem. Volgens de Rabobank waren toen enkele tientallen klanten de dupe.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3878845). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


Partnerinformatie
 

Reacties

voor dat alle metersdikke Rabobank storing procedures zijn bekeken, en alle Itil systemen zijn gevuld met allerlei storing gegevens, zal er na een paar dagen wel iemand naar het probleem kunnen kijken.

Fijne bedoeling als je opeens andermans rekening tot je beheer hebt. Oeps!!!

Zou het echt het onderhoud aan de website zijn wat de storing veroorzaakte ? Of zou er in de achterliggende systemen iets zijn 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.
En waar ik ook benieuwd naar ben is of dit te maken heeft met het outsourcen/offshoren van het software-onderhoud naar India. Maar dat zullen we waarschijnlijk niet te horen krijgen.

Gokje zonder info en betrokkenheid bij de rabobank : kernel caching op een IIS webserverfarm. Ook een keer meegemaakt : 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 uit gezet en dit probleem in de top 10 gezet van application pitfalls. Alsof dit te maken heeft met een applicatie en niet met de applicatieserver zelf : Yeah right...

@Chris :
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. De gegevens van een andere klant kunnen zien is een blamage voor mijn voormalige collega's, maar om een transactie te kunnen doen, moet je toch echt nog even bewijzen dat jij jij bent, en dat gaat niet werken. Dit is de prijs die de bank betaalt voor het bezuinigen op zijn IT-organisatie.

"Ik kan je verzekeren dat zo'n grote bank geen IIS servertjes heeft"

- Rabo gebruikt zeker IIS 5.0!
http://toolbar.netcraft.com/site_report?url=http://rabobank.nl

- Daarnaast komt je verhaal nogal management achtig over ipv technisch

- Ten derde doe je nogal raar over IIS. 20.2% van de websites, voornamelijke grote bedrijven, gebruiken IIS

- Ten vierde de rabobank is ook niet echt lekker bezig, in de pool van webservers hebben ze de meeste servers hun OS afgeschermd, behalve 2. Rara welk OS hebben die?

Ennuh sns bank gebruikt ook IIS (6) lijkt me ook niet echt een kleine bank..

http://uptime.netcraft.com/up/graph?site=www.snsbank.nl

En verder wordt IIS ook nog gebruikt door
http://uptime.netcraft.com/up/graph?site=frieslandbank.nl
http://uptime.netcraft.com/up/graph?site=asnbank.nl

Ook niet echt onbekende spelers..

Volgens mij is Schuberg Phillis de beheerorganisatie van de site en de mobile site da's nou net geen 100%:
http://www.schubergphilis.com/customers/cases/rabobank-international/

begint outsourcing en wegvloeien van kennis parten te spelen?

Ik mag er niet teveel over zeggen, want ik heb natuurlijk ooit schriftelijk moeten beloven dat ik dat niet zou doen, maar ik kan nogmaals bevestigen dat het geen IIS is, en dat het ook niet onder een Microsoft OS draait.
RaboMobiel wordt door een externe partij verzorgd, het echte geld gaat alleen door de servers van de bank. Je komt niet meteen op een webserver, er zit nog een laag tussen. We wordt binnen het systeem geroute, afhankelijk van wat je komt doen. Wil je wat lezen over hypotheken, dan hoef je niet door de zwaarste beveiliging heen.

SNS is inderdaad geen grote bank.

Het maakt helemaal niks uit welke webservers gebruikt zijn voor een dergelijke fout, of er nou IIS of iets anders gebruikt wordt. 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...

Knutsel

Onzinverhaal. Je zei dat de Rabobank geen IIS gebruikt. Dat doen ze dus wel, over welke laag is nu geen relevante discussie aangezien je zei dat ze het NIET gebruiken.

@knutsel e.a.
Ik zeg ook niet dat alle applicatie servers een IIS frontend farm gebruiken. Kan me voorstellen dat voor een hybride oplossing is gekozen en dat de financiele 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.

ECHTER, dit probleem lijkt alles te maken te hebben met de frontend servers, die delen de sessieIDs uit. Veel architecten vinden frontend servers minder belangrijk ,zetten daar de 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. (hoop ik) 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.

Ik weet niet of dat hier ook gebeurt is, maar ik geef alleen aan dat deze casus me iets te bekend voor komt. 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 i.s.m. Microsoft Redmond die daarna heeft besloten deze kernel caching in volgende versies uit te zetten !

Ik denk ook wel dat de fout in verwisseling van sessies zit. Misschien stelt iemand zich voor dat een bank draait op 2 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 2 machines hetzelfde ip-adres geven, na een verhuizing. Ik denk niet dat dit de schuld is van een programmeur.

@SP: Rabobank en Rabobank International, zijn 2 totaal verschillende partijen, zelfs hun bestuur is niet gelijk, dus wat probeer je nu met Schuberg Phillis aan te geven?

Daarnaast is Schuberg Phillis één van de meest hoogstaanste beheer partijen die Nederland ooit heeft gekend, kijk maar eens naar hun klanten portifolio, dat is niet voor niks, met zulke extreem grote namen er in.

Geeft me wel te denken over welke kennis jij beschikt...

Ik kan me ook voorstellen dat dit een ordinair caching probleem is. Er wordt een sessieId uitgedeeld, die staat nog in cache (van een tijd geleden) en wordt wordt vervolgens doodleuk verkeerd gekoppeld. Het niet schonen van cache kan dergelijke problemen opleveren.
Dat zou even logisch als simpel als stupide zijn.

Wat de (technische) oorzaak ook geweest is, dit mag nooit en ten nimmer gebeuren. Dat zou (en zal waarschijnlijk) ook wel als hoofdrequirement gesteld zijn, maar is onvoldoende uitgewerkt naar subrequirements die zowel technisch als procesmatig kunnen zijn. In de praktijk zie je vaak dat als er aandacht wordt besteed aan requirements, dat het dan vaak nog high level requirements zijn. We weten echter dat de devil in the detail zit en dus zou er meer aandacht besteed moeten worden aan risico-analyse, subrequirements en last but not least degelijk testen. Dat testen zal wel gebeurd zijn, geen twijfel, maar het verschil tussen testen en goed testen kan ook bij grote bedrijven nog het verschil maken.

Betalen met mijn PINpas lukte donderdagmiddag 7 april niet; mijn pas werd geblokkeerd omdat ik een verkeerde code zou hebben gebruikt. Gelukkig kon de blokkering wel opgeheven worden. Later in de middag werkte de PINcode weer prima.

Lees ook eens de reacties bij:
http://www.computable.nl/artikel/ict_topics/internet/3879480/1282763/markt-gist-naar-oorzaak-storing-rabobank.html?utm_source=Nieuwsbrief#3880068

Internetbankieren, het versturen van email en andere internettoepassingen waarvan verwacht wordt dat het allemaal de gewoonste zaak is van de wereld is in werkelijkheid op de achtergrond nog steeds een complexe zaak. Het draait allemaal om komma's, puntjes, codes , regeltjes, procedures, processen etc. Erg fragiel dus. Daarom kan nooit 100% garantie worden gegeven worden.

En als het een keer fout gaat, dan gaat het goed fout en sta je met je gezicht in de media en word je slachtoffer van de belevenis en perceptie van de maatschappij die over je heen valt. Want als je als bedrijf honderden miljoenen per jaar spendeert aan IT, hoe kan zoiets 'simpels' dan fout gaan?

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×