ARP is in principe puur lokaal, en we gaan er eigenlijk nog steeds vanuit dat de lokale netwerken min of meer veilig zijn. Geintjes als voor een groot deel van het internet een DNS record vervalsen gaat hier gewoon niet op; de schade is beperkt tot een broadcast domain. Buiten dat begint de schade niet met ARP. Hoe wil je bijvoorbeeld gewaarmerkte DHCP gaan doen?

Door DHCP servertjes voor certificaten van een certificaatbakker te laten betalen? Dat zullen ze leuk vinden!

Daarbij is er zo'n brede keus aan certificaatuitgevers (kijk maar in de certificaatcache in je browser of je OS) dat er altijd wel een rotte appel tussen te vinden is, en dan heb je nog niks. Maar je hebt wel je DHCP- danwel ARP-uitwisselingen een stuk rekenintensiever gemaakt, en een hoop dure administratieve rompslomp gecreerd.

Merk op dat de aanpak van DNSsec hier niet kan werken omdat er geen hierarchie is die "natuurlijk" duidelijk maakt waar je moet zijn voor je sleutels, met in het geval van DNSsec de Amerikaanse overheid die op de belangrijkste sleutels zit. Iets wat ik nou niet direct in mijn huiskamer wil introduceren.

Men heeft al moeite om een nepcertificaat van een echt te onderscheiden (gebruikers) of zelfs een eerlijke aanvrager van een oplichter (uitgevers). Ik denk niet dat er hiermee veel winst te behalen valt.

Opmerken als er ARP-stormen op het netwerk te zien zijn en dan het probleem isoleren en oplossen lijkt me vooralsnog de meer voor de hand liggende alsook practische aanpak. Bedenk zelf maar waarom, de "gemiddelde gebruiker" met z'n thuisnetwerkje in acht genomen.

In fröbel netwerken doe je dat ook niet.

In een echt netwerk kan een switch dhcp snooping / arp inspectie / ip source validatie doen .
Daarbij worden alleen frames toegestaan op een switchpoort het source mac en source ip eerst als dhcp transactie zijn langsgekomen.
Dan zijn alle spelletjes met arp spoofing / mac spoofing / ip spoofing klaar.

Dan eventueel nog private vlan (poort in hetzelfde vlan kan niet rechtstreeks met andere poort in dat vlan communiceren).

Eventueel nog te combineren met 802.1x (kan ook op bedrade netwerken), waarbij de client geauthenticeerd wordt voordat die het netwerk op komt.
(Alleen 802.1x is niet voldoende, want een valide client kan natuurlijk via andere weg besmet geraakt zijn )

Dit zou nog weleens problemen kunnen geven met statische IP adressen die typisch aan servers worden toegekend. Vooral als de server zelf een IP adres heeft i.p.v. de DHCP server een "statische" IP adres toekend.

Een andere redelijke optie is om "Gratuitious ARP replies" te blokkeren in de firewall als deze de mogelijkheid heeft. Dit biedt geen volledige bescherming tegen een aanvaller die eerder een antwoord geeft aan requests, maar sluit in ieder geval een aanvalsvector uit

Wat voor een kantoortuin werkt, werkt niet automatisch ook voor een serverpark. En een thuisnetwerkje is weer een ander feest. Schaalgrootte is al een factor, maar de gebruikspatronen en type gebruikers zeker tellen ook mee.

Een minder stringente aanpak is om bij te houden achter welke poort welk IP adres zit en als dat plotseling verandert dat dan te blokkeren. Is ook lastiger te omzeilen door zelf bijvoorbeeld eerst fake dhcp antwoorden op de lijn te zetten om de switch voor de gek te houden. Tenzij je dat dan weer dichtgetimmerd hebt door de switches te vertellen waar de dhcp antwoorden vandaan mogen komen.

Het is best leuk wat managed switches tegenwoordig allemaal kunnen, maar je kan jezelf er evengoed weer mee in de vingers snijden. Wat dat betreft zou doorhebben wat er gaande is de eerste prioriteit moeten zijn. Zelfs als je geen enkele geavanceerde barriere in je switches hebt kun je dan al problemen indammen en oplossen voordat ze groot worden.

Het is heel verleidelijk met de grote hamer vanalles maar te verbieden en vast te zetten, maar dit is een reflex waar je gebruikers als eerste tegenaanlopen en die nemen je dat niet in dank af. Plus dat het nog behoorlijk voeten in de aarde kan hebben als je niet al zo'n infrastructuur hebt.

Ga maar na, bijvoorbeeld: Gaat een 802.1x-uitrol je werk schelen, het werk dat het kost om het op te zetten meegerekend? Is het opzetten van wat gescheiden vlannetjes en een script laten bijhouden welk MAC adres waar zit niet effectiever?

Is je winkeltje groot genoeg, of komen arp stormen of wilde dhcp servers gewoon vaak voor op jouw netwerkje, kun je voorzichtig wat extra checks en blokkades instellen. Maar zoals altijd, doe je dat verkeerd dan staat ineens de telefoon roodgloeiend. Tenzij je VoIP hebt wellicht, maar we dwalen af.