De bewaking van de continuiteit van een netwerk volstaat tegenwoordig niet meer met het controleren of routers bereikbaar zijn, of het netwerk verkeer kan transporteren, of hoeveel verkeer dit betreft. Traffic moet ook geanalyseerd kunnen worden: wat is de bron en het doel, om welk protocol gaat het, welke poorten worden gebruikt en op welk moment?

Met de intrede van Juniper routers bij Duocast is tevens Netflow in gebruik genomen. Een router met Netflow-ondersteuning kan flows verzamelen en deze versturen naar een Netflow collector – een server die de flowinformatie voor langere tijd bewaart. Deze informatie kan vervolgens naderhand geanalyseerd worden. Een flow bevat alleen informatie over de bron, het doel (host/poort), protocol en andere ondersteunende informatie, en dus niet de inhoud van de data.

De Netflow collector, in ons geval een Linux server met NfSen, verzamelt per vijf minuten alle flow informatie in een bestand. Deze bestanden dienen vervolgens als bron voor het maken van grafieken en analyses. Tijdens en na een DDoS-aanval gebruiken we NfSen het meest, om het doel, de poorten en het gebruikte protocol te achterhalen. In een enkel geval kijken we ook naar de bron van het verkeer, maar veelal wordt er gebruik gemaakt van spoofed IP-adressen waardoor informatie over de bron weinig toevoegt.

Idealiter zou het gebruik van Netflow op een router geen impact mogen hebben op de performance van een router. Helaas hebben we bij Juniper routers gemerkt dat Netflow niet direct impact op de routing/forwarding heeft, maar dat het laden van een BGP-tabel wel enorm vertraagd wordt. Ditzelfde fenomeen, ook wel “een langere converge tijd door het gebruik van sampling” genoemd, is tevens beschreven in de Root Cause Analysis die is opgesteld na de laatste storing binnen ons netwerk.

We zochten daarom een oplossing die het bestaande netwerk zou ontlasten en geen performanceverlies zou kunnen veroorzaken. Alle koppelingen tussen onze routers en onze leveranciers bestaan uit glasvezel, singlemode, 10Gbps. Een gebruikelijke glasvezelverbinding gebruik twee vezels: een vezel waarop kant-A stuurt, kant-B ontvangt en een vezel waarop kant-B stuurt en kant-A ontvangt. Vanuit kant-A is wordt de eerste vezel dan voor TX (transmit) gebruikt en de tweede vezel voor RX (receive).

Het licht dat via de ene vezel verstuurd wordt en via de andere vezel ontvangen wordt kan getapt worden met een Optische Tap. In ons geval is dit een passief apparaat, het bevat geen elektronische onderdelen. De tap zelf heeft geen invloed op het dataverkeer, de lichtsterkte is alleen wel lager dan wanneer er geen tap gebruikt wordt. Of dit neveneffect acceptabel is op een specifieke verbinding hangt af van de lichtsterkte waarmee het orginele signaal binnenkomt en het optische budget waarbinnen de ontvangende kant nog normaal kan functioneren.

Dankzij de tap blijven per externe verbinding twee TX-signalen over voor analyse. Deze signalen zijn aangesloten op een server met daarin Intel XL710-QDA2 netwerkkaarten. Deze kaarten voorzien in twee SFP+ sloten waarin SFP+ modules (met Intel firmware) geplaatst kunnen worden. Daarop worden vervolgens de TX-vezels aangesloten. Binnen Linux is daarna een 10Gbe netwerk interface per externe verbinding beschikbaar. Op deze interface kunnen verschillende monitoring-, tap- en analysetools gedraaid worden.

Voor de analyse gebruiken we twee tools: NfSen en FastNetMon. NfSen kan niet direct overweg met de tapdata, want NfSen verwacht traffic flows. Daarom gebruiken we nProbe  om de tapdata om te zetten in traffic flows. Deze flows worden vervolgens door NfSen twee maanden bewaard. Doordat NfSen de flows aggregeert per 5 minuten en pas daarna de grafieken bijwerkt, is NfSen minder geschikt voor het snel opmerken van een (D)DoS-aanval.

FastNetMon is een (D)DoS analyse tool die binnen enkele seconden een (D)DoS opmerkt. Aan het opmerken kunnen vervolgens verschillende acties  verbonden worden, zoals het afgeven van een alarm. Daarnaast verzamelen we de meest recente 60 minuten aan data uit FastNetMon in Graphite om er met Grafana een overzichtelijk dashboard van te maken die wordt weergegeven op een monitor bij ons op kantoor.

De nieuwe monitoringomgeving heeft er voor gezorgd dat (D)DoS-aanvallen binnen enkele seconden opgemerkt worden, tegenover de 5+ minuten in de oude situatie. De routers zijn ontlast, een volledige BGP-tabel laadt nu binnen 5 minuten in plaats van 17+ minuten. Dankzij deze significante snlheidswinsten en de informatie die we vergaren via de nieuwe taps kunnen we ons netwerk nog nauwlettender in de gaten houden.