Elisabeth Donnaberger, Johann Kainrath
Um die Integrität eines Netzwerkes zu sichern, muss in die Netzwerkinfrastruktur
- neben der implizit vorhandenen - zusätzlich Sicherheit etwa in der Form
eines Firewalls implementiert werden. Dies kann durch eine eigene dedizierte
Hardware oder den Einsatz einer Firewall-Software auf einer Plattform wie
Gateway-Maschinen (Router, Rechner mit mehreren Interfaces) geschehen.
Firewalls bieten Sicherheit beim Management und bei der Kontrolle aller Verbindungen zwischen verschiedenen Netzwerkbereichen bzw. Netzwerksegmenten. Typischerweise verfügt ein Firewall über mehrere Interfaces (gleich einem Router), wobei man die innere durch den Firewall abgesicherte Zone das Inside Network (oder auch "Protected Network") nennt. Im Falle der TU Wien ist dies das TUNET. Die Seite gegenüber, also außerhalb des Firewalls, stellt das Outside Network (oder auch "Unprotected Network") dar, an der TU Wien im Konkreten der Internet-Anschluss zum ACOnet bzw. IBM Global Network. Neben diesen Netzwerkbereichen kann ein Firewall auch weitere mehr oder weniger geschützte Segmente (sprich Interfaces) haben, diese nennt man Perimeter Netzwerkbereiche. Hauptaufgaben eines Firewalls sind die Erkennung und der Schutz vor Angriffen auf Netzwerk- bis hin zur Applikationsebene (Abwehr von Denial of Service Attacken, Verhinderung von Mail-Spams und Port Scans). Methoden zur Kontrolle des Datenflusses reichen von einfachen Access-Listen auf Routern ("stateless" Packet Filtering, jedes einzelne Datenpaket muss für sich bestimmte Kriterien erfüllen) bis hin zu sogenannten "Stateful Packet" Filtering Methoden (kein Paket kann den Firewall passieren, welches nicht einer Verbindung zuordenbar ist bzw. einen definierten Status hat). alle Versuche, den Firewall unerlaubt zu durchdringen, werden mit entsprechenden Logging-Mechanismen aufgezeichnet.
Content Filtering und Network Address Translation sind nur einige weitere Möglichkeiten zur Steigerung der Sicherheit im internen Netzwerk-Bereich.
Wie im gesamten Internet traten auch an der TU Wien in der Vergangenheit Vorfälle im Netzwerk auf, die dem Thema Sicherheit in Rechnernetzwerken angehören. Zu den häufigsten Attacken neben echten Einbrüchen in Rechner gehören sogenannte Denial of Service Attacken und Mail-Spamming. Schon alleine um einige dieser gezielten Attacken auf die Verfügbarkeit von Netzwerkdiensten abwehren zu können, muss aus der Sicht des Netzwerkbetreibers mit proaktivem Management auf potentielle Angriffe reagiert werden. State-of-the-Art in heutigen Netzwerken ist der Einsatz von Firewalls.
Die konkrete Implementierung eines Firewalls in ein so komplexes Netz wie das der TU Wien muss jedoch im Vorfeld genau durchdacht sein. So ist eine sogenannte Security Policy für die gesamte TU Wien von der Technischen Universität selbst zu diskutieren und zu installieren, ohne deren Vorhandensein der sinnvolle Einsatz eines Firewalls in Frage gestellt ist. Dies ist auch die vorherrschende Meinung bei praktisch allen Internet Serviceprovidern. Eine besondere Komplexität ergibt sich dadurch, dass die TU Wien über eine redundante Internet-Anbindung an zwei Serviceprovider (ACOnet, IBM Global Network) verfügt.
Ein Firewall darf auf keinen Fall die im Netz implementierte Redundanz und somit Service-Qualität für seine Benutzer zunichte machen, und natürlich auch nicht die Performance des Netzes schmälern sondern er sollte ja die von Instituten und Organisationen der TU Wien über das Netz zur Verfügung gestellten Services (Mail, News, WWW und FTP Services, kritische allgemeine Services wie Nameservice und Timeservice) in höchstmöglichem Maße schützen.
Um diesen Schutz bieten zu können und nicht-autorisierte Verbindungen zwischen Netzwerkbereichen zu verhindern, muss sämtlicher Verkehr durch den Firewall laufen. Nur dadurch ist eine Kontrolle sicherzustellen. Da bei solch einer richtigen Firewall-Implementierung kein direkter Verkehr von außen nach innen möglich ist, muss eine Zone existieren, wo interne und externe Systeme miteinander kommunizieren können. Dieser neutrale Meeting Point wird durch die sogenannte DMZ (Demilitarized Zone) realisiert. Typischerweise sind in diesem Perimeter Netzwerkbereich WWW, FTP und Mail-Server für die Outside Internet Services angesiedelt. Man spricht dabei in speziellen Fällen auch von Bastionsrechnern. Hier sind auch die Nameserver für die von außen kommenden (quasi öffentlichen) Anfragen platziert. Dieses sogenannte Perimeter Network kann mit unterschiedlichem Sicherheitslevel konfiguriert werden. Dies ist mit höchster Sicherheitsstufe gleich dem Inside Network bis hin zur geringsten des Outside Network möglich.
Der Verkehrsfluss durch den Firewall teilt sich im Wesentlichen in zwei Arten von Verbindungen (Connections). Bei Outbound Connections sitzt der Client (Initiator einer Verbindung) quasi auf einem Interface mit einer höheren Sicherheitsstufe als der Server (Empfänger). Das Interface mit der höchsten Sicherheitsstufe ist immer das Interface zum Inside Network, das mit der niedrigsten zum Outside Network. Die Demilitarized Zone im Perimeter Netzwerkbereich kann je nach Erfordernissen zwischen diesen Sicherheitsstufen variieren. Inbound Connections (Verbindungen von außen nach innen, i.e. Verbindungen, wo der Initiator in einem Netzwerk mit geringerer Sicherheit sitzt als der Empfänger) sind bis auf explizit erlaubte (sogenannte Conduits) verboten. Im Szenario der TU Wien, wie in der gezeigten Abbildung dargestellt, handelt es sich beim Outside Network um das Internet (ACOnet, IBM Global Network), das Inside Network umfasst das TUNET. In der DMZ sind vorerst der Mail-Bastionsrechner sowie ein externes Nameserver-Paar (tunamec, tunamed) angesiedelt. Ein weiterer Vorteil dieser DNS Realisierung ist, dass die internen Nameserver von außen nicht mehr direkt erreichbar sind und daher nicht direkt Hackerattacken ausgeliefert sind. Ein weiterer Baustein zur Steigerung der Netzwerksicherheit ist NAT (Network Address Translation). Ursprünglich wurde NAT entwickelt, um der immer größer werdenden Knappheit an IP-Adressen im Internet entgegenzuwirken, damit können interne IP-Adressen in weltweit im Internet gültige Adressen umgewandelt werden. Durch den Einsatz von NAT in Verbindung mit externen Nameservern in der DMZ kann die interne Netzwerktopologie und die IP-Domain versteckt werden und dem Internet gegenüber somit eine komplett andere Sichtweise des Netzes präsentiert (vorgespiegelt) werden. Damit sind Hackerattacken durch Nichtkenntnis der exakten Netzwerkinfrastrukur zusätzliche Barrieren in den Weg gestellt.
all diese Maßnahmen sollen neben dem Schutz vor Angriffen aus dem Internet zur Sicherstellung eines reibungslosen Betriebes und stabiler Verfügbarkeit des TUNET und seiner Services beitragen. Das TUNET in seiner wichtigen und längst unabdingbaren Eigenschaft als Produktionsnetz für die Daten- und Telekommunikation der TU Wien muss in Zukunft verstärkt gesichert werden.
Das sogenannte Mail-Spamming, d. h. das Versenden unerwünschter Mails an eine große Anzahl von Personen, wird seit einiger Zeit immer mehr zu einer starken Belästigung für die Betroffenen und führt zu Überlastungen und Mails-Staus auf Mail-Servern. User und Betreiber mancher Mail-Server sperren ihre Mail-Zugänge gegenüber unerwünschten Sendern, manchmal gleich gegen ganze Domains. Spammer, denen bereits auf vielen Rechnern der Zugang gesperrt wurde, umgehen diese Restriktionen, indem sie ihre Mails über andere Mail-Server "routen" (Third Party Mail-Relaying. Man spricht von Relaying, wenn Mails von außerhalb der TU Wien über einen Rechner der TU Wien an einen anderen Rechner außerhalb weitergeleitet werden.).
Für die betroffenen Rechner ist SPAM-Relay ist eine extreme Bedrohung der Funktionsfähigkeit, des Ressourcenbedarfs und der Verfügbarkeit. Es kann zu Absturz, Plattenüberlauf und Inoperabilität des Rechners für Mail führen.
Da viele große Provider SPAM-Relaying automatisch erkennen, werden dort auch oft automatisch Aktionen gesetzt. Diese beinhalten z. B, dass keine Mails von den betroffenen Rechnern mehr akzeptiert werden und dass die Rechner an diverse Anti-SPAM Listen weitergemeldet werden. Solche Listen werden von etlichen Mail-Server-Betreibern (auch einigen Instituten der TU Wien) automatisch verwendet, um ihre Liste der Rechner, von denen sie keine Mails mehr akzeptieren, zu erweitern. Das kann so weit gehen, dass die Rechner an deren Firewall komplett gesperrt werden. Es ist sehr schwer, von solchen Listen in absehbarer Zeit wieder herunterzukommen.
SPAM-Relay ist aber auch eine Bedrohung einer gesamten Organisation wie der TU Wien, da ihre Ressourcen in erheblichem Ausmaß zu illegalen, kommerziellen oder belästigenden Aktionen missbraucht werden. Das Ansehen der TU Wien national und international leidet darunter, weil von ihr solche Mails kommen bzw. weil sie Mail Relaying überhaupt zulässt. Es besteht die Gefahr, dass die gesamte TU Wien auf eine Anti-SPAM Liste gerät.
Es ist daher äußerst wichtig, dass alle Mail-Server am TUNET entsprechend konfiguriert sind, sodass sie nicht als Mail-Relay missbraucht werden können. Weitere ausführliche Informationen über dieses Thema finden Sie in der PIPELINE Nr. 24 im Artikel "Mißbrauch von Mail-Servern an der TU Wien" von Martin Rathmayer.
Es zeigte sich jedoch, dass an manchen Institutsrechnern das Relaying nicht unterbunden wurde. Unter anderem aus diesem Grund wurde ein neues generelles Konzept für Mail-Routing und Mail-Bearbeitung an der TU Wien erstellt. Dabei wurde eine Lösung erarbeitet, die einen zentralen Mail-Bastionsrechner für die ganze TU Wien vorsieht, mit dessen Hilfe das gesamte TUNET von unerwünschtem Relaying u.ä. abgeschirmt werden kann. Die geplante Lösung hat folgende Struktur:
Eingehende Mails werden über einen sogenannten Mail-Bastionsrechner geleitet, der dazu dienen soll, für den gesamten Mail-Verkehr vom Internet zum TUNET die Relay-Möglichkeit zu unterbinden. Um ihn sowie alle Rechner der TU Wien entsprechend zu schützen, wird ein Firewall-System eingesetzt. Der Bastionsrechner wird in der sogenannten DMZ (de-militarized Zone) aufgestellt, also hinter dem Firewall.
Es wurde für dieses Konzept bereits eine Testkonfiguration aufgebaut und ausführliche Performance Tests wurden durchgeführt. Als Bastionsrechner ist eine Sun Ultra 2/2170 mit 640 MB Memory vorgesehen. Derzeit läuft das System im Testbetrieb, ab Sommer sollen dann die von außen zur TU eingehenden Mails standardmäßig über den Bastionsrechner geleitet werden. In akuten Fällen können auch einzelne Rechner schon früher eingegliedert werden, z .B. wenn ein Mail-Server eines Instituts als SPAM-Relay missbraucht wird und es nicht möglich ist, Relaying über diesen Rechner zu unterbinden.
Neben dem leichteren Umgang mit den derzeit vorliegenden Problemen hat dieses System auch den Vorteil, dass bei zukünftigen neuen Anforderungen nur an wenigen Stellen reagiert werden muss.
Außer der gewünschten Unterbindung des Mail-Relays und zusätzlichen Einträgen in den Mail-Headers wird die einzige zu erwartende Auswirkung eine Beschränkung der maximalen Größe von Mails am Bastionsrechner sein.
Da Mail im Internet nach dem "Store and Forward" Prinzip funktioniert, ist ein kurzer Ausfall des Bastionsrechners nicht weiter tragisch, da die Mails beim letzten Übergaberechner liegen bleiben. Es ist auch ein Backup-Mechanismus in Form der direkten Umgehung des Bastionsrechners möglich, dazu muss bei Ausfall des Bastionsrechners nur die Port-Sperre am Firewall aufgehoben werden. Für diesen kurzen Zeitraum ist dann allerdings der Relay-Schutz aufgehoben.
Bei Fragen betreffend den Mail-Bastionsrechner wenden Sie sich bitte an Elisabeth Donnaberger von der Abteilung Kommunikation.