Eine Security Policy legt fest, welche Informationen welchem User im
Netzwerk zugänglich sind. Diese Aufgabe kann man nur bewältigen, wenn man
sich einiger Dinge bewußt wird:
- Router und Firewalls können nur Zugriffe von bestimmten Clients mit
einer bestimmten IP-Nummer auf bestimmte Ports
von Servern kontrollieren, hinter denen sich bestimmte Dienste, wie Fileserver, FTP
Server, SQL Datenbank, Mailserver, Newsserver, WWW-Server u.s.w. verbergen. Für die
Kontrolle der Paßworte sind die Server selber zuständig.
- Es gibt Verknüpfungen zwischen Diensten untereinander. Das bekannteste
Beispiel dürfte die Verknüpfung eines WWW-Servers mit einer SQL Datenbank
über ein CGI-BIN (PERL, ASP, PHP3) sein. Man kann also über andere
Protokolle, z.B. dem Port 80 Zugang zu einer SQL Datenbank auf Port 1521
(ORACLE SQL) erhalten. Ein Router oder eine Firewall registriert dann den
Zugriff einer Arbeitsstation auf die SQL Datenbank nicht.
- Diese Verknüpfungen können auch über Server hinweg passieren, z.B.
kann man mit einem PHP3 Script auf dem WWW-Server eine weit entfernte Datenbank
abfragen, und die Ergebnisse über den Browser an die Arbeitsstation
übergeben. Damit die Security Policy überwacht werden kann, muß also im
Server aus den Logfiles ersichtlich sein, daß Arbeitsstation X über Port 80
(WWW) und ein CGI-BIN eine Abfrage des SQL Servers getätigt hat.
- Es gibt Anwendungen, die keinen bestimmten Port zur Kommunikation
untereinander verwenden. Hierzu gehören die NT PDC´s und BDC´s, die über ein
wildes Gemisch von TCP und UDP Protokollen, auch RPC (Remote Procedure
Protocols) miteinander kommunizieren. Hierzu findet zuerst eine Verbindung
auf Port 111 (Portmapper) statt, die mit einer Firewall noch zu überwachen
ist, danach hat die Firewall oder der Router keine Möglichkeit mehr, die
Verbindungen der PDC´s und BDC´s zu erkennen. Damit die Kommunikation über
eine Firewall oder einen Router in einem großen Netzwerk jedoch noch
funktioniert, müssen alle UDP und TCP Ports oberhalb von 1024 freigeschaltet
werden. Aber auch BACKOFFICE und SMS benutzen wild irgendwelche Ports und
Protokolle.
- Durch diese Freischaltung können andere Ports zwischen Clients
untereinander und Serverdiensten oberhalb 1024, z.B. SQL nicht mehr gesperrt
werden. Eine Kontrolle in der Firewall ist zwar möglich, jedoch benutzen
z.B. auch PDC´s eventuell einmal TCP Port 1521.....
- Damit keine Mißverständnisse bezüglich benutzter Ports für den
Datenaustausch aufkommen, kann und muß man bei Windows NT bestimmten
Diensten einen festen IP-Bereich zuweisen, der dann auch von der Firewall
zugeordnet werden kann. D.h. z.B., daß für RPC Protokolle nur Ports zwischen
15000 und 15100 verwendet werden dürfen. Zu einer Security Policy gehört
auch die Festlegung der Ports für bestimmte Dienste.
- Für alle Dienste müssen also legale Portnummern zugewiesen werden,
damit die Firewalls im Unternehmen den Datenfluß überhaupt kontrollieren
können.
- Danach erst können die Zugriffe von Arbeitsstationen auf bestimmte
Server und deren Dienste kontrolliert werden. Allerdings gehört dann zu
einer Überwachung auch die Protokollierung des Datenverkehrs über
Interfaces. Hierzu muß man alle möglichen Interfaces, die Daten
weitertransportieren können, kennen.
- Mögliche Interfaces sind teilweise bekannt: PROXY´s, CGI-BIN´s,
WWW-Server. Es gibt aber auch Interfaces, die kaum jemanden bekannt sind.
Fehlerhaft programmierte FTP-Server, der WWW-Server IIS, APACHE, der Inet-Dämon unter UNIX,
fehlerhafte TCP/IP Stacks bei Microsoft, der Filter WEBWASHER von Siemens,
der auch als PROXY arbeitet, der SAMBAR WWW-Server und PROXY, Groupware
Server (NOVELL Groupwise), der EXCHANGE Server, der MAIL-SERVER (SENDMAIL
ohne SPAM-Kontrolle), der DNS Server u.s.w. Die Liste ist sehr lang, der
mögliche Mißbrauch dieser o.g. Software ist nachgewiesen.
- Über diese Interfaces können Datenpakete weitergeleitet werden, sodaß
jemand eventuell Daten aus einem Datenbankserver abfragen kann, ohne direkt
mit diesem in Kontakt treten zu müssen. Damit kann die Firewall auch keinen
Protokolleintrag aufweisen.
- Zugriffe von Arbeitsstationen auf Server können in einer Firewall nur
dann korrekt einem Anwender zugeordnet werden, wenn diese Arbeitsstation
stets eine feste IP-Nummer zugeordnet wird. Beim Einsatz von DHCP, also dem
IP-Leasing Modell von IBM, muß die Firewall und alle Router stets darüber
informiert sein, welche Arbeitsstation mit welchem User gerade welche
IP-Numer verwendet. Da die meisten Router und Firewalls bei DHCP passen
müssen, bleibt nur die feste Zuordnung von IP-Nummern und Arbeitsstationen.
Im DHCP Server kann man Reservierungen für bestimmte MAC Adressen festlegen,
womit man das Problem dann umgangen hat. Ohne diese Festlegung ist eine Überwachung eines Netzwerkes viel
komplexer.
Leider hat Microsoft diese Kommunikationsprotokolle der PDC´s untereinander auf den RPC´s (Remote Procedure Calls) aufgebaut, einer
Mischung aus TCP und UDP Protokollen. Das hat zur Folge, daß der
Systemadministrator zur Absicherung und Überwachung von NT Netzwerken sehr
teuere Firewalls einsetzen muß, die die RPC Proxy Mechanismen beherrschen.
Die einzige Firewall, die im Quellcode verfügbar ist, und dieses Protokoll
beherrscht, ist das TIS FWTK. Aber auch über die Programmierung der Sinus
Firewall-1 lassen sich diese Mechanismen nachbilden. Grundsätzlich
ist der Systemadministrator gut beraten, Microsoft Protokolle weitestgehend
zu meiden. Es lassen sich auch sehr große heterogene Netzwerke mit auf NT
portierten UNIX Werkzeugen administrieren, hierzu sollte man einen Blick auf
Kerberos, NIS+, YP, LDAP (SLAPD), einem Directory Access Protokoll, ähnlich
NDS, X.500 oder Active Directory) durchaus riskieren. UNIX
Administrationswerkzeuge haben einen großen Vorsprung in Sicherheit und
lassen sich mit preiswerten Firewalls gut überwachen.
![[Inhalt]](../../Grundlagen/Firewall/images/toc.gif){kind=small}