Hoofdcategorieën
Device Settings

Experts wijzen Blasterworm aan als factor in stroomuitval

Door Tamara van Hal, maandag 1 september 2003 22:26
Bron: Computerworld, submitter: BillGaetes, views: 1.157

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.
Volgende 22:31 Komende week presentatie Sony Playstation PSX in Parijs
Vorige 21:10 Blu-Ray-videorecorders van JVC, Samsung en Sony
Advertentie

Reacties

«  1  2  3  4  »

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.

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

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?

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.

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.

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...[/]

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?

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"


"Click OK to enter powersave mode." :+

Dat is natuurlijk wel erg kort door de bocht...

Want als ze gewoon gepatched hadden was er niets aan de hand geweest.
En je kunt je Server/OS nog zo stabiel maken... als de gebruikers/beheerders hun werk niet doen, dan blijf je altijd dit soort dingen houden.
FirstEnergy Corporation was een van de slachtoffers toen. Gelukkig was hun kerncentrale toendertijd niet actief:
Dit ga je toch niet menen?? Dat straks een virus tot ontploffing kan gaan leiden van een kerncentrale.
Dan heeft die virusmaker zijn naam blaster wel erg toepasselijk gekozen.
Maar als door slecht systeembeheer een kerncentrale uit zou kunnen vallen... en die doet zijn werk niet, dan vind ik dat zo iemand een levenslang verbod op systeembeheer moet krijgen...damn...

Ja maar dan lijk de laatste tijd de wraak van mods over je heen te krijgen.. Het lijkt mij trouwnes onwaarschijnlijk dat de worm maar ook iets met de power uitval heeft te maken. Onlangs klaagde de voormalige secrataris voor energie dat hij dit 5 jaar geleden voorspelde omdat het apparatuur verouderd was, en neit dat ze een oude os draaide, neen oud as in mechanische systemen en die zouden het hebben begeven. Dit schreeuwen naar de worm is gewoon een spin om te schuld te kunnen afwijzen op iemand anders i.p.v. toe te geven dat het hele zooitje mismanaged is.

[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

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.

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..

Hmm, klinkt als Terminator 3 8-)

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.

ja hoor... electriciteits centrale ga je ook even via een totaal niet beveiligde verbinding over inet met elkaar laten communiceren }:O }:O }:O

Een driedubbelbeveiligde verbinding zou ook overbelast raken.

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
«  1  2  3  4  »

Op dit item kan niet meer gereageerd worden.

Volgende 22:31 Komende week presentatie Sony Playstation PSX in Parijs
Vorige 21:10 Blu-Ray-videorecorders van JVC, Samsung en Sony
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011