Gebrekkige routers overspoelen tijdserver van University of Wisconsin

Auteur: Dave Plonka, 21 augustus 2003 - University of Wisconsin-Madison Bijgewerkt: 19 juli 2006

Abstract

In mei 2003 stelde de University of Wisconsin-Madison vast dat zij het doelwit waren van een continue, grootschalige vloed van inkomend internetverkeer, bestemd voor een van de publieke Network Time Protocol (NTP) servers van de campus. De snelheid van dit verkeer liep op tot honderdduizenden pakketten per seconde en honderden megabits per seconde.

Vervolgens hebben we vastgesteld dat de bronnen van deze vloed letterlijk honderdduizenden echte internethosts over de hele wereld zijn. In plaats van een kwaadaardige distributed denial-of-service (DDoS) aanval, is de grondoorzaak echter een ernstige ontwerpfout in honderdduizenden goedkope internetproducten voor residentieel gebruik van één specifieke leverancier. Het onverwachte gedrag van deze producten vormt voor de komende jaren een aanzienlijk operationeel probleem voor UW-Madison.

Dit document bevat de eerste publieke onthulling van de details van deze ernstige ontwerpfout. Daarnaast wordt onze lopende, veelzijdige aanpak voor een oplossing besproken, waarbij de universiteit, de fabrikant van de producten, de relevante internetstandaarden (RFC's) en de publieke internetservice- en gebruikersgemeenschappen betrokken zijn.

De initiële vloed

Afbeelding 1. De initiële vloed

Afbeelding 1 is een grafiek van het inkomende verkeer naar onze campus over een periode van 48 uur, van dinsdag 13 tot en met donderdag 15 mei 2003.

De eerste helft van de grafiek toont typische verkeersniveaus voor onze campus, met piekwaarden voor inkomende pakketten van ongeveer 40.000 pakketten per seconde. Echter, zoals te zien is, nam de snelheid van inkomende pakketten per seconde dramatisch toe vanaf 14 mei rond 08:00 uur lokale tijd, voornamelijk via onze commerciële Internet Service Provider, WiscNet.

Rond 09:40 uur begon dit extra verkeer problemen te veroorzaken voor onze meetinfrastructuur en enkele van onze verouderde intra-campus routers. Tegen 11:00 uur hadden we de inkomende vloed kunnen identificeren op basis van protocol- en poortnummers. Het verkeer was bestemd voor onze publieke tijdserver. We hebben het inkomende verkeer upstream geblokkeerd bij de border-routers van WiscNet, wat het probleem voor die tijd verhief. Dit is een typische actie voor netwerkbeheerders in reactie op kwaadaardige Denial-of-Service vloedaanvallen, waarvan we in eerste instantie aannamen dat dit er een was.

Het blokkeren van de vloed

Het betreffende verkeer leek te bestaan uit Network Time Protocol (NTP) queries, bestaande uit IP-pakketten van 76 bytes bestemd voor UDP-poort 123 (NTP).

Deze pakketten hadden echter een ongebruikelijk kenmerk: hoewel ze van veel verschillende bronnen leken te komen, hadden ze allemaal hetzelfde bronpoortnummer: 23457. Hierdoor was het mogelijk om onze routers zo te configureren dat ze slechts een subset van de inkomende queries naar onze NTP-server blokkeerden, terwijl legitieme verzoeken gewoon verwerkt bleven worden. We blokkeerden simpelweg alle UDP-verkeer afkomstig van poort 23457 bestemd voor poort 123 (NTP) van de betreffende server. (Het getal 23457 lijkt bewust gekozen, aangezien het het getal direct na 23456 is). Op dat moment schreven we dit toe aan naïviteit van de "aanvaller", van wie we vermoedden dat hij vele willekeurige bronadressen vervalste, en we gingen ervan uit dat de vloed binnen enkele uren zou wegzakken, zoals vaak gebeurt bij aanvallen gelanceerd door "script kiddies".

Achtergrond: Simple Network Time Protocol (SNTP)

Geparafraseerd uit RFC2030 door Dave Mills:

Het Simple Network Time Protocol (SNTP) is een aanpassing van het Network Time Protocol (NTP) dat wordt gebruikt om computertijden op het internet te synchroniseren. Het is een eenvoudig, stateless remote-procedure call (RPC) systeem met nauwkeurigheids- en betrouwbaarheidsverwachtingen die vergelijkbaar zijn met het UDP/TIME-protocol beschreven in RFC-868. SNTP kan worden gebruikt wanneer de volledige prestaties van een volledige NTP-implementatie niet noodzakelijk zijn.

Let op dat SNTP hetzelfde pakketformaat gebruikt als NTP. Op deze manier kunnen SNTP-clients gebruikmaken van NTP-servers, ook al implementeren ze niet de complexiteit van het volledige peer-to-peer NTP-protocol.

SNTP-conversaties volgen doorgaans deze stappen:

1. Een client die de tijd wil weten, stuurt een UDP-pakket met het SNTP-verzoek naar het bekende NTP-poortnummer 123 van een NTP-server en wacht op antwoord.

Afbeelding 2. Een SNTP Request Packet (Technische specificatie van het pakket: LI=0, VN=1-4, Mode=3, Stratum=0, Poll=0, Precision=0, Root Delay=0, Root Dispersion=0, Reference Identifier=0, Reference Timestamp=0, Originate Timestamp=0, Receive Timestamp=0, Transmit Timestamp=n).

1. De server reageert met een UDP-pakket met het SNTP-antwoord van het bekende NTP-poortnummer 123 naar de SNTP-client.

Afbeelding 3. Een Unicast SNTP Reply Packet (Technische specificatie van het pakket: LI=0-2, VN=req, Mode=4, Stratum=1-14, Poll/Precision/Root Delay/Root Dispersion/Reference Identifier/Reference Timestamp = ignore, Originate Timestamp = gekopieerd uit request, Receive Timestamp = tijd van ontvangst, Transmit Timestamp=n).

Bij ontvangst van het antwoord gebruikt de client optioneel de Originate Timestamp uit het antwoord om de respons te valideren en te bevestigen dat het inderdaad een reactie is op het eigen verzoek. Daarna haalt de client de waarde uit de Transmit Timestamp, past deze eventueel licht aan om rekening te houden met de geschatte vertraging, en gebruikt het resultaat als de huidige tijd om de lokale klok in te stellen.

De vloed houdt aan

Een maand later ontdekten we dat de vloed van inkomend NTP-verkeer aanhield met een nog ongelooflijk hogere snelheid, zoals blijkt uit Afbeelding 4, die de snelheid van door onze router verworpen pakketten plot vanaf begin juni 2003.

Afbeelding 4. De vloed houdt aan: één maand later

In Afbeelding 4 is op te merken dat:

1. Er lichte dagelijkse schommelingen in de snelheid zijn (mogelijk door het gedrag van gebruikers overdag).
2. De snelheid over het algemeen boven de 250.000 pakketten per seconde (en boven de 150 megabits per seconde) blijft.
3. De verkeerssnelheid toeneemt gedurende de getoonde periode. De scherpe dalingen in de grafiek zijn niet te wijten aan het wegzakken van de vloed, maar aan netwerkonderhoud en een tijdelijke blokkade upstream.

Toen we zagen dat de vloed aanhield en toenam, zijn we verder gaan onderzoeken. Door de blokkade op enkele ingress-interfaces voorzichtig op te heffen, lieten we een kleine stroom verkeer door naar de server en captureden we de pakketten inclusief payload. We stelden vast dat deze pakketten legitieme, goed gevormde Simple Network Time Protocol (SNTP) versie 1 queries leken te zijn, zij het tegen een onverklaarbaar hoge snelheid per client-host. Tijdens één trace produceerden veel clients ongeveer één query per seconde. Dit is zeer ongebruikelijk voor een correct geconstrueerde SNTP-client, aangezien een applicatie die SNTP gebruikt enkel geïnteresseerd is in het relatief nauwkeurig instellen van de klok. Eén query per seconde is absurd en ver is verwijderd van de best-practice voor NTP-clientgedrag.

Ook ontdekten we dat veel van de IP-adressen konden worden opgelost naar DNS-namen en dat de IP-adressen valide bronnen leken te zijn voor de interface waarop we de blokkade hadden opgeheven. Dit wees erop dat de bronadressen waarschijnlijk niet waren vervalst, maar afkomstig waren van echte internethosts die een zeer ongebruikelijke SNTP-client draaiden.

Helaas bevonden geen van de bronhosts zich binnen ons eigen campusnetwerk. Dit betekende dat we hulp nodig hadden van personeel op externe locaties.

Onderzoek

Contact opnemen met bronnetwerken

Uit de packet trace selecteerde ik twee client-hosts van andere universiteiten met bekwaamd netwerkpersoneel. Hieronder volgt een e-mail die ik stuurde naar het Incident Response Team van een van deze instellingen. (Ter anonimisering is het IP-adres vervangen door 10.42.69.10 en zijn domeinnamen verwijderd).

Afbeelding 5. E-mail notificatie aan partnerinstelling

Datum: Zaterdag 14 juni 2003 04:34:11 -0500 Van: Dave Plonka <plonka@localdomain> Aan: abuse@[remotedomain] Onderwerp: sntp/ntp query flood van 10.42.69.10 naar ntp1.cs.wisc.edu

[Organisatie] network abuse folks,

Sinds 14 mei 2003 rond 08:00 uur centrale tijd is een van onze campus NTP-servers "ntp1.cs.wisc.edu" (128.105.39.11) het doelwit van een grootschalige vloed van Simple Network Time Protocol (SNTP) verzoeken - veel meer dan hij kan verwerken. Deze dramatische toename in inkomende SNTP-verzoeken houdt onverklaarbaar aan. Om deze vloed te beperken blokkeren we momenteel meer dan 250K pkts/sec, wat 150 megabits/sec overschrijdt, en dit gaat al weken door.

We proberen te bepalen of deze vloed potentieel kwaadaardig is of dat het gaat om een SNTP-client misconfiguratie of bug.

Dit verkeer bestaat voornamelijk uit UDP-pakketten van 76 bytes die SNTP versie 1 queries zijn van zeer veel verschillende bronadressen gericht op ntp1.cs.wisc.edu poort 123 (NTP). Ongebruikelijk is dat al deze verzoeken een UDP-bronpoort hebben van 23457. We hebben het hostadres 10.42.69.10 geïdentificeerd als één van de bronnen (er zijn echter tienduizenden bronadressen).

Ik heb een tijdstempel-log bijgevoegd van een packet capture van de middag van 13 juni 2003 (vrijdag), waaruit blijkt dat de host 10.42.69.10 SNTP query-pakketten stuurt tegen een ongebruikelijk hoge snelheid van ongeveer één per seconde. Een pakket-decompositie (via tethereal) en hex dump van het laatste pakket (frame 998) is inbegrepen, waaruit blijkt dat dit valide SNTP v1 queries zijn zoals beschreven in RFC 1361.

Kunt u ons zo spoedig mogelijk helpen bij dit onderzoek door het besturingssysteem van die host te identificeren en vast te stellen welke SNTP-client code er op die host draait? Het zou interessant zijn om te weten of een proces op 10.42.69.10 momenteel UDP-poort 23457 gebruikt en welke code dat proces draait.

Bedankt, Dave

P.S. Ons onderzoek tot nu toe heeft aangetoond dat Windows-systemen zoals 2000 en XP een "Internet Time" functie hebben die gewoonlijk is geconfigureerd om SNTP-verzoeken te sturen naar de Microsoft-server "time.windows.com", maar deze server kan worden gewijzigd. Ik heb tot nu toe geen enkele SNTP-client geïdentificeerd die regelmatig UDP-poort 23457 als bronpoort gebruikt. (Let op dat dit poortnummer handmatig gekozen lijkt, aangezien het het getal na 23456 is).

--- (Logbestanden en packet capture data volgen in de oorspronkelijke tekst, waarin wordt bevestigd dat host 10.42.69.10 elke seconde een NTP-pakket stuurt via poort 23457 naar 128.105.39.11)

Het netwerkpersoneel van twee universiteiten onderzocht de twee bronhosts die ik had gerapporteerd. Beiden meldden dat een router van het merk Netgear de bron van het verkeer was. (Specifiek werd één router geïdentificeerd als model MR814).

Nu begonnen de zaken logisch te worden. Dat veel bronhosts hetzelfde bronpoortnummer gebruikten, kon worden verklaard door een embedded SNTP-client waarin de programmeur het bronpoortnummer (23457) hard-coded had vastgelegd.

Achtergrondinformatie verzamelen

Tijdens het zoeken naar informatie over de geprezen NTP-ondersteuning van Netgear-producten, stuitte ik op de volgende quote (uit het ICSA Labs Firewall Lab Report over de NETGEAR FR114P):

"De Netgear FR114P vertrouwde op een aparte NTP-gebaseerde tijdsbron om de huidige datum en tijd in te stellen, aangezien deze geen interne batterij en klok had. Het product is hard-coded met specifieke NTP-tijdsbronnen die toegankelijk zijn via het publieke internet. Zelfs na het configureren van het product om toegang te krijgen tot een specifieke NTP-server, probeerde het product nog steeds toegang te krijgen tot zijn hard-coded NTP-tijdsbronnen, terwijl het gelijktijdig toegang zocht tot de opgegeven tijdsbron."

Netgear meldt dat de FR114P niet de specifieke SNTP-fouten bevat die hier worden beschreven. Ik vond het echter interessant, omdat dit de enige NTP-gerelateerde fout was waarover ik informatie op het web vond.

Analyse van de Netgear-code

Om onze hypothese te verifiëren dat de bron van de vloed de Netgear Platinum-familie producten zijn en om dit probleem correct aan de leverancier te rapporteren, is de Netgear-code voor een aantal van hun producten gedownload en onderzocht.

Door simpelweg het Unix "strings" commando te gebruiken, kon ik verifiëren dat de Netgear-code inderdaad het magische getal 23457 (als poortnummer) bevat:

$ strings RP614412.bin |grep 23457 on 23457 port.

$ strings MR814411.bin |grep 23457 on 23457 port.

Met een vergelijkbare techniek vond ik de volgende IP-adressen als ASCII-strings in RP614412.bin:

• 128.105.39.11 # ntp1.cs.wisc.edu (a.k.a. "caesar.cs.wisc.edu")
• 192.168.1.101
• 66.37.215.43
• 12.234.94.14
• 192.168.0.1

Hetzelfde gold voor MR814411.bin:

• 0.0.0.0
• 12.234.94.142
• 66.37.215.43
• 192.168.0.102
• 128.105.39.11 # ntp1.cs.wisc.edu
• 192.168.0.1
• 192.168.1.101

Van de drie wereldwijd routeerbare IP-adressen lijkt alleen 128.105.39.11 te worden gebruikt als NTP-server. Netgear heeft ons gemeld dat de overige wereldwijd routeerbare IP-adressen niet langer worden gebruikt en deel uitmaken van "dead code" die is overgebleven van debugging door een van de ontwikkelaars.

Contact met Netgear

Op 16 juni 2003 stuurde ik de volgende e-mail naar de Netgear-support. Omdat dit probleem significanter is dan een typische klantondersteuningsvraag, stuurde ik hem ook rechtstreeks naar enkele Netgear-medewerkers.

Afbeelding 6. E-mail naar Netgear Support

Datum: Maandag 16 juni 2003 16:00:21 -0500 Van: Dave Plonka <plonka@localdomain> Aan: support@netgear.com Onderwerp: NETGEAR producten misbruiken tijdserver van University of Wisconsin

NETGEAR support folks,

Sinds 14 mei 2003 is de publiek geadverteerde internet tijdserver "ntp1.cs.wisc.edu" (a.k.a. "caesar.cs.wisc.edu", 128.105.39.11) aan de University of Wisconsin-Madison het doelwit van een grootschalige vloed van tijd-queries, blijkbaar afkomstig van NETGEAR-producten wereldwijd.

Op basis van onze analyse geloven we dat de NETGEAR "Platinum" producten, zoals de RP614 en MR814, de primaire bron van deze vloed zijn. De code van deze producten moet waarschijnlijk worden gewijzigd om wat in feite een accidentele Denial-of-Service aanval is op onze NTP-infrastructuur te beperken. Het geaggregeerde inkomende verkeer van NETGEAR-producten overschrijdt momenteel de 250.000 pakketten per seconde en 150 megabits per seconde bij onze border-routers, afkomstig van tienduizenden NETGEAR-bronnen. Dit heeft ons ook talloze werkuren gekost aan internetverkeersengineering, troubleshooting en misbruikonderzoek.

Specifiek lijkt de code voor de Platinum-producten een embedded Simple Network Time Protocol (SNTP) client te bevatten, die queries stuurt van UDP-poort 23457 naar poort 123 van de IP-host 128.105.39.11. Onverklaarbaar is dat de productcode wordt geleverd met onze server expliciet geconfigureerd per IP-adres. We hebben vastgesteld dat ten minste de volgende code-images onze server IP expliciet bevatten: MR814411.bin, MR814v409.bin, RP614400.bin, RP614412.bin.

We geloven dat dit ongepast is en niet voldoet aan de best current practice voor load-balancing en betrouwbaarheid van de NTP-service op internet. Daarnaast treden deze verzoeken vaak op tegen een zeer hoge snelheid per apparaat (bijvoorbeeld één per seconde), wat een enorme belasting vormt voor onze NTP-server.

Neem zo spoedig mogelijk contact met mij op over de standaard SNTP-clientconfiguratie van uw producten, een mogelijke softwarebug en het resulterende incident.

Ik zie uw reactie tegemoet. Dave

---

Na dagen zonder reactie belde ik het hoofdkantoor van Netgear en stuurde ik e-mails naar leden van het executive team. Op donderdag 19 juni ontving ik een voicemail van de director of support van Netgear. Hij bevestigde dat ze een fout in hun code hadden gevonden.

De reguliere supportorganisatie van Netgear was echter volledig niet-responsief. Pas 23 dagen na mijn melding ontving ik een standaardantwoord via hun supportsysteem.

Afbeelding 7. E-mail van Netgear Support (Het antwoord verontschuldigt het vertragingsverkeer door een onverwachte toename in e-mailvolume en vraagt of het probleem inmiddels is opgelost).

Het reviewproces

Kort na het contact met Netgear stelde ik de vorming van een reviewteam voor om mogelijke oplossingen te bespreken. Er werd een team gevormd met ongeveer vijftien leden, verdeeld over:

• Netgear-medewerkers.
• Universiteitsmedewerkers.
• Onafhankelijke experts uit vakgebieden zoals Regional Internet Registries, Internet Measurement Research en het Network Time Protocol.

Tijdens het reviewproces werden de volgende actiepunten ontwikkeld:

1. Fix de SNTP-client.
2. Stel netwerkoperationele opties voor.
3. Informeer de internetcommunity.
4. Verduidelijk Internet Best Current Practice en protocolstandaarden.

De gebrekkige SNTP-client

De gebrekkige Netgear SNTP-client implementatie in de getroffen producten heeft de volgende kenmerken:

• Gebruikt een hard-coded IP-adres voor de NTP-server: 128.105.39.11 (ntp1.cs.wisc.edu).
• Gebruikt een vast UDP-bronpoortnummer: 23457. (Dit was voordelig voor UW-Madison om clients te tellen, hoewel NAPT/NAT upstream dit poortnummer soms herschrijft).
• Opmerking voor netwerkbeheerders: Blokkeer alstublieft geen UDP-verkeer via poort 23457 of verkeer naar 128.105.39.11, omdat dit de beste oplossing in de weg kan staan.
• Polls met intervallen van één seconde totdat er een respons van de NTP-server komt. Daarna wordt een langer interval gebruikt (één minuut, tien minuten, twee uur of 24 uur, afhankelijk van model en firmware).

Impact op Netgear-klanten

In augustus 2003 doet de universiteit haar best om de Netgear-verzoeken te bedienen. Gebruikers van de getroffen producten zouden normaal gesproken geen problemen moeten merken. Bovendien lijkt slechts een kleine subset van klanten zich bewust te zijn van de tijdgerelateerde functies van deze producten (zoals logging, planning van beleid en e-mailmeldingen).

Parallel hieraan heeft Netgear firmware geproduceerd die deze problemen niet vertoont. Klanten kunnen upgraden naar nieuwere versies via de supportsite van Netgear.

Code-updates voor getroffen Netgear-producten

De volgende producten bevatten deze SNTP-ontwerpfouten. Bij de versies is de vroegste versie met een fix vermeld:

Afbeelding 8. Getroffen Netgear-producten

• RP614v2, RP614 (4-Port Cable/DSL Router):
• RP614v2: upgrade naar v5.13 (11-07-2003)
• RP614: upgrade naar v4.14 (20-08-2003)
• MR814 (802.11b Cable/DSL Wireless Router):
• upgrade naar v4.13 (20-08-2003)
• DG814 (DSL Modem Internet Gateway):
• upgrade naar v4.8 (09-07-2003)
• HR314 (802.11a Cable/DSL High-Speed Wireless Router):
• upgrade naar v1.4.2 (05-09-2003)

Aantal gebrekkige producten

Ik heb meer dan 500.000 unieke Netgear-bronnen geteld die in één dag onze tijdserver hebben bevraagd. Dit is waarschijnlijk een onderschatting vanwege NAT.

Op 30 juni 2003 rapporteerde Netgear dat er in totaal 707.147 getroffen producten waren gefabriceerd. Een eenvoudige rekensom: als 700.000 errante SNTP-clients elk één verzoek per seconde sturen, is de maximale aggregate rate ongeveer 700.000 pakketten per seconde. Bij 76 bytes per pakket is dat 426 megabits per seconde aan verkeer.

Afbeelding 8a. Netgear SNTP Clients Per Dag

Voorgestelde oplossingen

Tijdens het reviewproces werden diverse verbeteringen voor de SNTP-client gesuggereerd. Een SNTP-implementatie:

• ZOU een poll-interval moeten gebruiken tussen de 64 en 1024 seconden of langer.
• ZOU lokale NTP-servers of multicast moeten gebruiken wanneer beschikbaar, geconfigureerd door de operator of via DHCP (RFC 2132).
• MAG een exponentiële backoff van het poll-interval toepassen bij het uitblijven van een respons.
• MAG NIET een korter poll-interval gebruiken wanneer een respons uitblijft.
• MOET de operator toestaan om het query-gedrag in te schakelen/uit te schakelen en de tijdservers te configureren.
• ZOU het Domain Name System (DNS) moeten gebruiken om server-IP's te bepalen.
• ZOU het server-IP via DNS moeten resolven vóór elke poll, zodat TTL-waarden worden gerespecteerd.
• ZOU het bestaande NTP-toegangscontrolemechanisme moeten ondersteunen door na een 'kiss-of-death' pakket de queries te staken.
• MAG een door de implementatie gedefinieerd vast bronpoortnummer gebruiken.

De initiële oplossing: "Instant" code

Netgear had al aan code-wijzigingen gewerkt voor de RP614v2 vóór mijn melding. In firmware v5.13 RC7 (beschikbaar op 10 juli) vertoonde de client de volgende kenmerken:

• Vereist nu een DNS-server voordat er SNTP-queries worden gegenereerd.
• Voert DNS-queries uit voor time-a.netgear.com en time-b.netgear.com om de tien minuten.
• Na succesvolle resolutie wordt een NTP-query gestuurd; bij geen respons na tien minuten wordt de naam opnieuw geresolved.

Ik vond echter ook bugs in deze nieuwe code:

• De client valideert het NTP-responspakket niet; elk pakket op poort 23457 wordt geaccepteerd, zelfs als de flags onjuist zijn.
• Terwijl de client wacht op antwoord, accepteert hij elk UDP-responspakket, zelfs als het bron-IP niet dat van de bevragde tijdserver is.

Netwerkoperationele opties: Bedienen of afsluiten?

Omdat deze apparaten niet eenvoudig reconfigureerbaar zijn, is het niet haalbaar om te vertrouwen op firmware-updates door klanten. Het reviewteam overwoog twee scenario's:

Endgame A: UW-Madison Netgear Anycast-tijdservice

Hierbij worden zeer betrouwbare, redundante NTP-servers geplaatst op de grenzen van WiscNet. Inkomende verzoeken naar 128.104.39.11 worden via BGP anycast naar deze servers geleid.

Voordeel: UW-Madison behoudt controle over zijn IPv4-adressen; er wordt slechts één /32 host-adres gebruikt. Risico: De universiteit heeft geen controle over of de respons de client bereikt. "Zombies" die geen respons ontvangen, zullen blijven flooden.

Afbeelding 10. Een WiscNet BGP-gebaseerde Anycast-tijdservice

Endgame B: Poging tot onderdrukking van de verzoeken

Om te voorkomen dat verzoeken ons netwerk bereiken, zou UW-Madison een blok IP-adressen moeten opofferen. In het huidige internet worden routes vaak pas geaccepteerd als ze groot genoeg zijn (bijv. een /21 of /20 blok).

Afbeelding 11. Gebruik van de globale BGP-routings tabel om verzoeken te smoren

Benodigde IP-bronnen voor Endgame B

Deze optie is kostbaar: de universiteit moet mogelijk tot 4.096 IP-adressen opofferen voor de levensduur van de defecte producten.

Afbeelding 12. IP-bronnen vereist voor BGP-gebaseerde onderdrukking

Het risico is dat delen van het internet geen toegang meer hebben tot legitieme campus-IP-adressen die in het opgeofferde blok liggen.

De internetcommunity informeren

De publicatie van dit document is bedoeld om anderen te waarschuwen en te voorkomen dat dergelijke fouten worden herhaald. Netgear is vooraf op de hoogte gesteld van deze publicatie.

Tijdens het proces bleek dat de Commonwealth Scientific & Industrial Research Organisation (CSIRO) in Australië soortgelijke problemen heeft met ongeveer 85.000 SMC-routers.

Verduidelijken van Internet Best Current Practice en protocolstandaarden

Er wordt gewerkt aan twee Internet Drafts:

1. "Embedding Globally Routable Internet Addresses Considered Harmful": Een pleidooi tegen het hard-coden van publieke IP-adressen in hosts.
2. Herziening van RFC2030: De NTP-community probeert SNTP te herzien als een standard track protocol binnen de IETF.

Status per 21 augustus 2003

Netgear heeft meegewerkt aan de eerste stappen en er wordt gewerkt aan een overeenkomst voor een geschikte oplossing. Voorlopig blijft UW-Madison de verzoeken bedienen, ondanks incidentele grote vloeden.

Afbeelding 13. De meest recente vloed (De grafiek toont een "haaienvinnige" anomalie waarbij het verkeer groeide tot ongeveer 100.000 pakketten per seconde).

Overige overwegingen

Deze casus roept enkele vragen op:

• Wat zegt deze onbedoelde DDoS-vloed over de levensvatbaarheid van publieke internetdiensten?
• Kan de routing-infrastructuur worden verbeterd om minder disruptieve oplossingen mogelijk te maken?
• Zijn dergelijke incidenten een onvermijdelijk bijproduct van alomtegenwoordige, goedkope internet-hosts?

Dankwoord

Hulp bij dataverzameling en analyse werd geboden door:

• University of Wisconsin-Madison: Jeff Bartig, Jim Gast, Michael Hare, Adam Kunen, Dave Thompson.
• University of Florida: Robert Bird, Greg Goddard.
• Harvard University: Greg Mazzu.
• Overig: k claffy, Nevil Brownlee, George Michaelson.

Analyse-instrumenten

De volgende tools zijn gebruikt: MRTG, RRDTOOL, RRGrapher, junipoll, flow-tools, Cflow, FlowScan, tcpdump, ethereal (nu wireshark), sntp.pl, strings.

Referenties en verdere lectuur

• RFC2030: Simple Network Time Protocol (SNTP) Version 4
• RFC1305: Network Time Protocol (Version 3)
• Home of the Network Time Protocol (NTP) project
• RFC2132: DHCP Options and BOOTP Vendor Extensions
• RFC1546: Host Anycasting Service

Veelgestelde vragen (FAQ)

Wat is de aansprakelijkheid van Netgear voor het veroorzaken van deze denial of service? Mijn verantwoordelijkheden maken mij geen partij in deze onderhandelingen, maar er wordt aan een overeenkomst gewerkt. Dit document is een technische samenvatting en geen voertuig voor juridische of financiële details.

Heeft u overwogen een server op te zetten die nepantwoorden stuurt om mensen te dwingen te upgraden? Ja, maar we concludeerden dat dit weinig effect zou hebben omdat weinig klanten op de hoogte zijn van de NTP-functies. Bovendien zou het onbeleefd zijn om een betrouwbare publieke tijdservice plotseling onbetrouwbaar te maken.

Wat is de verwachte levensduur van deze producten? Een schatting is dat velen ervan nog vijf tot tien jaar in gebruik zullen zijn.

Heeft de "haaienvin" in afbeelding 13 te maken met de stroomuitval (Blackout 2003)? Nee, het tijdstip kwam niet overeen. Wel was er tijdens de blackout een lichte daling in het Netgear-verkeer omdat sommige systemen offline waren.

Zijn er andere apparaten met deze fout? Sommige gebruikers meldden dat Netgear model RO318 (firmware V3.26) ook deze server gebruikt en NTP-fouten logt.

Wat was het effect van het feit dat dit artikel op Slashdot verscheen? Het had een aanzienlijk effect op de webserver (30 requests per seconde), maar was een insignificant niveau van verkeer voor de campus als geheel.

Waarom is een traditionele productterugroeping (recall) geen optie? Het is onwaarschijnlijk dat eigenaren het apparaat zouden terugsturen omdat het voor hen gewoon werkt. Bovendien hebben te weinig klanten hun producten geregistreerd bij de fabrikant om hen gericht te kunnen benaderen.

Hoe is dit verhaal in de pers belicht? Het is verslagen door onder andere Slashdot, The Inquirer, ZDNet, CNET en PC World, hoewel sommige artikelen details onjuist weergeven.