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 , , 36 reacties
Submitter: Eagleman7

Netwerkapparatuurbedrijf Cisco heeft een patch uitgebracht voor de 3000- en 3500-series van zijn Nexus-switches. Deze zijn kwetsbaar doordat er in de NX-OS-software een gebruikersaccount aanwezig is met een vast wachtwoord, waarmee aanvallers root-toegang kunnen krijgen.

cisco nexus 3000Cisco laat weten dat de software het gebruikersaccount tijdens de installatie aanmaakt en gebruikers het niet kunnen verwijderen zonder de werking van het systeem in gevaar te brengen. Waarom het account er is, vermeldt het bedrijf niet.

Dit account maakt het voor een aanvaller mogelijk om via telnet of in een enkel geval via ssh verbinding te maken met de apparaten en beheerderstoegang te verkrijgen. De kwetsbaarheid heeft het nummer cve-2016-1329 toegewezen gekregen en kan onder andere gebruikt worden om netwerkverkeer te onderscheppen.

De kwetsbare versies van de NX-OS-software zijn 6.0(2)U6(1) tot en met versie 6.0(2)U6(5) voor de switches in de 3000-serie. Voor de 3500-serie betreft het versies 6.0(2)A6(2) tot en met 6.0(2)A6(5) en versie 6.0(2)A7(1). De apparaten in deze serie van de Nexus-switches zijn gemaakt voor gebruik in datacenters. Gebruikers die geen update kunnen uitvoeren wordt aangeraden om als workaround telnet uit te schakelen. Het is Cisco niet bekend dat er kwaadwillenden misbruik hebben gemaakt van de kwetsbaarheid.

Moderatie-faq Wijzig weergave

Reacties (36)

Was het niet Cisco die schreeuwde van daken dat ze niet zulke 'backdoors' in hun producten hadden toen dit bij Juniper werd gevonden. Ik was al uiterst sceptisch toen ze dit gingen roepen en dat blijkt maar weer.

Waarom alleen Nexus switches van 3000 en 3500 series? De 7000 series draaien toch ook NX-OS? Of zijn er verschillende operation systems die NX-OS heten?
Maar dit is toch gewoon slordig dat je het niet kan aanpassen? Het is hetzelfde als je van je router niet je admin/admin kan aanpassen...
Slordig? Dat is wel een heel vriendelijke manier om het te zeggen. Grof nalatig lijkt me een betere omschrijving. Dat ze die dingen nog leveren met telnet ingeschakeld is al schandalig. Dat er nu nog hard-coded wachtwoorden gebruikt worden is niet te begrijpen.
Ik hoop eigenlijk dat er klanten zijn die Cisco nu aanklagen voor aan het crimineel grenzende nalatigheid. Cisco zou echt beter moeten weten.

Is die account nu te benaderen via SSH of niet? Als dat zo is dan heeft het uitschakelen van telnet geen enkele zin. Het wachtwoord staat vast, je hoeft het niet af te luisteren.

Is er geen kwaliteitscontrole? Mijn monitoring-systemen waarschuwen me als er accounts zijn met een wachtwoord waar dat niet hoort. Worden er geen automatische controles gedaan op zo'n firmware? Als dat niet zo is dan is dat een schande op zich, als het wel zo is dan stellen die controles dus niks voor.

[Reactie gewijzigd door CAPSLOCK2000 op 3 maart 2016 11:25]

Voor alle duidelijkheid: Hetgeen hier is gebeurd is tegen de interne security policies van het bedrijf (met name: geen hardcoded accounts en/of paswoorden tenzij in factory-reset state).

En wat betreft telnet: daarvoor moet je Microsoft aankijken, want die leveren voor zover ik weet nog steeds enkel een telnet client mee en geen SSH client bij hun OS. Veel installatie-locaties hebben geen internet-access (en wil je vanuit security oogpunt ook niet) dus zijn de systemen erachter quasi verplicht dat soort onveilige protocollen te gebruiken.
Telnet moet trouwens ook aan/uit te zetten zijn door de klant (nog zo'n policy).
Zie ook de release note:
The Telnet protocol is disabled by default on Nexus 3000 Series and 3500 Platform Switches.
Automatische controles op firmware is eigenlijk een onmogelijk voorstel. Mocht je weten hoeveel flavors van OS'en er intern gebruikt worden, dan moet ofwel iedereen die verificatie herimplementeren voor zijn images (met opnieuw kans op bugs) of simpeler nog: gewoon de fout niet begaan. Helaas zijn niet alle ingenieurs security specialisten en net daarom dat die policies er zijn waar elke groep op moet aftekenen (hoewel het duidelijk mag zijn dat er voor zowat elke groep nog een redelijke weg af te leggen is).
Er ligt intern een behoorlijke druk om iedereen tot een bepaalde niveau van security te verplichten, maar de weg is lang en het onbegrip van product management groot (want security smeer je geen boterhammen van, behalve voor security producten zelf).

[Reactie gewijzigd door H!GHGuY op 3 maart 2016 12:29]

Voor alle duidelijkheid: Hetgeen hier is gebeurd is tegen de interne security policies van het bedrijf (met name: geen hardcoded accounts en/of paswoorden tenzij in factory-reset state).
Tja, dat het tegen de policy is zal wel maar daar hebben we blijkbaar niet zo veel aan.
Als het policy was om het zo te doen... :+
En wat betreft telnet: daarvoor moet je Microsoft aankijken, want die leveren voor zover ik weet nog steeds enkel een telnet client mee en geen SSH client bij hun OS. Veel installatie-locaties hebben geen internet-access (en wil je vanuit security oogpunt ook niet) dus zijn de systemen erachter quasi verplicht dat soort onveilige protocollen te gebruiken.
Dan leveren ze maar een CD'tje met putty mee, bij zo'n dure switch mag dat geen probleem zijn. Je moet er ook een netwerkkabel in steken voor het werkt. De gemiddelde consumtenrouter/switch kan prima zonder telnet.
Telnet moet trouwens ook aan/uit te zetten zijn door de klant (nog zo'n policy).
Gelukkig. Maar daarmee valt het hele verhaal dat je telnet nodig hebt op Windows in duigen, je zal toch eerst een keer verbinding moeten maken om telnet aan te zetten. Als je toch al verbinding hebt dan heb je ook geen telnet meer nodig.
Automatische controles op firmware is eigenlijk een onmogelijk voorstel.
Echt niet, ik weet dat er genoeg leveranciers zijn die het wel doen. Ik kan geen namen noemen maar het gebeurt. Firmware is gewoon software. Vanuit het oogpunt van de eindgebruiker is er misschien een klein verschil maar niet vanuit het oogpunt van de developer.
Mocht je weten hoeveel flavors van OS'en er intern gebruikt worden, dan moet ofwel iedereen die verificatie herimplementeren voor zijn images (met opnieuw kans op bugs)
Zo'n test-suite kun je helemaal automatiseren. Zoveel OS'en heeft Cisco trouwens niet. Er zijn wel een hoop versies en patches maar die hebben grotendeels een gemeenschappelijke basis. De meeste van die checks zouden niet afhankelijk moeten zijn van een specifieke versie van het OS. Zeker het probleem waar het hier om gaat is triviaal om te controleren. Ik kan het weten het omdat ik zo'n check op m'n eigen systemen heb.
Natuurlijk doe je zo iets niet van vandaag op morgen maar Cisco is oud en groot genoeg dat ze er al 10 jaar geleden aan hadden moeten beginnen, dan was het nu wel klaar geweest.
of simpeler nog: gewoon de fout niet begaan.
Als er een manier was om fouten te voorkomen dan hadden we deze hele discussie nooit gehad.
Helaas zijn niet alle ingenieurs security specialisten en net daarom dat die policies er zijn waar elke groep op moet aftekenen (hoewel het duidelijk mag zijn dat er voor zowat elke groep nog een redelijke weg af te leggen is).
Ik snap wel hoe het werkt maar vind dat best wel onacceptabel. Van de bakker accepteer ik het ook niet als er gif in m'n brood zit omdat hij nu eenmaal niks van hygiŽne weet. Zo'n specialisme is deel van het werk. Als je dit soort fouten maakt dan heb je niks te zoeken in een dergelijk team.
Er ligt intern een behoorlijke druk om iedereen tot een bepaalde niveau van security te verplichten, maar de weg is lang en het onbegrip van product management groot (want security smeer je geen boterhammen van, behalve voor security producten zelf).
Tijd voor een flinke rechtzaak om de prioriteiten goed te krijgen.
Tja, dat het tegen de policy is zal wel maar daar hebben we blijkbaar niet zo veel aan.
En jij maakt nooit fouten? Voor hetgeen ik er van zie lijkt het gewoon een bug.
Dan leveren ze maar een CD'tje met putty mee, bij zo'n dure switch mag dat geen probleem zijn. Je moet er ook een netwerkkabel in steken voor het werkt. De gemiddelde consumtenrouter/switch kan prima zonder telnet.
Kort door de bocht. Je moet niet elke mogelijke remote dependency meeleveren die de klant misschien ooit in een verre toekomst zou kunnen nodig hebben. Waarom dan niet meteen ook Tectia SSH of een andere? Dan kunnen ze nog kiezen ook.
Gelukkig. Maar daarmee valt het hele verhaal dat je telnet nodig hebt op Windows in duigen, je zal toch eerst een keer verbinding moeten maken om telnet aan te zetten. Als je toch al verbinding hebt dan heb je ook geen telnet meer nodig.
Die switches/routers krijgen veelal via RS-232 hun initiŽle configuratie.
Pas daarna zet je telnet en/of SSH open.

Trouwens krijgt deze een CVSS score van 2 (voor zover ik kon zien). En dat is net omdat telnet niet veel gebruikt wordt.
Echt niet, ik weet dat er genoeg leveranciers zijn die het wel doen. Ik kan geen namen noemen maar het gebeurt. Firmware is gewoon software. Vanuit het oogpunt van de eindgebruiker is er misschien een klein verschil maar niet vanuit het oogpunt van de developer.
Van wat ik van het probleem kon zien leek het probleem niet zo simpel. Het is niet alsof er een passwd file stond met een vergeten account of zo...
Maar ik kon niet de volledige fix zien, dus dit is onder voorbehoud.
Zo'n test-suite kun je helemaal automatiseren. Zoveel OS'en heeft Cisco trouwens niet. Er zijn wel een hoop versies en patches maar die hebben grotendeels een gemeenschappelijke basis. De meeste van die checks zouden niet afhankelijk moeten zijn van een specifieke versie van het OS. Zeker het probleem waar het hier om gaat is triviaal om te controleren.
Maak aub geen claims die je niet hard kunt maken. Er is een gigantische 'wildgroei' van OS'en. Van RTOS'en, tot tientallen Linux flavors, IOS, Windows-versies, etc.
Ik kan het weten het omdat ik zo'n check op m'n eigen systemen heb.
Proficiat dat JIJ (n=1) op JOUW (n=1) systeem een check hebt op je passwd file of iets dergelijks. Als je scans moet organiseren op de schaal van Cisco voor elk product (hint: er zijn er VEEL) dan is dit een gigantische operatie. En om je maar meteen voor te zijn: daar wordt aan gewerkt, maar Rome is ook niet op 1 dag gebouwd. Er zijn tools/scans voor vanalles en nog wat, maar van het weinige wat ik van deze bug gezien heb, ben ik niet zeker dat ie met een simpele scan zoals jij voorstelt zou gevonden zijn.
Natuurlijk doe je zo iets niet van vandaag op morgen maar Cisco is oud en groot genoeg dat ze er al 10 jaar geleden aan hadden moeten beginnen, dan was het nu wel klaar geweest.
....
Ik snap wel hoe het werkt maar vind dat best wel onacceptabel. Van de bakker accepteer ik het ook niet als er gif in m'n brood zit omdat hij nu eenmaal niks van hygiŽne weet. Zo'n specialisme is deel van het werk. Als je dit soort fouten maakt dan heb je niks te zoeken in een dergelijk team.
De beste stuurlui staan aan wal, nietwaar. De economische realiteit is echter nog altijd dat je met security geen klanten wint. Je kan er enkel mee verliezen. Gelukkig is dat besef ondertussen al lang doorgedrongen en wordt er hard getimmerd om alle producten adequaat te beveiligen (waar dit nog niet het geval was).
Security is trouwens een specialisme die je bij de doorsnee developer niet tegen komt. Ik kan je verzekeren dat dit bij elk bedrijf zo is. Je vergelijking loopt dus mank.

[Reactie gewijzigd door H!GHGuY op 3 maart 2016 19:49]

De telnet-client is op moderne Microsoft-OSen ook niet meer standaard geÔnstalleerd. Als je deze dan toch moet installeren kun je net zo goed een ssh-client installeren. Inderdaad wel absurd dat een ssh-client alleen van derden beschikbaar is. Waarom zit dat niet bij PowerShell?
Sinds windows 10 is er toch een ssh client in de shell of heb ik dat verkeerd gelezen?
Nee, in juni 2015 heeft MS aangekondigd dat het PowerShell team mee gaat werken aan het OpenSSH project. Dit zou tot een ssh-client en server moeten leiden die standaard meegeleverd wordt, maar ik kan geen planning vinden.
En wat betreft telnet: daarvoor moet je Microsoft aankijken, want die leveren voor zover ik weet nog steeds enkel een telnet client mee en geen SSH client bij hun OS.
Het lijkt me stug dat met de populariteit van OSX en Linux + de zelfredzaamheid van de gemiddelde sysadmin het van de meegeleverde Telnet client van Microsoft af hangt dat een bedrijf als Cisco dat wel of niet op hun apparaten open heeft staan 8)7

[Reactie gewijzigd door Lekkere Kwal op 3 maart 2016 14:17]

Het staat standaard uit. Het is de klant die het al dan niet op zet. Het wordt (althans in ons geval) voorzien omdat systemen binnen een bepaalde perimeter geen internetverbinding hebben en sterk beperkt worden/zijn qua tools. Telnet is dan een go-to tool omdat het gewoon quasi standaard op Windows staat (Zie Yggdrasil).

Ik moet echter zeggen dat de laatste tijd meer en meer van onze klanten wel degelijk een putty staan hebben op de machines en dit ook gebruiken ipv telnet. Het begint dus wel stilaan uit te sterven.
Komt eerder over als opzettelijk achtergelaten.
Slordig, het is eerder bedenkelijk.

Er staat letterlijk het account is nodig aangezien verwijdering de werking van het systeem in gevaar brengt. Waarom het er is vermelden ze niet.

De enige conclusie die ik er uit trek is dat het gewoon een backdoor is die men bewust heeft aangebracht. Het is niet onbewust aangezien het met het systeem verbonden is en verwijdering problemen geeft.

Het vaste wachtwoord gebruik men zodat men op afstand gewoon toegang kan krijgen tot deze type routers. Een vast wachtwoord is natuurlijk nooit goed maar ja lijsten bijhouden maakt het moeilijker dus laten we het simpel houden.

Aangezien cisco ook geen uitspraken doet over de functie moet je je ook afvragen of dit niet in meer type routers zit en hoe betrouwbaar cisco als bedrijf is.
Je mag er namelijk van uitgaan dat bijv de NSA al lang toegang had tot deze routers via dit standaard wachtwoord, wie weet is het er wel op hun verzoek.
Er staat letterlijk het account is nodig aangezien verwijdering de werking van het systeem in gevaar brengt. Waarom het er is vermelden ze niet.
Omdat er software draait met dat account?
De enige conclusie die ik er uit trek is dat het gewoon een backdoor is die men bewust heeft aangebracht. Het is niet onbewust aangezien het met het systeem verbonden is en verwijdering problemen geeft.
Het kan ook, en is net zo waarschijnlijk, bijzonder slechte geprogrammeerd zijn. Maar goed meteen backdoor en NSA roepen is natuurlijk makkelijker.
De enige conclusie die ik er uit trek is dat het gewoon een backdoor is die men bewust heeft aangebracht
Dat is natuurlijk geen backdoor: dit is gewoon een loper voor de voordeur.
Het is kwalijk dat een grote gerenomeerde fabrikant zo'n beginners fout maakt. Een dergelijk account mag gewoon niet noodzakelijk zijn, sterker nog het mag niet eens bestaan.
Een dergelijk account mag gewoon niet noodzakelijk zijn, sterker nog het mag niet eens bestaan
Ok, dan niet. Kun je meteen 50% (of meer) van de features van dat apparaat uit de brochure halen, want die doen het dan ook niet meer...

Denken mensen nu echt zo simpel? Dat account is er echt niet voor niks... Er is alleen een foutje gemaakt (ja, echt... In tegenstelling tot degenen die hier hard roepen hoe schandalig het wel niet is maakt de rest van de mensheid wel eens een foutje) waardoor je er mee kunt inloggen via een obsolete, default disabled protocol.
Dat account is er echt niet voor niks... Er is alleen een foutje gemaakt
Het is geen foutje. Het een enorme designfout. Om het apparaat goed te laten werken mag gewoon geen useraccount noodzakelijk zijn. Het is een switch, dat netwerk verkeer van de ene naar de andere poort stuurt. Op welke wijze is het logisch dat daarvoor de aanwezigheid van een user account noodzakelijk is?
Het is een switch, dat netwerk verkeer van de ene naar de andere poort stuurt.
Je hebt overduidelijk geen goed beeld van wat een datacenterswitch precies is en/of doet. Op zich is dat niet erg, maar je vormt je wel een (hele stellige) mening over iets waar je blijkbaar niet zoveel vanaf weet, en dat is jammer :)

Er is een reden dat zo'n Cisco Nexus 'iets' meer kost dan een Sweex switchje, en dat is niet alleen de throughput. Die dingen hebben allemaal advanced features zoals Virtual PortChannels, Auto Provisioning, buffer monitoring reports, multipath routing, ingebouwde diagnostische programma's, BGP, OSPF, EIGRP, RP, SPANning van poorten, SNMP, NAT, ACL's, trunking, LACP, spanning tree, HSRP, VRRP, VRF, GRE... Er draaien allemaal processen op die switch die op jouw voorbeeldswitch helemaal niet draaien, en ook niet nodig zijn. Op een datacenterswitch zijn die echter wel nodig, en daarom dat er ook een volwaardig OS op draait.

[Reactie gewijzigd door Paul op 5 maart 2016 13:02]

Je kunt wel een hele berg features opnoemen en beweren dat ik niet weet waar ik het over heb maar zelf nadenken mag je natuurlijk ook wel even doen. Het gaat om fundamentele systeem architectuur (en ja daar heb ik dan weer wel verstand van) en als je feature beheer/support aan het aanwezig zijn van een gebruikersaccount knoopt die je gewoon iets verschrikkelijk fout in je software ontwerp. Als je naar een doodgewoon Windows 7 systeempje (qua complexiteit net iets groter dan zo|n switch) kijkt dan is daar een gebruiker System. Maar inloggen als die gebruiker kan niet. En dat had Cisco ook moeten doen als ze niet hadden kunnen voorkomen dat deze gebruiker moet bestaan. Maar inloggen kon en de voor het systeem noodzakelijk gebruiker had zelfs een vast wachtwoord. Onacceptabel.
...en dat is dus het foutje: Als deze gebruiker kon je wel inloggen.

Op zo'n switch draait natuurlijk geen Windows, en qua complexiteit durf ik het vergelijk tussen Windows en zo'n switch niet zomaar te maken, maar bijvoorbeeld bij een Linux-systeem staan alle gebruikers (ook de equivalente "system" en "network service") in /etc/passwd. Het kan zo simpel zijn als /bin/bash invullen als shell ipv /bin/nologin, of het uitroepteken vergeten in /etc/shadow, om maar iets te noemen.

Ik zeg niet dat die switches Linux draaien, maar het verschil tussen met een account in kunnen loggen of niet kan bijzonder klein zijn.

Maar maak ik hieruit op dat je er op terug komt dat er op zo'n switch geen users zouden mogen bestaan?

[Reactie gewijzigd door Paul op 5 maart 2016 13:44]

als het een backdoor was dan hadden ze het wel ook toegestaan op SSH want er zal maar een heel klein aantal routers zijn die telnet access open hebben staan. Als je dan toch een backdoor bouwt maak er dan eentje waar de kans op succes iets groter is.
Het is uberhaupt slordig dat je software kennelijk niet kan werken zonder een eigen admin account met fixed wachtwoord, dat ook nog eens extern toegankelijk is. Vanuit security oogpunt is dat echt not-done.
The vulnerability is due to a user account that has a default and static password. This account is created at installation and cannot be changed or deleted without impacting the functionality of the system.
De meest logische verklaring die ik kan bedenken is dat tijdens het ontwikkelen van de firmware er software was dat met root rechten gedraaid moet worden, bijvoorbeeld omdat er te weinig tijd/zin was om uit te zoeken welke specifieke rechten bovenop een gewoon gebruikersaccount nodig zijn.

Aangezien je dat niet onder 'root' zelf wilt, is er een workaround ('dirty fix') gemaakt door een vast gebruikersaccount en wachtwoord aan te maken met root rechten. Hierbij zijn zij vergeten om remote access voor dit account uit te schakelen.

Het lijkt mij sterk dat dit bedoeld was als backdoor. Daarvoor staat het iets te veel in de schijnwerpers. Het is immers toch geen verborgen account?

[Reactie gewijzigd door The Zep Man op 3 maart 2016 11:11]

Of, en nu speculeer ik enorm, is dit een back-door voor de overheidsdiensten en wil Cisco met de recente ophef over de iPhone de boel rechtbreien... :X

Nogmaals pure speculatie maar apart is het wel. In ieder geval goed dat er nu een patch voor komt
Wat echter nog steeds bedenkelijk is, is dat men geen uitspraak doet over de functie en waarom de "backdoor" er is. Dat is op zich al heel apart.
Nee, dat is heel standaard.

Als je nu plots alle info verstrekt, dan vergroot je de kans op misbruik. Door opzettelijk een beetje vaag te blijven beperk je die kans.

De bugtracker bevatte oorspronkelijk wel de naam van de account, maar deze is er uit gescrubbed, net om misbruik te beperken. Ik kan je alvast vertellen dat het niet op een backdoor lijkt.

[Reactie gewijzigd door H!GHGuY op 3 maart 2016 20:09]

Dit vaste wachtwoord is natuurlijk een hele slechte zaak.

Maar als je bedrijf hierdoor plotseling enorme risico's loopt dan moeten er een paar mensen ontslagen worden.

Regel nummer 1 is dat je dit soort management interfaces niet aan je reguliere bedrijfsnetwerk knoopt maar dat je een speciaal management (v)LAN hebt zodat alleen IT-personeel er bij kan komen. Dat neemt al het grootste deel van het risico weg.
Was externe toegang automatisch ingeschakeld als gebruikers de software/hardware installeren?
Nee, telnet staat standaard uit. Daarom ook dat de CVSS score zo laag is.
Dit had je ook kunnen vinden als je de publieke bugreport had gelezen.
Bij het Cisco modem kan de ISP precies zien hoeveel apparaten je gebruikt en wat voor merk. Zelfs is het mogelijk om deze op afstand te resetten en poorten open of dicht te zetten. Hier komt ook een account bij kijken die standaard aanwezig is. Heel veel mensen hebben zo'n modem thuis. Is dat niet zorgelijk want als een sleutel op straat ligt kan de hele wereld bij je thuis kijken wat je allemaal aan hebt staan en nog erger wat voor muziek, foto's, film en documenten je hebt. Dit zou de eindgebruiker toch moeten kunnen in-, uitschakelen?
Bij het Cisco modem kan de ISP precies zien hoeveel apparaten je gebruikt en wat voor merk.
Joh kunnen ze de ARP tabel lezen?
. Heel veel mensen hebben zo'n modem thuis. Is dat niet zorgelijk want als een sleutel op straat ligt kan de hele wereld bij je thuis kijken wat je allemaal aan hebt staan en nog erger wat voor muziek, foto's, film en documenten je hebt.
Denk dat het aantal mensen met een Nexus Switch thuis niet heel groot is. Cisco modems is echt een andere tak van sport. Draait ook geen NX-OS op.
Het blijft in dit geval Cisco die met achter deuren binnen kan komen. Zonder kloppen.
1) De Nexus-reeks van Cisco is een datacenter-switch, geen CPE / kabelmodem. De enige link tussen je post en het nieuwsbericht is dat Cisco ook kabelmodems maakt :P
2) Dat account is geen backdoor maar de manier waarop (de helpdesk van) je ISP onderhoud pleegt op je modem en jou helpt als je ze belt met een probleem
3) Dat account in je modem heeft een wachtwoord dat alleen je ISP weet, en waarschijnlijk (maar dat is inderdaad een aanname) per modem anders is
4) Met dat account kun je dingen doen op het modem, voor de rest heeft het nul rechten op jouw computer of server, tenzij jij zelf gast-toegang aan hebt gezet.
Niet bekend dat er kwaadwillenden misbruik hebben gemaakt, en natuurlijk is de NSA geen kwaadwillende dus klopt dat....
Interessante toevoeging, dit bericht, aan de steeds langer wordende lijst van dit soort meldingen uit de VS. ...
Het is op zich heel erg dat dit voorkomt, maar IEDERE zichzelf respecterende netwerk-beheerder zou toch minimaal een Access-list moeten configureren en deze aan de vty-lines moeten koppelen.
Als je dit niet doet, ben je gewoon een klojo en kun je beter plantsoenen gaan onderhouden of zo.
Verder is de nexus-serie een datacenter-switch puur sang, en ik verwacht dat ieder datacenter zijn beheers-vlan niet bereikbaar is vanuit internet, en minimaal met firewalls beschermd heeft!

Dus ja, het is niet echt goed te praten, maar nee, dit is geen device wat normaal aan internet hangt om via die weg toegang te gevem!

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