Dataopsamling på en internet exchange

Jeg har ikke specifik viden om at der idag foregår dataopsamling på DIX, men det er nok en sund antagelse at tro det. Vi ved at der foregår dataopsamling via GovCERT mange andre steder på offentlige myndigheders netværk.

Dagens nyhed idag er at NSA surveillance program reaches ‘into the past’ to retrieve, replay phone calls så hvad er nu det?! Jeg kender ikke omfanget af data der opsamles, men det sætter nogle tanker igang.

Lad os antage at vi vil opsnappe al datatrafikken i et bestemt område, vil det være muligt?
For at gøre det let så lad os tage et konkret eksempel DIX.dk hvad skal der til for at opsamle alt og gemme det?

Danish Internet Exchange Point - som til trods for navnet ikke indeholder al dansk trafik, men de har dog offentligt tilgængelig statistik. Hvis vi ser på grafen ligger trafikken omkring maximum på 40Gbit og vi skal have lidt luft så vores opsamling skal ihvertfald håndtere op til peaks med 50Gbit indgående trafik nu, og mere i fremtiden. Jeg kender ikke gennemsnit, men vi sigter mod 50Gbit average så der er luft til at tage trafik udenom internet exchange, fra "frivillige" leverandører.

Så hvad skal vi bruge? Vi skal bruge noget hardware til opsamlingen, software til at opsamle og gemme data, samt analyseprogrammer til at finde det interessante. Jeg har en forkærlighed for open source og kender nogle bestemte produkter - så den viden vil jeg bruge som udgangspunkt.

Valg af værktøjer

Jeg forestille mig således at vi skal bruge standard servere med standard netkort til opsamling. Til softwaren kender jeg til et godt produkt Moloch til opsamling og Suricata til "analyse"

Moloch is a open source large scale IPv4 full PCAP capturing, indexing and database system.

Suricata is a high performance Network IDS, IPS and Network Security Monitoring engine

Estimering af setup

Vi er så heldige at til det software som jeg har valgt Moloch er der et eksempel på deres README. Så hvis man skal opsnappe fra 8 stk gigabit interfaces med gennemsnitlig 5Gbit med 7 dage tilbage, så skal man ca. bruge:

• 8 servere til opsamling af data og opbevaring, med 48Gb memory og 40TB disk

• 10 servere til elasticsearch indexering med 64Gb memory og 2TB disk, efter formlen (1/4 * Number_Highly_Utilized_Interfaces * Number_of_Days_of_History)

Hvis vi så laver lidt løs hovedregning skal vi altså bruge et setup der er 10 gange kraftigere til opsamlingen, og kan gemme 30 dage, dvs storage skal mindst være en faktor 4,3 gange mere. Jeg vil også antage at vi bruger 10Gbit netkort og vi kan holde det samlede antal relativt lavt, måske omkring 10x10Gbit interfaces - vi håber at kunne få nogle ISP'er med på at vi sniffer lidt andet trafik hos dem samtidig :-).

Så et gæt er at vi skal bruge, omkring:

• 10 kraftige 2U servere a 40kkr med hver dual-10Gbit Intel netkort til ca. 2kkr. Baseret på SPT princippet (slag på tasken) og dagens tilbud fra Dell.dk på R720 med Intel Xeon processor E5-2600 serien (Der er visse fordele ved E5 og 2600 serien! Søg på dem og check Jesper Brouers Linux præsentationer). Måske flere hvis vi finder flere opsamlingspunkter.

• 40 servere 1U a 15kkr til elasticsearch, formlen siger (1/4*10 interfaces * 30dg) = 60 men vi er lidt nærrige og kan godt vente lidt på at indexering indhenter opsamlingen.

• Storage skal vi nok prøve at udregne ligesom i eksemplet, de havde gennemsnit 5Gbit/sec * 7 dage = 5120Mbit/s * 60s * 60 * 24 * 7dg = 387.072.000Mb = 400TB = ~40TB/server * 10servere

Så opsamling med gennemsnit 50Gbit er ca. 400TB pr server og 30 dage (30/7=4,3) vil være ca. 1.720TB - PER server. Så vi snakker nok en større storageløsning for at opsamle og gemme det hele. Jeg tror ikke vi skal købe det som Amazon S3 storage, men det bliver nok også svært at bygge det helt fra bunden selv. Jeg fik lidt hjælp fra BSD-DK på IRC og der kom tal på 288TB på 4U inkl server så hvis vi flotter os lidt kan vi have en server+1.800TB på 24U og med et skohorn 2 servere og storage pr rack. Jeg tror også vi er nødt til at putte lidt ekstra servere til management, sikker adgang, logning og monitorering mv. Så vi taler om
en rack space udregningen, som er helt uden garantier og med meget løse antagelser:

• 5x48U racks med 10 servere og storage til opsamling og opbevaring

• 1 rack med 40x1U og det løse til management og routing/adgang.

Det vil godt nok være en stor udskrivning til at starte med, men så vil man kunne søge efter sessions og downloade eksempelvis en komplet TCP session, under forudsætning af at routing er nogenlunde symmetrisk. Suricata vil ligeledes kunne matche eksempelvis filnavne og uddrage data automatisk - specielt Suricata har nogle stærke funktioner lavet til malware detektion og data exfiltration.

Konklusion

Ovenstående er med et væld af antagelser og usikkerhed omkring hvor meget storage man skal bruge, men jeg mener bestemt det er et nyttigt tanke eksperiment.

Vi kan formentlig konkludere:

• Det vil være muligt at lave en mindre installation (6 racks er relativt småt i min verden)
• Man vil kunne opsamle 5Gbit,10Gbit op til måske 50Gbit fordelt på et mindre antal servere og vil kunne indeksere det i big data stil med tilgængelige programmer
• Omkostningen for at komme igang vil være lille, men en fuld løsning er relativt omkostningstung - specielt antal dage har indflydelse på prisen
• Programmerne virker. Jeg har selv Suricata kørende på en delmængde af vores traffik og Moloch er testet i LAB, men bliver nok på en delmængde med fulde pakker indgående og måske ~200byte af udgående pakker.

Hvad synes I forøvrigt? Er det den rigtige vej at gå, wholesale opsamling og sjælden brug af data?

The1 på IRC gav også følgende link som eksempel på opbygning af store cold storage systemer, hvor data sjældent læses - hvilket formentlig matcher vores use-case nogenlunde:
http://www.opencompute.org/assets/download/Open-Compute-Project-Cold-Sto...