Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 45 reacties
Submitter: Netraam

Door een mogelijke aanval op het netwerk van de Universiteit Utrecht waren woensdag duizenden studenten en werknemers verstoken van toegang tot het netwerk. Ook waren interne applicaties onbereikbaar en was mailen onmogelijk.

De storing als gevolg van de mogelijke aanval begon op woensdagochtend rond 9 uur. "Deze storing werd veroorzaakt door een server buiten de Universiteit Utrecht die probeerde permanent vele verbindingen tegelijkertijd met ons netwerk te maken", aldus Ineke Molenaars, directeur Informatiemanagement & ICT-dienstverlening van de universiteit.

Door deze storing waren diverse applicaties onbereikbaar, kon er niet ingelogd worden op het netwerk en was er geen mailverkeer mogelijk. Volgens Molenaars duurde het tot het eind van de middag voordat de server was ontdekt en 'onschadelijk' gemaakt. Of de server onderuit is gehaald door een technische fout of moedwillig door hackers, wordt nog onderzocht.

Moderatie-faq Wijzig weergave

Reacties (45)

Nu ben ik absoluut geen expert, maar volgens mij moet het doodeenvoudig zijn te achterhalen dat alle query's van één ip-adres komen. En vervolgens moet het ook doodeenvoudig zijn dat ene ip-adres te blokken.

Als je een hele werkdag nodig hebt om dat voor elkaar te krijgen, ben je niet goed bezig. :X
Tja, da's natuurlijk makkelijk om nu te zeggen.

We kunnen hier nu lezen waar het aan heeft gelegen.
Maar daar moet je natuurlijk ook eerst achter zien te komen.

Een universiteits netwerk is niet bepaald een doorsnee thuisnetwerk met 1 router/firewall en enkele systemen er achter.
Maar een complex geheel van allerlei aan elkaar geknoopte gebouwen/netwerken met vele (verschillende) servers.

Dus ik vindt het eigenlijk niet zo vreemd dat ze daar een dag zoet mee zijn geweest.

Het lijkt me niet dat ze dan even op een webinterface inloggen, om vervolgens maar eens even te kijken welke van de 10 firewall log regels het probleem laat zien.

Dat zal waarschijnlijk een kwestie zijn van meerdere logs op verschillende plekken door gaan spitten op overeenkomsten/verschillen. Logs die natuurlijk ook vol staan met veel legitieme meldingen dat zaken niet bereikbaar zijn.
stelsel-matig uitschakelen van segment om zo het probleem te resolven lijkt me wel effectiever , het netwerk lag al plat dus of je nou de kabel van een segment even uittrekt of niet heeft dan ook geen belang.

als je dan het segment te pakken hebt is het meeral een kwestie van minuten om het probleem te vinden evenredig met de grootte van het segment.
Maar een complex geheel van allerlei aan elkaar geknoopte gebouwen/netwerken met vele (verschillende) servers.
Een zooitje, dus, wil je zeggen. Maar dan wel politiek correct :X

Enne... voor alle andere "specialisten": hoe denk je een probleem aan je netwerk te kunnen tackelen, als je netwerk het niet doet?!? Logs doorspitten kan dus wel eens lastig worden, niet?
Doordat er een server alle logs bijhoudt, tegen de tijd dat die server geen contact meer heeft zou je voldoende informatie moeten hebben... mist goed ingericht natuurlijk.
Ik vermoed dan ook een kwestie van een gebrek aan monitoring.
Ter illustratie, een uni waar ik gewerkt heb heeft een heel monitoring centrum, maar uit de praktijk is al meerdere malen gebleken dat die niet goed ingericht was (veel vergeten zaken zeg maar). prutsers... :+

[Reactie gewijzigd door cibrhusk op 17 april 2011 19:45]

Hmm, je weet niet wat er aan de hand was eh? Ik neem aan dat ze bij de uni wel de nodige kennis in huis hebben/ingehuurd hebben. Kan me niet voorstellen dat het zo simpel is als jij schetst; dan had iedereen het wel voor elkaar gekregen.
Een heel groot deel van het netwerkbeheer van de UU is outsourced tegenwoordig. Bij een dergelijke storing kom je dan gewoon in de wachtrij te staan.

Het is niet de eerste keer dat een relatief eenvoudig op te lossen storing langere tijd aanhoud. Vorig jaar kwam het regelmatig voor dat Osiris (roosters, cijfers, inschrijven) er soms dagen uit lag en ook de websites met vakinformatie lagen regelmatig plat.

Persoonlijk vermoed ik dat dit een intern systeem is geweest of een systeem wat via VPN verbonden is. Elke student kan over VPN inloggen op zijn/haar homedir etc, dus een netwerk platleggen kan dan ook.
Dan zul je als netwerkbeheer eerst moeten uitvogelen of dat interne IP een VPN is of een systeem op locatie.
Je doet het moeilijker lijken dan het is. Computers die via een vpn verbonden zijn komen normaal gesproken in een eigen ip range terecht. Weten of iets dus lokaal of extern is kost misschien 1minuut. Dat wil niet zeggen dat men dit in een veel kortere tijd had moet kunnen fixen, wel dat het probleem waar jij op doelt geen probleem zou moeten zijn.

Het probleem is meer het localiseren van het probleem. Als het hele systeem plat ligt, zie je overal fouten en is het lastig om te zien wat het kernprobleem is.
Afgezien daarvan - het kwam van buitenaf. Dan gooi je de poort toch dicht? trek die kabel eruit en klaar is Ineke
1 server van buitenaf? Dat is toch zo opgelost? Volgens mij kan dat zelfs automatisch...
Inderdaad, automatische DDoS (laat staan DoS) protectie is volgens mij vrij algemeen?
Probleem is dat DDoS bescherming natuurlijk niet alles filtert.

Als jij een webpagina online zet die bijvoorbeeld 1000 query's uit voert, en ik verbind daar 2 keer per seconde mee, dan kan dat best funest zijn voor jouw systeem, maar jouw DDoS zal er niets mee doen.

Vergelijk het maar met Belgie laatst; een ongelukje kan een desastreuser effect hebben dan een vooraf opgezette aanval, puur omdat het zo onvoorspelbaar is.

Overigens wel teleurstellend dat het een dag duurde, maarja, da's makkelijk praten vanaf hier :?
Vergelijk het maar met Belgie laatst; een ongelukje kan een desastreuser effect hebben dan een vooraf opgezette aanval, puur omdat het zo onvoorspelbaar is.
tja, een ongelukje kan inderdaad voor veel problemen zorgen. Maar ik ben erg benieuwd hoe dat nu van één externe server gekomen moet zijn.

Doet me trouwens denken aan die keer dat bij ons op school de server was omgevallen........ letterlijk 8)7
De hele dag niets te bereiken |:(
1 server is DoS, niet DDoS. Daar is inderdaad makkelijk beveiliging voor op te zetten. Voor een DDoS aanval is er niet altijd een simpele oplossing.

[Reactie gewijzigd door Smilezz op 15 april 2011 09:19]

Ik begrijp het ook niet. Mensen konden niet inloggen en zelfs data-/fileservers op het netwerk waren down (konden niet meer gepingd worden). De website van de UU deed het wel nog, maar op de pagina "storingen" verscheen de hele dag niets.

Ik ben geen expert in netwerken, maar het moet toch niet kunnen dat 1 server een organisatie met duizenden users een hele dag uit de lucht houdt? Ik zou verwachten dat mail- en dataverkeer losse onderdelen waren?
Wat ik nog het meest apart vind: de email van de uni gaat sinds begin dit studiejaar via google. Hoe kan het dan dat die ook uit de lucht lag?
Door deze storing waren meerdere applicaties niet bereikbaar, kon er niet ingelogd worden op het netwerk en was er geen mailverkeer mogelijk. Ook de gebruikelijke berichtgeving op deze website kon hierdoor niet uitgevoerd worden.
Misschien dat men bedoelde dat binnen de uni geen connectie kon worden opgezet naar de Gmail servers waardoor mailverkeer niet mogelijk was.

[Reactie gewijzigd door Facer op 15 april 2011 11:22]

Nog lang niet alle e-mail van de uni gaat via Google. Medewerkers gebruiken nog steeds vaak het oude systeem, en ook lang niet alle studenten zijn al overgezet. Het was dus ook dat systeem dat plat lag. Ik kon gewoon bij mijn studenten-Gmail, maar mijn homedir was bijv. wel onbereikbaar en ik kon ook niet inloggen op Blackboard.
Dat is dus wel een tegenvaller als je op Blackboard zaken in moet leveren ivm plagiaat controle.
Ah ok, nooit geweten dat niet iedereen over was. Ik kreeg een mail (en ik dacht iedereen) waarin stond hoe en uiterlijk wanneer je moest overstappen. Helaas ging dat niet vlekkeloos, maar ik dacht dat inmiddels iedereen wel over zou zijn.
Klinkt als het niet goed gescheiden hebben van interne en externe applicaties?
Hoe kan een externe server die verbinding probeert te maken je interne netwerk plat leggen?
Was ook het eerste wat bij mij te binnen schoot. Vooral omdat ze zeggen dat het maar 1 server was.
1 server kan heel veel verkeer genereren hoor. Aan de andere kant weet je niet hoe de infrastructuur van de Uni is opgezet, misschien was de loadbalancer een dag vrij, of de firewall ziek.

Onhandig wel in ieder geval, tentamenweken enzo? Ideaal :+
Was best wel frustrerend midden in een tentamenweek met handige info op het interne netwerk...
Ik heb er niets van gemerkt. 'Vroeger' had informatica een eigen systeembeheer. Wellicht dat we daar nog steeds de vruchten van plukken.

Overigens ben ik wel nieuwsgierig wat voor een server dat dan wel niet geweest moet zijn. Je zou verwachten dat het identificeren en blokkeren van verbindingen van een enkele server routine is. Wat als het nu eens een paar duizend servers zijn...
Zou dat geen student geweest kunnen zijn die een soort crawler had gemaakt om bijvoorbeeld het rooster van de UU bij te houden en dat veel te vaak per seconde controleerd op wijzigingen.
Jij hebt een hobby project opgezet? :o
Belachelijk was dit. 's Ochtends eerder naar de Uni gegaan om te leren, want had 's middags een tentamen. Nou het schoot dus niet op... Vreemd dat een instantie met zoveel geld het probleem niet snel kan oplossen, dan wel voorkomen.
Vreemd dat een instantie met zoveel geld het probleem niet snel kan oplossen, dan wel voorkomen.
Veel geld? Ik neem aan dat jij nog een eerste of tweedejaars bent? De UU is nog niet failliet, maar veel scheelt het niet. De schuldenlast is gigantisch en er is een structurele begrotingstekort. Nee, veel geld is er niet eigenlijk. Daarom zijn alle IT diensten feitelijk uitbesteed aan CapGemini, zodat daar geld op kon worden bespaard (of dat ook werkelijk heeft geholpen, laat ik hier maar in het midden). Maar dat daardoor deze zaken zo lang duren, verbaasd me eigenlijk helemaal niet.
dat is 1 hele goede server, of 1 heel slecht netwerk.
Dat komt wel heel beroerd uit zo in de tentamenweek. Maar ik snap niet hoe 1 server het hele netwerk van een grote universiteit op zijn gat krijgt. Is dat dan zo slecht beveiligd?
eerder slecht geprogrammeerd en/of slecht opgezet.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True