Beveiligingsonderzoekers leggen gaten in routing-protocollen bloot

Twee beveiligingsonderzoekers hebben tijdens de Black Hat-conferentie in Amsterdam kwetsbaarheden in een tweetal routingprotocollen beschreven. Hackers kunnen misbruik maken van het gehanteerde vertrouwensmodel.

Daniel Mende en Enno Rey, beide werkzaam voor de firma ERNW, behandelden in hun 'all your packets are belong to us'-lezing als eerste het border gateway protocol. Het bgp-protocol wordt gebruikt voor de uitwisseling van routingtabellen tussen internetswitches en kan worden gezien als de lijm die het internet bij elkaar houdt. Bgp is gebaseerd op een vertrouwensmodel, waarbij eenmaal toegelaten routers elkaar vertrouwen op basis van een md5-handtekening. In het gebruik van md5 zit ook direct de kwetsbaarheid; indien een hacker het lukt om een router op de backbone direct te benaderen, dan kan hij een verbinding opzetten die door de router wordt geaccepteerd. Mende en Rey toonden twee proof-of-concept-tools die dit mogelijk maken.

Met de kwetsbaarheid in het bgp-protocol kan een kwaadaardige hacker naar hartelust routingtabellen aanpassen en nieuwe entry's toevoegen. Dat het bgp-protocol niet alleen kwetsbaar is voor hackers, bleek vorig jaar: een medewerker van de Pakistaanse telecommunicatieautoriteit PTA maakte toen een fout bij het instellen van een ip-blokkade via het bgp-protocol. Als gevolg daarvan was Youtube wereldwijd urenlang onbereikbaar.

Mende en Rey namen ook het mpls-protocol onder vuur. Mpls wordt door carriers gebruikt als forwarding-protocol om het netwerkverkeer binnen de backbone in goede banen te leiden. Daarbij worden ip-pakketjes voorzien van labels, waardoor bijvoorbeeld het dataverkeer van vpn's kan worden gescheiden van overige datastromen. Er bestaan daarom ook verschillende mpls-routeringstabellen, naast de global routing table voor het 'normale' internetverkeer.

Omdat ook mpls uitgaat van het vertrouwensmodel, kan er door een hacker relatief eenvoudig met de labels worden gerommeld op een zogeheten PE-router. De beveiligingsonderzoekers demonstreerden op de Black Hat-conferentie een tool waarmee zulke labels kunnen worden gewijzigd of zelfs aangemaakt. Deze laatste mogelijkheid geeft hackers de kans om eigen vpn's op te zetten. Volgens de twee beveiligingsonderzoekers zijn dergelijke virtuele netwerken niet of nauwelijks door carriers te detecteren.

Aan het einde van de presentatie werd ook nog kort ingegaan op de mogelijke gevaren van nieuwe carrier ethernet-protocollen. Volgens de onderzoekers zijn deze protocollen veelal ontwikkeld voor lokale netwerken, en levert het routeren van dergelijk verkeer via de backbone de nodige hoofdpijn bij beveiligingsexperts op.

Mende en Rey concluderen dat de bgp- en mpls-routingprotocollen toe zijn aan nieuwe versies waarbij het vertrouwensmodel wordt losgelaten. Bedrijven zouden waar mogelijk meer veiligheidsmaatregelen van hun providers moeten eisen. Wel benadrukten de twee dat hun inmiddels vrijgegeven proof-of-concepts-tools waardeloos zijn zonder directe toegang tot de netwerkapparatuur van een carrier, maar het wachtwoord 'cisco' blijkt volgens hen nog angstig vaak te worden gebruikt.

Reacties (46)

[Verwijderd]

Bgp is gebaseerd op een vertrouwensmodel, waarbij eenmaal toegelaten routers elkaar vertrouwen op basis van een md5-handtekening. In het gebruik van md5 zit ook direct de kwetsbaarheid; indien een hacker het lukt om een router op de backbone direct te benaderen, dan kan hij een verbinding opzetten die door de router wordt geaccepteerd. Mende en Rey toonden twee proof-of-concept-tools die dit mogelijk maken.

Volgens mij wordt het hier toch een heel stuk simpeler voorgedaan dan het is. Alle BGP implementaties die ik ken, accepteren alleen een binnenkomende TCP sessie op een adres waarvandaan ze een BGP sessie verwachten (oftewel, de geconfigureerde BGP-sessies), dat zou dus betekenen dat je een IP adres van een bestaande router (die in vrijwel alle gevallen direct verbonden is met de router under attack moet spoofen. Wil je ook nog wat zinnigs met die TCP-connectie doen, zul je dus het retourverkeer terug moeten routeren naar jouw machine, dat is normaal al lastig, maar met een directly connected netwerk is dat vrijwel onmogelijk; en dat is dan nog zonder MD5 check.

Omdat ook mpls uitgaat van het vertrouwensmodel, kan er door een hacker relatief eenvoudig met de labels worden gerommeld op een zogeheten PE-router.

MPLS wordt in de meeste gevallen alleen binnen het eigen netwerk gedraaid. Het is dus logisch dat de routers elkaar vertrouwen: de routers zijn immers allemaal onder beheer van dezelfde partij. Als je eenmaal toegang hebt tot een PE-router, dan kun je wel gekkere dingen doen dan dit.

Mende en Rey concluderen dat de bgp- en mpls-routingprotocollen toe zijn aan nieuwe versies waarbij het vertrouwensmodel wordt losgelaten. Bedrijven zouden waar mogelijk meer veiligheidsmaatregelen van hun providers moeten eisen.

Laat me raden: deze heren kunnen de providers adviseren over die veiligheidsmaatregelen?

Wel benadrukten de twee dat hun inmiddels vrijgegeven proof-of-concepts-tools waardeloos zijn zonder directe toegang tot de netwerkapparatuur van een carrier, maar het wachtwoord 'cisco' blijkt volgens hen nog angstig vaak te worden gebruikt.

Sorry hoor, maar dat is geen kwetsbaarheid in het protocol. Nogmaals: als je toegang hebt tot de netwerkapparatuur van een carrier dan kan je wel gekkere dingen doen dan dit. Het feit dat er slechte wachtwoorden worden gebruikt is geen kwetsbaarheid van de protocollen die er op dat apparaat draaien.

[Kabouterplop01]

PSies, BGP sessies worden opgezet en beveiligd met md5, mac filter, communities meds route maps en nog wat trucs. logisch dat als je snift en een of andere jandoedel configureert ebgp multihop 25, omdat diegeen niet weet met welk adres de neighbor is opgezet ,dat er de kans bestaat dat er iets word opgevangen.
Een beetje beheerder kan inderdaad dat aardig troubleshooten als er verkeer teruggerouteerd wordt "buiten het netwerk" met een simpele trace is dat al goed zichtbaar, bovendien zal als de sessie slim is opgezet gelijk down gaan.
Je weet dus gelijk dat de route ergens more specific wordt aangekondigd. Net zoals die Pakistaanse dude deed met youtube, more specific naar 0 null
Het zijn de mensen die laks zijn.

[Pomp]

Je moet altijd een neighbor ip adres opgeven bij bgp, zo werkt het protocol nou eenmaal. Het te (vermijde) risico van deze aanval is een man-in-the-middle attack.
bijvoorbeeld als een hacker het verkeer zo weet te routeren dat het een tussenstation passeert, kan er ,omdat het een slecht beveiligde verbinding is, bgp routing packetten gespoofd worden.


Dit risico is zeker goed af te dekken, door gebruik te maken van access-list en de beperking van fysieke toegang,etc. dingen die je allemaal mag verwachten bij een backbone architectuur.

De filosofie achter beveiliging is dat er met meerderen lagen 'of defence' wordt gewerkt.
Ook zou security een inherente eigenschap moeten zijn van een zo belangrijke netwerkprotocol. Je weet namelijk niet wanneer de volgende misconfiguratie of bug zich aandient.

[Punica-]

Heel goed verhaal.

Trouwens, een cisco router heeft als je niets instelt helemaal geen login / console / enable password dus dat 'op veel plaatsen' cisco gebruikt word als password lijkt me helemaal klinkklare onzin.

[Turtle]

cisco wordt wel degelijk op veel plaatsen als wachtwoord gebruikt. Dat is gewoon de praktijk, ook al komen ze niet op die manier uit de fabriek rollen. Als externen het spul configureren en dan afleveren zeggen ze vaak "oh en het wachtwoord is nu cisco" en dat wordt dan vervolgens (ja heel slecht, lui volk) nooit meer gewijzigd.

[Punica-]

Dat gaat niet over de routers waar in dit artikel over gesproken word...

[analog_]

Cisco heeft spul dat BGP en MPLS ondersteunt.

[serkoon]

Hrm; heb even naar de code lopen turen..

De BGP-tool lijkt simpelweg te connecten naar een router en valse BGP-updates te sturen. Voor routers die TCP-MD5 doen (en dat doe je als je snugger bent) zit er een wordlist-gebaseerde bruteforcer in.

De MPLS-tool onderschept, zo te zien, frames en vervangt wat labels en MAC-adressen. Een uurtje werk om zoiets te schrijven, dus.

Beide tools lijken vrij triviaal en weinig spannends aan als je het mij vraagt. Een fatsoenlijk geconfigureerde BGP-router doet TCP-MD5 en accepteert niet zomaar rogue peers en prefixes. Het bruteforcen van TCP-MD5 gaat alleen werken als de desbetreffende router kansloze passwords gebruikt. Het beveiligingsgat is dus: 'als je een slecht password gebruikt en geen filtering doet, kan iemand BGP-updates naar je sturen'. Sjah...

Ik ben zeer benieuwd naar de presentatie; doorgaans gaat Blackhat wel ergens over namelijk. Heeft iemand meer info?

[coretx]

Meer info: De informatie aangaande BGP zwerft al minstens 3 jaar op blackhat IRC kanalen rond.

Je geeft het zelf al aan "doorgaans" , dus niet altijd.

Edit:

Wat betreft die "slechte wachtwoorden" , je moest eens weten....
Een niet nader te noemen persoon die voor een ISP werkt, heeft mij ooit eens kunnen vertellen dat alle core meuk van BBned vroeger een wachtwoord had dat gelijk was aan hun reclame slogan. ( Geen hoofdletters, cijfers niets. )

Edit: En een dergelijk grote ISP beschikt over genoeg ASN's om het halve internet plat te leggen.

[Reactie gewijzigd door coretx op 22 juli 2024 18:28]

[PolarBear]

Mja, ik ken ISP's die gewoon standaard elke x dagen alle wachtwoorden op routers veranderde. Geeft me toch een beter gevoel

[Dennizz]

Overigens is dit niet mogelijk voor BGP peering, omdat deze sessies stable moeten zijn (als het even kan maanden of jaren actief zijn) omdat als de sessie wegvalt alle routes die geleerd zijn van de peer ongeldig worden. Je begrijpt dat als het wachtwoord veranderd (wat bij beide providers tegelijk zal moeten gebeuren!) de sessie opnieuw opgebouwd moet worden.

Overigens zou met gracefull service restarting dit misschien wel mogelijk zijn, omdat de routing engine dan tegen zijn peer zegt dat hij binnen korte tijd terug is en daardoor hoeft de peer de geleerde routes niet meteen als ongeldig te beschouwen...

[Verwijderd]

Meestal zal er gebruik gemaakt worden van een persoonlijke usernaam en wachtwoordcombinatie voor elke beheerder met behulp van bv TACACS of RADIUS. Bovendien is het heel eenvoudig om te zorgen dat je alleen van een bepaald blokje IP-adressen (het netwerk waar je beheers-PC's staan) kan inloggen op je netwerkapparatuur. Bij veel operators wordt er zelfs gebruik gemaakt van een apart netwerk om beheer over te doen.
Als ik een operator-netwerk beheer dan beschouw ik het al als een veiligheidsissue als een klant een inlogprompt kan krijgen, nog helemaal los van het feit of de wachtwoorden veilig zijn.

[coretx]

Zo behoor je dat idd aan te pakken. In de realiteit is het echter over algemeen nog steeds knudde.
In jou opstelling zijn serial >> ethernet converters overigens ook leuk.
Vooral als je ze vast plakt, zo vertraag je onsite sabotage , en kan je instellen dat root rechten uberhaupt niet over de ethernet interfaces te verkrijgen zijn.

[Liberteh]

brederband, dus?

[analog_]

Zijn er dergelijke (grote) problemen al ontdekt bij OSPF? Leukste wat je hiermee kan doen is root certificate authority gaan spelen of de root DNS servers herrouteren naar je eigen bakjes. Toch serieuze issues.

[Reactie gewijzigd door analog_ op 22 juli 2024 18:28]

[Dennizz]

Het faken van een Root CA is niet zo eenvoudig als DNS poisening of hijacking om vervolgens jezelf als de Root van bijv Verisign voor te doen... Simpelweg omdat browsers preloaded zijn met de public keys van deze Root CA's. Daardoor moet je ook de private key hebben van bijv Verisign, en als je daar aankomt doe je het echt goed ;-).

Betreft de security leaks, een aantal simpele best practices voorkomen heel veel problemen. Sommige zullen ongetwijfeld al genoemd zijn:

- MD5 sums gebruiken zodat je niet zonder hash een peer opbouwd

- Access lists voor peering, alleen peeren dus met bekende IP's van je peers. Als je dan het source ip spoofed van een legitieme peer zal deze niet op komen als het goed is. Je stuurt namelijk een tcp syn uit naar de target router, welke een syn ack stuurt naar de legitieme peer die deze (nieuwe) sessie niet kent. Hence... gets dropped. Dit helpt echter niet tegen een spoofed bgp update die je in een bestaande sessie injecteerd, maar met MD5 sum protected sessies kun je niet zomaar injecteren en daarnaast opereer je "in the blind" omdat je geen enkele response ziet, tenzij je aanval slaagt. Ik weet overigens niet of er ook nog een check plaats vindt op tcp sequence, want dan moet je ook die nog correct hebben om een bgp update in een bestaande sessie te kunnen injecteren...

- Prefix filters; accepteer alleen routes die je wil accepteren van je peer, zoals zijn eigen IP space. Voor transit bgp peers geld dat je waarschijnlijk alle routes wil importeren en dan gaat dit niet zomaar op, maar je kunt dan volgens mij wel routes filteren waarin het AS path begint met het AS van je peer.

- Brainstorm: Apart subnet gebruiken voor peering wat wellicht niet gerouteerd wordt in de internet tables ? (de "connected" route niet exporteren naar BGP, BGP hoeft normaliter namelijk enkel zijn werk te doen op het lokale subnet (iBGP buiten de beschouwing gelaten).

Al met al veel herrie om weinig spannends imho...

[coretx]

MPLS word doorgaans vooral (mis)bruikt om netneutraliteit te beschadigen.

[Verwijderd]

Absoluut onzin.

Vrijwel elke grote carrier gebruikt MPLS om verschillende verkeerstromen uit elkaar te houden (MPLS-VPN) en om snelle redundante paden (MPLS Fast Reroute), daarnaast kan het gebruikt worden om verkeer op basis van 'flows' te routeren over het netwerk (MPLS-TE / Traffic Engineering) en dat laatste zou je eventueel kunnen gebruiken om bepaald verkeer af te knijpen, maar er zijn veel eenvoudiger methoden (QoS-achtige zaken, bijvoorbeeld) om dat voor elkaar te krijgen.

[peak]

Ben het eens met jeroenr en ik wil wat aanvullen.

MPLS wordt mede gebruikt door het label switching protocol. De pakketten krijgen allemaal een label en een backbone router hoeft nu alleen maar naar het label te kijken en weet via welke uitgang dit moet gaan.
Een router hoeft nu niet alle pakketten te openen en te kijken naar IP source en destination header wat veel meer tijd/rekenkracht kost.

[iceking_e]

Klopt het complex is. Maar voor mensen die eraan kunnen verdienen is het gewoon een simpele rekensom opbrengst vs kosten... en de mogelijkheden zijn legio voor corrupte routing tabellen.

[peak]

Dat is totaal niet waar.

Toen men BGP v3 gebruikten, konden ze makkelijk naar BGP v4, omdat het Internet op dat moment niet uit 100000+ routers bestond.

Om nu een nieuw BGP protocol te invoeren in alle routers is een wereldwijde coordinatie nodig. Dit is nog niet eens het grootste probleem. Waarschijnlijk zullen routers vervangen moeten worden, omdat er met een andere encryptie methode gewerkt gaat worden.

Dit is niet zo zeer een opbrengst vs kosten plaatje. Dit is meer een, oke kan de wereld een periode zonder Internet zodat we alles kunnen upgraden en alle 270 duizend routes weer toegankelijk zijn.

[Verwijderd]

Het mooie van BGP4 is dat het dusdanig modulair opgezet is, dat het eigenlijk niet meer vervangen hoeft te worden. Mooie voorbeelden hiervan zijn MPLS en IPv6, die maken gebruik van de BGP Multiprotocol extenties, terwijl dat beide protocollen zijn die pas bedacht zijn ná BGP4. Een ander voorbeeld is de overschakeling van 16 bits ASN's naar 32 bits ASN's, ook daarvoor is er geen nieuwe BGP versie nodig (natuurlijk is er wel een nieuwe softwareversie op je router nodig, die de nieuwe extenties ondersteund). Er is dus geen wereldwijde coordinatie nodig om een nieuwe feature te introduceren, je hoeft alleen maar met je directe peers te coordineren en dan nog hoef je niet bij allemaal tegelijk over te stappen omdat je dit soort dingen per peer kunt configureren (en er bovendien een capabilities negotiation is), tenslotte kan een router in BGP aangeven of een bepaalde parameter doorgestuurd moet worden of niet, waardoor zelfs een router die de parameter niet begrijpt toch weet of hij hem weer moet doorsturen naar zijn peers.

[Turtle]

Goed moment om hier over te beginnen. De lekken zijn er al sinds het internet is ontstaan en BGP4 al bijna 20 jaar alle netwerken aan elkaar knoopt. Dus wat dat betreft is het wat laat. Vrijwel ieder bedrijf dat BGP routeerd kan een willekeurige IP reeks naar zich toe laten komen op internet. Voor korte duur tenminste, want de sociale gemeenschap zal dergelijke figuren snel verbannen en laten aanklagen

Aan de horizon staan echter nieuwe protocollen om met IPv6 om te kunnen gaan en waar ook functionaliteiten in zitten die PKI en dus Certificaten te gebruiken om te bewijzen dat je IP reeksen ook daadwerkelijk bezit met die RIPE handtekening. Deze protocollen zijn nog in beweging, maar markt support is ondertussen wel hard nodig. Dus motiveert uw ISP om hier mee bezig te zijn mocht je de kans krijgen
Hier is wel wat nuttige informatie hierover te vinden:
http://www.bgpexpert.com/#bgpsec

[Reactie gewijzigd door Turtle op 22 juli 2024 18:28]

[Punica-]

Snap je dat 'artikel' zelf ook? BGPsec niets met IPv6 te maken heeft, verder word in dat artikel zelf aangegeven dat bgp-s waardeloos is en sobgp nergens door iemand gebruikt word.

BGP is veilig, het is alleen zo onveilig als de beheerder het achterlaat.

[Turtle]

Ja ik snap het artikel zo te horen een stuk beter dan jij. Maar wellicht is het handiger om niet zo kinderachtig persoonlijk aan te vallen.

BGP4 is waar alles nog steeds op draait en IPv6 is ook een "driver" naar een nieuwe industrie standaard om het internet aan elkaar te knopen. Zorg dan dat dat nieuwe protocol wel dergelijke beveiligingen mogelijk maakt, waar nu de veiligheid toch echt wat te wensen over laat.

[edit]
reactie op hier onder::
Oke, kennelijk omschrijf ik het niet helemaal duidelijk. Dus nog 1 poging:
Niet iedere (BGP) router op internet ondersteund nu IPv6. Dus er moet nog heel wat vervangen worden de komende jaren. Als ze in die markt nu ook zorgen dat er een echte security toevoeging voor BGP "Industrie standaard" wordt dan kan dit mooi momentum krijgen. Het gaat meer om timing in de markt dan daadwerkelijk het technische protocol zelf.
Zoals nu moet je maar op goede filters en blauwe ogen van de grotere ISP's vertrouwen, om je eigen verkeer de goede kant op te laten gaan. Redelijk veilig, maar geen garanties mogelijk.

[Reactie gewijzigd door Turtle op 22 juli 2024 18:28]

[Verwijderd]

BGP4 is waar alles nog steeds op draait en IPv6 is ook een "driver" naar een nieuwe industrie standaard om het internet aan elkaar te knopen.

Voor IPv6 gebruik je ook nog steeds gewoon BGP4. IPv6 heeft, zoals Punica al zegt, niks met dit gebeuren te maken.

[Punica-]

De ' nieuwe standaard' is er al en die heet BGP6.

[Verwijderd]

BGP6? Voor zover ik weet is BGP4 nog steeds de meest recente versie?

[Punica-]

Je hebt gelijk Ik dacht dat als het over IPv6 ging dat het automatisch BGP6 heette, maar daarin had ik me vergist, het is gewoon BGP4 over IPv6.

[Punica-]

Het zou tweakers.net sieren als ze wat meer onderzoeks journalistiek doen, dan hadden ze kunnen inzien dat ze dit artikel konden schrappen omdat het allemaal al bekende feiten zijn welke helemaal niet makkelijk te misbruiken zijn.

Leer eerst eens het verschil tussen een switch en een router voor je iets publiceert.

[Verwijderd]

Punica wordt hier wel naar beneden gemod, maar hij heeft wel gelijk. Dit verhaal is allemaal opgeklopte onzin van een paar beveiligings-'experts' die om werk verlegen zitten. Ze geven zelf al aan dat je de "lekken" alleen kan misbruiken als je al toegang tot de router hebt. (Krijgen we volgende week een artikel in de Autoweek: "Beveiliging auto's zo lek als een mandje: als je de contactsleutel hebt is het stelen van de auto kinderspel!" ?).

En inderdaad: een switch draait geen BGP.

[Turtle]

Ik ben dan toch echt van mening dat het hier wel over een serieus beveiligings "probleem" gaat. Als in pakistan door een foutje youtube aan de andere kant van de aarde van het internet verdwijnt dan kun je je toch voorstellen wat moedwillege "cyber-attacks" kunnen aanrichten op internet.

Het zijn allemaal al lang en breed bekende problemen.... Als je zelf met BGP werkt in de internet omgeving. Voor het breedere publiek blijken deze kwetsbaarheden totaal onbekend. Vooral omdat er nog nooit echt grote problemen en/of aanvallen zijn geweest. Heeft het internet een goede reputatie kwa betrouwbaarheid.

"Zo lek als een mandje" is het zeker niet. Maar de beveiliging is ook zeer zeker niet solide te noemen.

[Verwijderd]

Ik ben dan toch echt van mening dat het hier wel over een serieus beveiligings "probleem" gaat. Als in pakistan door een foutje youtube aan de andere kant van de aarde van het internet verdwijnt dan kun je je toch voorstellen wat moedwillege "cyber-attacks" kunnen aanrichten op internet.

Dat foutje heeft niks te maken met de hier beschreven "gaten in routing-protocollen". Het is ook al heel lang mogelijk om je te wapenen tegen dit soort foutjes: door filters op je BGP-sessies te zetten kun je dit soort foutjes voor een groot deel tegengaan. Daarnaast is het ook nog zo dat het altijd te zien is wie het foutje gemaakt heeft en maak je regelmatig dit soort foutjes, dan wordt je op een bepaald moment gewoon van het Internet afgekegeld.

Dat is ook het lastige van BGP: het protocol zelf is niet zo ingewikkeld (het is veel simpeler dan bijvoorbeeld OSPF), maar als je een foutje maakt, dan ziet heel de wereld het gelijk...

[xCell]

Relatief complex gebeuren, maar goed dat dit aan het licht wordt gebracht. Des te sneller kan er een oplossing voor worden gecreëerd. Nu moet er wel bij worden gezegd dat het direct benaderen van een switch middels een md5 signature een niet al te makkelijke handeling is. Maar blijkbaar niet onmogelijk...

Het is wel triest dat systeembeheerders en dergelijke nog steeds standaard wachtwoorden gebruiken.

[wica]

De oplossing is niet zo gemakkelijk.
Zoals je zegt, maken ze gebruik van md5. Dit zit dus in de netwerkapparatuur in gebakken. Waardoor het waarschijnlijk niet snel opgelost is.

via een workaround is dit misschien op te lossen. Maar denk dat het dan wel vaak ten koste is van resources van het ding.

[Verwijderd]

Dit soort netwerkapparatuur werkt altijd met eenvoudig te updaten software, dus dat zal het probleem niet zijn.

[coretx]

In theorie een goed argument.

Jammer dat er bedrijven zijn die "om kosten te besparen" binnen dit segment er frequent bewust voor kiest om niet te updaten. On het mom van " Om de stabiliteit te behouden" en andere drog beredeneringen.

o.a de oorzaak van de "Maxima/WillemAlexander" dos aan aantal jaren terug. ( "verzorgd" door KPN )

[Reactie gewijzigd door coretx op 22 juli 2024 18:28]

[PolarBear]

Het ligt wel wat genuanceerder dan alleen kosten besparen. Core routers kan je niet zomaar even updaten, de risico's zijn te groot. En testen is nog niet zo makkelijk (simuleer maar even realistisch het verkeer op een core router van KPN). Daarnaast is het kiezen van een juist OS (IOS) voor een Cisco core router geen sinicure. Ik heb in het verleden mee gemaakt dat er gebruik gemaakt werd van een branch van het IOS buiten de standaard brache (vanwege specifieke bugs). Gevolg even upgraden zit er niet in.

Je kan zeggen wat is het risico, maar zelfs al is het maar 1x op de 100 het kan enorme gevolgen hebben. Core routers etc ga je niet zomaar upgraden.

[coretx]

Het is zeker niet makkelijk. Dat heb ik ook niet gesteld. Maar gebeuren moet het toch! Als je het dan niet aankan, ben je naar mijn mening simpelweg incompetent, en ben je verantwoordelijk voor de risico's.

[Verwijderd]

In een complex netwerk kost het volledig doortesten van een nieuwe softwarerelease veel tijd. Je gaat dus niet elke week of elke twee weken upgraden.
Dat heeft helemaal niks met competenties te maken. Dat heeft met inschatting van risico's te maken. Hoe groot is het risico dat er iets fout gaat tijdens een upgrade en hoe groot is het risico dat er iemand misbruik maakt van een veiligheidsissue? Sowieso zijn veel van de beveiliginsissues die gevonden worden in routersoftware (en dat zijn er al niet zo heel veel) dingen die je door een bepaalde feature uit te zetten of door middel van een accesslist kan blokkeren: het is dan dus ook helemaal niet nodig om te upgraden.

[coretx]

Eerst heb je het over "elke week of elke twee weken"
Daarna zeg je "veiligheidsissue.... zijn er al niet zo veel"
Dubbelspraak.

Toch kan het in exentrieke gevallen voorkomen.
Maar dat neemt nog niet weg dat het een keus is. En dus blijf je dan alsnog verantwoordelijk.

[Reactie gewijzigd door coretx op 22 juli 2024 18:28]

[Punica-]

Dat zegt hij omdat je routers 9 v/d 10x om bugfixes of feature enhancements upgrade , die ene keer doe je het voor een echt serieuze security flaw.

In veel netwerken is het trouwens vaak wel mogelijk om core routers te upgraden, doordat het netwerk goed opgezet is, dit hoeft geen downtime tot gevolg te hebben, doordat een andere router de taak kan overnemen van de router die je aan het upgraden bent.

Maar dan nog, moeten dit soort upgrades natuurlijk altijd in aangekondigde afgesproken maintenance windows gebeuren.

[Verwijderd]

Eerst heb je het over "elke week of elke twee weken"
Daarna zeg je "veiligheidsissue.... zijn er al niet zo veel"
Dubbelspraak.

Dat bedoelde ik bij wijze van spreken, dat snap je toch zelf ook wel neem ik aan?

Toch kan het in exentrieke gevallen voorkomen.
Maar dat neemt nog niet weg dat het een keus is. En dus blijf je dan alsnog verantwoordelijk.

De nieuwste softwareversies hebben ook de nieuwste bugs. Zolang er geen echt ernstige beveiligingsproblemen zijn gevonden is de beste keus vaak om op een wat oudere "proven" versie te blijven draaien.

[polthemol]

dan kun je je misschien afvragen of daar geen uitdaging ligt om ervoor te zorgen dat het wel om de paar weken kan.

Traag zijn met updaten is nogal een grote veroorzaker van problemen in het algemeen (natuurlijk na de admin met het password "Cisco", "Class" of "Cisco123" )

[Verwijderd]

dan kun je je misschien afvragen of daar geen uitdaging ligt om ervoor te zorgen dat het wel om de paar weken kan

Er zijn al wel veranderingen waardoor je met minder risico kan updaten, zo kan je op sommige systemen inmiddels upgraden zonder downtime, zo worden ook netwerk-OS'en modulair: zit er een bug in je BGP implementatie, dan upgrade je alleen de BGP daemon en draait IS-IS of OSPF gewoon door, maar dan blijft het probleem: elke wijziging is een risico. Je houdt je netwerk het lieftst stabiel.

Traag zijn met updaten is nogal een grote veroorzaker van problemen in het algemeen

Volgens mij valt dat, in netwerkland in ieder geval, best mee. Er worden niet zoveel securityfouten in netwerk-OS-en gevonden; als ze gevonden worden zijn ze vaak lang niet overal te exploiten en zelfs dan worden ze niet zoveel geexploit. Dat wil natuurlijk niet zeggen dat je niet voorzichtig moet zijn: als je netwerk een bekend issue heeft, moet je zo snel mogelijk upgraden.