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 , , 85 reacties
Bron: Computerworld, submitter: BillGaetes

Diverse experts uit zowel het bedrijfsleven als de regering hebben openbaar gemaakt dat de Blasterworm misschien medeverantwoordelijk is voor de stroomstoring die midden augustus een deel van de Verenigde Staten overviel. De experts bevestigen dat de worm de performance van verschillende communicatielijnen tussen de datacentra van de elektriciteitsbedrijven heeft verminderd, zo is te lezen op Computerworld. Gary Steifer van het U.S. Department of Energy's Idaho National Engineering and Environmental Laboratory zegt dat Blaster niet de controlesystemen zelf aantastte, maar wel de snelheid waarmee zij de data ontvingen van andere netwerken.

Worm De data bevatte gegevens over flow-control en load-balancing en werd verzonden over publieke telecommunicatienetwerken. Doordat de controlegegevens niet snel over het netwerk verspreid konden worden, hadden de operators minder kans om het sneeuwbaleffect van de storing te voorkomen. Een voormalige adviseur van het U.S. Department of Homeland Security zei dat het virtuele kronkelbeest ook het herstel van het elektriciteitsnet in de regio New York heeft vertraagd. Sommige energiebedrijven uit deze regio werkten namelijk op Windowssystemen met poort 135 open, waardoor de worm de systemen kon aanvallen.

Carol Murphy, vice-president van de New York Independent System Operator, gaf toe dat Blaster de faciliteit wel had aangetast, maar het probleem was snel opgelost en het had geen invloed op het herstel van de stroomtoevoer naar de stad. Een anonieme industry executive vertelde Computerworld dat de Slammerworm in januari al schade had toebracht aan elektriciteitsbedrijven. Omdat deze schade niet resulteerde in een storing, bleef de boel onopgemerkt. FirstEnergy Corporation was een van de slachtoffers toen. Gelukkig was hun kerncentrale toentertijd niet actief:

Stroomvoorziening One of those companies was Akron, Ohio-based FirstEnergy Corp. Although FirstEnergy has said publicly that Slammer didn't infect any of the control systems at its Davis-Besse nuclear power plant in Oak Harbor, Ohio, knowledgeable sources said the worm did cause disruptions. However, the plant was in "cold shutdown maintenance mode" and wasn't producing electricity at the time, the sources said. FirstEnergy didn't respond to a request for comment.
Moderatie-faq Wijzig weergave

Reacties (85)

Bah. Een regelrechte schande. Als je als datacentre van iets belangrijks zoals een elektriciteitscentrale je servers nog niet kan patchen! Onvoorstelbaar!
M'n baas zou me villen moest ik de windows servers in het ziekenhuis niet patchen! |:(

En ok, een groot deel van de schade zal wel toegebracht zijn niet door kwetsbare systemen maar door de grote toevloed een traffic van die worm ... maar dan nog. Dan configure je je firewall rules ff wat anders en het probleem is opgelost. Bah.
Het ging hier niet om de servers van de centrale (die eerder QNX dan Win2k zullen draaien), maar om de overbelasting van de communicatie-lijnen.
Het klinkt mij vrij onlogisch in de oren, want dit is zeker niet het eerste virus/worm dat veel bandbreedte opslokt.

In Nederland loopt een mooie glasvezel van hoogspanningsmast naar hoogspanningsmast (die bovenste kabel in het midden). Het lijkt mij dat je een bepaald deel van die capaciteit vast reserveert voor communicatie tussen centrales...
M'n baas zou me villen moest ik de windows servers in het ziekenhuis niet patchen!
Ik werk ook in die branche en het zal je verbazen hoe terughoudend men is met patchen...
Ja omdat men vreest voor stabiliteitsproblemen. Die zouden dan, volgens de experts uit de praktijk, moeten voortkomen uit servicepacks en patches die bij Microsoft uitgebreid getest zijn. Wie mij deze achterlijke "wij weten het beter" mentaliteit uit kan leggen, ga vooral je gang :?
Uitleg: bij zoiets belangrijks als ziekenhuissystemen wil je zo min mogelijk risico nemen. Software is imperfect, bugs worden altijd gevonden, ook in servicepacks en patches die bij Microsoft uitgebreid getest zijn. En zo'n servicepack of patch kan niet alleen bugs bevatten die daarvoor al bestonden in vorige servicepacks/patches, maar ook nieuwe bugs introduceren.
Elke keer als je dus een servicepack of patch installeert, neem je een risico. Je neemt het risico dat je systeem dan totdan toe altijd stabiel draaide, en waar je nu de servicepack of patch op geinstalleerd hebt alleen maar om 'bij' te zijn ook al had je nergens last van, ineens kuren gaat vertonen.
Dat risico kun je verminderen door wanneer Microsoft een nieuw servicepack of patch uitbrengt, deze niet meteen te installeren maar de kat uit de boom te kijken en zien wat de ervaringen zijn bij diegenen voor wie het risico minder van belang is.
Ja omdat men vreest voor stabiliteitsproblemen. Die zouden dan, volgens de experts uit de praktijk, moeten voortkomen uit servicepacks en patches die bij Microsoft uitgebreid getest zijn. Wie mij deze achterlijke "wij weten het beter" mentaliteit uit kan leggen, ga vooral je gang
Lees eens goed wat je schrijft, als de MS testprocedures zo betrouwbaar zouden zijn, waren die patches natuurlijk uberhaupt niet nodig. Alsof elke windows versie niet nog VEEL uitgebreider getest is door MS dan een patch die haastig wordt uitgebracht.

Waarom heb jij blind vertrouwen in een patch die niet nodig geweest zou zijn als diegene inderdaad blind te vertrouwen was?
Het gebeurd wel vaker dat een rotte combinatie van servicepacks en patches dingen breekt. Zo regelmatig dat de meesten mensen liever wachtten. Een goed firewall scheelt al 90%.

Ik heb ook al een paar systemen onderhoud geholpen met updates. En servicepacks wil je zelf het liefst eerst testen in een gecontroleerde omgeving (ook vanwege de verminderde downtime).
Die patches en SPs zijn helemaal niet op alle mogelijke platformen getest. Als ik zo lees welke ellende er voortkomt uit oude installaties die al eerder gepatcht zijn met andere hotfixes en dingen, en dan ineens SP4 over zich heenkrijgen, die kunnen gewoon opnieuw beginnen.
Heb al heel wat verhalen gelezen over bedrijven die vrolijk aan't patchen waren en na 30 workstations en 3 terminal servers erachter kwamen dat niemand er nog iets mee kon :P
Ja omdat men vreest voor stabiliteitsproblemen. Die zouden dan, volgens de experts uit de praktijk, moeten voortkomen uit servicepacks en patches die bij Microsoft uitgebreid getest zijn. Wie mij deze achterlijke "wij weten het beter" mentaliteit uit kan leggen, ga vooral je gang
Gewťťťldige servicepack test afdeling daar dan.
Servicepack 2 voor SQL server 2000 laat je synchronisatie vastlopen als je meer dan twee subscribers hebt. Dus je installeert servicepack 3, snel, want je moet morgen op vakantie. servicepack drie draait, hop, hele synchronisatie weg (4 GB vital company info...)
OK. Je blijft dus kalm, en gaat de readme nog een keer opnieuw lezen. er staat echt NIETS in over dit probleem. dan de knowledgebase. wat tref je daar aan: ťťn lullig 4 regelig artikeltje over dat als je binairy sort order gebruikt in je database (BaaN vereist dat...) je je synchronisatie gewoon helemaal kunt vergeten. oplossing: bel MS support of wacht op SP4. je wil over ondertussen 9 uur nog steeds op vakantie, dus je gaat als een gek MS bellen. die zijn dicht, want het is ondertussen #(*(#@& na vijven op vrijdag middag. je vrouw vraagt of je nog gaat slapen voor je morgen in ťťn ruk naar ItaliŽ gaat rijden.
Zoekende naar een oplossing vůůr je vakantie kom je stom toevallig een patch voor iets anders tegen wat je sqlserver.exe versie tilt naar een versie hoger dan die van de patch waar je MS voor moet bellen. je installeert deze patch dus na de readme te hebben gelezen, en na nog een kwartiertje config files bijschaven en checken of het nu blijvend gaat werken, kun je naar bed. drie uur later wordt je door je dochter uit bed gehaald, pappa moet naar ItaliŽ rijden. mamma is al wakker.

Goddank overkwam dit niet mij maar een collega. Tijdens zijn rit naar ItaliŽ ben ik dus remote patches aan het installeren geweest op drie servers.

Ik denk niet, dat je als je zegt dat MS het goed onderzocht heeft, en dat mensen die daar wantrouwend tegenover staan eigenwijs zijn, echt verstand hebt van microsoft producten, microsoft policies en vooral niet van netwerkbeheer.
Ieder z'n vak, maar maak dan geen lompe opmerkingen over dat van een ander.
Je hebt gelijk :).
Maar uiteraard moet je zelf een nieuwe patch/service pack eerst grondig testen voor je hem op je belangrijke systemen los laat. Dan ben je misschien een beetje later met je patch maar intussen ben je wel zeker dat er niemand aan sterft (en in deze branche is dat dus perfect mogelijk).
En daar zit 'm nou precies de kneep, wie heeft tijd voor al dat testen/installeren, wie heeft daar zin in? Wie betaalt dat?

Als je MS mag geloven en alle "had je de patch maar moeten installeren" meepraters, dan hoeft er dus helemaal niet getest te worden en bestaan die problemen niet. Het prachtige verhaal hierboven (vooral dat "je vrouw vraagt of je nog gaat slapen voor dat je morgen naar italie rijdt") geeft aan dat dat gewoon niet zo is.

Buiten nieuwe bugs is het bij patches/SP heel goed mogelijk dat dingen opeens anders werken wat je allemaal weer moet uitzoeken. Dit is echt niet wat de systeembeheerder z'n hoofdtaak zou moeten zijn die heeft genoeg nuttigere dingen te doen.

/edit typos
Juist en daarom is het nou zo belangrijk dat je een staging omgeving hebt, waar je dit soort zaken op kan testen voordat je het naar je productie omgeving migreert.

Daarnaast, kan ik je uit eerste hand vertellen dat de Sqlserver patches ZEER goed getest worden, ben zelf beta tester voor de Sqlserver patches, en er wordt door een behoorlijk grote groep getest. En dat is echt geen 2 weekjes, maar eerder enkele maanden.
In Nederland loopt een mooie glasvezel van hoogspanningsmast naar hoogspanningsmast (die bovenste kabel in het midden).
Grote bullshit, die middelste kabel is namelijk de bliksemafleiding.
Niet zo bull shit. Ik weet niet of het het middelste lijn is, maar over de hoogspannings leidingen loopt wel degelijk een glasvezel. In een grijs verleden nog meegewerkt aan de opbouw van de eerste verbindingen in het zuiden van het land. Apparatuur van Siemens, initieel 2 Mbit, opschaalbaar tot 512Mb als ik het me goed herinner. Dit was ergens eind jaren 80.
zal wel 155meg zijn,,SDH?
Als je niet weet of het de middelste is, waarom schrijf je het dan op een manier waarmee je probeert om je verhaal te versterken? Maw. je haalt je eigen geloofwaardigheid vanaf de bodem onderuit.
Ja omdat men vreest voor stabiliteitsproblemen. Die zouden dan, volgens de experts uit de praktijk, moeten voortkomen uit servicepacks en patches die bij Microsoft uitgebreid getest zijn. Wie mij deze achterlijke "wij weten het beter" mentaliteit uit kan leggen, ga vooral je gang
goh, laten wij nu net problemen hebben na de RPC patch. roaming profiles van users worden niet meer weggeschreven na het uitloggen van een citrix-sessie.

Ook Microsoft weet niet hoe dit komt en is al een week aan het debuggen.


dus de moraal: blijf altijd terughoudend met patchen en test het zelf ook. Microsoft kan gewoonweg niet alles testen.
\[off-topic]raar, wij draaien hier ook met citrix (metaframe 1.8), en NT4 terminal servers en hebben helemaal geen problemen met roaming profiles e.d. na de patch[/]
ik d8 trouwens tijdens die stroomuitval op het nieuws te horen dat het geen terroristiche aanval was, en ook niet door een virus kwam.... raar...
[noobmode]
citrix is toch een remote desktop en heeft toch helemaal niets met de lokale machine te maken?
hoe kan ie dan last hebben als er kokaal 135 dicht word gezet?
[/noobmode]
[nog meer off topic mode]
de server waar je citrix op installeerd, als die een RPC shutdown krijgt gaat hij uit de lucht k,rijgen alle servers die (bij ons 6) dan kun je niet meer inloggen met je citrix sessie ;)(je kunt meerdere servers opgeven, en met loadballancing kom je dan op de minst drukke server), dus je moet de server gewoon patchen tegen het RPC lek... Nu is het bij thanatosti zo dat nŠ de patch op de server er roaming profiles zijn...[/]
Dit lijkt me in het geheel een broodje aap verhaal dat die 'experts' de wereld insturen om de incompetente 'technici' van FirstEnergy Ohio vrij te pleiten. Wat die firma al op 18 augustus heeft toegegeven wijst in het geheel niet op communicatieproblemen, het zijn juist de technici in lokale controlekamers die de problemen niet gesignaleerd hebben, die hadden helemaal geen long distance communicatie nodig.
ALARM DID NOT SOUND
FirstEnergy acknowledged that an alarm that should have flashed a red warning on computer monitors when power was being lost, did not sound in its central control room.
That "certainly contributed to it," said Gent, appearing Sunday on ABCís "This Week." But he said the alarm did not fail at other locations where technicians were supposed to monitor the lines.
"We have to dig into this to see why the alarm wasnít noticed by somebody else" in addition to why the alarm was not working at the FirstEnergy control center.
Ik zou je alleen al afgeschoten hebben omdat je server-systemen aan het Internet hebt hangen.
Zoiets als: "Bij de volgende operatie naast zijn p*nis verlengen ook effe zijn arm amputeren..." aanpassing in het operatie schema... Niet goed, niet doen.

Internet op aparte dozen met fisiek ander netwerk is goed, al het andere zijn gewoon foute compromises.
Terug naar het jaar nul...

En bovendien: wat nu als er iemand met een laptopje thuis aan het internet heeft gezeten en 'm nu in het bedrijfsnetwerk prikt?
Bewijst wel weer dat een internetverbinding soms niet de meest veilige verbinding is om netwerken met elkaar te verbinden.

Als het een op zichzelf staande netwerk was zonder de tussenkomst van het internet zou die machines er geen last van gehad hebben en ook zelf nooit besmet kunnen raken.......
Ja ip over de energie kabels net zoals nuon deed.
In Nederland is dat nog haalbaar, maar als je een glasvezelkabel mag neerleggen (inclusief zeer specialistische montage op zo'n mast, mag ik zeggen) voor afstanden zoals binnen de US gebruikelijk zijn, mag je toch een aardig aantal metertjes vezel aanschaffen... En gezien de tekorten in de energie-branche is daar vast niet echt veel animo voor. Internet is snel, veelzijdig, goedkoop en overal. Niet gek dus dat ze data routen over het internet.
New York heeft vertraagd. Sommige energiebedrijven uit deze regio werkten namelijk op Windowssystemen met poort 135 open, waardoor de worm de systemen kon aanvallen.
PRUTSERS!
:( |:(
Met een firewall zet je eerst alles DICHT! Je zet daarna pas de poorten open die je ook open wilt hebben naar of van je bedrijfs netwerk, ook al heeft je MCSE systeem beheerder liggen slapen ;)
Tuurlijk...en poort 135 dichtzetten kan zonder problemen ? |:(
Het is waarschijnlijk niet zo dat het om een netwerk of systeem gaat, wat te vergelijken is met wat jij thuis hebt draaien(en PC of routertje direct aan het internet).

Centrales zitten waarschijnlijk via huurlijnen en routers verbonden, iets wat behoorlijk ingewikkeld kan zijn.
Poort 135 dichtzetten op een server in een windows netwerk(VPN, WAN oid) is niet echt zinvol ;)

Desalniettemin kan het een beveiligingsfout van het netwerk zijn geweest.
Misschien handig als je ff verteld wat op poort 135 draait ... volgens een netstat op mijn PC draait er een EPMAP .. geen idee wat het is .. maar schijnbaar kan jij uitleggen waarom je dat niet uit kunt zetten
Tuurlijk...en poort 135 dichtzetten kan zonder problemen ?
Er is geen bitje dat van het internet over poort 135 binnenkomt, wat jij nodig hebt of nodig kan hebben voor je netwerk. Dus ja, poort 135 kun je voor de buitenwereld in ieder geval probleemloos dichtgooien.
Binnen je netwerk waarschijnlijk ook, maar dat hangt meer af van de programma's, servers en services die je aanbiedt op je netwerk, en of die poort 135 gebruiken. Meten is weten: je zal het dus moeten testen.
waarom hebben ze dan geen dedicated lines voor zo iets? dit zou dit betekenen dat je met een goede ddos attack een deel van amerika zonder stroom kan zetten. :?
Ja inderdaad.. Dikke onzin dus.
Dit is gewoon FUD van de VS overheid om te gaan lobbyen voor een grotere vinger in de pap wat betreft internet/security en alles..
Meer controle, dat is het doel van het de media inslingeren van dit soort praat..
Er wordt nu al sinds die stroom uitval naar elkaar gewezen wie de schuldige is voor de stroom uitval. Eerst was het Canada die naar de VS wees en andersom, daarna was het 1 specifieke centrale en nu is het maar de blaster worm ??

Kom op zeg, ik heb geen idee wie dit gezegt heeft. Maar het blijft een feit dat er in de VS gewoon een brak stroom netwerk is en dan gaan ze het nu een beetje afschuiven. Ze moeten gewoon toegeven waar het om gaat.

Daarbij kan ik me niet voorstellen dat de communicatie mbt. het stroom netwerk niet over een apart losstaan netwerk gaat. Ik geloof gewoon niet dat dit over internet heen gaat. En zelfs al zou dit wel het geval zijn, dan _kan_ het zijn dat je een domme systeem/netwerk beheerder heb, maar eentje die op deze manier zijn netwerk beheert mag zich nog wel 2x achter zijn oren krabben.
Diverse experts uit zowel het bedrijfsleven
Ah, dat zijn dat soort mannetjes die hebben de klok horen luiden, maar weten totaal niet waar de klepel hangt. :Z
Ja omdat men vreest voor stabiliteitsproblemen. Die zouden dan, volgens de experts uit de praktijk, moeten voortkomen uit servicepacks en patches die bij Microsoft uitgebreid getest zijn. Wie mij deze achterlijke "wij weten het beter" mentaliteit uit kan leggen, ga vooral je gang
Die terughoudendheid is bijzonder gezond. Wie met Windows NT 4.0 heeft gewerkt, weet wat er gebeurde met sommige database-servers waarop de eerste release van SP4, of SP6 werd geinstalleerd (van SP4 is een gelijknamige bijgewerkte versie verschenen, van SP6 hebben ze zelfs maar SP6a gemaakt). ODBC- en netwerk-drivers hadden het plotseling niet lekker, dag databasejes !

Maar het geldt voor elk kritisch systeem : al roept de leverancier nog zo hard dat je die-en-die patch beslist moet installeren, en dat die volkomen veilig is, je gaat eerst in je test-omgeving kijken of het ook echt blijft werken in jouw specifieke configuratie (hardware, operating system, programmatuur, netwerken, enz.). Als dat zich gedurende tenminste enkele weken heeft bewezen, mag het naar de acceptatie-omgeving, om uiteindelijk naar de productie-omgeving door te stromen. Het is een zware beslissing om af te wegen of bijv. een fix voor het lek waar Blaster doorheenglipte buiten deze procedure moet worden doorgevoerd.

Paranoia is soms een teken van fatsoenlijk systeem-beheer.
in dergelijke gevallen alleen wel een teken van te langzaam systeembeheer
Vind het wel vreemd dat de centrale worden uitgezet als de netwerkverbinding tussen de centrales uitvalt....
Volgens mij was het net iets anders. Door de wegvallende verbinding wisten de centrales niet dat er een centrale was uigevallen. Hierdoor werd de defecte centrale niet van het netwerk losgekoppelt, en de capaciteit van de overige centrales niet aangepast. Hierdoor kwam dus het "sneeuwbaleffect" waardoor er nog een aantal (7?) centrales uitvielen.

Kortom, door de blasterworm kon de uitvallende centrale niet opgevangen worden, en vielen er meer centrales uit. Het uitvallen van de eerste centrale zelf had niet direct iets te maken met de blaster worm.
Tja...

"This Powerplant is shutting down. Please grab all the batteries you can and log off.
Any unused power will be lost. This shutdown was initiated by NT AUTHORITY\DUDEDONTPATCH"
Als ze dus de stroomuitval gedeeltelijk wijten aan het blaster virus, zullen gedupeerden de kosten van die storing dan ook (kunnen) verhalen bij de onlangs opgepakte verdachte?
Yep, waarschijnlijk wel. Dat gassie was 18 jaar. EN zal dus zijn hele leven betalen. EN zelf niet overhouden.
Ik denk het niet, de schade ontstaat tenslotte niet door de worm maar door nalatig handelen van windows gebruikers.

natuurlijk kun je in de VS rechtspersonen overal voor aanklagen, daar lijkt de mate van geld en de het gebrek aan kennis bij de rechters/jury meer van invloed op het vonnis dan de eigenlijk wetgeving.
:? Dat is wel een erg vreemde redenering!

Als ik mijn achterdeur niet op slot draai en er word ingebroken is de inbreker schuldig, niet ik!
Verzekeringstechnisch ben ik dan wel nalatig geweest, maar de inbreker is juridisch aansprakelijk!

Zou een mooi zootje worden:
"Jij hebt mijn autoradio gestolen!"
=>"Maar je auto zat niet op slot!"
"Fuck, mijn fout... sorry hoor, plezier met de radio!"

Got the point?
Virusmakers zijn aansprakelijk, niet de gebruiker!

En updaten is echt niet zo gemakkelijk voor de gemiddelde newbie, met een 56k6 lijntje is het zelfs vrijwel onmogelijk!

Als jij een andere mening hebt mag jij mijn ouders gaan instrueren, succes! 8-)
Die verdachte (Parson) was slechts de maker van Blaster.B, dus niet van de originele Blaster. Ik vraag me af, of de maker van het origineel zwaarder bestraft kan worden dan iemand die een virus muteert.

Na betaling van 25.000 dollar borg mocht hij weer naar huis. De zaak zal op 17 september in Seattle voorkomen. Hem wacht een maximale gevangenisstraf van tien jaar.

Hij was betrekkelijk eenvoudig op te sporen. Zijn aangepaste versie van Blaster was namelijk zo geprogrammeerd dat deze verbinding zocht met zijn eigen website, www.t33kid.com. Deze site was op zijn eigen naam en adres geregistreerd.
Vraag me af wat er nu waar van is, maar goed!

Zitten er ook Nucleaire installaties tussen?

Hoop dat de systeembeheerders hiervan dan wel weten waar ze mee bezig zijn!
Een anonieme industry executive vertelde Computerworld dat de Slammerworm in januari al schade had toebracht aan elektriciteitsbedrijven. Omdat deze schade niet resulteerde in een storing, bleef de boel onopgemerkt. FirstEnergy Corporation was een van de slachtoffers toen. Gelukkig was hun kerncentrale toendertijd niet actief:
soms vraag ik me af hoe het kan dat die gasten zichzelf nog niet hebben opgeblazen..
In de Verenigde Staten staan alleen inherent veilige centrales, misschien een of twee oude centrales daargelaten. Alle moderne centrales zijn zodanig ontworpen dat als er iets misgaat, er als gevolg van de natuurwetten niets engs kan gebeuren. Zo wordt voor de koeling een schoorsteen gebruikt. Stroomuitval of niet, een schoorsteen koelt altijd. Zelfs als er absoluut geen wind is!

Door in het ontwerp van dit soort inherent veilige principes uit te gaan, kunnen de Amerikaanse kerncentrales hooguit stilvallen in het geval van (ernstige) calamiteiten. Een meltdown is uitgesloten. Overigens geldt dit ook voor de Nederlandse kerncentrales.
Elke kernreactor kan een meltdown krijgen, hoe geavanceerd en veilig hij is.

Lucht gekoelde reactors kunnen gaan branden. Dit omdat er gebruik wordt gemaakt van grafiet (koolstof) in de reactor, deze kan gaan branden als hij heet genoeg wordt. De lucht die gebruikt wordt voor de koeling wakkert het vuur aan, de lucht stroom kan men dan niet afsluiten omdat de reactor overhit raakt en je een meltdown krijgt, water kun je niet gebruiken omdat je dan de koeling uitschakelt en je ontploffingsgevaar veroorzaakt.

Deze branden zijn al voorgekomen in kerncentrales in het Verenigde koninkrijk en in de Verenigde Staten.

Ook kan in een watergekoelde kernreactor een meltdown voorkomen, als er ergens een catostrofale fout in de koeling ontstaat en men kan de kern reactie niet onder controle krijgen.

Een meltdown is eenvoudig weg niet uit te sluiten. Het kan altijd gebeuren, omdat men misschien iets lulligs over het hoofd heeft gezien, bepaalde kennis nog niet aanwezig was of door andere interne/externe factoren.

Ik ben geen expert op dit gebied maar ik heb me wel geinformeerd over kerncentrales omdat er vaak heftige discussies over zijn en ik de feiten wil weten over iets dat potentieel dodelijk is (daarom kunnen er fouten zitten in wat ik gezegd heb maar je begrijpt hopelijk wat ik probeer te zeggen ;) ).

links:
Engelse reactor die in brand vloog:
http://www.lakestay.co.uk/1957.htm
Website met een lijst met nucleaire 'incidenten':
http://www.efn.org/~bsharvy/nukes.html
[offtopic] Dus poort 135 is de ingang van de blaster worm ?? Fijn,, ik heb een hele nacht zitten uitvissen hoe die nou steeds binnenkwam als ik pc cillin uitzette.

[offtopic]
Man, dan heb je toch aardig wat gemist de afgelopen maand geloof ik :)
Beetje beter de nieuws-sites, en de AntiV-sites in de gaten houden

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