DE19741239A1 - Verallgemeinertes Sicherheitspolitik-Management-System und Verfahren - Google Patents

Verallgemeinertes Sicherheitspolitik-Management-System und Verfahren

Info

Publication number
DE19741239A1
DE19741239A1 DE1997141239 DE19741239A DE19741239A1 DE 19741239 A1 DE19741239 A1 DE 19741239A1 DE 1997141239 DE1997141239 DE 1997141239 DE 19741239 A DE19741239 A DE 19741239A DE 19741239 A1 DE19741239 A1 DE 19741239A1
Authority
DE
Germany
Prior art keywords
rule
request
network
authentication
protocol
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE1997141239
Other languages
English (en)
Other versions
DE19741239C2 (de
Inventor
Edward B Stockwell
Alan E Klietz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
McAfee LLC
Original Assignee
Secure Computing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US08/715,343 external-priority patent/US5983350A/en
Priority claimed from US08/715,668 external-priority patent/US5950195A/en
Application filed by Secure Computing LLC filed Critical Secure Computing LLC
Publication of DE19741239A1 publication Critical patent/DE19741239A1/de
Application granted granted Critical
Publication of DE19741239C2 publication Critical patent/DE19741239C2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Description

Die vorliegende Erfindung betrifft allgemein Netzwerk-Kommunikation und insbesondere ein System und ein Verfahren zum Regeln des Flusses von Inter- Netzwerk-Verbindungen durch einen Firewall.
Firewalls sind ein zunehmend wichtigerer Teil einer Netzwerk-Gestaltung geworden. Firewalls bieten Schutz wertvoller Ressourcen in einem privaten Netzwerk, während sie Kommunikation mit Systemen und Zugriffe auf Systeme erlauben, die in einem ungeschützten Netzwerk wie dem Internet vorhanden sind. Weiterhin blocken sie Angriffe auf ein privates Netzwerk ab, die aus dem ungeschützten Netzwerk an kommen, durch Bereitstellen einer einzelnen Verbindung mit begrenzten Diensten. Ein gut ausgebildeter Firewall begrenzt die Sicherheitsprobleme einer Internet-Ver­ bindung für ein einzelnes Firewell-Computersystem. Dies erlaubt einer Organisation, ihre Netzwerk-Sicherheitsbemühungen auf die Definition der durch den Firewall durchgesetzten Sicherheitspolitik zu konzentrieren. Ein Beispiel eines Firewall ist gegeben in "SYSTEM AND METHOD FOR PROVIDING SECURE INTERNETWORK SERVICES" von Boebert et al. (veröffentlichte PCT-Anmeldung Nr. WO 96/13113, veröffentlicht am 2. Mai 1996), auf dessen Beschreibung hierdurch Bezug genommen wird. Eine weitere Beschreibung eines Firewalls wird gegeben von Dan Thomsen in "Type Enforcement: the new security model", Proceedings: Multimedia: Full-Service Impact on Business, Education, and the Home, SPIE Ausgabe 2617, Seite 143, August 1996. Noch ein weiteres System ist beschrieben in "SYSTEM AND METHOD FOR ACHIEVING NETWORK SEPARATION" von Gooderum et al. (veröffentlicht in der PCT-Anmeldung WO 97/29413, ver­ öffentlicht am 14. August 1997), auf dessen Beschreibung hier Bezug genommen wird. Alle obigen Systeme sind Beispiele für Anwendungsebenen-Gateways. Anwendungsebenen-Gateways verwenden Proxies oder andere Mechanismen, welche in der Anwendungsschicht wirken, um den Verkehr durch den Firewall zu verarbeiten. Als solche können sie nicht nur den Mitteilungsverkehr, sondern auch den Mitteilungs-Inhalt überprüfen. Zusätzlich bieten sie Authentifizierungs- und Identifizierungs-Dienste, Zugriffssteuerung und Prüfung.
Zugriffssteuerungslisten oder ACLs sind Listen mit Regeln, welche den Fluß der Internetverbindungen durch einen Firewall regeln. Diese Regeln steuern, wie Server und Proxies eines Firewalls auf Verbindungsversuche reagieren. Wenn ein Server oder Proxy eine ankommende Verbindung empfängt, führt er eine ACL-Prüfung der Verbindung aus.
Eine ACL-Prüfung vergleicht die Quellen- und Ziel-IP-Adresse der Verbindung anhand einer Liste von ACL-Regeln. Die Regeln bestimmen, ob die Verbindung zugelassen oder zurückgewiesen wird. Eine Regel kann ebenfalls eine oder mehrere Nebenwirkungen aufweisen. Eine Nebenwirkung veranlaßt den Proxy, sein Verhalten in irgendeiner Weise zu ändern. Zum Beispiel ist eine bekannte Nebenwirkung, die Ziel-IP-Adresse zu einem alternativen Gerät umzuleiten.
Sidewinder, Version 2.0, ist ein Firewall, welcher ein Beispiel eines Systems ist, welches eine ACL-Prüfung verwendet, um den Fluß von Internetverbindungen durch seinen Firewall zu regeln. ACLs in Sidewinder 2.0 sind in einer Datei /etc/sidewin­ der/acl.conf gespeichert. Diese Datei wird von sämtlichen Servern und Proxies des Sidewinder-Firewall gelesen. Eine Zeile in der Datei läßt eine Verbindung basierend auf der Quellen-IP-Adresse, der Ziel-IP-Adresse und der Ziel-Anschlußnummer der Verbindung zu oder weist sie zurück. Einige Beispiele sind nachfolgend gezeigt:
Diese Regel läßt einen Zugriff von jedem in dem internen Sicherheitsbereich vorhandenen Client auf jeden in dem externen Sicherheitsbereich vorgesehenen ftp-Server zu.
Die erste Regel erlaubt einen http-Zugriff aus dem internen Sicherheitsbereich auf alle Web-Server in dem externen Sicherheitsbereich. Die zweite Regel verweigert den Zugriff auf einen bestimmten Web-Server, der bei 174.252.1.1. angeordnet ist.
Diese Regel fängt alle ankommenden Verbindungen ab, die zu der Außenseite des lokalen Sidewinder (192.168.1.192) verlaufen und leitet sie zu shade.sctc.com (172.17.192.48) um.
In Sidewinder, Version 2.0, verwendete ACL-Regeln weisen allgemein die folgenden Übereinstimmungskriterien auf:
  • - Die Quellen-IP-Adresse. Diese kann als ein Teilnetz ausgedrückt werden durch Angeben der Anzahl der signifikanten Bits in der Adresse.
  • - Den Quellen-Sicherheitsbereich. Dieser ist stets entweder "intern" oder "extern".
  • - Die Ziel-IP-Adresse.
  • - Der Ziel-Sicherheitsbereich, wiederum entweder "intern" oder "extern".
  • - Der Dienst-Name. Die Namen und Protokolle der Dienste werden aus der Datei /etc/services erhalten.
und sie haben die folgenden zwei Nebenwirkungen:
  • - Umleiten der IP-Adresse zu einem anderen Gerät.
  • - Umleiten der Anschlußnummer zu einem anderen Anschluß.
Eine Verbindung von einer bestimmten IP-Quelladresse zu einer bestimmten IP-Ziel­ adresse wird verweigert, solange nicht eine Regel vorhanden ist, welche die Verbindung zuläßt, und kein Eintrag vorhanden ist, welcher die Verbindung zurückweist. Die Reihenfolge der Einträge in der Liste ist unerheblich.
Ein ACL-Ansatz wie der in Sidewinder 2.0 verwendete weist eine Anzahl von Beschränkungen auf. Da z. B. sämtliche ACL-Regeln in dem Firewall-System festgelegt sind, wobei nur IP-Adressen verwendet werden, ergibt sich keine Möglichkeit, einen Host-Namen zu bestimmen. Eine Regel kann nur eine Quelle, ein Ziel und einen Dienst aufweisen; eine separate Regel ist für jeden Dienst und für jeden Arbeitsplatz erforderlich. Daher muß bei Blockzugriffen auf mehrere Web- Positionen (Sites) eine separate Regel für jede einzelne erzeugt werden. Weiterhin kann eine Position mit fünf Diensten und 1000 Arbeitsplätzen 5000 Regeln benötigen. Dies kann die Leistung verlangsamen.
Zusätzlich schafft die Verwendung statischer IP-Adressen ein Problem für eine Position, welche den Microsoft Windows NT Server und DHCP (Dynamic Host Configuration Protocol) mit Desktop-Personalcomputern (PCs) verwendet. Der DHCP-Server ordnet eine willkürliche IP-Adresse aus einem Pool zu, wenn jeder PC bootet. Es ist unmöglich, eine ACL-Regel einem bestimmten PC zuzuordnen, da die IP-Adresse nicht festgelegt ist.
Zusätzlich gibt es keine Position zum Speichern eines Benutzernamens. Die Auflösung der Zugriffssteuerung erfolgt auf einer Host-weisen Basis.
Sidewinder 2.0 speichert eine vollständige Kopie der gesamten Zugriffssteuerungs­ liste in dem Speicher jedes Proxy. Wenn die Anzahl der Regeln groß ist, beein­ trächtigt der verbrauchte Speicher die Leistungsfähigkeit. Zusätzlich gibt es keine Unterstützung zum Aktivieren von Regeln während bestimmter Tageszeiten oder während bestimmter Wochentage.
Schließlich gibt es keine Möglichkeit, um ein abweichendes Authentifizierungsver­ fahren für eine bestimmte Verbindung festzulegen. Für einen gegebenen Dienst muß das Authentifizierungsverfahren für sämtliche Benutzer und für sämtliche Hosts das gleiche sein.
Was benötigt wird, ist ein verallgemeinertes Sicherheitspolitik-Management-System, welches frei von diesen Beschränkungen arbeiten kann.
Die vorliegende Erfindung ist ein System und ein Verfahren zum Regeln des Flusses der Inter-Netzwerk-Verbindungen durch einen Firewall mit einem Netzwerk- Protokoll-Stack, welcher eine Internet-Protokoll-(IP)-Schicht beinhaltet. Eine Festlegung wird für die Parameter getroffen, welche kennzeichnend für eine Verbindungsanforderung sind, einschließlich eines NetzeIement-Parameter- Kennzeichens dafür, von wo die Verbindungsanforderung kommt. Eine Anfrage wird erzeugt, und eine Festlegung wird getroffen, ob eine mit dieser Anfrage korrespon­ dierende Regel vorhanden ist. Wenn eine mit dieser Anfrage korrespondierende Regel vorhanden ist, wird festgestellt, ob eine Authentifizierung durch diese Regel gefordert ist. Wenn eine Authentifizierung durch die Regel gefordert ist, wird ein Authentifizierungs-Protokoll aktiviert und die Verbindung wird aktiviert, wenn das Authentifizierungs-Protokoll erfolgreich beendet ist.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird ein System und ein Verfahren zum Regulieren des Flusses von Inter-Netzwerk-Verbindungen durch einen Firewall mit einem Netzwerk-Protokoll-Stack angegeben, welcher eine Internet-Protokoll-(IP)-Schicht beinhaltet. Eine Zugriffssteuerungsliste wird aufgebaut, wobei die Zugriffssteuerungsliste mehrere Regeln beinhaltet, wobei jede Regel mehrere Regel-Parameter und den Regel-Parametern zugeordnete Werte beinhaltet. Anfrage-Parameter-Kennzeichen einer Verbindungsanforderung werden bestimmt, wobei die Anfrage-Parameter ein Netzelement-Parameter-Kennzeichen dafür beinhalten, von wo die Verbindungsanforderung kommt, und eine Anfrage wird erzeugt, welche die Anfrage-Parameter auflistet. Die Anfrage wird dann an die Zugriffssteuerungsliste abgegeben und die Feststellung wird getroffen, ob eine dieser Anfrage entsprechende Regel vorhanden ist. Wenn eine Regel vorhanden ist, wird die Feststellung getroffen, ob eine Authentifizierung durch diese Regel gefordert ist, und, wenn die Authentifizierung von dieser Regel gefordert ist, wird ein Authentifizierungs-Protokoll ausgeführt. Wenn das Authentifizierungs-Protokoll erfolgreich beendet ist, ist die Verbindung aktiviert.
Gemäß noch einem weiteren Aspekt der Erfindung wird ein vom Netzwerk getrennter Anwendungsebenen-Gateway-Firewall beschrieben.
In der folgenden detaillierten Beschreibung von beispielhaften Ausführungsformen der Erfindung wird auf die beigefügten Zeichnungen Bezug genommen, welche einen Teil davon bilden, und welche nur als Darstellung bestimmte Ausführungs­ formen gezeigt werden, in welchen die Erfindung ausführbar ist. Es versteht sich, daß andere Ausführungsformen verwendbar sind und Änderungen in der Anordnung vorgenommen werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen.
In den Zeichnungen zeigen gleiche Bezugszeichen gleiche Komponenten in den unterschiedlichen Ansichten. Dabei zeigen:
Fig. 1 ein Funktions-Blockdiagramm einer Ausführungsform eines Anwen­ dungsebenen-Gateway-Firewall gemäß der vorliegenden Erfindung;
Fig. 2 ein Funktions-Blockdiagramm einer Ausführungsform eines von einem Netzwerk getrennten Anwendungs-Ebenen-Gateway-Firewall gemäß der vorliegenden Erfindung;
Fig. 3 ein Blockdiagramm, welches die Wechselwirkung von Vermittlern und Wächtern darstellt, und mit dem Zugriffssteuerungs­ listen-Dämon;
Fig. 4 eine Darstellung der Schritte, die ein Vermittler beim Authentifizieren einer Verbindung durchläuft; und
Fig. 5 eine Darstellung einer Ausführungsform eines Regelsatzes, welcher mit dem Zugriffssteuerungslisten-Dämon in Fig. 3 verwendet werden kann.
In der folgenden detaillierten Beschreibung der bevorzugten Ausführungsform wird auf die beigefügten Zeichnungen Bezug genommen, welche einen Teil hiervon bilden, und in welchen als Darstellung bestimmte bevorzugte Ausführungsformen gezeigt sind, in welchen die Erfindung ausgeführt werden kann. Diese Ausführungs­ formen sind in ausreichenden Einzelheiten beschrieben, um dem Durchschnitts­ fachmann zu ermöglichen, die Erfindung auszuführen, und es versteht sich, daß andere Ausführungsformen anwendbar sind und daß strukturelle, logische, physikalische, architektonische und elektrische Änderungen vorgenommen werden können, ohne vom Geist um Umfang der vorliegenden Erfindung abzuweichen. Die folgende detaillierte Beschreibung wird daher nicht in beschränkendem Sinne angenommen und der Umfang der vorliegenden Erfindung wird nur durch die beigefügten Ansprüche und ihre Äquivalente festgelegt.
Ein Firewall, welcher verwendet werden kann, um den Fluß der Inter-Netzwerk-Ver­ bindungen von einem internen zu einem externen Netzwerk zu regeln, ist in Fig. 1 gezeigt. Der Firewall 10 ist ein Anwendungsebenen-Gateway. Wie oben erwähnt, verwenden die Anwendungsebenen-Gateways Proxies 12, welche in der Anwendungsschicht arbeiten, um Verkehr durch den Firewall zu verarbeiten. Als solche können sie nicht nur den Mitteilungsverkehr, sondern auch den Mitteilungs­ inhalt überprüfen. Zusätzlich bieten sie Authentifizierungs- und Identifizierungs- Dienste, Zugriffssteuerung und Prüfung. Wie in Fig. 1 erkennbar ist, ist der Proxy 12 durch eine Transportschicht 14 und eine Internet-Protokoll-(IP)-Schicht 16 mit einer physikalischen Schicht 18 verbunden. Die physikalische Schicht 18 beinhaltet eine Ethernetverbindung 20 zu einem externen Netzwerk 22 und eine Ethernetver­ bindung 24 zu einem internen Netzwerk 26.
Eine verbesserte Version des in Fig. 1 gezeigten Firewall ist in Fig. 2 gezeigt. In Fig. 2 ist der Firewall 30 aufgeteilt in einen Satz aus zwei unabhängigen Regionen oder Bereichen mit einem Bereichs- und einem Protokoll-Stack, der jedem Bereich zugeordnet ist. Jeder Protokoll-Stack weist seinen eigenen, unabhängigen Satz von Datenstrukturen auf, einschließlich Routing-Informationen und Protokoll-Informatio­ nen. Ein solcher Mechanismus zum Aufteilen eines einzelnen Protokoll-Stack in zwei oder mehr Protokoll-Stacks ist beschrieben bei Dan Thomsen in "Type Enforcement: the new security model", Proceedings: Multimedia: Full-Service Impact on Business, Education, and the Home, SPIE Band 2617, Seite 143, August 1996. Thomsen lehrt, daß Modifikationen an dem Kernel eines Betriebssystems vorgenommen werden können, um einen Typ-Durchsetzungs-Schutz hinzuzufügen. Dieser Typ- Durchsetzungs-Schutz kann dann verwendet werden, um separate Bereiche für internen und externen Netzwerk-Verkehr zu schaffen und durchzusetzen.
Eine Netzwerk-Trennung kann ebenfalls innerhalb eines Firewalls verwendet werden, um getrennte Protokoll-Stacks zu schaffen und zu unterstützen. Bei diesem Ansatz wird ein gegebener Sockel zum Zeitpunkt der Erstellung an einen einzelnen Protokoll-Stack gebunden und es können keine Daten zwischen Protokoll-Stacks 40 ausgetauscht werden, ohne den Proxy-Raum 42 zu durchlaufen. Ein Proxy 50 wirkt daher für Übertragungen zwischen Bereichen als dazwischen geschaltet. Ein böswilliger Angreifer, der die Kontrolle über eine der Regionen erhält, wird deshalb daran gehindert, in der Lage zu sein, Vorgänge zu gefährden, die in anderen Regionen ausgeführt werden.
Eine Netzwerktrennung und ihre Anwendung auf einem Anwendungsebenen-Gateway ist beschrieben in "SYSTEM AND METHOD FOR ACHIEVING NETWORK SEPARATION" von Gooderum et al. (veröffentlichte PCT-Anmeldung Nr. WO 97/29413, veröffentlicht am 14. August 1997). Bei der Netzwerktrennung werden mehrere Bereiche oder Regionen festgelegt. Jeder Bereich beinhaltet einen Protokoll-Stack. Jede der Netzwerk-Schnittstellen ist einem der Bereiche zugeordnet und mehr als eine Netzwerk-Schnittstelle kann einem bestimmten Bereich zugeordnet sein. Vorgänge sind an bestimmte Bereiche gebunden, wenn sie versuchen, auf den Bereichs-Protokoll-Stack zuzugreifen und eine Kommunikation zwischen Vorgängen, die unterschiedlichen Bereichen zugeordnet sind, ist beschränkt.
Eine Netzwerk-Trennung bietet einige signifikante Vorteile beim Implementieren eines Zugriffssteuerungs-Schemas. Eine Schule kann z. B. Studenten-Geräte hinter einem äußeren Internet-Firewall anordnen und das Lehrer-Gerät hinter einem inneren Firewall plazieren (um das Lehrer-Gerät vor den Studenten zu schützen, z. B. so, daß die Studenten nicht die Zensur-Dateien des Lehrers verfälschen). Eine Lösung ist, zwei Firewall-Systeme zu installieren. Eine billigere Lösung ist, einen einzelnen Firewall 30 vorzusehen, der drei Bereiche aufweist: "extern", "Studenten" und "Lehrer", mit ACLs, welche den Fluß von den äußeren Ringen zu den inneren Ringen beschränken. Mit anderen Worten, mehrere Bereiche erlauben geschachtelte Schutzebenen ohne den Aufwand zusätzlicher Firewalls zu erfordern.
Weiterhin kann eine Verschlüsselung mit der Netzwerk-Trennung verwendet werden, um Bereiche in einer Schnittstelle 24 einer einzelnen physikalischen Schicht zu multiplexen. Zum Beispiel können zwei Bereiche einer einzelnen Ethernet-Schnitt­ stellenkarte zugeordnet sein. Jeder Bereich weist seinen eigenen Netzwerk- Protokoll-Stack auf, jeder Stack ist jedoch an die gleiche Schnittstellenkarte angeschlossen. Beim Verschlüsseln eines Kanals bleibt der andere Kanal unver­ schlüsselt und einschließlich der ACL-lnformation, ob eine bestimmte Mitteilung verschlüsselt oder unverschlüsselt ist, ist es für beide Bereiche möglich, die gleiche Ethernet-Karte zu nutzen.
Wie oben angemerkt, ist eine Zugriffssteuerungsliste, oder ACL, eine Liste mit Regeln, die den Fluß von Internet-Verbindungen durch einen Firewall regeln. Diese Regeln steuern, wie Server und Proxies eines Firewalls auf Verbindungsversuche reagieren. Wenn ein Server oder Proxy eine ankommende Verbindung empfängt, führt er eine ACL-Prüfung dieser Verbindung aus.
Eine ACL-Prüfung vergleicht einen der Verbindung zugeordneten Parameter-Satz mit einer Liste von ACL-Regeln. Die Regeln bestimmen, ob die Verbindung zugelassen oder zurückgewiesen wird. Eine Regel kann ebenfalls eine oder mehrere Neben­ wirkungen aufweisen. Eine Nebenwirkung veranlaßt den Proxy, sein Verhalten in irgendeiner Weise zu verändern. Eine bekannte Nebenwirkung ist z. B., die Ziel-IP-Adresse zu einem alternativen Gerät umzuleiten. Zusätzlich zu IP-Verbindungs-Ver­ suchen können ACL-Prüfungen ebenfalls beim Konsol-Login und Login über serielle Anschlüsse ausgeführt werden. Schließlich können ACL-Prüfungen anstelle von IP-Zugriffsgeräten, wie einer Cisco-Box, durch die Verwendung des Industrie­ standard-TACACS + -Protokolls ausgeführt werden.
In einer Ausführungsform wird die ACL verwaltet durch einen acld-Dämon, der in dem Kernel der Firewalls 10 und 30 läuft. Der acld-Dämon empfängt zwei Arten von Anforderungen, eine für Anfragen an die ACL und eine, um sie zu administrie­ ren. In einer solchen Ausführungsform ist die ACL in einer relationalen Datenbank wie der Oracle-Datenbank für einen schnellen Zugriff gespeichert. Durch Verwenden solch einer Datenbank ist die Anfrage-Ausführung asynchron und viele Anfragen können gleichzeitig ausgeführt werden. Zusätzlich sind diese Arten von Daten­ banken so ausgebildet, daß sie lange Listen mit Regeln schnell und effizient manipulieren. Diese Qualitäten stellen sicher, daß eine gegebene Anfrage den Vorgang, der diese Anfrage ausgegeben hat, nicht für eine wahrnehmbare Zeit (< 1-2 Sekunden) aufhängen kann.
Die gegenwärtige Datenbank kann bis zu 100 000 Benutzer und bis zu 10 000 Hosts enthalten, kann aber aufwärts skaliert werden bis zu der Kapazität der darunterliegenden Datenbank-Engine. Die Ergebnisse einer ACL-Prüfung werden abgefangen und erlauben wiederholte Prüfungen, die sehr schnell umlaufen.
Anwendungen auf den Firewalls 10 und 30 können den acld anfordern, um zu bestimmten, ob einem gegebenen Verbindungsversuch erlaubt werden sollte, fortzuschreiten. In einer Ausführungsform wie der in Fig. 3 gezeigten können die Arten von Anwendungen (d. h. "Vermittlern"), die ACL-Anfragen ausführen können, in vier Klassen unterteilt werden:
  • 1) Proxies 50. Diese erlauben Verbindungen, den Firewall 10 oder 30 zu durchlaufen, um Zugriff auf einen entfernten Dienst bereitzustellen. Sie beinhalten tnauthp (authentifizierter Telnet Proxy), pftp (FTP-Proxy), httpp (HTTP-Proxy) und tcpgsp (TCP Generic Service Proxy).
  • 2) Server 52. Diese bieten einen Dienst in dem Firewall selbst. Sie beinhalten ftpd und httpd.
  • 3) Login-Vermittler 54. Ein Login-Vermittler 54 ist ein Programm in dem Firewall, das eine Unix-Shell erzeugen kann. Er wird nicht als ein Server betrachtet, da es keine IP-Verbindungen empfangen kann. Ein Beispiel ist /usr/bin/login, wenn es zum Erzeugen einer Wählverbindungs-Sitzung oder einer Konsol-Sitzung in dem Firewall 10 oder 30 verwendet wird. Ein anderes Beispiel ist der Befehl srole.
  • 4) Netzwerk-Zugriff-Server (NAS) 56. Ein NAS 56 ist ein Fern-IP-Zugriffsgerät, typisch eine Wählverbindungs-Box, die von solchen Unternehmen wie Cisco oder Bridge hergestellt wird. Der NAS bietet gewöhnlich einen Telnet- Wählverbindungs-Dienst und kann ebenso einen SLIP- oder PPP-Dienst bereitstellen.
Proxies 50, Server 52, Login-Vermittler 54 und NAS 56 führen Anfragen an den acld 60 aus, um zu bestimmen, ob einem gegebenen Verbindungsversuch erlaubt werden soll, fortzuschreiten. Sämtliche Vermittler mit Ausnahme des NAS 56 führen ihre Anfragen direkt aus. Der NAS 56 muß über einen Hilfs-Dämon kommunizieren, der typisch ein Industrie-Standardprotokoll wie RADIUS oder TACACS+ verwendet, da er entfernt ist. Der Hilfs-Dämon (z. B. tacradd 62) wiederum leitet die Anfrage zu dem lokalen acld 60 weiter.
Als Nebenwirkung der Anfrage teilt der acld 60 dem Vermittler mit, ob eine Authentifizierung erforderlich ist. Wenn keine Authentifizierung erforderlich ist, wird die Verbindung sofort fortgesetzt. Anderenfalls stellt der acld 60 (als weitere Nebenwirkung) eine Liste zugelassener Authentifizierungsverfahren bereit, aus welcher der Benutzer wählen kann. Der Vermittler kann ein Auswahlmenü darstellen oder einfach per Vorauswahl das erste Authentifizierungsverfahren aufgreifen. Typische Authentifizierungsverfahren beinhalten klare Paßworte SNK DSS, SDI SecurID, LOCKout DES und LOCKout FORTEZZA. In einer Ausführungsform variiert die Liste zugelassener Authentifizierungsverfahren abhängig von dem Host-Namen, dem Benutzer-Namen, der Tageszeit oder jeder Kombination davon.
In der in Fig. 3 gezeigten Ausführungsform wird eine Authentifizierung gegen­ wärtig durch einen besonderen Server ausgeführt, der als Wächter bezeichnet wird. Der Vermittler spricht den Wächter an, um die Authentifizierung auszuführen. In einer Ausführungsform ist jedem Authentifizierungsverfahren ein Wächter zugeordnet. Der Wächter 64 kann z. B. der SNK-DSS-Wächter sein, der Wächter 66 kann der LOCKout DES-Wächter sein und der Wächter 68 kann der LOCKout FORTEZZA-Wächter sein. Ein Wächter ist ein Vorgang, welcher ein Authentifizie­ rungsverfahren ausführt. In einer Ausführungsform weisen alle Wächter eine gemeinsame Standard-Authentifizierungs-Schnittstelle auf, die zum Austausch mit den Vermittlern verwendet wird. Durch Verwenden dieser Wächter-Struktur kann ein einzelner Vermittler auf alle verfügbaren Authentifikationsverfahren durch einfaches Ansprechen des geeigneten Wächters zugreifen. Es gibt keine direkte Kommunikation zwischen dem Wächter und dem acld.
In einer Ausführungsform arbeitet der Proxy-Vermittler 50 innerhalb der Anwen­ dungsschicht zum Verarbeiten von zwischen internen und externen Netzwerken übertragenen Mitteilungen. Der gesamte Netzwerk-zu-Netzwerk-Verkehr muß einen der Proxies innerhalb der Anwendungsschicht durchlaufen, bevor ihm der Durchgang durch Netzwerke erlaubt wird. Eine von dem externen Netzwerk 22 eintreffende Mitteilung wird in der IP-Schicht 16 geprüft und eine Sicherheits- Zuordnungs-Datenbank (SADB) wird abgefragt, um zu bestimmen, ob die Quell- Adresse und SPI einer bestimmten Sicherheitszuordnung (SA) zugeordnet sind. In einer Ausführungsform wird eine SADB-Masterkopie im dauerhaften Speicher in der Anwendungsschicht erhalten, während eine Kopie der SADB in einem flüchtigen Speicher innerhalb des Kernel erhalten wird. Wenn die Mitteilung verschlüsselt werden soll, wird die Mitteilung basierend auf dem Algorithmus und dem Schlüssel entschlüsselt, der der bestimmten SA zugeordnet ist, und die Mitteilung wird aufwärts durch eine Transportschicht zu dem Proxy 50 übertragen. Der Proxy 50 prüft die Quell- und Ziel-Adressen und die Art des gewünschten Dienstes und entscheidet, ob die Authentifizierung des Senders anerkannt wird. Wenn ja, löst der Proxy 50 ein Authentifizierungs-Protokoll aus. Das Protokoll kann so einfach sein, daß es einen Benutzernamen und Paßwort erfordert, oder es kann einen Anforderungs/Antwort-Authentifizierungs-Vorgang beinhalten. Der Proxy 50 prüft ebenfalls, ob die ankommende Mitteilung verschlüsselt ist oder nicht und kann daran entscheiden, ob eine bestimmte Art von Authentifizierung erforderlich ist. Im Telnet kann z. B. eine Benutzername/Paßwort-Authentifizierung ausreichend sein für eine FFE-Verbindung, während die Sicherheitspolitik vorschreiben kann, daß ein stringenteres Anforderungs/Antwort-Protokoll für unverschlüsselte Verbindungen erforderlich ist. In diesem Fall ist der Proxy 50 ein Telnet-Proxy und legt sein Authentifizierungs-Protokoll zugrunde, gleich, ob die Verbindung verschlüsselt ist oder nicht.
Da IPSEC innerhalb der IP-Schicht 16 ausgeführt wird, gibt es kein Bedarf für Host- Firewalls, um ihre Anwendungen zu aktualisieren. Benutzer, bei denen IPSEC bereits auf ihren eigenen Host-Maschinen verfügbar ist, müssen jedoch anfordern, daß der Firewall-Administrator SA's in der SADB für ihren Verkehr einstellt.
Der Systemadministrator ist verantwortlich für das Erzeugen des ACL-Regelsatzes. Der ACL-Regelsatz ist eine Reflexion der Sicherheitspolitik des Administrators. Der Administrator muß die folgenden Fragen beantworten, bevor er den Regelsatz schafft:
  • 1) Wo sind die Grenzen der Sicherheitsbereiche?
  • 2) Welchen Sicherheitsbereichen soll es erlaubt sein, Verbindungen in andere Sicherheitsbereiche auszulösen?
  • 3) Welchen Arten von Informationen soll es erlaubt sein, zwischen den Sicherheitsbereichen zu fließen?
  • 4) Sollen auf dem Host-Namen, dem Benutzer-Namen, der Tageszeit oder einer Kombination davon basierende Verbindungen zugelassen werden?
  • 5) Welche Arten von Benutzer-Authentifizierung, wenn überhaupt, soll erforderlich sein, um in einen Sicherheitsbereich hineinzugelangen?
In der bevorzugten Ausführungsform kann der ACL-Regelsatz von dem Administra­ tor unter Verwendung entweder einer graphischen Benutzeroberfläche, GUI, oder einer Befehlszeilen-Schnittstelle modifiziert werden. Veränderungen in dem ACL- Regelsatz werden in der internen Datenbank gespeichert. Um das Auftreten von Übergangszuständen zu verhindern, welche die Sicherheitspolitik schwächen können, wird die Datenbank während Perioden, in welchen der Administrator mehr als die Aktualisierung einer Regel vornimmt, verriegelt (dies ist insbesondere wesentlich, wenn die gesamte Datenbank von einer Diskette oder einem Band erneut geladen wird).
In einer Ausführungsform ist die Datenbank unter Verwendung entweder von Faircom's C-Tree- oder Just Logic's SQL-Database-Manager in SQL implementiert. In einer weiteren Ausführungsform ist der acld 60 an eine externe, kommerzielle Client/Server-SQL-Datenbank-Engine, wie Oracle, angeschlossen. Dies gibt dem Kunden zusätzliche Flexibilität beim Verwalten des Regelsatzes.
In einer Ausführungsform werden nicht-zeitkritische Teile des ACL-Steuerungs- und Administrations-Codes in Python geschrieben. Zeitkritische Teile werden in C codiert.
Erzeugen einer Anfrage
Zum Ausführen einer ACL-Prüfung sammelt der Vermittler Informationen über die Art der Verbindung. Diese Informationen beinhalten die Quellen- und Ziel-IP-Adresse. Der Vermittler plaziert diese Information in einer Anfrageliste. Die Anfrageliste enthält sämtliche relevanten Informationen, die zum Ausführen der ACL-Prüfung benötigt werden. Der Vermittler überträgt dann die Anfrageliste zu dem acld 60 und der acld 60 sucht nach einer Regel, welche mit der Anfrageliste übereinstimmt und gibt eine Antwortliste zurück. Die Antwortliste beinhaltet entweder "Zulassen" oder "Zurückweisen" zum Zeigen, ob die Verbindung zugelassen oder zurückgewiesen werden soll. Andere Werte in der Antwortliste sind Nebenwirkungen, welche das Verhalten des Vermittlers verändern.
In einer Ausführungsform enthält die Anfrageliste folgende Informationselemente:
  • - Die Quellen-IP-Adresse, wenn anwendbar.
  • - Die Ziel-IP-Adresse, wenn anwendbar.
  • - Der Quellen-Sicherheitsbereich.
  • - Der Ziel-Sicherheitsbereich.
  • - Das Netzwerk-Protokoll (TCP oder UDP), wenn anwendbar.
  • - Die Art des Vermittlers (Proxy, Server, Login oder NAS).
  • - Die Art der von der Verbindung verwendeten IP-Verschlüsselung, wenn überhaupt.
  • - Der Name des Benutzers (wenn bekannt).
  • - Der Name des vom Benutzer selektierten Wächters (wenn bekannt).
Diese Information wird von dem acld 60 verwendet, um eine Regel zu suchen, die "am besten" mit der Anfrage übereinstimmt.
Regel-Vorrang
Allgemein werden Regeln mit bestimmten Werten für einen Anfrage-Parameter gegenüber Regeln mit einem Wildcard(Joker)-Parameter bevorzugt. Zum Beispiel wird eine Regel, die sagt, Benutzer = "alan" gegenüber einer Regel bevorzugt, die sagt, Benutzer = * (wobei * ein Wildcard-Zeichen ist). Manchmal ist es jedoch schwer, zu entscheiden, welche Regel die beste ist. Zum Beispiel kann eine Regel sagen, Host= "t-bone", Benutzer= *, während eine andere Regel sagen kann, Host = *, Benutzer= "alan". Welche Regel ist in diesem Fall die "beste"? Die Antwort ist "es kommt darauf an". Der System-Administrator muß entscheiden, was wichtiger ist: Hosts oder Benutzer, und die Sicherheitspolitik dementsprechend in die ACL einbetten.
In einer Ausführungsform werden die ACL-Regeln in sequentieller Folge geprüft. Die erste Regel, welche mit der Anfrage übereinstimmt, wird gewählt. Wenn der Administrator eine neue Regel schafft, schlägt in einer solchen Ausführungsform die acld-Schnittstelle eine Position in dem Regelsatz basierend auf einem vor­ bestimmten Vorrangschema vor. Die Position der Regel ist das einzige Kriterium zum Bestimmen, ob die Regel selektiert wird oder nicht. Der Administrator kann die vorgeschlagene Position überschreiben, wenn er oder sie das entscheidet und die Schnittstelle führt eine Plausibilitätsprüfung aus und warnt den Administrator, wenn die Position einer Regel offensichtlich falsch ist.
Es sei beispielhaft angenommen, daß zwei Regeln "alle_zurückweisen" und "alan_zu­ lassen" vorhanden sind:
In diesem Beispiel zeigt die acld-Schnittstelle eine Warnung, daß die zweite Regel (alan_zulassen) niemals mit einer Anfrage übereinstimmt, da die erste Regel (alle zurückweisen) eine Wildcard für den Benutzernamen aufweist.
Es ist offensichtlich, daß andere Vorrang-Schemata verwendet werden können, einschließlich Schemata, welche einen höheren Sicherheitswert bei dem Host als dem Benutzer zuordnen, und umgekehrt.
Sobald eine Regel selektiert ist, empfängt der Vermittler eine Antwortliste. Die Antwort kann die Verbindung zulassen oder zurückweisen (wenn der Vermittler ein Flag setzt, wird eine ausführliche Erklärung gesendet, welche erläutert, warum die Verbindung zugelassen oder zurückgewiesen wird). Für jede Regel in dem Regelsatz gibt die Antwort eine Zeichenfolge zurück, welche das Ergebnis des Vergleiches mit der Anfrageliste erläutert. Wenn die Regel mit der Anfrage (nicht) übereinstimmt, gibt sie eine Zeichenfolge zurück, die erläutert, warum (nicht).
Die Antwort kann eine Authentifizierung anfordern. Wenn die Authentifizierung angefordert wird, beinhaltet die Antwort eine Liste zugelassener Wächter. Der Vermittler kann ein Menü von Authentifizierungsverfahrens-Auswahlen für den Benutzer darstellen oder einfach den ersten Wächter als die Vorauswahl heraus­ greifen.
Die Antwort kann dem Vermittler mitteilen, die Ziel-IP-Adresse zu einem anderen Gerät umzuleiten. Dies ist nur bei Proxies 50 anwendbar.
Die Antwort kann dem Vermittler mitteilen, die Ziel-Anschlußnummer zu einem anderen Anschluß umzuleiten. Dies ist nur bei Proxies 50 anwendbar.
In einer Ausführungsform weist jede Regel einen Namen auf und die Antwort gibt den Namen der Regel, welche mit der Anfrage übereinstimmt, zurück. Dies ist hilfreich zum Lösen von Problemen in dem Regelsatz. In einer weiteren Aus­ führungsform gibt die Antwort die Position der Regel in dem Regelsatz zurück. Auch dies ist hilfreich zur Problemlösung.
Die Antwort kann zusätzliche Nebenwirkungen bieten, die einmalig für den Dienst sind. Für einen FTP-Dienst bestimmen sie z. B., ob GET oder PUT-Vorgänge zugelassen sind. Für einen HTTP-Dienst bestimmen sie, welche Arten von URLs von dem HTTP-Proxy blockiert werden.
Die Antwort kann ein Ablaufdatum für das Ergebnis dieser Anfrage beinhalten. Dies wird intern zum Zwischenspeichern verwendet. Wenn eine doppelte Anfrage von dem gleichen Vermittler ausgeführt wird, bevor die Zeit abgelaufen ist, wird die zwischengespeicherte Antwort zurückgegeben.
Der Vermittler soll die Werte in der Antwortliste prüfen und in geeigneter Weise mit ihnen arbeiten. Obwohl es nicht streng gefordert ist, dies zu tun, wird von dem Vermittler erwartet, die Ergebnisse der Anfrage aufzubewahren.
ACL-Prüf-Verfahren
Die in der Ausführung einer ACL-Prüfung folgenden Schritte sind in Fig. 4 gezeigt. In Fig. 4 beginnt der Ablauf bei 100, wo ein Vermittler eine optionale Anfangs- ACL-Prüfung ausführen kann, wenn eine Verbindung erstmalig erfaßt wird. Die meisten Vermittler führen eine Anfangs-ACL-Prüfung aus, wenn eine Verbindung erstmalig erfaßt wird. Der Grund ist, daß Verbindungen von einigen Hosts stets unzulässig sind. In diesem Fall soll die Verbindung ohne weiteres zurückgewiesen werden. Für die meisten Proxies und Server selektiert der Netzwerk-Dienste- Wächter (NSS) 70 die Anfangs-Verbindung.
Anmerkung: Wenn der Vermittler nicht in der Lage ist, die Authentifizierung auszuführen (z. B. Gopher oder WAIS) soll der NSS 70 den selektierten Wächter auf "keinen" einstellen, bevor er die Anfangs-Prüfung ausführt. Dies vermeidet eine potentielle Ungewißheit, die durch eine vorläufige Prüfung eines unbekannten Benutzernamens (später erläutert) geschaffen wird.
Einige Vermittler, wie httpd, warten direkt auf Verbindungen und sind nicht von dem NSS abhängig. Diese Vermittler müssen die Anfangsprüfungen selbst ausführen.
Wenn die Antwort auf diese Anfangsprüfung "Zurückweisen" sagt, wird die Verbindung an diesem Punkt geschlossen und es findet keine weitere Kom­ munikation statt. Wenn die Anfangsprüfung "Zulassen" sagt, kann der Vermittler zu dem Schritt 102 fortschreiten. Wie nachfolgend erkennbar ist, bedeutet "Zulassen" tatsächlich "vielleicht", bis weitere Informationen über den Benutzer erhalten werden.
Wenn die Antwort auf die Anfangsprüfung sagt "Zulassen", prüft der Vermittler bei 102 die Antwort, um zu erkennen, ob sie eine Authentifizierung des Benutzers erfordert. Es ist anzumerken, daß, wenn der Vermittler durch den NSS 70 vorausgewählt wurde, der Vermittler eine zweite Prüfung ausführen muß, um die ACL-Informationen zu erhalten, da der NSS 70 die ACL-Informationen nicht zu dem Vermittler weitergibt.
Wenn die ACL-Antwort keine Authentifizierung erfordert, wird das ACL-Prüfver­ fahren beendet und der Vermittler kann zu 104 fortschreiten, um die Verbindung zu öffnen. Es ist anzumerken, daß einige Server, wie ftpd, stets eine Authentifizie­ rung erfordern.
Wenn jedoch die ACL-Antwort eine Authentifizierung erfordert, schreitet der Vermittler fort zu 106 und fragt nach dem Benutzernamen. Es ist anzumerken, daß einige Dienste wie Gopher und WAIS keine Einrichtung zum Erfragen eines Benutzernamens bereitstellen. In diesem Fall muß der acld die Verbindung bei der Anfangs-ACL-Prüfung zurückweisen (da der NSS 70 den Wächter-Namen auf "keinen" einstellt).
In einer Ausführungsform wird ein "magisches Fenster" außerhalb des regulären Dienstes geöffnet, um Dienste wie Gopher und WAIS zu authentifizieren. In einer solchen Ausführungsform öffnet eine erfolgreiche Authentifizierung ein Zeitfenster zu diesen Diensten, um einen Zugriff zu erlauben.
Die Abfrage eines Benutzernamens soll einen Weg beinhalten, um den Namen des Wächters anzugeben. Zum Beispiel:
login: alan
login: alan: securid
login: alan: snk
login: alan: lockout
login: alan: fortezza
login: alan: password.
Sobald der Vermittler den Benutzernamen kennt, wechselt er zu 108 und führt eine zweite ACL-Prüfung aus. Die Anfrage-Parameter in der zweiten Prüfung beinhalten die gleichen Parameter wie die erste Prüfung und zusätzlich den Namen des Benutzers. Sie beinhalten ebenfalls den Namen des selektierten Wächters (wenn der Benutzer einen angibt).
Wenn die Antwort auf die zweite Prüfung "Zurückweisen" sagt, wechselt der Vermittler zu 110 und wirft die Verbindung ab. Der Vermittler kann jedoch zuerst ein Dummy-Paßwort/Abfrage-Prompt ausgeben, um einen Informationsverlust zu vermeiden.
Wenn die Antwort der Prüfung "Zulassen" sagt, beinhalten die Antwort-Parameter eine Liste zugelassener Wächter für diesen Benutzer. Der Vermittler stellt sicher, daß der von dem Benutzer selektierte Wächter in der Liste der zugelassenen Wächter ist (wenn der Vermittler den Namen des selektierten Wächters zu dem acld 60 weiterleitet, wird diese Prüfung durch den acld 60 automatisch ausgeführt).
Wenn der Benutzer nicht einen Wächter selektiert, greift der Vermittler den ersten Wächter in der Liste zugelassener Wächter heraus und schreitet fort zu 112, um den Benutzer zu authentifizieren. An diesem Punkt führt der Vermittler ACL- Prüfungen aus. (In einer Ausführungsform wird ein Menü verfügbarer Wächter für den Benutzer angezeigt und der Benutzer selektiert einen dieser Wächter aus der Liste der verfügbaren Wächter. In solch einer Ausführungsform werden jedoch sämtliche Wächter gelistet, auch solche, die nicht tatsächlich anwendbar sind, um ein Informationsverlust zu vermeiden.)
Bei 112 authentifiziert der Vermittler die Verbindung mit dem selektierten Wächter. Der Vermittler spricht den selektierten Wächter an und führt die Authentifikation aus. Dies kann eine Abfrage/Antwort-Sequenz enthalten. Es ist anzumerken, daß, wenn der Benutzer seinen/ihren Login-Namen ändert, während er/sie sich mit dem Wächter unterhält, der Vermittler die ACL mit dem neuen Benutzernamen erneut prüfen muß.
Eine Prüfung der Ergebnisse der Authentifizierung wird bei 114 vorgenommen und, wenn bei 114 der Benutzer die Authentifizierungs-Prüfung durchläuft, geht der Vermittler über zu 104. Wenn jedoch der Benutzer die Authentifizierungs-Prüfung nicht besteht, geht der Vermittler zu 110 über und wirft die Verbindung ab.
Zeit-Intervalle
In einer Ausführungsform können ACL-Regeln konfiguriert werden, um ein Zeitintervall zu bestimmen. Wenn eine Verbindung aktiv ist, wenn das Zeitintervall abläuft, teilt der acld 60 jedem Vermittler mit, die Verbindung erneut zu prüfen. In einer Ausführungsform empfängt jeder Vermittler eine asynchrone Mitteilung in dem acld-Sockel, wenn ein Zeitintervall abläuft. Die Mitteilung teilt dem Vermittler mit, seine sämtlichen aktiven Verbindungen erneut zu prüfen.
Der Vermittler behält eine Sicherheitskopie der Anfrageliste für jede aktive Verbindung. Wenn er die Mitteilung empfängt, daß ein Zeitintervall abgelaufen ist, führt er erneut ACL-Prüfungen für sämtliche gespeicherten Anfragelisten aus (der Vermittler benötigt keine erneute Authentifizierung). Wenn die Antwort auf eine ACL-Prüfung "zurückweisen" ist, wirft der Vermittler die entsprechende Verbindung ab. Wenn der Vermittler freundlich sein will, kann er eine Warn-Mitteilung an den Benutzer senden und eine zusätzliche Periode gewähren, um dem Benutzer zu erlauben, aufzuräumen.
Eine gleiche asynchrone Mitteilung wird von dem acld 60 zu sämtlichen Vermittlern gesendet, wenn der Administrator den ACL-Regelsatz verändert.
Die ACL-Regel
Das Herz des ACL-Systems ist die Regel. Die ACL-Datenbank beinhaltet eine Liste mit Regeln, bezeichnet als Regelsatz. Ein repräsentativer Regelsatz 200 ist in Fig. 5 gezeigt, wobei eine Regel 202 drei Arten von Attributen enthält: Überein­ stimmungskriterien 204, die Wirkung 206 und die Nebenwirkungen 208.
Wenn ein Vermittler eine Anfrageliste überträgt, werden die Parameter in der Anfrageliste mit den Übereinstimmungskriterien 204 in jeder Regel 202.1 bis 202.N verglichen. Die erste Regel 202, welche mit sämtlichen der Kriterien übereinstimmt, wird zurückgegeben (ausgenommen eine vorläufige Prüfung, welche mit mehr als einer Regel übereinstimmen kann).
In einer Ausführungsform sind die Übereinstimmungskriterien einer Regel wie folgt:
  • 1) Das Quellen-Netzelement. Ein Netzelement ist ein Host-Name, ein Teilnetz- Name, ein Bereichs-Name, eine IP-Adresse oder ein Netzgruppen-Name (eine Netzgruppe enthält Netzelemente). Bei Verzicht wird die Quelle als Wildcard angegeben. Durch Verwenden der Netzelemente und Netzgruppen ist es möglich, Gruppen von Geräten symbolisch zu benennen, und ebenfalls Gruppen von Gruppen zu schaffen (d. h., die Netzgruppen).
  • 2) Das Ziel-Netzelement. Bei Verzicht wird das Ziel mit einer Wildcard ausgedrückt.
  • 3) Der Quellen-Sicherheitsbereich. Bei Verzicht wird der Bereich mit einer Wildcard ausgedrückt.
  • 4) Der Ziel-Sicherheitsbereich. Bei Verzicht wird der Bereich mit einer Wildcard ausgedrückt.
  • 5) Eine Liste von Vermittler-Arten: Proxy, Server, Login und/oder NAS.
  • 6) Eine Liste mit Dienst-Namen. Ein Dienst-Name ist gewöhnlich ein in /etc/ser­ vices gefundener Name wie "ftp" oder "http". Für einen Login-Vermittler kann der Dienst-Name ebenfalls einer der folgenden sein:
    • a) Konsole: ein Login von der System-Konsole.
    • b) Wählen: ein Login von einem seriellen Wählverbindungs- Anschluß.
    • c) Telnet: ein Login von einer Telnet-Verbindung.
  • 7) Das Netzwerkprotokoll: entweder TCP oder UDP. Die Vorauswahl ist TCP.
  • 8) Die minimal geforderte Verschlüsselung. Dies kann entweder keine oder IPSEC sein. Die Verbindung wird zurückgewiesen, wenn die in der Anfrage angegebene Verschlüsselungsebene nicht so streng ist, wie diejenige der Regel.
  • 9) Der Name der Benutzergruppe. Bei Verzicht wird die Benutzergruppe mit einer Wildcard ausgedrückt.
  • 10) Eine Liste zugelassener Wächter. Die Liste zugelassener Wächter wird zu dem Vermittler zurückgegeben, um dem Benutzer ein Auswahlmenü darzustellen. Wenn der Benutzer einen Wächter festlegt, muß er mit einem in dieser Liste übereinstimmen. Anderenfalls wird die Verbindung zurückge­ wiesen.
  • 11) Eine Liste von Zeitintervallen, während welcher diese Regel aktiv ist.
  • 12) Ein "Übergehen"-Kennzeichen. Wenn dieses Kennzeichen gesetzt ist, wird die Regel übergangen. Dies kann verwendet werden, um eine Regel vorübergehend zu deaktivieren, ohne sie zu löschen.
Andere Ausführungsformen beinhalten Teilsätze der obigen Übereinstimmungs­ kriterien. In einer Ausführungsform ist es möglich, einer Zusammenstellung von Benutzern, Hosts oder Diensten einen symbolischen Namen zuzuordnen. Dies wird oben für Gruppen von Geräten und für Gruppen von Benutzern dargestellt, kann aber ebenfalls verwende werden, um Dienste darzustellen. Durch Ausführung dessen ist erreichbar, daß mit einer einzelnen ACL-Regel 202 die Majorität der Benutzer, Dienste und Geräte abgedeckt wird. Eine einzelne Regel 202 kann z. B. aufweisen: Dienste = Standard_Dienste und Benutzer = Internet_Benutzer. Um Dienste für einen neuen Mitarbeiter Joe Smith freizugeben, muß einfach sein Name zu der Liste der Benutzer der Internet_Benutzer-Gruppe hinzugefügt werden; eine neue Regel 202 ist nicht erforderlich.
Das wichtigste Attribut einer Regel ist die Wirkung. In einer Ausführungsform kann jede Wirkung einen von zwei Werten annehmen: Zulassen oder Zurückweisen. Zulassen bedeutet, die ankommende Verbindung anzunehmen, Zurückweisen bedeutet, die ankommende Verbindung zurückzuweisen.
In einer weiteren Ausführungsform kann jede Wirkung einen von drei Werten annehmen: Zulassen, Zurückweisen oder Vorauswahl. In dieser Ausführungsform hat Vorauswahl eine besondere Wirkung, welche die Möglichkeit bietet, gemeinsa­ me Nebenwirkungen für mehrere Regeln festzulegen; beim Empfang einer Anfrage sammelt der acld 60 sämtliche Nebenwirkungen von den übereinstimmenden Vorauswahl-Regeln und verknüpft sie mit der letzten Zulassen- oder Zurückweisen- Regel. Das Verknüpfen findet in der sequentiellen Reihenfolge der Regeln statt, wobei die Nebenwirkungen der letzten Regel die Nebenwirkungen der vorausge­ wählten Regel(n) überschreiben.
Die Nebenwirkungen einer Antwort können das Verhalten des Vermittlers in irgendeiner Weise verändern. Die Antwort kann z. B. eine Authentifizierung erfordern. Jede Antwort enthält ein Kennzeichen, welches anzeigt, ob eine Authentifizierung erforderlich ist. Wenn dieses gesetzt ist, muß der Vermittler den Benutzer authentifizieren. Er muß einen Benutzernamen abfragen, dann einen Wächter auswählen und den ausgewählten Wächter ansprechen.
Wenn eine Authentifizierung erforderlich ist, beinhaltet die Antwort eine Liste zugelassener Wächter. Die Liste zugelassener Wächter erlaubt dem Vermittler, dem Benutzer ein Auswahlmenü darzustellen. Wenn der Benutzer einen Wächter festlegt, muß der Vermittler verifizieren, daß er mit einem der Auswahl in dieser Liste übereinstimmt.
Die Antwort kann dem Vermittler mitteilen, die Ziel-IP-Adresse zu einer anderen Maschine umzuleiten. Dies ist nur für Proxies 50 anwendbar.
Die Antwort kann dem Vermittler mitteilen, die Ziel-Anschlußnummer zu einem anderen Anschluß umzuleiten. Dies ist nur für Proxies 50 anwendbar.
Die Antwort kann zusätzliche Nebenwirkungen angeben, die einmalig für diesen Dienst sind. Diese werden Dienst-Parameter genannt. Für FTP geben die Dienst­ parameter z. B. an, ob GET oder PUT-Vorgänge zugelassen sind. Für HTTP geben die Dienst-Parameter die Arten von URLs an, die blockiert sind.
Wie vorstehend erwähnt, ist in einer Ausführungsform die ACL in einer relationalen Datenbank implementiert. Solch eine Implementation hat den Vorteil, daß die ACL erweiterbar ist; neue Parameter können festgelegt werden, ohne den gesamten Regelsatz neu aufzubauen.
Um ein besseres Verständnis zu geben, wie eine ACL-Prüfung arbeitet, zeigt dieser Abschnitt einige Beispiele. Es beginnt mit einem einfachen Beispiel, einem Regelsatz, der nur eine Regel enthält:
Name: telnet_out
Position: 1
Wirkung: zulassen
Übergehen: nein
Quelle: *
Ziel: *
Quell-Sicherheitsbereich: intern
Ziel-Sicherheitsbereich: extern
Vermittler: [Proxy]
Dienste: [Telnet]
Protokoll: tcp
Benutzergruppe: *
Zeit-Intervalle: []
Umleitungs-Host:
Umleitungs-Anschluß:
Auth. erforderlich: nein
Min-Verschlüsselung: keine
Alarm: keiner
Zugelassene Auth.-Verfahren: []
Dienst-Parameter: {}
Anmerkungen: '' ''.
Die Regel erlaubt jedem in dem internen Sicherheitsbereich plazierten Client, eine Verbindung zu jedem in dem externen Sicherheitsbereich plazierten Telnet-Server aufzubauen. Es ist keine Authentifizierung erforderlich.
Es folgt ein Regelsatz mit zwei Regeln:
Die erste Regel (ftp_out) erlaubt jedem Client in dem internen Sicherheitsbereich, auf jeden FTP-Server in dem externen Sicherheitsbereich zuzugreifen. Die zweite Regel unterstützt einen anonymen FTP-Server in dem lokalen Firewall (lokal bezeichnet stets den lokalen Firewall, ungeachtet des Sicherheitsbereiches). Ein Zugriff auf den Server ist beschränkt auf die Zeit außerhalb der Bürostunden und nur GET ist zugelassen.
Es folgt ein Regelsatz für eine Organisation mit reisenden Verkäufern. Einige Verkäufer haben Laptops mit IP-Verschlüsselungssoftware.
Eine einfache Authentifizierung ist zugelassen, wenn eine IP-Verschlüsselung verwendet wird, da die klaren Paßworte (pas) durch Paket-"Schnüffler" nicht beobachtet werden können.
Unten ist ein Beispiel dafür gegeben, warum einige ACL-Prüfungen nicht vollständig aufgelöst werden können, bis der Benutzername bekannt ist.
Wenn die Anfangs-ACL-Prüfung bei 102 ausgeführt ist, ist der Name des Benutzers noch nicht bekannt. Daher können potentiell alle drei Regeln zutreffen. In einer Situation wie dieser führt der acld 60 eine vorläufige Prüfung aus. Eine vorläufige Prüfung gibt "Zulassen" zurück, wenn wenigstens eine Regel vorhanden ist, welche die Verbindung zulassen kann, sofern nicht eine Zurückweisungs-Regel vorhanden ist, welche die Verbindung bestimmt zurückweist (wenn z. B. die erste Regel eine Wildcard für die Benutzergruppe anstelle von "anderer" hat, weist der acld 60 die Verbindung sofort zurück).
Eine vorläufige Prüfung kann mit mehr als einer "Zulassen"-Regel übereinstimmen. Wenn dies auftritt, faßt der acld 60 sämtliche zugelassenen Wächter zusammen. Für das obige Beispiel gibt er die folgenden Nebenwirkungen zurück:
Auth.-erforderlich: ja
Zugelassenes Auth.-Verfahren: [securid, lockout] beide
SecurID und LOCKout werden als zugelassene Wächter zurückgegeben. Allgemein gibt der acld 60 die Gesamtheit sämtlicher zugelassenen Wächter für alle vorläufig übereinstimmenden Regeln zurück. In der gezeigten Ausführungsform ist der voreingestellte Wächter SecurID, da Verkauf vor Eng kommt.
Wenn der Vermittler seine zweite Prüfung bei 108 einschließlich des Benutzerna­ mens ausführt, stimmt sie mit exakt einer Regel überein und gibt nur den einen Wächter-Namen zurück. Dies wird als letzte Prüfung bezeichnet. Die Kenntnis des Benutzernamens ist entscheidend zum Selektieren der letzten Regel. Wenn der Vermittler nicht in der Lage ist, die Authentifizierung auszuführen (z. B. Gopher oder WAIS), setzt er den selektierten Wächter auf "keiner". Der "keiner" benannte Wächter ist ein besonderer, da er den acld 60 zwingt, eine letzte Prüfung anstelle einer vorläufigen Prüfung auszuführen.
Zusammengefaßt ergeben sich zwei Wege, um den acld 60 zu zwingen, eine letzte Prüfung auszuführen:
  • 1. Festlegen des Benutzernamens in der Anfrage-Liste; oder
  • 2. Einstellen des ausgewählten Wächters auf "keiner" in der Anfrage- Liste.
Anderenfalls führt der acld 60 eine vorläufige Prüfung aus und kann mit mehr als einer Regel übereinstimmen. Der Vermittler ist verantwortlich für das Ausführen einer letzten Prüfung der Verbindung, sobald der Benutzername bekannt ist. Ein Nichtausführen einer letzten Prüfung ist ein schwerer Fehler.
In einer Ausführungsform beinhaltet der Regelsatz 200 einen URL-Filter-Parameter. Einer der in einer ACL-Anfrage enthaltenen Werte kann dann die URL sein, auf die der Benutzer zugreifen möchte. Der Regelsatz 200 beinhaltet dann Einträge für bestimmte URLs oder Gruppen von URLs, die ausgeschlossen oder eingeschränkt sind. In einer Ausführungsform kann ein Bewertungsdienst wie WebTrackTM, verfügbar von Webster Network StrategiesTM, verwendet werden, um URLs zu filtern. In WebTrackTM werden URLs in Kategorien gruppiert, basierend auf Haß-Sprüchen, Sexualität zeigendes Material, etc. Der ACL-Regelsatz kann dann verwendet werden, um den Zugriff auf Kategorien von URLs zu beschränken oder zu unterbinden.
Zusammenfassend wird während der Dauer einer TCP-Verbindung die ACL- Datenbank zu vier unterschiedlichen Zeitpunkten angefragt:
  • 1) Durch den NSS 70, wenn die TCP-Verbindung zuerst versucht wird. Der Name des Benutzers ist an diesem Punkt unbekannt, so daß der acld 60 eine "vorläufige Prüfung" ausführt. Eine vorläufige Prüfung wird fortgesetzt, wenn eine Zulassen-Regel gefunden wird, die wenigstens einen Benutzer akzeptiert, dem Quelle, Ziel, Dienst, etc. zugeordnet sind. Sie versagt, wenn eine Zurückweisen-Regel mit einer Wildcard-Benutzergruppe gefunden wird.
  • 2) Durch den Vermittler (Proxy 50, Server 52 oder Login-Vermittler 54) wenn bekannt sein muß, ob ein Benutzername abzufragen ist oder nicht. Einige Proxies fragen stets einen Benutzernamen ab und müssen daher diese Prüfung nicht ausführen.
  • 3) Durch den Vermittler, nachdem er den Benutzernamen und (optional) den Namen des Wächters erhält. An diesem Punkt verfügt der Vermittler über alle notwendigen Informationen, um eine letzte Prüfung auszuführen. Als Nebenwirkung gibt der acld 60 eine Liste zugelassener Wächter zurück, von denen der erste der vorausgewählte Wächter ist. Der Vermittler verifiziert, daß der selektierte Wächter in der Liste der zugelassenen Wächter enthalten ist. Der Vermittler führt dann die Authentifizierung mit dem selektierten Wächter aus. Es ist anzumerken, daß die Liste leer sein kann, was bedeutet, daß keine Authentifizierung erforderlich ist.
  • 4) Durch den Vermittler, wenn der acld 60 eine asynchrone Mitteilung sendet, die anzeigt, daß der ACL-Regelsatz 200 durch den Administrator verändert wurde. Der Vermittler prüft sämtliche seiner aktiven Verbindungen neu. Eine Mitteilung wird ebenfalls gesendet, wenn eine zeitbasierte Regel eine Zeitgrenze überschreitet.
Obwohl bestimmte Ausführungsformen hier dargestellt und beschrieben sind, ist es für den Durchschnittsfachmann erkennbar, daß jede Anordnung, welche vorgesehen ist, um das gleiche Ziel zu verwirklichen, für die bestimmte, gezeigte Ausführungs­ form einsetzbar ist. Diese Anmeldung ist vorgesehen, um sämtliche Anpassungen und Variationen der vorliegenden Erfindung abzudecken. Daher ist vorgesehen, daß diese Erfindung nur durch die Ansprüche und deren Äquivalente beschränkt ist.

Claims (19)

1. Verfahren zum Regeln des Flusses von Inter-Netzwerk-Verbindungen durch einen Firewall mit einem Netzwerk-Protokoll-Stack, wobei der Netzwerk-Protokoll- Stack eine Internet-Protokoll-(IP)-Schicht beinhaltet, wobei das Verfahren die Schritte umfaßt:
Bestimmen von Parametern, welche kennzeichnend für eine Verbindungsanforde­ rung sind, wobei die Parameter ein Netzelement-Parameter-Kennzeichen dafür beinhalten, wo die Verbindungsanforderung herkommt;
Erzeugen einer Anfrage, wobei der Schritt des Erzeugens einer Anfrage den Schritt beinhaltet, Parameter zu einer Anfrage-Liste hinzuzufügen;
Bestimmen, ob eine der Anfrage entsprechende Regel vorhanden ist;
wenn eine Regel vorhanden ist, bestimmen, ob eine Authentifizierung durch diese Regel gefordert ist;
wenn eine Authentifizierung durch diese Regel gefordert ist, Ausführen eines Authentifizierungs-Protokolls; und
Aktivieren der Verbindung, wenn das Authentifizierungs-Protokoll erfolgreich beendet wird.
2. Verfahren nach Anspruch 1, bei welchem der Schritt des Ausführens eines Authentifizierungs-Protokolls den Schritt beinhaltet, einen Wächter zu rufen.
3. Verfahren nach Anspruch 1, bei welchem der Schritt des Bestimmens, ob eine der Anfrage entsprechende Regel vorhanden ist, den Schritt beinhaltet, eine relationale Datenbank mit der Anfrage anzusprechen.
4. Verfahren nach Anspruch 1, bei welchem der Netzelement-Parameter eine Gruppe von Host-Namen identifiziert.
5. Verfahren nach Anspruch 1, bei welchem der Netzelement-Parameter eine Gruppe von IP-Adressen identifiziert.
6. Verfahren nach Anspruch 1, bei welchem der Netzelement-Parameter eine Gruppe von Teilnetzen identifiziert.
7. Verfahren nach Anspruch 1, bei welchem der Netzelement-Parameter eine Gruppe von Netzgruppen identifiziert, wobei eine Netzgruppe eine Zusammenfassung von Netzelementen ist.
8. Verfahren nach Anspruch 1, bei welchem der Netzelement-Parameter eine Gruppe von DNS-Bereichen identifiziert.
9. Verfahren zum Regulieren des Flusses von Inter-Netzwerk-Verbindungen durch einen Firewall mit einem Netzwerk-Protokoll-Stack, wobei der Netzwerk- Protokoll-Stack eine Internet-Protokoll-(IP)-Schicht beinhaltet, wobei das Verfahren die Schritte umfaßt:
Bilden einer Zugriffssteuerungsliste, wobei die Zugriffssteuerungsliste mehrere Regeln beinhaltet, wobei jede Regel mehrere Regel-Parameter und Werte beinhaltet, welche den Regel-Parametern zugeordnet sind;
Bestimmen von Anfrage-Parameter-Kennzeichen einer Verbindungs-Anforderung, wobei die Anfrage-Parameter ein Netzelement-Parameter-Kennzeichen dafür beinhalten, von wo die Verbindungsanforderung kommt;
Erzeugen einer Anfrage, wobei der Schritt des Erzeugens einer Anfrage den Schritt beinhaltet, die Anfrage-Parameter zu einer Anfrage-Liste hinzuzufügen;
Abgeben der Anfrage zu der Zugriffssteuerungsliste, wobei der Schritt des Abgebens den Schritt beinhaltet, zu bestimmen, ob eine der Anfrage entsprechende Regel vorhanden ist;
wenn eine Regel vorhanden ist, bestimmen, ob eine Authentifizierung durch die Regel gefordert ist;
wenn eine Authentifizierung durch die Regel gefordert ist, Ausführen eines Authentifizierungs-Protokolls; und
Aktivieren der Verbindung, wenn das Authentifizierungs-Protokoll vollständig beendet ist.
10. Verfahren nach Anspruch 9, bei welchem das Verfahren weiterhin die Schritte umfaßt:
Überwachen der Tageszeit; und
Schließen von Verbindungen zu vorbestimmten Tageszeiten.
11. Verfahren nach Anspruch 9, bei welchem die Anfrage-Parameter einen URL-Parameter beinhalten.
12. Firewall (30), mit:
einer ersten Kommunikationsschnittstelle (20);
einer zweiten Kommunikationsschnittstelle (24);
einem ersten Netzwerk-Protokoll-Stack (40.1), welcher an die erste Kommunika­ tionsschnittstelle angeschlossen ist, wobei der erste Netzwerk-Protokoll-Stack eine Internet-Protokoll-(IP)-Schicht (16.1) und eine Transportschicht (14.1) beinhaltet;
einem zweiten Netzwerk-Protokoll-Stack (40.2), welcher an die zweite Kom­ munikationsschnittstelle angeschlossen ist, wobei der zweite Netzwerk-Protokoll- Stack eine Internet-Protokoll-(IP)-Schicht (16.2) und eine Transportschicht (14.2) beinhaltet;
einem Zugriffssteuerungslisten-Vorgang (60), wobei der Zugriffssteuerungslisten- Vorgang mehrere Regeln anspricht, welche eine Sicherheitspolitik implementieren; und
einem Vermittler (50), welcher an den Zugriffssteuerungslisten-Vorgang und an die Transportschichten der ersten und zweiten Netzwerk-Protokoll-Stacks ange­ schlossen ist, wobei der Vermittler Mitteilungen von der Transportschicht empfängt, dem Zugriffssteuerungslisten-Vorgang eine Anfrage sendet, welche auf der Mitteilung zugeordneten Parametern basiert, und ein Authentifizierungs-Protokoll ausführt, welches von dem Zugriffssteuerungslisten-Vorgang als Ergebnis der Anfrage selektiert wird.
13. Firewall nach Anspruch 12, bei welchem der erste Netzwerk-Protokoll-Stack (40.1) und die erste Kom­ munikations-Schnittstelle (20) einem ersten Bereich zugeordnet sind und der zweite Netzwerk-Protokoll-Stack (40.2) und die zweite Kommunikations-Schnittstelle (24) einem zweiten Bereich zugeordnet sind.
14. Firewall nach Anspruch 13, bei welchem die Anfrage ein Bereichs-Symbol beinhaltet, welches den ersten Bereich identifiziert, und wobei das von dem Zugriffssteuerungslisten-Vorgang selektierte Authentifizierungs-Protokoll als eine Funktion des Bereichs-Symbols variiert.
15. Firewall nach Anspruch 12, bei welchem die Anfrage ein Sender-Symbol beinhaltet, welches den Sender der Mitteilung identifiziert, und wobei das durch den Zugriffssteuerungslisten-Vorgang selektierte Authentifizierungs-Protokoll als eine Funktion des Sender-Symbols variiert.
16. Firewall nach Anspruch 12, bei welchem der erste Netzwerk-Protokoll-Stack (40.1) einen Entschlüsselungsvor­ gang beinhaltet, welcher in der IP-Schicht (16.1) arbeitet, der verschlüsselte Mitteilungen entschlüsselt, welche durch die erste Kommunikations-Schnittstelle (20) empfangen werden, und die entschlüsselten Mitteilungen über die Transport­ schicht (14.1) zu dem Vermittler weiterleitet.
17. Firewall nach Anspruch 12, bei welchem das von dem Zugriffssteuerungslisten-Vorgang selektierte Au­ thentifizierungs-Protokoll als eine Funktion, ob die Mitteilung verschlüsselt war oder nicht, wenn sie von IP-Schicht empfangen wurde, variiert.
18. Computerprogramm, mit:
einem Computer-nutzbaren Medium mit Computer-lesbarem Programmcode, der darauf vorhanden ist, wobei der computerlesbare Programmcode, wenn er ausgeführt wird, auf dem Computer ein Verfahren zum Regulieren des Flusses von Inter-Netzwerk-Verbindungen durch einen Firewall mit einem Netzwerk-Protokoll- Stack implementiert, wobei der Netzwerk-Protokoll-Stack eine Internet-Protokoll-(IP)-Schicht beinhaltet, wobei das Verfahren die Schritte umfaßt:
Bestimmen von Parameter-Kennzeichen einer Verbindungsanforderung, wobei die Parameter ein Netzelement-Parameter-Kennzeichen dafür beinhalten, von wo die Verbindungsanforderung kommt;
Erzeugen einer Anfrage, wobei der Schritt des Erzeugens einer Anfrage den Schritt beinhaltet, die Parameter zu einer Anfrage-Liste hinzuzufügen;
Bestimmen, ob eine der Anfrage entsprechende Regel vorhanden ist;
wenn eine Regel vorhanden ist, Bestimmen, ob von der Regel eine Authentifizierung gefordert ist;
wenn eine Authentifizierung von der Regel gefordert ist, Ausführen eines Authentifizierungs-Protokolls; und
Aktivieren der Verbindung, wenn das Authentifizierungs-Protokoll erfolgreich beendet ist.
19. Computerprogramm nach Anspruch 18, bei welchem der Schritt des Ausführens eines Authentifizierungs-Protokolls den Schritt beinhaltet, einen Wächter zu rufen.
DE1997141239 1996-09-18 1997-09-18 Verallgemeinertes Sicherheitspolitik-Management-System und Verfahren Expired - Fee Related DE19741239C2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/715,343 US5983350A (en) 1996-09-18 1996-09-18 Secure firewall supporting different levels of authentication based on address or encryption status
US08/715,668 US5950195A (en) 1996-09-18 1996-09-18 Generalized security policy management system and method

Publications (2)

Publication Number Publication Date
DE19741239A1 true DE19741239A1 (de) 1998-05-07
DE19741239C2 DE19741239C2 (de) 2000-08-24

Family

ID=27109321

Family Applications (1)

Application Number Title Priority Date Filing Date
DE1997141239 Expired - Fee Related DE19741239C2 (de) 1996-09-18 1997-09-18 Verallgemeinertes Sicherheitspolitik-Management-System und Verfahren

Country Status (2)

Country Link
DE (1) DE19741239C2 (de)
GB (2) GB2317539B (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10031896C1 (de) * 2000-06-30 2002-01-24 Chris Holland Netzverknüpfungseinrichtung und -verfahren sowie Daten-Telekommunikationsanordnung

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7580919B1 (en) 1997-03-10 2009-08-25 Sonicwall, Inc. Query interface to policy server
US7272625B1 (en) 1997-03-10 2007-09-18 Sonicwall, Inc. Generalized policy server
US6408336B1 (en) 1997-03-10 2002-06-18 David S. Schneider Distributed administration of access to information
US7821926B2 (en) 1997-03-10 2010-10-26 Sonicwall, Inc. Generalized policy server
US8914410B2 (en) 1999-02-16 2014-12-16 Sonicwall, Inc. Query interface to policy server
US7912856B2 (en) 1998-06-29 2011-03-22 Sonicwall, Inc. Adaptive encryption
US6104716A (en) * 1997-03-28 2000-08-15 International Business Machines Corporation Method and apparatus for lightweight secure communication tunneling over the internet
SE512440C2 (sv) * 1998-05-27 2000-03-20 Telia Ab Metod för säker telefoni med mobilitet i ett tele- och datakommunikationssystem som innefattar ett IP-nät
EP1105809A4 (de) * 1998-06-29 2005-10-05 Internet Dynamics Inc Generalisierter verfahrens-server
US6502135B1 (en) 1998-10-30 2002-12-31 Science Applications International Corporation Agile network protocol for secure communications with assured system availability
US7418504B2 (en) 1998-10-30 2008-08-26 Virnetx, Inc. Agile network protocol for secure communications using secure domain names
US7188180B2 (en) 1998-10-30 2007-03-06 Vimetx, Inc. Method for establishing secure communication link between computers of virtual private network
CA2349519C (en) 1998-10-30 2011-08-09 Science Applications International Corporation An agile network protocol for secure communications with assured system availability
US10511573B2 (en) 1998-10-30 2019-12-17 Virnetx, Inc. Agile network protocol for secure communications using secure domain names
US6615357B1 (en) * 1999-01-29 2003-09-02 International Business Machines Corporation System and method for network address translation integration with IP security
FI106594B (fi) * 1999-02-10 2001-02-28 Intrasecure Networks Tietoliikennemenetelmä viestin lähettämiseksi palomuurin läpi
GB2353676A (en) * 1999-08-17 2001-02-28 Hewlett Packard Co Robust encryption and decryption of packetised data transferred across communications networks
GB0003018D0 (en) * 2000-02-11 2000-03-29 Secr Defence Computer security system
EP2323335B1 (de) * 2000-04-26 2020-04-08 VirnetX Inc. Gesicherteskommunikationsprotokol
US6996842B2 (en) * 2001-01-30 2006-02-07 Intel Corporation Processing internet protocol security traffic
US7315537B2 (en) 2001-09-25 2008-01-01 Siemens Aktiengesellschaft Method for the transmission of data in a packet-oriented data network
US20030084319A1 (en) * 2001-10-31 2003-05-01 Tarquini Richard Paul Node, method and computer readable medium for inserting an intrusion prevention system into a network stack
US7185365B2 (en) * 2002-03-27 2007-02-27 Intel Corporation Security enabled network access control
CN100512278C (zh) * 2003-11-13 2009-07-08 中兴通讯股份有限公司 一种把ipsec嵌入到ip协议栈的方法
CN100414929C (zh) * 2005-03-15 2008-08-27 华为技术有限公司 一种移动互联网协议网络中的报文传送方法
US10708230B2 (en) * 2018-06-14 2020-07-07 Servicenow, Inc. Systems and methods for firewall configuration using block lists

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5864683A (en) * 1994-10-12 1999-01-26 Secure Computing Corporartion System for providing secure internetwork by connecting type enforcing secure computers to external network for limiting access to data based on user and process access rights
US5757924A (en) * 1995-09-18 1998-05-26 Digital Secured Networks Techolognies, Inc. Network security device which performs MAC address translation without affecting the IP address
US5602918A (en) * 1995-12-22 1997-02-11 Virtual Open Network Environment Corp. Application level security system and method
WO1997026734A1 (en) * 1996-01-16 1997-07-24 Raptor Systems, Inc. Transferring encrypted packets over a public network
AU1748797A (en) * 1996-01-16 1997-08-11 Raptor Systems, Inc. Key management for network communication
WO1997026731A1 (en) * 1996-01-16 1997-07-24 Raptor Systems, Inc. Data encryption/decryption for network communication
US5918018A (en) * 1996-02-09 1999-06-29 Secure Computing Corporation System and method for achieving network separation

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10031896C1 (de) * 2000-06-30 2002-01-24 Chris Holland Netzverknüpfungseinrichtung und -verfahren sowie Daten-Telekommunikationsanordnung

Also Published As

Publication number Publication date
DE19741239C2 (de) 2000-08-24
GB9719818D0 (en) 1997-11-19
GB2317792A (en) 1998-04-01
GB9719816D0 (en) 1997-11-19
GB2317539A (en) 1998-03-25
GB2317792B (en) 2001-03-28
GB2317539B (en) 2001-03-28

Similar Documents

Publication Publication Date Title
DE19741239C2 (de) Verallgemeinertes Sicherheitspolitik-Management-System und Verfahren
DE60213391T2 (de) Persönlicher Firewall mit Positionsdetektion
DE69825801T2 (de) Vorrichtung und Verfahren zur Ermöglichung gleichranginger Zugangskontrolle in einem Netz
DE60121483T2 (de) Sicherheitkommunikationsverfahren, System und Vorrichtung welche erlauben den Sicherheitstyp zu wechseln
DE60216218T2 (de) Persönlicher Firewall mit Platzabhängiger Funktionalität
DE60019997T2 (de) Ggesicherte Kommunikation mit mobilen Rechnern
DE69720351T2 (de) Verfahren und Vorrichtung zum Begrenzen des Zugriffes an privater Information in Domänennamensystemen durch Umleitung von Abfrageanforderungen
DE60111089T2 (de) Verfahren und Vorrichtung zum Analysieren von einer oder mehrerer Firewalls
DE69929268T2 (de) Verfahren und System zur Überwachung und Steuerung der Netzzugriffe
DE10249428B4 (de) Verfahren zum Definieren der Sicherheitsanfälligkeiten eines Computersystems
DE60102934T2 (de) Verfahren und system für sitzungsbasierte berechtigung und zugangskontrolle für vernetzte anwendungsobjekte
DE69836271T2 (de) Mehrstufiges firewall-system
US5950195A (en) Generalized security policy management system and method
DE10197063B4 (de) Verfahren und Einrichtung zum Verhindern eines unberechtigen Zugriffs durch ein Netzwerkgerät
DE69835416T2 (de) Verfahren zur sicheren ausführung eines fernmeldebefehls
DE10296804B4 (de) Verfahren und System zum Autorisieren des Zugriffs auf Betriebsmittel auf einem Server
DE69921455T2 (de) System und verfahren zur zugriffssteuerung auf gespeicherte dokumente
DE10052312B4 (de) Automatische Sperre gegen unberechtigten Zugriff im Internet (Snoop Avoider) für virtuelle private Netze
DE69832946T2 (de) Verteiltes System und Verfahren zur Steuerung des Zugriffs auf Netzmittel und Ereignismeldungen
DE19740547B4 (de) Vorrichtung und Verfahren zum Sicherstellen sicherer Kommunikation zwischen einer anfordernden Entität und einer bedienenden Entität
DE10249427A1 (de) System und Verfahren zum Definieren des Sicherheitszustands eines Computersystems
WO2020229537A1 (de) Verfahren zum selektiven ausführen eines containers und netzwerkanordnung
WO2003025758A2 (de) Vorrichtung und verfahren zur etablierung einer sicherheitspolitik in einem verteilten system
DE60302003T2 (de) Handhabung von zusammenhängenden Verbindungen in einer Firewall
DE602004005181T2 (de) Beschränkung von datentransfers auf ein lokales netzwerk

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
D2 Grant after examination
8364 No opposition during term of opposition
R082 Change of representative

Representative=s name: EISENFUEHR SPEISER PATENTANWAELTE RECHTSANWAEL, DE

R081 Change of applicant/patentee

Owner name: MCAFEE, INC., SANTA CLARA, US

Free format text: FORMER OWNER: SECURE COMPUTING CORP., ROSEVILLE, MINN., US

Effective date: 20140925

R082 Change of representative

Representative=s name: EISENFUEHR SPEISER PATENTANWAELTE RECHTSANWAEL, DE

Effective date: 20140925

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee