zkmlf: Architekturanpassungen vorschlagen, Altlasten von morgen verhindern

So hatte ein von mir besonders gehasstes Firewallprodukt die Möglichkeit, durch einfache und für wenig erfahrene Leute verständliche Konfiguration Zugriffe auf gewisse Ports einer IP-Adresse aus dem äußeren Transfernetz durch eine ekelhafte Kombination aus Proxy-ARP und Destination NAT auf einen “innen” liegenden Server weiterzuleiten. Da dieses Feature so schön einfach zu nutzen ist (man muss nicht beim ISP um ein weiteres Netz offizieller IP-Adressen für “innen” liegende Server betteln und ihn nicht um statische Routen bitten), wurde das natürlich auch fleißig benutzt. Auf “richtigen” Firewalls muss man sich für die Nachbildung mit virtuellen IP-Adressen oder Alias-Adressen einen abbrechen und den ganzen Mist auch noch dokumentieren. Dabei wäre es doch viel einfacher, es gleich “richtig” zu machen, dem Zielserver eine offizielle IP-Adresse aus einem neuen Servicenetz zu verpassen und den Traffic einfach nach passender Filterung weiterzurouten.

Auch immer wieder gern genommen ist die Classful-Denke vieler historisch ausgebildeter Leute, für die es keine Prefixlängen zwischen /16 und /24 gibt und die für ihr 300-Client-Netz deswegen ein “flaches” /16-Netz, gerne das komplette 192.168/16 oder Standardprefixe wie 10.0/16. Wenn man dann aufgekauft wird oder aus anderen Gründen das eigene Netz mit einem Gegner verheiraten muss, der denselben Designfehler gemacht hat, darf entweder einer der beiden renumbern oder man muss sich auf beiden Seiten mit NAT einen abbrechen. Letzteres geht üblicherweise damit einher, dass man aus Gründen der “Einfachheit” nicht mit DNS arbeitet, sondern direkt IP-Adressen der Gegenseite überall einträgt, was dazu führt, dass bei weiteren Umstellungsarbeiten entweder noch mehr geNATtet wird oder man sich schwer zu debuggende Fehler oder noch aufwändigere Migration einfängt. Daraus entsteht meine Empfehlung, Netze immer noch so groß wie nötig, aber so klein wie möglich zu machen und den Prefix aus den zur Verfügung stehenden Adressräumen zusammenzuwürfeln, möglichst nicht systematisch. Denn auf Ideen wie “10.49.62/24 ist Deutschland, Rhein-Neckar”, sind vor uns auch noch andere gekommen.

Und dann gibt es natürlich auch die Designfehler, die man ohne Neuinstallation der gesamten Windows-Welt niemalsnie wieder los wird. Besonders gern genommen natürlich der “example.com” als AD-Root der Example GmbH, die extern genauso benutzt wird. Wenn man sich hier vertut, hat man “innen” andere Fehler als “außen”, merkt “innen” nicht, dass außen der RR für www.example.com oder gar der MX für example.com verschwunden ist, oder es steht mitten in der Migration das Marketing auf Deinem Fuß und brüllt Dich an, warum die Aktionswebseite nicht mehr aufgelöst werden kann. Ich bin übrigens kurz davor, einen Preis dafür auszuloben, dass mir jemand das Microsoft-Whitepaper beschafft, in dem der Example Ltd explizit davon abgeraten wird, für ihr AD den Root intern.example.com zu verwenden, wenn example.com “draußen” produktiv verwendet wird - denn das wäre eine Konfiguration, die aus meiner Sicht ausgesprochen sinnvoll wäre.