Online Suche im Handbuch

LITTLE-IDIOT NETWORKING

28. Erstellung einer Security Policy

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.

Online Suche im Handbuch

LITTLE-IDIOT NETWORKING