Ich habe derzeit noch nichts konkretes vorzuweisen. Das Konzept der Internet-Emulation geht bei mir auf ca. 1998 zurück als ich mich das erste Mal intensiver mit dem theoretischen Aufbau einer Firewall beschäftigte, einfach weil ich eine das erste Mal eine Firewall brauchte (es wurde ein einfacher NAT Paketfilter auf meiner Standleitungs-Cisco).

• Der erste vollkommen naheliegende und logische Schritt ist der, eine Firewall durch 2 Geräte aufzubauen die dasselbe tun, nur daß der 2. beim ersten zurückweisen eines Pakets die Verbindung vollständig (am besten physikalisch und nicht automatisch wiederherstellbar) kappt. Die "innere" Maschine taucht indes nicht auf und ist etwas anders aufgebaut, damit dieselbe Hintertür die außen wirkt nicht auch innen wirkt. Ansonsten ist das Setup identisch, also auch mit derselben IP. Da die äußere Maschine alle Pakete an die innere abfängt kann kein Paket direkt an die innere gerichtet sein. Sobald das passiert ist die äußere Maschine kompromittiert.
• Das reichte mir aber nicht. Ich träumte (das darf man wörtlich nehmen) von eine Firewall, die wirklich sicher ist, also die man also auch nicht von innen umgehen kann. Logischerweise braucht es dann 3 Maschinen, eine, die nach außen sichert, eine die nach innen sichert und eine, die die beiden Maschinen verbindet (der eigentliche Application Firewall). Das Problem ist jetzt aber, daß diese Mittlere Maschine (ich nenne sie Transport Hub oder TH) von "innen" nicht mehr angesprochen werden kann, weil die Firewalls sinnvollerweise nur Verbindungen "nach außen" erlauben sollen.
• Außerdem hat das innere Netz jetzt keine eigene Firewall mehr, die Firewall ist ja gegen das innere Netz gerichtet und schützt dieses nicht mehr. Es ist aber wichtig daß man beim zusammenschalten von LANs diesen verschiedene Policies geben kann, also alle über eine eigene Firewall verfügen.
• Des weiteren darf - auch logisch - die Intranet-Struktur nicht umgewürfelt werden. Die Intranet-Rechner müssen also eine Verbindung nach außen schalten. Der TH nimmt aber keine Verbindungen an weil seine Firewalls das nicht zulassen.
• Also muß noch eine weitere Zone her. Das ist die Zone, die die Verbindungen von innen annimmt. Dies ist der Internet-Emulator, weil alle Services, die vom Intranet im Internet angesprochen werden, dort emuliert werden müssen.
• Für die Vermittlung der Realdaten sorgt die 3-geteilte Firewall. Diese gehört natürlich nur zur Vermittlungsschicht, interpretiert also selber keine Daten, außer hinsichtlich Sicherheitspolicies.
• Sinnvollerweise gibt man dem TH noch eine dritte Firewall mit auf den Weg hinter der die Transportrechner angesiedelt werden die die Daten interpretieren. Auf diese Weise kann man einer Kompromittierung der Transport-Systeme vorbeugen und so weitere schädliche Einflüsse vor der Emulationszone fernhalten.

• Bei Ungereimtheiten schaltet sich der TH ab, und diskonnektiert damit das Intranet sicher vom Internet.
• Man kann im Intranet mit dem IE weiterarbeiten so lange der TH abgeschaltet ist und keine zusätzlichen Informationen aus dem Internet benötigt werden.
• Dedizierte Staging-Systeme zur Evaluation noch nicht freigeschalter Services oder Content werden unnötig. Der IE übernimmt diese Funktion für das Intranet. Die Arbeit wird natürlicher weil man sich nicht mit Deployment-Systemen befassen muß. Die eigentliche Freischaltung bzw. das Deployment geschieht über den TH nach Standardverfahren, d. h. der TH synchonisiert Externsysteme mit den Internsystemen.
• Ein automatisiertes steganographisches Durchtunneln von Informationen unter Umgehung von Firewallstrategien wird fast unmöglich. Beispielsweise funktionieren DNS-Tunnel sowie Ping-Morsen (anpingen von mehreren IPs um Bits zu tunneln) nicht mehr. HTTPS-Tunneln wird ebenfalls zuverlässig erkannt, weil der Internet-Emulator die Daten entschlüsseln muß, schließlich werden sowohl der Empfangsserver als auch die CA-Root emuliert.
• Policies der Form "was nicht erlaubt ist ist verboten" können auf einfache Weise implementiert werden, indem der fehlende Service im IE nicht existiert. Es ist aber auch kein Problem, den Benutzern zu ermöglichen, sich diesen Service freizuschalten, sofern es sich um einen Standardservice handelt. Somit können unerwünschte Verbindungen (Popups, Banner-Server, Malicious Code Exploits, Cross-Site-Scripting Attacken) ebenfalls verhindert werden.

In diesem Kontext ist der Sicherheitshinweis zu HilbiX zu sehen, weil HilbiX für herkömmliche, vollkommen unzureichende Firewallstrategien zu einem gewaltigen Problem werden kann. Sofern HilbiX eine Gefahr für das LAN darstellt ist der Firewall schlicht unzureichend.

Ich sage nicht, daß der Internet-Emulator als einziges eine sichere Firewall ermöglicht. Ich sage nicht einmal, daß eine Firewall jemals sicher sein kann. Aber der IE ist die einzige Lösung, die alle Probleme zuverlässig adressiert, die mir bisher bekannt wurden. Und das auf eine leicht verständliche und relativ simple Art und Weise.

Weil ich dafür keien Zeit habe würde ich mich freuen wenn jemand dieses Konzept aufgreift und implementiert. Allerdings erwarte ich, daß dies Open Source geschieht, damit man die Validität des Ganzen auch objektiv ermitteln kann. Meine Gedanken indes sind Public Domain. Der Aufwand dies hier hinzuschreiben war (jedenfalls für mich) höher, als die Methodik einzusehen. Somit ist die Erfindungshöhe verschwindend gering. Es genügt dazu die Extrapolation von reinem Wissen das allen Ortens bekannt ist. Von einem genialen Einfall fehlt jede Spur, es handelt sich, wie immer "um wenig Inspiration, aber viel Transpiration".

Ich bin außerdem bereit die von mir reservierten Domains "internet-emulator.com" usw. kostenlos in ein entsprechendes Freies Software Projekt (unwiderruflich) einzubringen.