Vorschlag ZID Netzwerksicherheit Themen

Einleitung

Liebe Leute,

ich habe mir einige Gedanken über die ausstehenden Arbeiten im Sicherheitsbereich gemacht und habe untenstehend versucht, das zusammenzuschreiben.

Im Wesentlichen geht es hier um Netzwerksicherheit. Ich schweife aber ab und komme auch zum Punkt Policies.

Der Text geht an die Mitarbeiter der Abteilung Systemplanung Kommunikationssysteme sowie an Helmut Pedit als Sicherheitskoordinator.

Ich erhoffe mir, dass daraus eine Diskussion entsteht und in Folge ein gemeinsames Konzept (welcher Art auch immer).
Dieses sollte dann den ZID Mitarbeitern vorgestellt werden.

Ja, der Text ist lange, tut mir leid, ging nicht anders. Bitte aber trotzdem lesen ... :)

Inhalt

Management Werkzeug

Ein neues Werkzeug zur Verwaltung der "Netzwerk Daten" (Patchungen, IP, DHCP) wird von uns schon länger angestrebt.
Im Zuge der hier vorgestellten Maßnahmen ist diese Notwendigkeit noch stärker zu betonen. Insbesondere die unter "DHCP" und "plug-INN für Institute" angeführten Maßnahmen sind wohl nur so sinnvoll realisierbar.

Dieses Werkzeug sollte nach Möglichkeit die volle Funktionalität der bisher eingesetzten Werkzeuge haben bzw. Schnittstellen zu diesen schaffen.

Ein wesentlicher Punkt ist die "Mandantenfähigkeit": Lese- und Schreibrechte auf einzelne Bereiche beziehungsweise Teilaspekte dieser sollten an beliebige Personen (etwa ZID Mitarbeiter oder die EDV Kontaktperson der Institute) vergeben werden können.

Diesbezüglich sind mit der Abteilung Systemplanung Datenbanken und Informationssysteme möglichst bald Gespräche zu führen.

Vermehrter Einsatz von VLANs

Es sollte versucht werden, für kleinere Einheiten als bisher VLANs zu schaffen. So könnte beispielsweise im Technik NATWI Gebäude für jedes Institut ein VLAN geschaffen werden.

Hierbei sind jedoch begleitende Maßnahmen zu treffen, weil dadurch zum Beispiel ein Instituts-Laptop in den Hörsälen nur mit unterschiedlicher IP Konfiguration eine IP Konnektivität erhält. Dies wird nachfolgend in den Abschnitten "DHCP" und "plug-INN für Institute" beschrieben.

Neben den VLANs für "normale" Mitarbeiter- und Studenten-PCs sind weitere VLANs sinnvoll:

  • plug-INN für Institute
    siehe weiter unten
  • VLANs für "interne" Rechner (lokale IP Adressen)
    siehe weiter unten
  • VLANs für Institutsserver
    siehe weiter unten
  • Management VLAN
    Es ist gängige Praxis, ein Management VLAN zu schaffen, in dem sich beispielsweise die Switches befinden.
    Das scheint sicherheitstechnisch sinnvoll und sollte diskutiert werden.

DHCP

Viele der hier beschriebenen Maßnahmen werden durch den Einsatz von DHCP erleichtert, weil dadurch eine größere Flexibilität bei notwendigen Umstellungen besteht.

(Unter DHCP wird hier, wenn nicht anders angegeben, die "statische" Variante verstanden, bei der einer bekannten MAC Adresse eine IP Adresse zugeordnet wird.
Der Einsatz von "dynamischen" DHCP erfolgt nur in Verbindung mit Maßnahmen zur Benutzerauthentifizierung. Dies wird auch unter "plug-INN für Institute" behandelt.)

Für einige Szenarien ist der Einsatz von DHCP zwingend notwendig.
Wird etwa ein Gebäude in mehrere VLANs unterteilt, können Rechner nicht mehr in allen Bereichen eingesetzt werden - etwa wie im oben beschriebenen Fall von Laptops und Hörsälen.
Zumindest "mobile" Geräte sollten daher über DHCP die IP Konfiguration erhalten. Dies wird noch genauer unter "plug-INN für Institute" beschrieben.

Es ist zu klären, ob ein durchgehender Einsatz von DHCP für alle (Mitarbeiter- und Studenten-)PCs angestrebt werden soll.
Ist dies der Fall, sind eine Reihe von Fragen zum Prozedere zu klären:

  • Wer darf MAC Adressen ändern bzw. Änderungen melden?
  • Wie ist das vorgeschlagene Prozedere zum Auslesen der MAC Adressen?
  • Wie schnell wird die MAC Adresse "aktiviert"?
  • Soll es möglich sein, dass ein Rechner bis zur "Aktivierung" der MAC Adresse eine dynamische Adresse erhält?

Das wesentliche Problem ist natürlich, dass die Benutzer natürlich sofort mit dem PC arbeiten wollen, was bei unseren Abläufen nicht möglich ist (erst am nächsten Arbeitstag). Wird davor eine statische IP Adresse verwendet, wird dies wohl nie wieder geändert ...
Schafft man für diesen Fall echte dynamische Adressen, ist die Gefahr ähnlich - die MAC Adressen werden nie gemeldet, wodurch der (sinnvoller Weise kleine) Adressbereich bald belegt und für den erwünschten Einsatz nicht verfügbar ist. Eine zusätzliche Gefahr stellen hier z.B. Drucker dar, die standardmäßig versuchen, über DHCP eine Adresse zu erhalten.

plug-INN für Institute

Oben wurde schon das Szenario beschrieben, dass beim vermehrten Einsatz von VLANs Laptops in den Hörsälen nicht funktionieren. Ein Lösungsansatz ist, dass die Laptops über DHCP ihre Adresse erhalten.
Das hat jedoch den Nachteil, dass im Hörsaalbereich (an einer Dose) jeder Rechner eine IP Adresse erhält, was sicherheitstechnisch problematisch ist.
Dies kann behoben werden, wenn man das plug-INN System auf diesen Bereich ausweitet. Damit erhalten die Rechner zwar IP Adressen, die Benutzer müssen sich jedoch validieren, um die volle IP Konnektivität zu erhalten.


Eine weitere Idee ist, das plug-INN System noch intensiver einzusetzen. In diesem Szenario werden auch normale Institutsrechner über plug-INN betrieben.

Es ist auch vorstellbar, Mitarbeiter-PCs in Kombination mit plug-INN zu verwenden, um etwa die Sicherheitsprobleme von DHCP zu vermeiden (die MAC Adresse kann leicht geändert werden).

Generell ist hier zu beachten, dass die maximalen plug-INN Verbindungszeiten (etwa die automatische Abmeldung) so gewählt sein müssen, dass ein normales Arbeiten möglich ist.

Außerdem ist zu beachten, dass durch die automatische Unterbrechung der IP Verbindung die Arbeit mit Fileservern problematisch sein kann (NCP, CIFS?, AFS).

Lokale Adressen

Ein relativ großer Teil der Rechner an der Universität Innsbruck benötigt keine Verbindung zu Systemen außerhalb der Universität. Dies reicht von Testsystemen, Druckern und Netzwerkkomponenten über Serversysteme bis hin zu INNET Bar Systemen und einzelnen Mitarbeiter-PCS.
Ich gehe von einem Potential von zumindest 5-10% der Rechner aus.

Die Idee ist, hier ein privates Class B Netzwerk (172.16.0.0 - 172.31.255.255) zu verwenden. Dieses wird innerhalb der Universität geroutet, sodass hier die volle Funktionalität besteht

Die Rechner kommen in eine Unterdomäne intern.uibk.ac.at, wobei die Namen auch unter Weglassung von "intern" eindeutig bleiben, d.h. es gibt keinen Rechner "xxx.intern.uibk.ac.at", wenn ein Rechner "xxx.uibk.ac.at" existiert und umgekehrt.
Damit sind die Rechner immer als rechner.intern ansprechbar. Außerdem bleibt die Eindeutigkeit bei "Siedelung" eines Rechners zwischen denm öffentlichen und dem privaten Bereich gegeben.

Der Nameserver liefert über diese Unterdomäne nach außerhalb der Universität Innsbruck keine Auskunft.

Die Rechner haben trotzdem weiterhin beschränkten Internet-Zugriff, da die Verwendung des Proxy Servers möglich ist, womit sich neben HTTP und FTP auch eine Reihe anderer Zugriffe, etwa von Multimedia Applikationen (Real Player etc.) realisieren lassen.

Es ist zu beachten, dass für diese internen Systeme auch kein Zugriff von und zu Systemen hinter der Firewall der Universitätsklinik möglich ist.

Folgende Dinge sind zu beachten:

  • Es sind entsprechende Änderungen an den Routern vorzunehmen.
  • Für die Nameserver ist die beschriebene Konfiguration zu entwickeln.
  • Es sind entsprechende Anpassungen im Bereich der Server Sicherheit (Firewalls, TCP Wrapper) vorzunehmen.
  • Die Applikationen (HTTP Server, Proxy etc.) sind ggf. in ihrer Konfiguration ebenfalls anzupassen.

Es ist anzudenken, in dieses Konzept einen Applikationsproxy (Delegate, SOCKS) zu integrieren.
Damit wäre es gleichsam möglich, die Wirkung eines klassischen Firewall Konzeptes mit (Applikations-)Proxy "auf freiwilliger Basis" zu erzielen (und damit ggf. auch schon einmal für eine "ordentliche" Firewall zu "üben").

VLANs für Institutsserver

In Vorbereitung auf strengere Firewall Regeln (ob nun über einen Border Router oder einen "echten" Firewall) sollten Institutsserver in eigene VLANs (z.B. 1 VLAN pro Gebäude oder Standort) verschoben werden.

Dadurch werden erstens exponierte Systeme netzwerktechnisch isoliert, und zweitens werden dadurch notwendige Firewall Regeln auf ein praktikables Maß reduziert (z.B. reichen wenige Regeln aus, um den Zugriff auf HTTP Port 80 zu erlauben - es müssen nur wenige Subnetze angegeben werden, und nicht einzelne Systeme, was sowohl für die Wartbarkeit als auch den Durchsatz der Firewall relevant ist).

Es ist zu beachten, dass im Folgenden die ZID Server wie ein VLAN für Institutsserver behandelt werden (auch wenn sich der Regelsatz der Firewall unterscheiden kann). Es gelten daher auch dieselben Regeln und Pflichten.

Im Folgenden werden viele Punkte aufgeführt, die sich mit dem Abschnitt über Firewalls überschneiden beziehungsweise zu diesem hinführen.

Als erstes sind entsprechende Richtlinien erforderlich, die den Betrieb von Serversystemen regen.
Diese Richtlinie sollte sich an jener orientieren, die bereits für HTTP Server existiert. Jenseits dem bereits Formulierten sollten folgende Punkte aufgenommen oder betont werden:

  • Es ist eine ständige Erreichbarkeit eines Betreuers zu gewährleisten.
  • Die Server, da exponiert, sind ständig durch Updates auf dem aktuellen Sicherheitsstand zu halten.
  • Da seitens der Firewall kein Schutz für diese Systeme besteht, ist zwingend ein rechnerbasierendes Firewalling einzusetzen, das nur die benötigten Dienste (und nur im benötigten Ausmaß) zugänglich macht.
  • Der ZID hat das Recht, die Systeme unter Einsatz von Hilfsmitteln zum Test der Serversicherheit zu überprüfen.

Zu Beginn sollten vordringlich die HTTP und FTP Server behandelt werden, gefolgt von Systemen mit ssh Zugriff (telnet, rsh etc. werden deaktiviert). Es folgen Rechner mit Serversystemen bis Port 1024.
Danach wird versucht, auch den Zugriff auf die höheren Ports zu kontrollieren. Ab diesem Schritt iset aber der Einsatz eines "stateful Firewall" notwendig.

Mit der Migration der entsprechenden Server ist der Zugriff auf die Server-Ports am Firewall schrittweise abzudrehen.

Das Ziel, unter Einsatz eines geeigneten Firewalls, ist, jegliche Serverfunktionalität auf die Server VLANs zu beschränken.
Dies betrifft auch ICMP Pakete soweit sinnvoll (echo u.a.).

Diese Vorgehensweise ist durch die Universität entsprechend abzusegnen. Es ist festzustellen, inwiefern der ZID hier eigenverantwortlich handeln kann, bzw. wie hier das Prozedere festzusetzen ist.

Es ist zu beachten, dass bestehende Institutsfirewalls in dieses Konzept entsprechend zu integrieren sind (da hinter den Firewalls sowohl Klienten alks auch Server stehen).

Benutzerregelungen und Beschreibungen

Soweit nicht durch Firewalling und ähnliche Maßnahmen erzwingbar, sind entsprechende Regelungen zu erstellen und entsprechend kundzutun.

Wo Regelungen technisch erzwungen werden, ist dies entsprechend zu vermitteln.

Zentrale Firewall

Die wichtigste Frage hier ist im Wesentlichen, wo der Firewall platziert werden soll - als "Border Firwall" (in der Funktionalität ähnlich dem jetztigen Einsatz von r1b), oder aber im Backbone Bereich, zwischen den VLANs/Instituten.

Die wesentlichen Aufgaben einer zentralen Firewall wurden bereits im Abschnitt über VLANs für Institutsserver behandelt.
Hier einige Punkte, die meines Erachtens relevant sind:

  • Die Firewall sollte sowohl den internationalen Verkehr als auch jenen des ACO-IX (Verkehr zwischen den österreichischen Universitäten) überwachen.
  • Für die Kontrolle der Ports jenseits 1024 ist auf jeden Fall eine "stateful Firewall" jenseits der Möglichkeiten der Cisco Router ACLs notwendig.
  • Der Einsatz eines nicht-Cisco Firewalls ist zu erwägen (auch aus Sicherheitsgründen, damit nicht das ganze Sicherheitskonzept bei Auftreten eines Cisco Sicherheitsproblemes zusammenbricht). Hier drängt sich vor allem der Netscreen Firewall auf (aufgrund der Performance), auch Checkpoint FireWall-1 ist zu beachten. Eine Linux basierende Lösung (jenseit von Checkpoint) scheint ebenfalls möglich.
  • Wird der Firewall nicht redundant ausgelegt, so sollte das Regelwerk auf einem Linux (iptables) Firewall System entsprechend abgebildet werden, um längere Ausfallzeiten und/oder die Nichtverfügbarkeit der Firewall zu vermeiden.
  • Hinter der Firewall sollten die basalen Regeln am nachfolgenden Router (r1b oder sr1a/b) ebenfalls implementiert werden, um das Versagen eines einzelnen Systems abzufangen.

Institutsfirewalls

Wird der zentrale Firewall als Border-Firewall gestaltet, sollte überdacht werden, ob weitere Firewalls vor den Instituten sinnvoll sind (für Server und/oder Klienten).

Für eine derartige Lösung bietet sich ein Linux basierendes System an. Dieses kann auf einem standard Linux System basieren. Gleichzeitig sind aber bestehende freie komplette Linux Firewall Lösungen zu untersuchen.
Hier sollte auch überdacht werden, inwiefern die Produkte von Phion interessant sind (aus meiner Sicht ist dafür vorauszusetzen, dass Phion Produkte auf Basis von Linux iptables anstelle von ipchains anbietet).

Bevor diese Möglichkeit ernsthaft erwogen wird, sollten die entsprechenden Performance Tests durchgeführt werden (100/1000 Mbit ohne Firewall, mit Firewall ohne Regeln, mit Firewall und "Standard-Regelwerk").
Eine Auflistung der wichtitsten Testprogramme (ttcp, netperf, netpipe etc.) findet sich unter: http://www.fokus.fhg.de/research/cc/glone/projects/ip-qos/tools/bench.html.

Scannen von Rechnern

Einhergehend mit einer Regelung für Server ist es sinnvoll, diese regelmäßig zu überprüfen. Dieses Vortgehen ist in den Regelungen entsprechend festzuhalten.

Die Überprüfung sollte von einem externen Rechner (exthost) aus erfolgen.

Die Überprüfung sollte "stateful" sein, d.h. es werden nur die Änderungen zum vorherigen Lauf angezeigt.

Als Software bietet sich hier nessus an, mit dem sich diese Tests sowohl automatisch als auch "stateful" durchführen lassen. Kommerzielle Produkte (ISS) sollten jedoch ebenfalls evaluiert werden.

Zumindest zweimal jährlich sollte ein Test von einer anderen IP Adresse aus durchgeführt werden, um eine Umgehung seitens der Betreuer zu vermeiden. Diese Überprüfungen sind nach Durchführung umgehend kundzutun.

Es ist zu überdenken, inwiefern solche Überprüfungen zulässig und wie sie ggf. mitzuteilen sind. Auf jeden Fall ist dies in der Regelung zum Betrieb von Servern kundzutun.

Sperren von Rechnern

Es ist in den Regelungen (zumindest für den Serverbetrieb) festzuhalten, dass seitens des ZID Rechner gesperrt werden können, wenn

  • akute Sicherheitsmängel oder -probleme festgestellt werden oder
  • die bestehenden Regelungen verletzt werden oder
  • bei gröberen Problemen Kontaktperson am Institut innerhalb eines Arbeitstages nicht erreichbar ist oder keine ausreichenden Aktionen setzen kann.

Accounting

Es ist zu erwägen, inwiefern die Accounting Daten (des zid-netsn) verwendet und/oder weiter ausgebaut werden sollen.
Eine Möglichkeit besteht darin, die Daten den Instituten zur Verfügung zu stellen.

Sollte es notwendig werden, ein IP basierendes Accounting durchzuführen (etwa zu Verrechnungszwecken) sind die entsprechenden gesetzlichen Verpflichtungen, etwa die Aufbewahrungszeit der Daten, umzusetzen.

Bei der Zuordnung des Verkehrs zu Verwaltungseinheiten ("tagging") sollten die ZID Mitarbeiter von den vom ZID angebotenen Services getrennt werden, zum Beispiel:

  • ZID Mitarbeiter
  • Serverraum
  • Studentenheim 1 ... n
  • Modem
  • VPN

Es ist zu beachten, dass durch die Schaffung von VLANs, in denen sich die Rechner verschiedener Einheiten befinden, zusätzliche Probleme für das Accounting entstehen (plug-INN, VLANs für Institutsserver etc.).

Switch Portsicherheit

Der Einsatz von VQS ("VLAN Query Protocol") zur Sicherung der Benutzerräume sollte angedacht werden. Damit wäre es beispielsweise möglich, dass in einem Benutzerraum genau nur dessen Rechner an die zugehörigen Switch Ports angeschlossen werden können (Überprüfung auf MAC Basis). Das bietet (da MAC Adressen fälschbar sind) keine echte Sicherheit, setzt aber die Latte schon sehr hoch ...

Andere Universitäten (Linz und noch irgendwer ...) setzen VQS bzw. einen VMPS ("VLAN Membership Policy Server) im gesamten Netzwerk zur Konfiguration der VLANs ein. Wäre Derartiges zu überlegen?