-
Gebiet der
Erfindung
-
Die
Erfindung bezieht sich auf die Überwachung
eines Stroms eines Datenflusses, der zwischen einem Klienten und
einem Server-System fließt.
Die Erfindung ist insbesondere gedacht für Kommunikationsprotokolle,
die Repräsentationsdaten
führen,
die über
eine verbindungsorientierte Protokollschicht geführt werden.
-
Hintergrund
der Erfindung
-
Wegen
der jüngsten
weiteren Zunahme der Internet-Verwendung ist die Anzahl potentieller
Ziele für Angriffe
gegen Computersysteme durch böswillige
Anwender sprunghaft angestiegen. Um mögliche Sicherheitslücken in
den zahlreichen an weltweite Kommunikationsnetze angeschlossenen
Systemen zu finden, haben die Teilnehmer, die in vernetzte Computer
einbrechen möchten,
ein gutes Arsenal leistungsfähiger
Hilfsmittel entwickelt, die systematisch Betriebsmittel finden können, die
für verdächtige Aktivitäten verfügbar sind. Zusammen
mit der Sachkenntnis der Eindringlinge hat sich dies als äußerst schädlich für die Netzsicherheit erwiesen,
auch wenn es zum Beginn eines schnellen Wachstums der Netzsicherheitsindustrie
geführt
hat, die gegen die unberechtigte Verwendung und gegen das Abhören vernetzter
Computer ankämpft.
-
In 1A ist
ein typisches Beispiel eines Netzes gezeigt, in dem Eindringvorgänge und
andere unerwünschte
Angriffe stattfinden können.
Das Kernnetz ist in diesem Fall das Internet 102, mit dem
der durch den Klienten 101 bezeichnete Hacker verbunden.
Auf einer Seite des Internet befindet sich ein Gateway-Element 103,
das ein privates Netz 104 wie etwa ein Unternehmens-LAN
oder Intranet von dem Internet trennt. Die mit dem Intranet verbundenen
Hosts wie etwa der Server 105 sind die potentiellen Ziele
von Eindringvorgängen oder
Angriffen.
-
Besonders
viele Dienstplattformen, die auf an das Internet angeschlossenen
Servern ausgeführt
werden, haben ihre Anfälligkeit
für böswillige
Anwender gezeigt. Als ein Beispiel werden viele im World Wide Web (WWW)
verwendeten E-Commerce-Systeme angegriffen. Dies verursacht sowohl
finanzielle Schäden
als auch schwere Probleme hinsichtlich des Missbrauchs vertraulicher
Anwenderdaten wie etwa Kreditkartennummern oder anderer sensibler
Informationen.
-
Falls
die Dienstplattform keine hohen Sicherheitsstandards erfüllt, kann
sie wahrscheinlich missbraucht werden, um die Steuerung über das
System zu erhalten, um einige geheime Informationen zu erlangen oder
zumindest zu veranlassen, dass das System abstürzt. Als ein Beispiel ist zu
erwarten, dass feste Parameter in einer von einem Klienten kommenden
Abfragezeichenfolge die gleichen Werte wie in dem ursprünglichen
von dem Server an den Klienten gesendeten Hypertext Transport Protocol-Fluss
(HTTP-Fluss) haben. Falls ein Angreifer die Parameterwerte auf unerwartete
Weise ändert,
kann das System beginnen, sich auf merkwürdige Weise zu verhalten. Das
Gleiche betrifft die Längen
der Parameter, die der Klient zurückgibt.
-
Web-Server
können
so genannte Verzeichnisdurchquerungsfehler aufweisen, die bekanntlich
ausgenutzt werden können,
um eine nicht für
die Öffentlichkeit
bestimmte Datei wiederzugewinnen. Ein Beispiel hierfür ist eine
HTTP-Anfrage, die in das Adressfenster eines Web-Browsers eingetippt
wird, wie etwa http://www.sitename.net/../../../etc/password. Der
Server kann als Reaktion die Kennwortdatei eines UNIX-Systems zurückgeben,
wobei die Datei leicht für
künftige
Entschlüsselungszwecke
verfügbar
ist.
-
Weitere
häufige
Ziele von Angriffen sind verschiedene Common Gateway Interface-Binärdateien (CGI-Binärdateien)
und Skripte, die Hypertext Markup Language Formulare (HTML-Formulare)
verarbeiten. CGI ist der Standard für die Umgebung, die ein Server
an im WWW verwendete Skripte weiterreicht. Viele CGI-Skripte haben
Fehler, die Verzeichnisdurchquerungsfehler oder etwas anderes wie
etwa Shell-bezogene Fehler oder Pufferüberlauffehler sein können.
-
Maßnahmen,
die entwickelt werden, um die Sicherheitsanfälligkeiten oder Ausbeutungen
in Servern anzugehen und/oder wahrzunehmen, sind z. B. Sicherheits-Scanner
und Network Intrusion Detection Systems (NIDS). Unter Verwendung
einiger verfügbarer
Sicherheits-Scanner ist es möglich,
eine Anfälligkeitsanalyse des
Servers auszuführen,
die die anfälligen
Teile eines Dienstes erfassen kann. In der Analyse werden die CGI-Skripte
in dem System auf bekannte Anfälligkeiten
durchsucht. Ein NIDS ist ein stiller Lauscher, der den in dem Netz
strömenden
Verkehr überwacht
und einen Alarm erzeugt, wenn in dem Verkehr etwas Verdächtiges
erfasst wird. Das NIDS sucht nach regulären Ausdrücken, wobei die Gleichheitsprüfung üblicherweise
für Ethernet-Rahmen, IP-Pakete
oder für
den TCP-Fluss erfolgt. Bei der Suche nach verdächtigen Parameterwerten können Fingerabdrücke bekannter
schädlicher
HTTP-Anfragen verwendet werden.
-
Da
eine TCP-Verbindung typisch ein HTTP-Anfrage-Antwort-Paar führt, werden
HTTP-Anfragen und -Antworten typisch als entsprechende Paare geprüft. Das
Problem bei der Verwendung von Fingerabdrücken ist, dass sie selbst für geringfügige Änderungen
des verwendeten Anfragemusters anfällig sind. Außerdem ist das
Verfahren rechentechnisch belastend, da bei der Analyse jeder einzelnen
Anfrage mehrere Fingerabdrücke
benötigt
werden. Dies hat eine nachteilige Wirkung auf die Gesamtleistungsfähigkeit
des Systems.
-
Eine
weitere Sicherheitslösung
ist ein HTTP-Proxy, der die Anfrage-Antwort- Paare filtern kann. Leider hat er dieselben
Beschränkungen
wie die anderen oben diskutierten Lösungen. 1B zeigt
ein vereinfachtes Beispiel der allgemeinen Wirkung eines HTTP-Proxy-Gateways 151 des
Standes der Technik. Der Anwenderagent 150, der eine Anfrage
an den Web-Server 152 senden möchte, sendet eine Anfrage an
den Proxy. Der Proxy kann einige Informationen wie etwa statische
Web-Seiten in einen Cache kopieren, um die für den Server durch ankommende
Anfragen verursachte Last zu verringern. Der Anwenderagent wie etwa
ein Web-Browser sendet zuerst ein TCP SYN-Paket 181 an den Proxy, um
eine Verbindung aufzubauen. Falls der Proxy die Verbindung zulässt, antwortet
er, indem er als Reaktion ein TCP SYN + ACK-Paket 182 sendet. Der Anwenderagent
empfängt
dieses und antwortet mit einem TCP ACK-Paket 183 und schließt somit
die TCP-Dreiphasen-Quittungsaustauschprozedur
ab. Von dem IP-Rahmen, auf dem die TCP-Pakete geführt werden, kann die Host-ID
geprüft
werden. Ähnlich
kann von den TCP-Anfangsblöcken
die Klienten-ID überprüft werden;
diese Informationen können
den Ziel- und den Bestimmungsport usw. enthalten. Der Anwenderagent ist
bereit, eine HTTP-Anfrage 184, z. B. eine Anfrage für eine Web-Seite,
die Informationen in einer Präsentationssprache
wie etwa HTML enthält,
zu senden.
-
Der
Proxy öffnet ähnlich eine
TCP-Verbindung zu dem Web-Server, indem er Nachrichten 185–187 sendet,
sofern die Antwort für
die Anfrage nicht in dem Proxy in einen Cache kopiert worden ist,
wie es z. B. der Fall ist, wenn die HTTP-Daten wie etwa der HTML-Inhalt
einige dynamische Teile wie etwa Formulare oder Skripte aufweisen.
Daraufhin sendet der Proxy die HTTP-Anfrage 188 an den Web-Server.
Die Anfrage 188 kann im Wesentlichen ähnlich der Originalanfrage 184 sein.
Der Server antwortet auf die Anfrage, indem er eine HTTP-Antwort 189 an
den Proxy sendet. Daraufhin leitet der Proxy die Antwort als eine
neue HTTP-Antwort 190 an den Anwenderagenten weiter. Der
Anwenderagent kann die TCP-Verbindung schließen, indem er das TCP FIN +
ACK-Paket 191 sendet, für
das der Proxy durch Senden zunächst
eines TCP ACK-Pakets 192 und daraufhin eines TCP FIN +
ACK-Pakets 193 antwortet. Daraufhin schließt der Proxy
die Verbindung zu dem Web-Server, indem er ein TCP FIN + ACK-Paket 194 sendet.
Der Web-Server antwortet, indem er zunächst ein TCP ACK-Paket 195 und
daraufhin ein TCP FIN + ACK-Paket 196 sendet.
-
Das
Dokument WO 0049528 beschreibt ein Verfahren, das für das Sitzungsmanagement über ein
zustandsloses Protokoll wie etwa HTTP gedacht ist. Dieses Verfahren
verwendet wie folgt Fingerabdrücke.
Zunächst
empfängt
das Verfahren eine HTTP-Anfrage 200 und erzeugt durch digitale
Hash-Codierung von
Kennungen, die aus der HTTP-Anfrage erhalten werden, einen Fingerabdruck.
Daraufhin sucht das Verfahren den erzeugten Fingerabdruck in einer
Datenbank. Wenn er gefunden wird, wird ein bestimmter Datenbankeintrag verwendet,
um Anwenderinformationen wiederzugewinnen. Ansonsten wird ein neuer
Eintrag in der Datenbank erzeugt.
-
Für die Erfassung
von Angriffen gegen die in modernen Informationssystemen umfassend
verwendeten dynamischen Seiten sind Fingerabdrücke nicht gut geeignet. Außerdem ist
es möglich,
dass die Verbindung zwischen dem Anwenderagenten und dem HTTP-Proxy
andauert. Das heißt,
dass der Anwenderagent die Verbindung zwischen dem HTTP-Proxy und
dem Anwenderagenten nach Empfang der HTTP-Antwort 190 nicht
schließt,
sondern weitere Anfragen an den Proxy senden kann.
-
Die
Server des Standes der Technik leiden an dem folgenden technischen
Problem. Wenn ein Server eine Antwort von einem Klienten empfängt, sollte
der Server überprüfen, ob
der Inhalt der Antwort des Klienten richtig ist oder nicht. Zum
Beispiel könnte
die Antwort die Sprachauswahl "en" enthalten, die sich
auf Englisch bezieht. Die Sprachauswahl ist richtig, falls die Anfrage,
die der Server an den Klienten gesendet hat, "en" als einen
der so genannten "verfügbaren Zustände" enthält. Das
technische Problem ist, dass der Server die Sprachauswahl nicht
mit Sicherheit überprüfen kann,
da er keine Informationen über
die verfügbaren
Zustände besitzt.
Bei Verwendung der Fingerabdrucktechnik ist die Sprachauswahl "en" richtig, wenn sie
jemand zuvor verwendet hat, d. h., wenn ein bestimmter Fingerabdruck
in der Fingerabdruckdatenbank zu finden ist. Diese Art der Bestimmung
ist unzuverlässig.
-
Keine
der oben beschriebenen Lösungen
des Standes der Technik kann unvorhergesehene Angriffe gegen CGI-Binärdateien
erfassen, die z. B. Formulare oder Skripte nutzen. Außerdem funktionieren
die Lösungen
des Standes der Technik schlecht beim Schutz des Servers vor anwenderinduzierten
Pufferüberläufen von
Feldern statischer Länge
wie etwa den verborgenen Auswahl/Options-Feldern, die in vielen
HTML-Formularen verwendet werden. Mit anderen Worten, die Lösungen des
Standes der Technik schützen
einen Server nicht vor entweder bewusst oder versehentlich vorgenommenen
unerwünschten
Angriffen und Missbrauchsversuchen in Fällen, in denen der Missbrauch
an einem zulässigen
Systemport unter Verwendung formal richtiger Anfragen, jedoch unter
Ausnutzung der Schwäche
des Systems ausgeführt
wird.
-
Zusammenfassung
der Erfindung
-
Die
Aufgabe der vorliegenden Erfindung ist die Schaffung eines Stromüberwachungsmechanismus, der
die Systemsicherheit verbessert. Diese wird unter Verwendung eines
Verfahrens, eines Systems oder eines Computerprogrammprodukts, die
in den unabhängigen
Ansprüchen
beschrieben sind, gelöst.
-
Die
vorliegende Erfindung bezieht sich auf die Überwachung eines Datenflusses,
der von einem Klienten zu einem Server fließt. Der Datenfluss enthält Repräsentationsdaten,
die auf einem verbindungsorientierten Trägerprotokoll geführt werden.
Vorzugsweise nutzen die Repräsentationsdaten
ein anderes Protokoll als das Trägerprotokoll
und können
ein zustandsloses Protokoll sein. In dem Überwachungsprozess wird ein Datenfluss
analysiert, der von dem Server zu dem Klienten fließt, um zumindest
einen Antwort-Deskriptor in dem Datenfluss zu identifizieren. Identifizierte
Antwort-Deskriptoren werden in einem Satz verfügbarer Zustände für den Klienten gespeichert.
Nachfolgend wird ein Datenfluss analysiert, der von dem Klienten
zu dem Server fließt,
um zumindest einen Anfrage-Deskriptor zu identifizieren. Die identifizierten
Anfrage-Deskriptoren werden mit dem Satz verfügbarer Zustände des Klienten verglichen,
wobei als Reaktion auf den Vergleichsschritt ein Überwachungsergebnis
erzeugt wird.
-
In Übereinstimmung
mit einem Aspekt der vorliegenden Erfindung kann die Überwachung
des Weiteren die Ausführung
einer vorbestimmten Tätigkeit
enthalten, die zumindest teilweise auf dem Überwachungsergebnis beruht.
-
In Übereinstimmung
mit einem Aspekt der vorliegenden Erfindung kann die vorbestimmte
Tätigkeit
die Gleichheitsprüfung
des Datenflusses mit bekannten Missbrauchsmustern enthalten, falls
zumindest ein Antwort-Deskriptor nicht mit den im Satz verfügbarer Zustände gespeicherten
Antwort-Deskriptoren übereinstimmt.
-
In Übereinstimmung
mit einem Aspekt der vorliegenden Erfindung kann die vorbestimmte
Tätigkeit das
Zulassen des Durchgangs des Datenflusses, wenn die Anfrage-Deskriptoren
mit den im Satz verfügbarer Zustände gespeicherten
Antwort-Deskriptoren übereinstimmen,
und das Beschränken
des Datenflusses, wenn zumindest ein Antwort-Deskriptor nicht mit
den im Satz verfügbarer
Zustände
gespeicherten Antwort-Deskriptoren übereinstimmt, enthalten.
-
In Übereinstimmung
mit einem Aspekt der vorliegenden Erfindung kann die vorbestimmte
Tätigkeit das
Erzeugen eines Alarms umfassen, der zumindest teilweise anhand des Überwachungsergebnisses
gewählt
wird.
-
In Übereinstimmung
mit einem Aspekt der vorliegenden Erfindung kann in dem Überwachungsprozess eine
Host-Kennung aus dem Trägerprotokollteil
des ersten Datenflusses zwischen dem Klienten und dem Server gespeichert
werden und daraufhin verwendet werden, um den Satz verfügbarer Zustände für den Klienten zu
wählen.
Die Host-Kennung wird zur Identifizierung verfügbarer Zustände für irgendeinen Klienten des
Hosts verwendet.
-
In Übereinstimmung
mit einem weiteren Aspekt der vorliegenden Erfindung kann dies des
Weiteren durch Speichern einer Klientenkennung aus dem ersten Datenfluss
zwischen dem Klienten und dem Server ausgeführt werden. Die gespeicherte
Klientenkennung wird daraufhin verwendet, um den Satz verfügbarer Zustände für den Klienten
zu identifizieren.
-
In Übereinstimmung
mit einem weiteren Aspekt der vorliegenden Erfindung kann die Klientenkennung mit
den gespeicherten Klientenkennungen verglichen werden, um den Satz
verfügbarer
Zustände
für den
Klienten zu wählen.
Falls das Ergebnis des Vergleichs ist, dass die Klientenkennung
nicht mit den gespeicherten Klientenkennungen übereinstimmt, wird der Satz
verfügbarer
Zustände
für den
Klienten aus dem Satz verfügbarer
Zustände
für den
Host gewählt.
-
In Übereinstimmung
mit einem Aspekt der vorliegenden Erfindung enthält in dem Überwachungsprozess das Analysieren
eines Datenflusses, der von dem Server zu dem Klienten fließt, das
Analysieren verschiedener möglicher
Zustände
von Makro- und/oder Formulardefinitionen, die in dem Datenstrom
enthalten sind, um zumindest einen Antwort-Deskriptor zu identifizieren.
-
In Übereinstimmung
mit einem weiteren Aspekt der vorliegenden Erfindung kann das Analysieren
verschiedener möglicher
Zustände
des Weiteren das Ausführen
der Makrodatei in dem System enthalten, um zumindest einen Antwort-Deskriptor
zu identifizieren.
-
Die
vorliegende Erfindung ist besonders gut geeignet für den Schutz
oder für
die Stabilisierung von Systemen, die Protokolle wie etwa das HTTP
oder das Wireless Application Protocol (WAP) nutzen, die Repräsentationsdaten
wie etwa die HyperText Markup Language (HTML), die Wireless Markup
Language (WML), die Extensible Markup Language (XML) oder XML-basierte
Repräsentationssprachen
wie etwa WSDL/SOAP (Web Services Description Language/Simple Object
Access Protocol) führen.
Falls der Klient auf unproblematische Weise identifiziert werden
kann, wie es etwa der Fall ist, wenn das TCP als ein Trägerprotokoll
verwendet wird, können
die protokollführenden
Repräsentationsdaten
ein zustandsloses Protokoll sein. Bei Anwendung auf diese Protokolle
können
die verfügbaren
Zustände,
die zuerst aus dem Datenfluss erfasst werden, der von dem Server
zu dem Klienten fließt,
den erforderlichen Anfragen entsprechen. Falls der Datenfluss derart
ist, dass auch komplexere Möglichkeiten
verfügbar
sind, können
einige der verfügbaren
Zustände
im Voraus berechnet und in einer Zustandstabelle gespeichert werden,
die dem Satz verfügbarer
Zustände
entspricht. Somit wird die Analyse im Gegensatz zu der im Stand
der Technik ausgeführten
Anfrage-Antwort-Analyse
an einem Antwort-Anfrage-Paar ausgeführt. Außerdem lehrt die Erfindung
anstelle der Analyse des Standes der Technik eines Anfrage-Antwort-Paars einer einzelnen
Verbindung ein Verfahren der Verwendung von Informationen, die aus
einer Antwort erhalten werden, die in einer TCP-Verbindung übertragen wird, um eine Anfrage
zu analysieren, die in einer anderen TCP-Verbindung übertragen
wird.
-
Um
die Überwachung
des Datenstroms zu erleichtern, löst die erste Anfrage von dem
Klienten zu dem Server in einer Ausführungsform der vorliegenden
Erfindung die Aktualisierung einer Verbindungstabelle aus. Des Weiteren
kann die Verbindungskennung erfasst werden, um die Sitzung zwischen
dem Klienten und dem Server zu identifizieren und somit durch schnellere
Korrelation der Anfrage-Antwort-Paare die Effizienz des Systems
zu verbessern.
-
Die
vorliegende Erfindung kann z. B. in einem NIDS oder in einer Proxy-Firewall
realisiert werden. Somit schafft die Erfindung gegenüber diesen
Systemen des Standes der Technik neue Funktionalität.
-
Kurzbeschreibung
der Zeichnung
-
Die
Erfindung wird näher
beschrieben anhand der Beispiele, die in den 2–6 der
beigefügten Zeichnung
beschrieben sind, in der
-
1A eine
vereinfachte Architektur einer typischen Netzumgebung zeigt, wo
HTTP-Proxies üblicherweise
verwendet werden,
-
1B den
Betrieb eines HTTP-Proxy des Standes der Technik veranschaulicht,
-
2 ein
beispielhafter Funktionsblockschaltplan ist, der zeigt, wie die
vorliegende Erfindung in Anwendung auf einen Datenflussmoderator
arbeitet,
-
3 zeigt,
wie die wie in 2 realisierte vorliegende Erfindung
für HTTP-Verkehr
arbeitet.
-
4 veranschaulicht,
wie der Datenflussmoderator in 2 arbeitet,
wenn ein Datenfluss einer von dem Server zu dem Klienten fließenden Antwort
erfasst wird,
-
5 eine
Funktion des wie in 3 gezeigten ANALYZE RESPONSE-Blocks
ausführlicher
veranschaulicht, wenn er auf einen HTTP-Fluss angewendet wird,
-
6 zeigt,
wie der Datenflussmoderator in 2 arbeiten
kann, wenn die vorliegende Erfindung auf einen HTTP-Fluss angewendet
wird, und
-
7 zeigt,
wie der Satz verfügbarer
Zustände
in 2 für
einen neuen Klienten initialisiert werden kann.
-
Ausführliche
Beschreibung der Erfindung
-
Um
den Betrieb der Erfindung besser zu veranschaulichen, wird die Erfindung
in der folgenden Beschreibung in Verbindung mit einem HTTP-Proxy
beschrieben. Dies soll aber nicht beschränkend sein, da die Erfindung
auch in irgendeiner anderen geeigneten Netzvorrichtung genutzt werden
kann. Die vorliegende Erfindung wird genauer anhand von 2 beschrieben.
Ein Datenfluss, der von einem Klienten, d. h. von dem Anwenderagenten 150,
kommt, wird zunächst
in einem Empfangsblock 202 empfangen. Der Datenfluss kann irgendeinem
im Internet fließenden
Verkehr entsprechen, wobei im Weiteren aber angenommen wird, dass
zumindest ein Teil von ihm einem Protokoll entspricht, das zum Führen von
Repräsentationsdaten
verwendet wird, und dass er einem zustandslosen Protokollformat
wie etwa HTTP sein kann. Der Empfangsblock kann sich in diesem Beispiel
in einem Proxy befinden. Der Datenfluss kann aus Paketen bestehen,
die in dem Empfangsblock gesammelt werden können, um eine vollständige Anfrage
zu bilden. Wenn der Empfangsblock TCP/IP-Pakete empfängt, kann
er aus den Anfangsblockteilen der Pakete Ziel- und Host-Informationen
wie etwa die Netzadressen und Ports extrahieren. Allgemein wird
das HTTP über
der TCP-Schicht
geführt,
wobei Anfragen oder Antworten diese Informationen nicht mehr enthalten.
-
Der
Empfangsblock 202 leitet den empfangenen Datenstrom zusammen
mit den Host-Informationen zu dem Steuerblock 204 weiter.
Der Steuerblock führt
eine Pufferung der empfangenen Daten aus, wobei aber interessanter
ist, dass er die Daten dann, wenn sie für einen HTTP-Port in dem Server 152 bestimmt
sind, zusammen mit den Host-Informationen zu einem Überprüfungsblock 206 weiterleitet.
Außerdem
empfängt
der Steuerblock validierte Daten von dem Überprüfungsblock, die einem Weiterleitungsblock 208 zuzuführen sind. Der
Weiterleitungsblock leitet den Datenfluss in einer oben beschriebenen
Weise zu dem Server weiter.
-
Der Überprüfungsblock
weist einen Host-ID-Erkennungsblock 220 auf, der zusammen
mit einem Klientenerkennungsblock 222 prüfen kann,
ob der Klient zuvor mit dem Server kommuniziert hat. Der Host-Erkennungsblock
prüft anhand
der Host-Informationen, ob er den Ursprungshost identifizieren kann.
Der Klientenerkennungsblock prüft,
ob er irgendeine Klientenkennung in dem Datenfluss identifizieren
kann. Diese Klientenkennungen enthalten Identifizierungs-Cookies
oder andere Informationen, die durch einen Systemadministrator vorkonfiguriert
worden sind. Falls solche vorkonfigurierten Informationen nicht
vorhanden sind, können
andere Identifizierungsinformationen wie etwa der HTTP-Anwenderagenten-Anfangsblockwert
verwendet werden. Die Klientenkennung kann zum Identifizieren des
Klienten verwendet werden. Des Weiteren kann der Klientenidentifizierungsblock
einen Teil für
die Erkennung weiterer gemeinsamer Parameter enthalten. Gemeinsame
Parameter sind Parameter, die allen von einem Klienten ausgehenden
Verbindungen/Anfragen gemeinsam sind. Solche gemeinsamen Parameter
können
z. B. der HTTP-Host-Anfangsblockwert,
d. h. der Name des Ziel-Servers, und daraufhin einige weitere Cookie-Referenzen
sein.
-
Die
Host-Informationen und Klienteninformationen werden zusammen mit
den erfassten gemeinsamen Parametern in einer Tabelle 250 gespeichert.
Der Anfrage-Parser 232 parst die Anfrage und kann wie im Folgenden
ausführlicher
beschrieben arbeiten. Der Beschränkungsprüfblock 234 verifiziert,
dass die geparsten Parameter in der Anfrage innerhalb der definierten
Beschränkungen
liegen, die aus der Beschränkungstabelle 252 gelesen
werden. Die entsprechenden Erkennungsblöcke 220 und 222 prüfen, ob
die Informationen in der Tabelle 250 vorhanden sind. Falls
der entsprechende Eintrag nicht gefunden wird, leiten sie den Datenfluss
zu einem Fingerabdruck-Gleichheitsprüfungsblock 230 weiter,
der prüft,
ob der HTTP-Datenfluss Teile enthält, die bekannten Angriffsmustern,
d. h. bekannten Fingerabdrücken 253, ähneln. Falls
das Fingerabdruckergebnis negativ ist, d. h., falls kein Angriff
erfasst wird, wird ein neuer Eintrag in der Tabelle 250 vorgenommen.
Auf diese Weise kann zumindest teilweise verifiziert werden, dass
ein neuer Klient keinen Angriff versucht. Im entgegengesetzten Fall
kann der Datenfluss im Speicher in einer Tabelle 254 gespeichert
werden, die ungültige
Parameterwerte enthält,
und daraufhin zu einem Ereignisanalyse- und Ereignisberichtsblock 240 weitergeleitet
werden. Es wird angemerkt, dass der Parse-Schritt und der Beschränkungsprüfschritt
ausgeführt werden
können,
entweder bevor oder nachdem die in den Schritten 220 und 222 ausgeführten Operationen ausgeführt werden,
da es erwünscht
ist, alle Anfragen zu parsen, um sie genauer zu überprüfen. Die Beschränkungstabelle 252 kann
z. B. zulässige
Parameterwertbereiche für
verschiedene CGI-Binärdateien
enthalten. Diese Beschränkungen
können
von jeder CGI-Binärdatei
abhängen,
so dass die in der Beschränkungstabelle 252 beschriebenen
Beschränkungen
für jede
CGI-Binärdatei und
für jedes
Skript getrennt definiert werden können.
-
Daraufhin
werden in dem Deskriptoridentifizierungsblock 226 aus der
geparsten Anfrage die Deskriptoren identifiziert, die den Inhalt
der Anfrage definieren. Die Identifizierung der Deskriptoren wird
im Folgenden anhand von 5 ausführlicher diskutiert. Der Deskriptorverifizierungsblock 224 liest
aus einer Tabelle verfügbarer
Zustände 251,
die Deskriptoren enthält,
d. h., welche Art zulässiger/gültiger Anfragen
von dem Klienten kommen können,
die für
den Klienten verfügbaren
Zustände.
Des Weiteren vergleicht der Deskriptorverifizierungsblock die Deskriptoren
in der Anfrage mit den Deskriptoren in der Tabelle verfügbarer Zustände. Grundsätzlich wird
die Tabelle verfügbarer
Zustände
für jeden
Klienten getrennt erzeugt, wobei sie aber ebenfalls eine Host-gestützte Tabelle
sein könnte,
in der die verfügbaren
Zustände
für verschiedene
Klienten von demselben Host gesammelt werden. Entweder der Anfrage-Parser,
der Deskriptoridentifizierungsblock oder der Deskriptorverifizierungsblock
können
die Funktionalität
besitzen, zumindest einen Teil der Anfrage in ein allgemeineres
Format abzubilden, d. h., Ausdrücke mit
einer Syntax wie etwa %20 können
durch einen Leerraum ersetzt werden usw.
-
In
dem Verifizierungsergebnis-Analyseblock 228 wird festgestellt,
ob irgendwelche ungültigen
Parameterwerte oder Deskriptoren erfasst werden. Der Verifizierungsergebnis-Analyseblock
kann eine Regelbasis aufweisen, auf deren Grundlage der Verifizierungsergebnis-Analyseblock
Nichterfüllungen
der verfügbaren Zustände und/oder
gemeinsamer Beschränkungen
klassifizieren kann. Zumindest die Fälle, für die der Fehler als ernst
oder gefährlich
klassifiziert wird, werden an den Ereignisanalyse- und Ereignisberichtsblock 240 weitergeleitet,
anstatt den Datenfluss an den Weiterleitungsblock 208 zu übergeben,
damit er zu dem Server 152 weitergeleitet wird.
-
Der
Ereignisanalyse- und Ereignisberichtsblock kann die Datei 254 ungültiger Parameterwerte
lesen, die ebenfalls eine Klassifizierung erhalten kann, die durch
den Verifizierungsergebnis-Analyseblock 228 gemäß einer
Regelbasis, falls sie definiert worden ist, hergestellt worden ist.
Der Ereignisanalyse- und Ereignisberichtsblock kann den Datenfluss
als Ganzes sowie ebenfalls mit Informationen von den Host-Kennungen und
Klientenkennungen erhalten. Die Ereignisse werden in der Datei 256 klassifizierter
Ereignisse weiter klassifiziert und gespeichert, wobei diejenigen
Ereignisse, die schwer genug sind, berichtet zu werden, in der Datei 255 berichteter
Ereignisse aufgezeichnet werden, die für Administrationszwecke Mittel
zum visuellen oder hörbaren
Ausgeben eines Ereignisauftrittscodes enthalten kann. Des Weiteren
kann der Ereignisanalyse- und
Ereignisberichtsblock die gesamte Kommunikation dauerhaft als Beweis
aufzeichnen.
-
Der
von dem Server 152 zu dem Anwenderagenten 150 fließende Datenfluss
wird ebenfalls analysiert. Zu diesem Zweck ist es möglich, einen Überprüfungsblock 266 zu
verwenden. Offensichtlich können
die Funktionalitäten
des Untersuchungsblocks 266 in den Untersuchungsblock 206 integriert
sein, der auf diese Weise für
die Überprüfung von
Verkehr sorgen könnte,
der in beiden Richtungen fließt.
Die beschriebene Lösung,
die für
die verschiedenen Richtungen verschiedene Überprüfungsblöcke nutzt, wird nur für Lastverteilungszwecke verwendet.
Auf diese Weise ist es leicht, die Aufgaben der verschiedenen Überprüfungsblöcke auf
verschiedene Prozessoren unter Computer zu verteilen.
-
Der
Empfangsblock 262 empfängt
den von dem Server kommenden Datenfluss. Er leitet ihn an den Steuerblock 264 weiter,
der im Wesentlichen in der gleichen Weise wie der Steuerblock 204 arbeitet.
Der Hauptunterschied ist, dass jetzt die verschiedenen Teile der
TCP- und IP-Anfangsblöcke
verwendet werden, da es anstelle der Quellinformationen, die für den in
der entgegengesetzten Richtung gehenden Verkehr verwendet werden,
der Zielport und die Zieladresse sind, die den Host definieren,
auf dem die Anwenderagentenanwendung ausgeführt wird, zu der der Verkehr
fließt.
-
Der
Steuerblock leitet den Inhalts-HTTP-Fluss zu dem Überprüfungsblock 266 weiter.
Zunächst
wird aus dem Datenfluss in dem entsprechenden Host-ID-Erkennungsblock 272 die
Host-ID erkannt. Daraufhin wird in dem Klient-ID-Erkennungsblock 274 die Klient-ID
identifiziert. Falls die Antwort Repräsentationsdaten sind, wird
die Antwort in dem Antwort-Parser 276 geparst. In dem Deskriptoridentifizierungsblock 278 werden die
verfügbaren
durch die Antwort angebotenen Zustände und Beschränkungen
identifiziert. Falls die Antwort Skripte oder Formulare enthält, kann
sie der Deskriptoridentifizierungsblock des Weiteren überprüfen, um mögliche Beschränkungen
und unzulässige
Parameterkombinationen zu finden. Falls etwas gefunden wird, können die
Daten in der Beschränkungsdatei 252 gespeichert
werden. Falls die Antwort z. B. Skripte enthält, kann es erforderlich sein,
sie auszuführen,
bevor die verfügbaren
und unzulässigen
Parameterwerte und/oder Beschränkungen
mitgeteilt werden können.
-
Der
Block 280 zur Identifizierung verfügbarer Zustände liest die Tabelle verfügbarer Zustände für den Klienten 251.
Die richtige Tabelle wird anhand derjenigen Host- und Klienten-IDs
gewählt,
die die Identitäten mit
der Tabelle verfügbarer
Zustände
in der Tabelle für
die Host-ID und für
die Klienten-ID und für
die gemeinsamen Parameter 250 verknüpfen können. Daraufhin vergleicht
der Block zur Identifizierung verfügbarer Zustände die von dem Deskriptoridentifizierungsblock
empfangenen Deskriptoren mit den gespeicherten verfügbaren Zuständen 251 und
entfernt von den erfassten verfügbaren
Zuständen
Duplikate. Daraufhin speichert er die neuen verfügbaren Zustände in der Tabelle verfügbarer Zustände. Der
Weiterleitungsblock 268 empfängt von dem Steuerblock 264 den
Datenfluss, der ebenfalls die Antwortdaten enthält, und sendet ihn an den Klienten.
-
Der
Funktionsblockschaltplan aus 2 ist auch
für ein
NIDS geeignet. Der Hauptunterschied ist in diesem Fall, dass die
Weiterleitungs- und Steuerblöcke
nicht benötigt
werden, da ein NIDS ein stiller Lauscher ist und nur Netzverkehr überwacht.
-
3 veranschaulicht
den Datenstrom zwischen dem Anwenderagenten 150 und dem
Web-Server 152, der im Folgenden ausführlicher diskutiert wird. Der
Anwenderagent sendet ein TCP SYN-Paket 310 an den Web-Server,
um eine Verbindung aufzubauen. Der Server antwortet, indem er dafür ein TCP
SYN + ACK-Paket 312 sendet. Der Web-Server empfängt das
Paket 312 und antwortet, indem er ein TCP ACK-Paket 314 sendet,
wonach die TCP-Verbindung
vollständig
aufgebaut ist.
-
Die
offene Verbindung kann z. B. durch den Klienten verwendet werden,
um eine HTTP-Anfrage 316 an den Web-Server zu senden. Der
Web-Server analysiert die Anfrage und antwortet mit einer HTTP-Antwort 318.
Falls die HTTP-Verbindung nicht dauerhaft ist, schließt der Klient
die darunter liegende TCP-Verbindung, indem er ein TCP FIN + ACK-Paket 320 sendet,
für das
der Web-Server antwortet, indem er zunächst ein TCP ACK-Paket 322 und
daraufhin ein TCP FIN + ACK-Paket 324 sendet.
-
Um
eine neue HTTP-Anfrage zu senden, muss der Klient eine neue TCP-Verbindung öffnen. Dies
erfolgt ähnlich
durch Senden eines TCP SYN-Pakets 326, Empfangen eines
TCP SYN + ACK-Pakets 328 und des Weiteren durch Senden
eines TCP ACK-Pakets 330, bevor die neue HTTP-Anfrage 332 gesendet
werden kann. Nach Empfang der Antwort 334 schließt der Klient
die TCP-Verbindung wieder, indem er ein TCP FIN + ACK-Paket 336 sendet,
das durch den Server, der mit einem TCP ACK 338 und mit
einem TCP FIN + ACK 340 antwortet, bestätigt wird.
-
Falls
zwischen dem Klienten und dem Server ein HTTP-Proxy 151 verwendet
wird, entspricht die Mitteilungsübermittlung
dem bereits anhand von 1B diskutierten Prozess. Allerdings
ist es nicht notwendig, einen Web-Proxy zu verwenden, um die vorliegende
Erfindung für
die Überwachung
des Verkehrs zwischen einem Server und einem Klienten zu realisieren.
Der Verkehr wird durch das Analysesystem analysiert, das sich in
einem Proxy oder in einem anderen Netzelement befinden kann. Außerdem kann
das Element auch ein Teil eines Network Intrusion Detection Systems
sein.
-
Falls
ein Proxy-System verwendet wird, wird die Analyse der Antwort-Anfrage-Paare gemäß der vorliegenden
Erfindung für
die Anfrage 184 und für
die Antwort 190 usw. auch für die weitere Kommunikation
oder alternativ für
den Verkehr zwischen dem Proxy und dem Web-Server ausgeführt. Im
letzteren Fall müssen
die Anfrage-Antwort-Paare auf andere Weise identifiziert werden,
da der Absender des durch den Web-Server empfangenen Pakets tatsächlich der
Proxy und nicht der Anwenderagent sein kann. Somit können die
Host-Informationen
nicht zum Identifizieren eines Hosts verwendet werden, wobei die
Erfindung aber auch mit einem Proxy-System realisierbar ist, da
die Klientenkennungen weiter verwendbar sind. Darüber hinaus
können
andere Klienten ohne die Host-ID identifiziert werden, falls Identifizierungs-Cookies
oder irgendwelche anderen Identifizierungsmechanismen verwendet
werden. Im Allgemeinen werden die in der Anfrage 316 enthaltenen Informationen
an das Analysesystem 300 übergeben. Der erste Überprüfungsblock 206 prüft die Host-Kennung
und die Klientenkennung und mögliche
gemeinsame Parameter und speichert sie in der entsprechenden Tabelle 250.
Außerdem
kann er eine Beschränkungsprüfung und
eine Fingerabdruckprozedur ausführen,
um, wie es oben anhand von 2 beschrieben
wurde, böswillige
Anfragen zu finden, Ereignisse zu klassifizieren und zu berichten
usw. Der erste Überprüfungsblock 206 analysiert
die Anfrage in seinem Deskriptoridentifizierungsblock 226.
Falls die Anfrage die erste ist, kann sie nur mit Fingerabdrücken und
mit der Beschränkungsdatei 252 abgeglichen
werden.
-
Die
Antwort 318 wird ebenfalls analysiert. Der zweite Überprüfungsblock 226 führt in dem
Sinn, dass er den HTML-Teil des Flusses analysiert und mögliche Deskriptoren
und Beschränkungen
zu identifizieren versucht, ähnliche
Aufgaben wie der erste Überprüfungsblock 206 aus.
Die identifizierten Deskriptoren werden in der Tabelle verfügbarer Zustände 251 gespeichert. Ähnlich werden
die identifizierten Beschränkungen
in der Beschränkungsdatei 252 gespeichert.
-
Wenn
das Analysesystem die nächste
von demselben Host kommende HTTP-Anfrage
empfängt,
wird die Anfrage ebenfalls in dem ersten Überprüfungsblock 206 analysiert.
Da die erste für
den Klienten bestimmte Antwort bereits empfangen worden ist, hat
der Überprüfungsblock
nun mehr Informationen, da der zweite Überprüfungsblock 266 bereits
einige Zustandsinformationen in der Tabelle verfügbarer Zustände 251 gespeichert
hat. Diese Informationen können
verwendet werden, um die in der Anfrage 332 identifizierten
Deskriptoren zu verifizieren. In diesem Sinn könnte der Prozess als Validierung
der Anfragen verstanden werden, was aber etwas missverständlich dahingehend
sein könnte,
dass dann, wenn ein Network Intrusion Detection System verwendet
wird, der Verkehr nicht validiert zu werden braucht, sondern nur
verdächtige
Aktivitäten
identifiziert werden müssen.
-
Das
System setzt den Betrieb auf gleiche Weise fort. Mit anderen Worten,
die zukünftigen
Anfragen werden gegenüber
allem Historienwissen über
Deskriptoren analysiert, das in den Antworten während der Verbindung identifiziert
worden ist.
-
Zusammengefasst:
Das System gemäß der vorliegenden
Erfindung soll einen Strom von Datenflüssen zwischen einem Klienten
und einem Server überwachen,
wobei jeder Datenfluss Repräsentationsdaten
auf einem verbindungsorientierten Trägerprotokoll führt. Dieses
System enthält
einen ersten Überprüfungsblock (206),
der dazu ausgebildet ist, einen ersten Datenfluss, der vom Klienten
zum Server fließt,
zu bearbeiten, sowie einen zweiten Überprüfungsblock (266).
Der erste Überprüfungsblock
(206) ist ausgestattet mit:
- – Analysemitteln,
die zur Analyse der Repräsentationsdaten
eines Anfragedatenflusses ausgebildet sind, der vom Klienten zum
Server fließt,
um zumindest einen Anfrage-Deskriptor zu identifizieren,
- – Vergleichsmitteln
zum Vergleichen der Anfrage-Deskriptoren mit dem Satz verfügbarer Zustände (251)
für den
Klienten, und
- – Mitteln,
die von dem Vergleichsmittel abhängig
sind und dazu ausgebildet sind, ein Überwachungsergebnis zu generieren.
-
Der
zweite Überprüfungsblock
(266) ist ausgestattet mit:
- – Analysemitteln,
die zur Analyse der Repräsentationsdaten
eines Antwortdatenflusses ausgebildet sind, der vom Server zum Klienten
fließt,
um zumindest einen Antwort-Deskriptor zu identifizieren, und
- – Speichermitteln,
die von dem Analysemittel abhängig
sind und dazu ausgebildet sind, identifizierte Antwort-Deskriptoren
in einem Satz verfügbarer
Zustände
(251) für
den Klienten zu speichern.
-
Es
wird angemerkt, dass die Speichermittel, die dazu ausgebildet sind,
die Antwort-Deskriptoren zu speichern, wesentlich sind, wenn versucht
wird, das oben (im Hintergrund der Erfindung) erwähnte technische Problem
zu lösen.
-
Dementsprechend
ist das Verfahren gemäß der vorliegenden
Erfindung zur Überwachung
eines Stroms von Datenflüssen
zwischen einem Klienten und einem Server gedacht, wobei jeder Datenfluss
Repräsentationsdaten
auf einem verbindungsorientierten Trägerprotokoll führt. Wenn
ein erster Datenfluss, der vom Klienten zum Server fließt, von
einem ersten Überprüfungsblock
(206) bearbeitet wird, werden die folgenden Schritte ausgeführt:
- – Analyse
der Repräsentationsdaten
eines Antwortdatenflusses, der vom Server zum Klienten fließt, durch einen
zweiten Überprüfungsblock
(266), um zumindest einen Antwort-Deskriptor zu identifizieren,
- – als
Reaktion auf den Analyseschritt, Speichern von identifizierten Antwort-Deskriptoren
in einem Satz verfügbarer
Zustände
(251) für
den Klienten,
- – Analyse
der Repräsentationsdaten
eines Anfragedatenflusses, der vom Klienten zum Server fließt, durch den
ersten Überprüfungsblock
(206), um zumindest einen Anfrage-Deskriptor zu identifizieren,
- – Vergleichen
der Anfrage-Deskriptoren mit dem Satz verfügbarer Zustände (251) für den Klienten
durch den ersten Überprüfungsblock
(206), und
- – als
Reaktion auf den Vergleichsschritt, Generieren eines Überwachungsergebnisses.
-
4 zeigt
die Analyseaufgabe des Überprüfungsblocks 266,
die für Überprüfungsantworten
verwendet wird, die von dem Server zu dem Anwenderagenten gesendet
werden. Wenn der Überprüfungsblock
den Verkehr empfängt
(Schritt 400), werden in Schritt 402 die Daten
gelesen, die die HTTP-Antwort
und die Host-Identität
enthalten. Grundsätzlich
können
die Blöcke 272, 274, 276 und 278 an
verschiedenen Teilen dieses Prozesses beteiligt sein. Der Überprüfungsblock
verifiziert (Schritt 404), dass die Antwort in einer Präsentationssprache
wie etwa dem HTML ist. Die HTTP-Antworten können außerdem Daten im Binärformat
wie etwa Bilder, Klänge
oder andere Multimediainformationen enthalten. Diese Teile der Antworten
brauchen nicht notwendig analysiert zu werden. Falls die Antwort
vollständig
aus solchen Daten besteht, wird der Prozess abgeschlossen (Schritt 410).
Andernfalls wird zumindest der Host-Identitätsteil der Tabelle 250 gelesen
(Schritt 406), um die verfügbaren Zustandsinformationen
richtig wiederzugewinnen, wobei dieser Schritt aber außerdem das
Lesen der Klientenidentitätstabelle
und anderer gemeinsamer Parameter enthalten kann.
-
Danach
wird die Anfrage in Schritt 407 decodiert und geparst.
Das Parsen wird ausführlicher
anhand von 5 beschrieben. Der Analyseschritt 408 analysiert
die geparste Antwort genauer, wonach die Verarbeitung der Antwort
in dem Überprüfungsblock 266 abgeschlossen
wird (Schritt 410).
-
5 veranschaulicht,
wie die Antwort in Schritt 408 analysiert wird. Zunächst wird
in Schritt 502 die Tabelle verfügbarer Zustände gelesen. Aus Tabelle 251 werden
anhand der Klientenidentität
diejenigen Einträge
gewählt,
die den verfügbaren
Zuständen
entsprechen. Alternativ kann dies so realisiert werden, dass es eine
getrennte Tabelle gibt, die für
jede Klientenidentität
oder Host-Identität reserviert
ist.
-
Nach
Schritt 502 wird der Inhalt der Antwort untersucht. Mit
anderen Worten, aus der Antwort werden mögliche Deskriptoren identifiziert,
die den verfügbaren
Zuständen
entsprechen, um später
die Anfragen zu untersuchen. In Schritt 504 werden mögliche HTTP
REDIRECT-Nachrichten identifiziert und daraufhin die Parameter dieser
Nachrichten als Deskriptoren zum Satz verfügbarer Zustände in der Überprüfung hinzugefügt. Zum
Beispiel könnte
eine Umleitungsnachricht darüber
informieren, dass sich eine URL (Universal Resource Location) http://www.stonesoft.com/services/
tatsächlich
bei http://www.stonesoft.com/customer/services/ befindet.
-
In
Schritt
506 werden die Zustände identifiziert, die in den
möglichen
HTML HREF-Tags gegeben sind. Diese entsprechen Hyperlinks und sind üblicherweise
in einem Fluss wie
<a
href=''/contact.html''>Contact</a>
identifiziert,
wo der identifizierte HREF-Teil in Fettschrift hervorgehoben worden
ist. Falls die HREF-Kennungen gefunden werden, werden sie als Deskriptoren
zum Satz verfügbarer
Zustände
in der Prüfung
hinzugefügt. Das
heißt,
falls die folgende Anorderung von dem Klienten eine GET-Anfrage
für /contact.html
ist, wird die Anfrage in die verfügbaren Zustände aufgenommen, womit die
Anfrage zulässig
ist.
-
In
Schritt
508 wird eine Analyse möglicher Formulare in der Antwort
ausgeführt.
Es folgt ein Beispiel eines Formularteils in der Antwort, wobei
der Formularteil durch die in Fettschrift bezeichneten FORM-Tags gemeldet
wird:
-
Die
verfügbaren
Optionen, Parameterlängenbeschränkungen
und weiteren relevanten Informationen sind hier als Deskriptoren
in dem Satz verfügbarer
Zustände
und Beschränkungen
in der Prüfung
gespeichert. Die aus der obigen Antwort erhaltenen verfügbaren Zustände für das Betriebsmittel
/sites/search.exe für
den besagten Klienten sind:
-
-
Das
heißt,
die zukünftigen
Anfragen von dem besagten Klienten müssen diesen verfügbaren Zuständen entsprechen.
Die Beschränkungen
für das
Betriebsmittel /sites/search.exe, die alle Hosts und Klienten betreffen
und die aus der obigen Antwort erhalten werden, sind: 1) die Länge des
Abfrageparameterwerts ist kleiner oder gleich 800 und 2) die Länge des
Sprachparameterwerts ist gleich 2).
-
Das
heißt,
alle zulässigen
Anfragen von irgendeinem Klienten an die besagte Site müssen zu
diesen Beschränkungen
konform sein.
-
Falls
die Antwort aus Skripten besteht, werden sie in Schritt 510 analysiert.
Da die Skripttätigkeit
möglicherweise
nicht lediglich durch Analysieren des Inhalts der Skriptdaten dediziert
werden kann, ist dies eine kompliziertere Aufgabe. Somit kann es
notwendig sein, das Skript auszuführen, um herauszufinden, welche Art
von Antworten es generieren kann, so dass die entsprechenden Antwort-Deskriptoren
identifiziert werden können.
Das Skript wird in einem Prozessor analysiert, der derjenige sein
kann, den der Überprüfungsblock 266 nutzt,
oder die Skriptanalyse kann in einem getrennten Analyseprozessor
ausgeführt
werden. Die Ergebnisse der Analyse, die den identifizierten Deskriptoren
entsprechen, werden ebenfalls in dem Satz verfügbarer Zustände in der Prüfung gespeichert.
-
Nachdem
die verfügbaren
Deskriptoren in der Antwort analysiert worden sind, werden sie in
Schritt 502 mit den aus der Tabelle 251 gelesenen
verfügbaren
Zuständen
verglichen. Falls es irgendwelche Deskriptoren gibt, die nicht bereits
in der Tabelle 251 für
den Anwenderagenten enthalten sind, werden sie in der Tabelle aktualisiert
(Schritt 514). Um dies effizient zu tun, müssen mögliche Duplikate
(d. h. Zustände,
die bereits identifiziert und in der Tabelle gespeichert worden
sind) erfasst werden, so dass nur die neuen verfügbaren Zustände gespeichert werden (Schritt 512).
-
6 repräsentiert
die Bearbeitung einer HTTP-Anfrage wie etwa der Anfragen 316, 332 oder
irgendeiner nachfolgenden Anfrage in dem ersten Überprüfungsblock 206. Zunächst empfängt der Überprüfungsblock
in Schritt 600 den Datenfluss. Dieser Fluss kann einige
komprimierte oder codierte Teile enthalten, so dass sie zunächst dekomprimiert
und decodiert werden müssen.
Danach ist die Anfrage bereit, geparst zu werden. Diese Schritte
werden in dem HTTP-Anfrage-Decodierungs- und HTTP-Anfrage-Parse-Schritt 602 in dem
Anfrage-Parser-Block 232 ausgeführt.
-
Danach
muss der erste Überprüfungsblock
die Host-Kennung lesen. Diese Informationen können wie oben beschrieben aus
den IP- und TCP-Anfangsblöcken erhalten
werden, wobei der Überprüfungsblock
diese Daten möglicherweise
einfach aus dem leicht extrahierten Steuerblock 204 empfängt. Falls
die empfangene Host-Kennung, wie in Schritt 604 geprüft wird,
bereits in der Tabelle 250 vorhanden ist, entspricht die
Kommunikation zwischen dem Anwenderagenten 150 und dem
Web-Server 152 der Anfrage 332 oder irgendeiner nachfolgenden
Anfrage, für
die bereits Antworten wie 318 empfangen worden sind. Im
entgegengesetzten Fall, der zunächst
diskutiert wird, entspricht die Anfrage der ersten Anfrage 316 von
dem Anwenderagenten oder von dem Host. Somit wird die Analyse in
Schritt 604 oder in Schritt 606 verzweigt.
-
Falls
die Host-Kennung nicht gefunden wird, werden die Antwort-Deskriptoren
von der geparsten Anfrage anhand der Beschränkungstabelle 250 geprüft (Schritt 611).
Dies kann z. B. Parameterbeschränkungen enthalten,
die sich auf die IP-Adresse, auf den Host-Namen und auf den abs_path-Teil
des URI (Universal Resource Indicator) des Servers ausschließlich des
Abfrageteils der Anfrage beziehen. Daraufhin wird der Anfragefluss
selbst mit Fingerabdrücken
von bekannten Missbrauchsversuchen verglichen (Schritt 612).
Diese Schritte nutzen normale Mustererkennungsverfahren wie etwa
den Vergleich des Flusses mit einigen zuvor gespeicherten Zeichenfolgen,
die Teilen der Anfragen entsprechen. Der Vergleich kann in dem Fingerabdruck-Gleichheitsprüfungsblock 230 ausgeführt werden.
-
Schritt 614 evaluiert
die Ergebnisse der zwei vorangehenden Analyseschritte 611 und 612.
Falls das Ergebnis des Vergleichs ist, dass die bekannten Missbrauchsmuster
erfasst werden, oder falls in Schritt 611 mitgeteilt wurde,
dass Deskriptoren festgestellt wurden, die unzulässige Parameterwerte usw. definieren,
kann das Ereignis in dem Ereignisklassifizierungsschritt 616 klassifiziert
werden. Diese Verifizierung und diese Klassifizierung können in
dem Ereignisanalyse- und Ereignisberichtsblock 240 erfolgen.
Daraufhin wird bei Bedarf in Schritt 618 eine Warnung erzeugt
und die Anfrage gesperrt, d. h. nicht an den Web-Server weitergeleitet. Dieser
letzte Schritt kann in dem Proxy oder in dem HTTP-Abschirmungsprogramm
in dem Server, wahrscheinlich aber nicht in irgendeinem Network
Intrusion Detection System, stattfinden. Stattdessen erzeugt das NIDS
eine Warnung, die dem Systemadministrator mögliche Probleme identifizieren
hilft.
-
Im
entgegengesetzten Fall, d. h., wenn keine bekannten Missbrauchsmuster
erfasst werden, wird in Schritt 620 die Host-Kennung in
der Verbindungstabelle 250 aktualisiert. Ähnlich kann
die Klientenkennung in der Tabelle aktualisiert werden (Schritt 622).
Falls in der Anfrage irgendwelche gemeinsamen Parameter gefunden
werden, werden sie in Schritt 624 identifiziert und des
Weiteren in Schritt 626 in der Tabelle 250 aktualisiert.
-
Nach
diesen Tätigkeiten
ist die Bearbeitung der ersten Anfrage ausgeführt worden (Schritt 680),
wobei die Anfrage bereit ist, zu dem Web-Server weitergeleitet zu
werden.
-
Falls
in Schritt 604 erfasst wird, dass die Host-Kennung in der
Tabelle 250 bereits vorhanden ist, wird eine Klientenkennung
der Anfrage verarbeitet. In Schritt 606 wird verifiziert,
ob die Klientenkennung bereits in der Tabelle 250 vorhanden
ist. Somit wird die Tabelle 250 verwendet, um zu erfassen,
ob der Anwenderagent bereits in Kommunikation mit dem Server gewesen
ist. Wie oben anhand von 3 erläutert wurde, kann dies erfasst
werden, da die TCP-Verbindung
im Gegensatz zum Fall beständiger
HTTP-Verbindungen, für
die die TCP-Verbindung zwischen nachfolgenden Anfragen verbleibt,
nach jedem Anfrage-Antwort-Paar abgebaut werden kann. Somit kann
die Tabelle 250 die Antwort/Anfrage-Deskriptoren für die Anwenderagentenkennungen
abbilden, um die Kommunikationshistorie zu überspannen, die viele verschiedene
Verbindungen enthält. Dieses
Prinzip wird bei der Realisierung der Erfindung verwendet, d. h.,
es werden Antwort-Anfrage-Paare abgebildet, um nachfolgende TCP-Verbindungen
zu überbrücken.
-
Falls
die Klientenkennung nicht gefunden wird, prüft der Deskriptorverifizierungsblock 224 in
Schritt 608, ob der Anfrage-Deskriptor in irgendeiner der
verfügbaren
Zustandstabellen 251 in Bezug auf die Host-Kennung gefunden
werden kann. Falls keine Gleichheiten gefunden werden, was in Schritt 610 ermittelt wird,
wird die Anfrage als eine neue Anfrage bearbeitet und somit zum
Beschränkungsprüfungsschritt 611 weitergeleitet,
der im Block 234 stattfindet. Nachfolgend wird die Antwort
an den Fingerabdruck-Gleichheitsprüfungsblock 230 weitergeleitet,
der den Fingerabdruckschritt 612 ausführt. Der Rest der Schritte
wird wie für eine
neue Anfrage ebenfalls ausgeführt.
Falls ein Deskriptor gefunden wird, der einer anderen Klientenkennung
von demselben Host entspricht, wird die Klientenkennung von der
Anfrage zur zukünftigen
Verarbeitung auf die gefundene Klientenkennung abgebildet und der
Prozess in Schritt 680 abgeschlossen. Dies entspricht z.
B. einem Fall, in dem der Anwender einfach den Web-Browser vom Microsoft
Internet Explorer zu Netscape geändert
und die URL von dem vorangehenden Browser-Bildschirm in das Netscape-Adressfeld
kopiert hat.
-
Falls
die Host-Kennung und die Klientenkennung gefunden werden, wird die
Verarbeitung in Schritt 650 fortgesetzt. In diesem Schritt
werden die gemeinsamen Parameter von den HTTP-Anfangsblöcken identifiziert.
In Schritt 652 werden sie mit den aus Tabelle 250 wiedergewonnenen
Werten verglichen, wobei dann, wenn irgendwelche Anomalien wie etwa
ungültige
Parameterwerte erfasst werden, der nächste Schritt 616, wie
bereits erläutert
wurde, die Fortsetzung mit einer Ereignisklassifizierungsprozedur
ist. Dies kann z. B. einer Situation entsprechen, in der jemand
die HTTP-Anfragen direkt unter Verwendung von Telnet eintippt. Im
Allgemeinen kann dies als verdächtig betrachtet
werden. Alternativ kann (in der Figur nicht gezeigt) für die Anfrage
wie oben erläutert
die Fingerabdruckanalyse erfolgen und die Anfrage zugelassen werden,
falls keine Anomalien gefunden werden.
-
Im
entgegengesetzten Fall werden in Schritt 654 die möglichen
Beschränkungen
wie etwa für
die Skripte aus der Beschränkungsdatei 252 wiedergewonnen
und in Schritt 656 die in den vorangehenden Antworten identifizierten
Deskriptoren aus der Tabelle 250 verfügbarer Zustände gelesen. In dem Schritt 658 werden
die geparsten Deskriptoren in der Anfrage daraufhin des Weiteren
mit den wiedergewonnenen Beschränkungen
und Deskriptoren verglichen. Falls die Deskriptoren gleich jenen
in dem Satz verfügbarer
Zustände sind,
wie er aus den Beschränkungen
und aus den Deskriptoren kombiniert wird, scheint die Anfrage gültig zu sein,
wobei der Prozess beendet werden kann (Schritt 680). Im
Fall eines Web-Proxy kann die Anfrage an den Web-Server übergeben
werden, während
im Fall eines NIDS keine Operation benötigt wird.
-
Im
entgegengesetzten Fall, d. h., falls zumindest einer der Parameter
ungültig
ist, ist es möglich,
dass dies einem Ereignis entspricht. Aus diesem Grund wird das mögliche Ereignis
in dem Ereignisklassifizierungsschritt 616 geprüft. Des
Weiteren kann ein Alarm erzeugt werden (Schritt 618), falls
es ein Ereignis wie etwa einen Hacking-Versuch gibt, das etwas Alarmierendem
entspricht. Danach wird die Verarbeitung beendet (Schritt 680).
Es ist möglich,
dass in dem Ereignisklassifizierungsschritt erfasst wird, dass die Änderungen
in den Deskriptoren nicht gefährlich
sind. Falls die Erfindung in einem Proxy-Element realisiert ist,
ist es in diesem Fall möglich,
das Weiterleiten der Anfrage zuzulassen.
-
7 zeigt,
wie die Tabelle verfügbarer
Zustände
initialisiert wird, wenn ein neuer Klient und/oder Host das erste
Mal beobachtet wird. Die hier beschriebene Prozedur ist zusätzlich und
kann ebenso übersprungen werden,
verbessert aber die Systemleistungsfähigkeit und verringert die
Zusatzverarbeitung zukünftiger
Anfragen. Nach Schritt 626 und bevor die Anfrage weitergeleitet
wird, kann das System die konfigurierten Zustände in dem Speicher lesen (Schritt 710).
Diese konfigurierten Zustände
können
einige bekannte Beschränkungen für die Dienste
oder Zustände,
von denen bekannt ist, dass sie falsche Alarme verursachen, falls
sie nicht spezifisch zugelassen sind usw., die ihrem Wesen nach
statisch und für
die meisten Klienten gemeinsam sind, enthalten. Diese Deskriptoren
werden daraufhin in Schritt 712 in die Tabelle 251 initialisierter
Zustände
kopiert. Eine Alternative hierzu ist natürlich, dass die Deskriptoren,
die die konfigurierten Zustände
definieren, in einer Datei gespeichert werden, die für den Überprüfungsblock 206 nutzbar
ist, so dass diese Datei bei der Verarbeitung von Anfragen von allen
Klienten gelesen wird. Die letztere Lösung verkompliziert das System
etwas, wobei aber schneller mögliche Änderungen
in der Konfiguration verwirklicht werden können.
-
Eine
weitere Ausführungsform
der vorliegenden Erfindung betrifft, wie das Computersystem realisiert ist.
Für Lastverteilungszwecke
und Skalierbarkeit kann ein Prozessor oder ein Server-System, wenn
hohe Netzlasten erwartet werden, nicht ausreichend erscheinen. Aus
diesem Grund kann das System in einer wie etwa im Folgenden beschriebenen
Weise in einem Computer-Cluster realisiert werden.
-
Das
System kann mehrere Verarbeitungseinheiten zum Identifizieren der
Anfrage- und/oder Antwort-Deskriptoren umfassen, wobei in einer
Verarbeitungseinheit für
die Analyse gesorgt wird. Die Verarbeitungseinheit zum Parsen der
Anfrage kann gemäß einigen
vordefinierten Kriterien gewählt
werden. Diese vordefinierten Kriterien können z. B. die IP-Adressen
in Datenpaketen, die die Anfragen und Antworten führen, die
Host-Kennung, der verwendete Web-Dienst, die momentane Last in einer
Verarbeitungseinheit usw. sein. Die geparsten Anfragen und/oder
Antworten von mehreren Verarbeitungseinheiten werden an eine Verarbeitungseinheit
gesendet, die die Analyse bearbeitet. Somit wird der Vergleich der
Anfrage-Deskriptoren mit der Tabelle verfügbarer Zustände des Klienten in derselben
Verarbeitungseinheit ausgeführt.
-
Falls
die Systemkapazität
weiter erhöht
wird, können
außerdem
mehr Verarbeitungseinheiten für
den Vergleichsschritt bestimmt werden, wobei dies aber nicht so
problemlos wie die Verwendung mehrerer Parse-Blöcke ist, da alle Anfragen und
Antworten eines Hosts in demselben Vergleichsblock verarbeitet werden müssen, um
alle erforderlichen Informationen für die Analyse zu haben. Die
Verarbeitungseinheit, mit der die Anfrage analysiert wird, kann
gemäß gewissen
vordefinierten Kriterien gewählt
werden. Diese vordefinierten Kriterien können die Host-Kennung, der
verwendete Web-Dienst, die momentane Last in einer Verarbeitungseinheit
usw. sein.
-
Die
Reihenfolge, in der die Verarbeitungsschritte (4–7)
ausgeführt
werden, ist lediglich veranschaulichend und soll die Realisierung
der Erfindung in keiner Weise einschränken. Aufgrund des Wesens der
Erfindung ist nur eine Möglichkeit
gezeigt worden, wobei der Fachmann auf dem Gebiet aber schließlich eine ähnliche
Wirkung erzielen kann, indem er die Verarbeitungsreihenfolge geringfügig ändert.
-
Obgleich
die vorliegende Erfindung oben unter Verwendung eines Proxy-Systems als ein Beispiel
erläutert
worden ist, ist ein Netz-Proxy selbstverständlich nicht das einzige Netzelement,
in dem die Erfindung an sich realisiert werden könnte. Zum Beispiel kann ein
Network Intrusion Detection System (NIDS) ähnliche Elemente wie die Überprüfungsblöcke 206 und 266 zusammen
mit den relevanten Datendateien sowie mit dem Ereignisanalyse- und Ereignisberichtsblock 240 enthalten.
Das NIDS überwacht
den Netzverkehr und versucht, mögliche
Eindringereignisse zu erfassen. Es kennt den Status der Verbindungen
und kann, wenn es auf den Netzverkehr lauscht, einen Datenfluss
erfassen, der unzulässig
ist. Da dies ein Vorzeichen eines nahenden Eindringvorgangs sein
kann, kann es sofort berichtet werden, wobei das NIDS aber gewöhnlich der besagten
Verbindung genauer zu folgen beginnt.
-
Eine
zustandsbehaftete Firewall, die die oben beschriebenen Filteroperationen
ausführen
kann, ist ebenfalls ein geeigneter Ort für die Realisierung der vorliegenden
Erfindung.
-
Die
Erfindung betrifft ebenfalls andere Systeme als TCP/IP-Netze in
Verbindung mit Datenflüssen,
die HTTP nutzen. Als ein Beispiel ist das WAP (Wireless Application
Protocol), das Präsentationsspracheninhalt wie
etwa WML führt,
ebenfalls ein anwendbares Ziel für
die Realisierung der Erfindung, wenn der Verkehr über normale
leitungsvermittelte oder paketvermittelte Daten wie etwa GPRS läuft. Als
ein weiteres Beispiel sind Systeme, die XML oder eine andere Präsentationssprache
nutzen, ebenfalls anwendbar, wodurch sich der Umfang der Erfindung
erhöht.
Somit soll die Erfindung nicht als durch die Beschreibung beschränkt interpretiert werden,
sondern wie in den unabhängigen
Ansprüchen
beschrieben verstanden werden.
