Wie is verantwoordelijk voor de beveiliging van je netwerk? KPN en Ziggo beweren dat zij verantwoordelijk zijn. In deze aflevering laten we zien dat zij er een puinhoop van maken.

hetlab logo
Henk van de Kamer

 

In de vorige aflevering in PC-Active 309 vertelde ik over de strijd om het (internet)aansluitpunt die momenteel nog steeds gaande is. Providers beweren dat zij vanwege beveiliging absoluut de controle over de router moeten hebben, maar beveiliging staat ergens onderaan hun interne prioriteitenlijstje. Veel belangrijker is de verplichte koppelverkoop van hun veel te dure diensten. Maar dat argument voor een dichtgetimmerde router kunnen we natuurlijk niet serieus nemen...

Beveiliging
Onlangs heb ik een echte firewall op basis van iptables geïnstalleerd. De eis was al het uitgaande verkeer blokkeren, behalve surfen naar websites en mail. De router die de providers leveren, beweert vaak dat een firewall aanwezig is. Maar het instellen van de genoemde eis is met deze zogenaamde ‘firewalls’ niet mogelijk. Voor wie nieuwsgierig is hoe het wel kan:

iptables -A FORWARD -p tcp --dport  80 -j ACCEPT

iptables -A FORWARD -p tcp --dport 443 -j ACCEPT

iptables -A FORWARD -p tcp --dport 587 -d x.x.x.x -j ACCEPT

iptables -A FORWARD -p tcp --dport 993 -d x.x.x.x -j ACCEPT

iptables -A FORWARD -j LOG

iptables -A FORWARD -j DROP

Uiteraard zijn er nog wat meer regels nodig, maar dat voert voor dit artikel te ver. De eerste vier regels regelen het verkeer dat naar buiten mag, ofwel door lokale computers gevraagd. Omdat het IP-adres van de mailserver bekend is, kan dat verkeer nog verder worden dichtgetimmerd, zoals te zien in regels drie en vier. De laatste twee regels leggen al het andere verkeer vast en vernietigen vervolgens het pakketje. Simpel toch?

Schrikken
Na installatie besloot ik de volgende dag eens te kijken naar het geweigerde verkeer. We hadden weliswaar afgesproken dat als iets niet werkt, dat gemeld zou worden voor verder onderzoek. Maar het kan geen kwaad om actief op zoek te gaan in de geblokkeerde verbindingen. Al snel werd duidelijk dat in de afgelopen dag ruim 70.000 (!) verbindingen waren geblokkeerd. Terwijl alles gewoon werkte...

Onder Linux is het dankzij de command-line ‘tools’, ‘sed’, ‘grep’, ‘uniq’, ‘sort’ en ‘wc’ – geen grap – niet moeilijk om lijstjes te maken. Meer dan de helft van de pakketjes ging naar TCP-poort 5223 en IP-adressen in het 17.0.0.0/8-netwerk. Kenners weten meteen dat die ooit zijn toegekend aan Apple. Het bedrijf houdt een lijst (support.apple.com/en-us/HT202944) bij met bekende poorten in zijn software, in dit geval gaat het om Apple Push Notification Service (APNS). Deze dienst is volgens Apple voor allerlei diensten handig, maar na twee maanden hebben we nog steeds niet ontdekt waarom. Ik heb uitgerekend dat elke Apple-computer die aanstaat, gemiddeld om de dertig seconden naar huis belt. Alleen Joost weet wat zij allemaal over jou vertellen.

cfa51cc1 d2cc 45d2 85ff 040cb7efd822 2

Automatiseren
Al snel werd duidelijk dat ik het schiften moest automatiseren. Dat kan prima met Bash-scripts. Als eerste het opschonen van de ruwe informatie:

Dec 01 14:37:04 router kernel: IN=lan2 OUT=wan MAC=c6:8b:ff:00:00:02:f0:f6:1c:xx:xx:xx:08:00 SRC=192.168.2.227 DST=17.252.76.90 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=55495 DPT=5223 WINDOW=65535 RES=0x00 SYN URGP=0]

Op naar een meer hanteerbaar formaat:

Dec  1 14:37:04  IN=lan2   OUT=      SRC=192.168.2.227     DST=17.252.76.90      PROTO=TCP    SPT=55495   DPT=5223

Zowel de ruwe als de opgeschoonde versie wordt elke dag opgeslagen, dus ik kan altijd terug naar het origineel. Vervolgens heb ik per netwerk en status – gecontroleerd of onduidelijk – een bestandje gemaakt waarin ik reguliere expressies voor de ‘grep’-opdracht plaats. Voor dit maffe Apple-verkeer is die als volgt:

meerdere: Apple PNS                     SRC=192.168.2.* DST=17\..* PROTO=TCP .* DPT=5223

Het eerste deel is de naam van de computer (in dit geval meerdere) en welk verkeer. De reguliere expressie begint op positie 41. De ‘SRC’ is het IP-adres van de overtreder en de ‘*’ geeft aan dat alle schuldigen in het 192.168.2.0/24-netwerk voldoen. De ‘DST’ is het IP-adres waarheen het verkeer gaat en ‘17\..*’ is alles in het 17.0.0.0/8-netwerk. De eerste ‘\.’ is een echte punt en de ‘.*’ staat voor alle mogelijke tekens, waarmee de rest hopelijk voor zich spreekt. Iedereen die serieus teksten wil analyseren, moet zich eens verdiepen in reguliere expressies! Het deel van het Bash-script dat deze regel verwerkt, is als volgt:

    description=${line:0:40}

    regexp=${line:40}

    total=$(eval "grep -Ec '${regexp[@]}' blocked_unknown.txt")

    if [ "$total" == "0" ]; then

      printf "    %s\n" "$description" >> nohits.txt

    else

      printf "%8d   %s\n" $total "$description"

    fi

    eval "grep -Ev '${regexp[@]}' blocked_unknown.txt > blocked_unknown.tmp"

    mv blocked_unknown.tmp blocked_unknown.txt

In de eerste regel krijgt de variabele ‘description’ – ik werk vaak in het Engels – de inhoud van de eerste 40 tekens en ‘regex’ krijgt in de tweede regel de rest. In de derde wordt deze via de ‘grep’-opdracht gebruikt om te zoeken in het opgeschoonde bestand. De ‘c’ maakt een telling en die wordt opgeslagen in de variabele ‘total’. Als deze nul is, wordt dit vastgelegd in het ‘nohits.txt’-bestand. Het idee is dat regels die gedurende langere tijd niet meer voorkomen, waarschijnlijk zijn opgelost. De laatste twee regels schonen het tussenbestand op, zodat volgende reguliere expressies niet dubbel geteld worden. Met als eindresultaat dat we na het verwerken van alle reguliere expressies een bestandje overhouden met geblokkeerd verkeer dat verder uitgezocht moet worden.

         ziggo router 2
  Ziggo Connect Box

Bijzonder
Dit Apple-verkeer is al bijzonder, maar de dagen daarna ontdekte ik nog veel vreemdere zaken. Zo staan in het netwerk een aantal Windows 10-computers en die willen maandelijks een update van vele gigabytes doorvoeren. Microsoft kan dat verkeer blijkbaar niet aan en heeft besloten om jouw dataverbinding daarvoor te misbruiken. Ofwel: je gaat Windows 10-computers elders in je straat van updates voorzien. Een soort peer-to-peer-netwerk dus. Microsoft noemt dit WUDO, Windows Update Delivery Optimization. Tja, zo kunnen we alles wel goedpraten. Deze kwamen we op het spoor doordat privénetwerken in de reeks 192.168.0.0/16 benaderd worden:

SRC=192.168.0.96      DST=192.168\..* PROTO=TCP .* DPT=7680

Uiteraard zijn wij niet de enigen die dit vreemde verkeer bij toeval ontdekten (4it-inc.com/wudo-or-wudont) en gelukkig is het uit te zetten. Standaard staat dit echter aan! Laten we hopen dat Microsoft een goede controle heeft ingebouwd, want persoonlijk zie ik hier een systeem om kwaadwillende updates te verspreiden.

Eigen DNS
Iedereen weet dat Google veel over ons weet. Daarom besloten we om een eigen caching DNS-server te maken, zodat de bekende 8.8.8.8 en 8.8.4.4 niet meer nodig zijn. Of toch wel? Hierboven ziet je dat verkeer naar wildvreemde DNS-servers geblokkeerd wordt. Desondanks zagen we met enige regelmaat pogingen naar de Google DNS-servers voorbijkomen. De netwerkinstellingen waren in orde, dus hier is iets anders aan de hand.

Omdat al het netwerkverkeer via onze eigen router gaat, kunnen we het gemakkelijk afluisteren met ‘tcpdump’. Dat is de command-line-equivalent van Wireshark. Het vreemde verkeer afvangen gaat als volgt:

tcpdump -i lan2 -s0 -nnS src 192.168.2.104 and \(dst 8.8.8.8 or dst 8.8.4.4\) -w google_dns.cap &

Tot onze verbazing betrof het meeste verkeer aanvragen voor de update-servers van Avast en AVG. Omdat DNS-aanvragen door virussen omgeleid kunnen worden, menen beide dat dit via een ‘onafhankelijke’ controle opgespoord kan worden. Waardoor Google exact weet wie een van deze producten gebruikt. Deze controle kan in de gratis variant niet uitgezet worden. Verder wordt met het mislukken van deze controle niets gedaan. nergens een melding. Dit is dus totaal overbodig! Er zijn trouwens nog meer programma’s die deze vreemde truc gebruiken…

Tot slot
Helaas is de ruimte weer op. Ik wil je alleen nog even wijzen op het geheimzinnige verkeer naar een bepaalde Apple-server (hetlab.tk/klanten/apple-spioneert). Apple wast haar handen in onschuld en deze poort staat ook niet in het eerder genoemde overzicht. Ook nu ben ik niet de enige die dit heeft ontdekt en op internet wordt dan ook driftig gespeculeerd over wat dit kan zijn. Hopelijk heb ik nu duidelijk gemaakt waarom we een eigen modem/router willen. Want al deze activiteiten worden vrolijk toegestaan door het exemplaar van jouw provider.