Auch wenn ich mich ungern in eure lauschige Diskussion einmische, aber so ganz einleuchtend ist mir nicht, was Du da schreibst. Wenn Du in einer Firewall alles nach außen sperrst, dann kannst Du auch gleich die Internetleitung kappen. Irgendetwas nach außen muß offen sein, und wenn es über Proxies geht. Jetzt kommen wir zum hakeligen Punkt einer Appliance:
Sie kennt keine Applikationshashes und sie kennt nicht das Protokoll auf Anwendungsebene (mit sehr wenigen Ausnahmen sehr tuerer und proprietärer Systeme).
Gehen wir also mal von einem relativ gängigen und nach allgemeiner Meinung recht sicheren Konfiguration aus:
Die Firewall sperrt alles, sowohl eingehend wie auch ausgehend. Ausgehend sind nur die Ports für FTP, SMTP, POP3, HTTP und HTTPS freigegeben (zu irgendwas muß das Internet ja gebraucht werden). Da eine Firewall auf Ebene 4 des OSI-Modelles arbeitet, kann Sie nur Socket filtern, also anhghand von IP und Port (einmal die teuren und proprietären Lösungen ausgenommen). Sie kann also nur eine Handvoll Parameter kontrollieren:
-
- Ist der internen IP gestattet nach außen zu senden?
-
- Ist der Port zulässig?
-
- Ist die Ziel-IP zulässig (hier kann praktischerweise eigentlich nur eine Blacklist, keine Whitelist implementiert sein)?
-
Sie kann also nur erkennen, von Rechner X aus über einen erlaubten Port gesendet wird. Was sie dabei nicht prüfen kann ist, welche Anwendung auf Rechner X hier nach außen sendet und was die Protokolldaten enthalten. Es kann also durchaus jede beliebige Anwendung auf Rechner X alle möglichen Daten nach außen senden, sofern sie dies über einen der erlaubten Ports tut.
Gehen wir mal vom sichereren Fall aus:
Firmennetzwerk mit einer Firewall geschützt, deren Standardchain auf DENY steht, sowohl Inbound, als auch Outbound. Freigegeben ist nur ein Gateway für HTTP, FTP und ein Email-Store-and-Forward-Proxy. Somit sind also für eine einzige IP 5 Ports freigegeben. Rechner X kann nur mit dem Gateway kommunizieren, auf dem ein Proxy läuft, der die Anwendungsdaten filtert.
Aber selbst dieser Fall kann nicht sicherstellen, daß auf Rechner X wirkliche in Browser die Daten für HTTP aufbereitet, und welche Daten genau hier in HTTP gekapselt sind. Zwar ist hier sichergestellt, daß über Port 80 wirklich HTTP-Daten fließen, aber so lange es gültige HTTP-Daten sind funktioniert auch hier die Kommunikation für eine boshafte Anwendung einwandfrei. Es wäre z.B. kein Problem Base64-encodierte Daten über die aufzurufende URL oder über POST-Daten an einen entfernten Host zu übermitteln.
Die einzige Möglichkeit soetwas zu verhindern wäre auf den Clients effektiv zu verhindern, daß sich eine Schadsoftware installiert, oder ein so restriktives Gateway zu nutzen was eine Kommunikation verhindert, was jedoch praktisch unmöglich wäre. Letzte Möglichkeit wäre, für die Ziel-IPs mit einer Whitelist zu arbeiten, was im praktischen Alltag unmöglich ist, der Admin kann kaum jede einzelne Ziel-IP aller benötigten Server für den täglichen Arbeitsalltag einzeln freigeben. Dank Round-Robin, Caching und andere Arten des Loadbalancing hätte er da auch eine Menge zu tun. Zudem würde immer noch die theoretische Gefahr bestehen, daß einer der zulässigen Server kompromittiert wird, so hypothetisch sie im Normalfall auch sein mag.
IDE-ATAPI
kapaul
dirk42799
xafford
