The good, the bad and NAPT

Onderstaande tekst heb ik al eens gepubliceerd voor SURFnet. Ik heb een paar keer getwijfeld of ik het wel in de Achterkrant wilde plaatsen. Het is een kopie. Maar een goede programmeur hergebruikt ook code. Waarom zou ik dat dan niet voor teksten kunnen doen. Bij de start van Twents Datacentrum heb ik ook teksten en foto's uit diverse interviews opnieuw gebruikt. Ik heb wel geprobeerd de tekst licht aan te passen aan de laatste stand van zaken en wat nieuwe inzichten er in te verwerken. Zo gebruik ik in deze versie NAPT (Network Address Port Translation), een term die later in zwang kwam nadat het in een RFC werd beschreven.

NAT vs. NAPT

Ik wil even een misverstand uit de weg ruimen. Iedereen heeft het over NAT en de problemen die daarbij optreden t.a.v. het vinden van machines in het interne netwerk. Dat zou echter bij NAT niet het geval moeten zijn. NAT is namelijk Network Address Translation waarbij interne adressen 1-op-1 vertaald worden naar externe adressen.

Het probleem treedt op doordat alle leveranciers tegenwoordig NAPT (Network Address Port Translation) verkopen als NAT. Bij NAPT worden interne adressen vertaald naar een enkel extern adres en wordt de poort gewijzigd.

NAT bestaat al zeer lang. Als een organisatie aansloot op internet kregen ze van hun provider een range publieke adressen. Intern werden private adressen gebruikt en de NAT-router vertaalde de adressen van de ene naar de andere kant.

PAT

PAT is midden 90-er jaren ontstaan. Een van de eerste implementaties was IPmasquerade. Het werd ontwikkeld omdat zowel mijn vriendin als ik een PC hadden en we via onze PPP-inbelverbinding een enkel IP adres kregen. We wilden natuurlijk beiden tegelijk van internet genieten.

Ik gebruik hier trouwens de term PAT omdat die gebruikelijk was in die tijd. De term NAPT ontstond pas in 1999.

Waarom NAPT?

Veel van de huidige IT leveranciers zijn gewend zaken te doen met bedrijven die, nog steeds, maar een enkel IP adres van hun provider krijgen. De oplossingen die ze hebben bedacht, zijn daar dus op gericht. Ze zijn natuurlijk ook heel goed bruikbaar in situaties waarbij een organisatie een hele range krijgt. Andersom is lastiger.

Beveiliging is ook een veelgehoorde smoes. Met NAPT is het (nagenoeg) onmogelijk om een interne machine vanaf internet te bereiken. Jammer genoeg worden de meeste machines echter nog steeds besmet middels downloads en e-mail. Dan is toegang vanaf internet naar de machine niet nodig. Die machine maakt zelf wel een verbinding naar een Command & Control server om te horen welke streken hij uit moet halen.

Problemen

En daar komt het probleem om de hoek kijken. Een abuse-melding bevat niet meer dan het IP adres van de klant en die moet dan maar intern zien uit te zoeken wie een verbinding met de C&C server heeft gemaakt. Het adres van die server wordt ook niet altijd bekend gemaakt om criminelen niet te veel te vertellen.

Een ander probleem waar de security afdeling van een provider nog wel eens tegenaan loopt, is dat een klant zegt dat ze het IP adres dan wel zullen blokkeren. Dan komen er geen klachten meer. Dat wil natuurlijk niet zeggen dat het probleem is verholpen. De malware kiest een ander IP adres, dat waarschijnlijk niet in de gaten wordt gehouden, en gaat verder met zijn werk.

Blokkeren kan wel, maar zorg dan ook voor adequate logging. Als het IP adres bekend is en een machine verbinding wil maken met dat adres, laat dat dan registreren. De keus of de machine dan nog steeds naar buiten kan of geblokkeerd wordt, is aan de organisatie zelf. Als het adres geblokkeerd wordt, gaat de malware, zoals gezegd, op zoek naar een ander adres. Als de organisatie voldoende kennis heeft, zou dat adres achterhaald kunnen worden.

Oplossingen?

Hoe kun je een besmette machine vinden zonder dat je het adres van de C&C server weet? Ik moet bekennen dat zoiets heel lastig is. Het is wel eenvoudiger te maken om de bron te vinden. Probeer bij je provider meer adressen te krijgen. Gebruik die adressen voor verschillende doeleinden. Zet de mailserver op een ander adres dan de website en de werkplekken van de medewerkers op weer een ander adres.

Neem contact op met uw IT leverancier of IAF als u hier meer over wilt weten of hier gebruik van wenst te maken.

Portokosten

Zoals al in de Achterkrant, middels brieven en bijlagen bij de facturen, gaan we vanaf januari 2014 kosten in rekening brengen voor geprinte facturen. U kunt nog snel uw e-mail adres doorgeven om facturen via e-mail te ontvangen.

Disclaimer

Dit artikel is eerder gepubliceerd als een officiële Achterkrant voor Internet Access Facilities.