Eigentlich komme ich mir schon fast blöd vor, einen Beitrag über solch einfache Grundlagen zu schreiben. Und dennoch muss ich es tun, da ich es erst diese Woche wieder bei einem neuen Kunden gesehen habe. Es ist auch nicht der erste Kunde, bei dem ich das sehe. Die Leute, die den Fehler einst gemacht haben, sind schon lange nicht mehr da. Man kann also auch nicht fragen, weshalb das so gemacht wurde. Aber die Antwort kann auch nur Unwissenheit sein. Eigentlich gehört es zu den absoluten Basics und wird schon im ersten Ausbildungsjahr zum Fachinformatiker gelehrt. Das war zumindest bei mir so… Aber wovon ist denn nun eigentlich die Rede?!
Bitte verwendet in euren LANs ausschließlich IP-Adressen aus dem Private Address Space nach RFC 1918.
Darunter fallen die folgenden Adressen:
- 10.0.0.0 – 10.255.255.255 (10/8 prefix)
- 172.16.0.0 – 172.31.255.255 (172.16/12 prefix)
- 192.168.0.0 – 192.168.255.255 (192.168/16 prefix)
Aus diesen Blöcken darf man sich für die private Nutzung grundsätzlich frei bedienen. Alle anderen Adressen sind entweder an die Regional Internet Registries vergeben oder für spezielle Zwecke reserviert. Verwendet man solche Adressen in seinem LAN, hat man Konnektivitätsprobleme zu den entsprechenden Bereichen des Internets!
Bei der Verwendung von Adressen aus den oben aufgeführten Blöcken muss man sich seit Einführung von Variable Length Subnet Masking und Classless Inter-Domain Routing auch nicht mehr an die ehemaligen IP-Adressklassen halten. Das heißt, ein Netzwerk mit Netzadresse 172.16.0.0 muss nicht mehr mit der Subnetzmaske 255.255.0.0 (/16), sondern kann z.B. auch mit der Subnetzmaske 255.255.255.128 (/25) verwendet werden. Statt 216 = 65.536 IP-Adressen, hat dieses Netzwerk dann nur 27 = 128 IP-Adressen. Das skaliert also super!
Liebe Leser, bitte schreibt einen Kommentar, wie häufig ihr schon öffentliche IP-Adressen in LANs gesehen habt.
P.s.: Wer 217.17.192.0/24 in seinem Heimnetz konfiguriert, kann diese Seite nicht aufrufen. 😉
Foto von Mike Erskine auf Unsplash
2 Antworten zu “Admins, bitte macht das nicht!”
Hi Lukas. Danke für deinen Beitrag. In der Tat habe auch ich schon Kunden gesehen, bei denen öffentliche Bereiche irgendwo im internen Netz vorkamen.
Zum Blocken von nicht-routbaren Bereichen in Firewalls binde ich übrigens gerne externe Listen ein, die das für mich regeln. Es gibt neben den RFC 1918 Bereichen ja noch viele weitere, die laut RFCs/IANA nicht routbar sind. Ich nutze hierfür die Liste vonm team-cymru:
https://team-cymru.org/Services/Bogons/fullbogons-ipv4.txt
https://team-cymru.org/Services/Bogons/fullbogons-ipv6.txt
In einer Palo heißt das Feature „External Dynamic Lists“. Auf der Forti geht das über einen Externel IP Address Threat Feed. Ich blocke dann (in zwei Policies) sowohl eingehende als auch ausgehende Pakete von/zu diesen Listen.
Lieben Gruß,
Johannes
Dass es abseits der RFC 1918 Bereiche noch einige weitere gibt, z.B. Documentation Präfixe, Multicast, … war mir natürlich klar. Aber dass es insgesamt so viele sind, hätte ich echt nicht gedacht. Danke dafür!