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
4 Antworten zu “Admins, bitte macht das nicht!”
Hi Lukas,
deine Meldung spricht mir aus der Seele.
Ich kämpfe seit fast einem Jahrzehnt damit die Nicht-RFC1918-Adresse im gesamten Unternehmensnetz zu routen. Besonders herausfordernd ist es, wenn Kommunikationspartner im VPN erreicht werden müssen, die bei sich im privaten Netz öffentliche Adresse einsetzen, die aber nicht ihnen zugeordnet sind. „Wir machen doch NAT ins Internet“ bekommt man da zu hören….
Da hilft nur noch ein Griff in die policy-based routing Trickkiste, die bei manchen Produkten sogar auch das Source-Interface mir berücksichtigen kann. Ob das Feature beim nächsten OS-Update noch verfügbar ist…
Daher auch von meiner Seite: RFC1918 beachten und nicht nur weil M$ bei 10.x.y.z ein 255.0.0.0 vorschägt muss man das auch machen. Da geht auch ein /24 mit 255.255.255.0 oder noch kleiner…
Hi Ulrich,
Danke für deinen Kommentar. Der policy-based Trick geht aber nur so lange gut, bis das System auf deiner Seite zufällig mal mit dem tatsächlichen Eigentümer der Zieladresse kommunizieren möchte. Das könnte ja durchaus ein Webserver sein.
Eine von beiden Seiten könnte die Adressen hinter einem Many-to-Many NAT verstecken, idealerweise der Verursacher. Sollte ja kein Problem sein, wenn er es auch Richtung Internet so macht. 😉 Aber Achtung, dann müsst ihr natürlich die Phase 2 Einstellungen des VPN anpassen!
Lukas
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!