verlinkt - wortzwei

Transcription

verlinkt - wortzwei

Fachhochschule Wedel
Fachbereich Medieninformatik
Bachelor-Thesis
Erkennung von automatisierten Zugriffen auf
Webseiten unter Verwendung von
Selbstorganisierenden Karten
Eine Machbarkeitsstudie
eingereicht von:
John Freytag
Farnstieg 11
22559 Hamburg
Tel: (040) 361 660 87
Matrikelnummer: Minf 8164
eingereicht am:
25.02.2010
Referent:
Betreuer:
Prof. Dr. Ulrich Hoffmann
Fachhochschule Wedel
Feldstraße 143
22880 Wedel
Tel: (04103) 8048-41
Joris Wiebe
wortzwei GmbH
Friedensallee 9
22765 Hamburg
Tel: (040) 679 586 07
Inhaltsverzeichnis
Abbildungsverzeichnis
III
1 Einleitung
1.1 Hintergrund und Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Theoretische Grundlagen
2.1 Der SOM-Algorithmus . . . . . . . . . . . . . . . . . . .
2.1.1 Formale Definition . . . . . . . . . . . . . . . . .
2.1.2 Begriffserklärungen . . . . . . . . . . . . . . . . .
2.1.3 Topologischer Aufbau . . . . . . . . . . . . . . .
2.1.4 Training . . . . . . . . . . . . . . . . . . . . . . .
2.1.5 Alternativer Algorithmus: Die Batch-Map . . . .
2.2 Aufbereitung abstrakter Daten zu Trainings-Vektoren .
2.2.1 Bildung des Alphabets . . . . . . . . . . . . . . .
2.2.2 Semantische Aggregation . . . . . . . . . . . . .
2.3 Verfahren zur Optimierung . . . . . . . . . . . . . . . .
2.3.1 Dimensionsreduzierung durch Random Mapping
2.3.2 Abgekürzte BMU -Suche . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Erkennung von automatisierten Zugriffen anhand von Zugriffsprotokollen
3.1 Apache-Webserver-Zugriffsprotokolle . . . . . . . . . . . . . . . . . . .
3.2 Definition von Bots . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Kriterien zur Erkennung . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Klickpfad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Fehlendes Laden zusätzlicher Inhalte . . . . . . . . . . . . . . .
3.3.3 Zu hohe oder sonst unübliche Zugriffsgeschwindigkeit . . . . . .
3.3.4 Unübliche Browserkennung oder Referer-Angabe . . . . . . . .
3.4 Verwendung der Kriterien in Selbstorganisierenden Karten . . . . . . .
3.4.1 Klickpfad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2 Fehlendes Laden zusätzlicher Inhalte . . . . . . . . . . . . . . .
3.4.3 Zu hohe oder sonst unübliche Zugriffs-Geschwindigkeit . . . . .
4 Prototyp einer Zugriffsprotokollanalyse auf Basis von SOMs
4.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Zielgruppendefinition . . . . . . . . . . . . . . . . .
4.1.2 Wahl der Programmiersprache . . . . . . . . . . .
4.1.3 Technische Rahmenbedingungen . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
4
6
7
12
13
13
15
16
17
18
.
.
.
.
.
.
.
.
.
.
.
21
21
22
22
23
23
24
24
25
25
26
26
.
.
.
.
29
29
29
29
30
I
Inhaltsverzeichnis
4.2
4.3
Anforderungen . . . . . . . . . . . . .
4.2.1 Grundsätzliche Funktion . . . .
4.2.2 Präzision . . . . . . . . . . . .
4.2.3 Laufzeit-Einschränkungen . . .
4.2.4 Aufbereitung der Ausgabedaten
4.2.5 Erweiterbarkeit . . . . . . . . .
4.2.6 Benutzerschnittstelle . . . . . .
Komponenten . . . . . . . . . . . . . .
4.3.1 Architektur . . . . . . . . . . .
4.3.2 Zugriffsprotokoll-Analyse . . .
4.3.3 SOM-Algorithmus . . . . . . .
4.3.4 Visualisierung . . . . . . . . . .
4.3.5 Evaluierung . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Analyse und Bewertung der Ergebnisse
5.1 Beschreibung der Testumgebung . . . . . . .
5.1.1 Plattform . . . . . . . . . . . . . . . .
5.1.2 Quelle der Testdaten . . . . . . . . . .
5.2 Präsentation ausgewählter Experimente . . .
5.2.1 Einfache semantische Aggregation . .
5.2.2 Gemittelte semantische Aggregation .
5.2.3 Semantische Aggregation mit zeitlicher
5.2.4 Zeitsensitive semantische Aggregation
6 Zusammenfassung und Ausblick
6.1 Zusammenfassung . . . . . . . . . . . .
6.2 Bewertung der Ergebnisse . . . . . . . .
6.2.1 Präzision . . . . . . . . . . . . .
6.2.2 Laufzeit . . . . . . . . . . . . . .
6.3 Abschließende Bewertung des Verfahrens
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
Unterscheidung
. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
30
31
31
31
32
32
32
33
41
46
50
.
.
.
.
.
.
.
.
55
55
55
55
56
57
58
59
61
.
.
.
.
.
65
65
65
65
66
67
A Beispiel eines automatisierten Benutzers
69
B Beispiel eines menschlichen Benutzers
71
Literaturverzeichnis
73
Eidesstattliche Erklärung
75
II
2.1
2.2
2.3
2.4
2.5
2.6
Topologie einer SOM . . . . . . . . . . . . . . . . . . . . . . . . .
Beispiele der Abstandsfunktion bei steigendem t . . . . . . . . . .
Lernverhalten einer SOM zur Abbildung von Farbinformationen in
denen Iterationsschritten . . . . . . . . . . . . . . . . . . . . . . . .
Skalarproduktsverteilung von Zufallsvektoren [Kas98] . . . . . . .
Beispiel des Quick-Reaction-Algorithmus bei einer 10x10-SOM . .
Suche im Radius um zuvor gefundener BMU [Koh01, Seite 171] . .
. . . . . .
. . . . . .
verschie. . . . . .
. . . . . .
. . . . . .
. . . . . .
10
17
19
19
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Grundsätzliche Architektur der Implementierung . . . . . . . . .
Klassendiagramm der Zugriffsprotokoll-Analyse . . . . . . . . . .
Klassendiagramm des SOM-Algorithmus-Moduls . . . . . . . . .
Klassendiagramm der Visualisierungs- und Evaluierungs-Module
Beispiele einer Rasterbild-Visualisierung . . . . . . . . . . . . . .
Interaktive Darstellung einer kalibrierten SOM . . . . . . . . . .
Einfärbung von Knoten, auf die Kontrolldaten abgebildet werden
.
.
.
.
.
.
.
33
35
42
46
47
48
49
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
10
III
IV
1 Einleitung
Dieses Kapitel gibt eine kurze Einführung in das Thema der vorliegenden Arbeit. Darüber
hinaus wird die konkrete Zielsetzung festgelegt und die Herangehensweise in dieser Arbeit
allgemein beschrieben. Eine nähere Erläuterung der hier verwendeten Begriffe und beschriebenen Verfahren findet sich in den jeweiligen Kapiteln.
Diese Arbeit beschäftigt sich mit der Frage, ob Verfahren auf Basis des selbstlernenden
Algorithmus Self Organizing Map von Teuvo Kohonen [Koh01, Seite XI] dazu geeignet sind,
automatisierte Zugriffe auf Webseiten zu erkennen. Der Schwerpunkt der Arbeit liegt dabei
auf der kritischen Analyse und Bewertung einer solchen Vorgehensweise.
Im Rahmen dieser Arbeit ist eine Software entstanden, die durch Anwendung von selbstlernenden Systemen in der Lage ist, Zugriffsmuster auf Webseiten zu beurteilen. Hierfür werden
Self Organizing Maps auf Basis von Zugriffprotokollen eines Web-Servers trainiert, das normale Verhalten von Benutzern abzubilden, so dass davon abweichende Verhaltensmuster
erkennbar sind. Die Ergebnisse der Berechnungen dieser Software sind daher Grundlage für
die Beurteilung der verwendeten Verfahren.
1.1 Hintergrund und Motivation
Aktuelle Systeme zur Filterung von automatisierten Zugriffen verwenden häufig eine regelbasierte Erkennung von abweichendem, nicht menschlichem Zugriffsverhalten. Dieser Ansatz
hat mehrere Schwächen, insbesondere da er nur in der Lage ist, bekannte Verhaltensweisen
zu erkennen, und bei Kenntnis der Regeln leicht umgangen werden kann.
Statt also zu definieren, welches Zugriffsverhalten abweichend ist, soll hier versucht werden, mittels eines selbstlernenden Verfahrens zu erkennen, welche Verhaltensweisen normal
sind. Weicht ein Zugriffsmuster zu stark hiervon ab, so wird es sich sehr wahrscheinlich um
einen automatisierten Zugriff handeln. Als Basis für diese Analyse sollen in der BeispielImplementation der Arbeit reelle Zugriffslogs des Apache-Webservers verwendet werden.
Die Wahl des selbstlernenden Verfahrens fällt dabei auf die oben genannten Selbstorganisierende Karten (englisch Self Organizing Map, kurz SOM, nach dem Erfinder Teuvo Kohonen
auch oft Kohonennetz genannt). Dieser Algorithmus ermöglicht es, hochdimensionale Daten
1
1 Einleitung
zu Darstellungs- oder Auswertungszwecken auf niederdimensionale Ausgaberäume abzubilden. Häufig wird hierfür eine zweidimensionale Abbildung gewählt, welche eine einfache und
intuitiv erfassbare Darstellung der abzubildenden Daten ermöglicht. Damit sind Selbstorganisierende Karten kein klassisches Klassifizierungsverfahren, erlauben aber eine vereinfachte
Auswertung der Ergebnisse.
Der Algorithmus ist zudem in der Lage, unüberwacht zu lernen, benötigt also im Gegensatz zu vielen anderen Algorithmen auf Basis von künstlichen neuronalen Netzwerken keine
speziellen Zieldaten, an deren Abbildung sich angenähert wird. Solche Daten bereitzustellen
wäre bei dieser Problemstellung unmöglich, da man ein Zugriffsprotokoll dafür um Einträge
von automatisierten Zugriffen bereinigen müsste - diese zu erkennen ist ja aber gerade das
Ziel.
1.2 Zielsetzung
Es gilt zu beurteilen, ob dieses Verfahren dazu geeignet ist, solche Informationen zu ermitteln.
Hierbei spielen insbesondere Präzision und Zuverlässigkeit eine Rolle, sowie die Laufzeit des
Algorithmus: Für eine Verwendung zur Abwehr von automatisierten Zugriffen muss das
Verfahren diese nach Möglichkeit in Echtzeit erkennen. Das heißt, dass die Bewertung von
Zugriffen schnell genug geschehen muss, um die eigentliche Arbeit eines Web-Servers (die
Auslieferung von Inhalten) nicht zu beeinträchtigen, so dass automatisierte Zugriffe nach
Möglichkeit sofort nach ihrem Auftreten erkannt werden können.
Es gilt daher, die Zugriffprotokolle derart aufzubereiten, dass sie von dem Algorithmus sinnvoll verarbeitet werden können. Dabei sollen sich einander ähnliche Zugriffsmuster (Zugriffsabfolgen des jeweils gleichen Aufrufers der Webseite) auf der entstehenden Karte örtlich nah
beieinander abbilden. Eine einmal derart trainierte SOM kann dann zu einem neuen, gegebenen Zugriffsmuster die zugehörigen im Ausgangsraum abgebildeten Orte ermitteln. Folgen
diese nicht dem Abbildungsverhalten natürlicher Zugriffe, so kann davon ausgegangen werden, dass es sich bei diesem Zugriffsmuster um einen automatisierten Zugriff handelt.
Im Rahmen dieser Arbeit wurden daher mehrere Verfahren zur Abbildung von Zugriffsprotokollen durch Selbstorganisierende Karten und deren Auswertung erarbeitet und bewertet.
2
In diesem Kapitel sind alle im Rahmen der Arbeit verwendeten Algorithmen und Verfahren
in Bezug auf Self-Organizing Maps (im Weiteren kurz SOM ) erläutert. Auf eine grundlegende
Erklärung des Self-Organizing Map-Algorithmus folgt eine Beschreibung, wie aus beliebigen,
nicht-numerischen Daten Trainings-Vektoren erstellt werden können. Abschließend werden
einige in dieser Arbeit verwendete Verfahren zur Geschwindigkeitsoptimierung des SOM Algorithmus betrachtet, welche dabei helfen, die bei großen Datenmengen enorme Laufzeit
des Trainings einer Self-Organizing Map zu verkürzen, ohne dabei signifikant an Präzision
zu verlieren.
2.1 Der SOM-Algorithmus
Das Verfahren der so genannten Self Organizing Map (oder auch Self-Organizing Feature
Map) wurde 1981 erstmals von Professor Teuvo Kohonen erforscht [Koh01, Seite XI]. Inspiriert durch das Lernverhalten des menschlichen Gehirns, handelt es sich hierbei um einen
Algorithmus aus der Klasse der künstlichen neuronalen Netze. Er ermöglicht es, Daten aus
einem hochdimensionalen Eingaberaum in einen niederdimensionalen Ausgaberaum (häufig
bidimensional) abzubilden. Dabei werden ähnliche Eingabewerte örtlich nah beieinander abgebildet, so dass automatisch eine Bündelung inhaltlich verwandter Daten erfolgt. Zudem ist
das Verfahren in der Lage, unüberwacht zu lernen, benötigt also im Gegensatz zu vielen anderen Algorithmen auf Basis von künstlichen neuronalen Netzen keine speziellen Zieldaten,
an deren Abbildung sich angenähert wird [Koh01, Seiten 105ff].
Als einfaches Beispiel für die Erklärung des Verfahrens wird im Folgenden die Abbildung
von Farben, repräsentiert durch dreidimensionale Vektoren mit den Komponenten Rot, Grün
und Blau, auf den zweidimensionalen Raum einer Rastergrafik verwendet (siehe Abbildung
2.3).
3
2.1.1 Formale Definition
Eine Self Organizing Map ist ein 5-Tupel, bestehend aus einem Eingaberaum E, einem
Ausgaberaum A mit den Ausdehnungen l1 . . . ln , einer Menge Knoten K, attribuiert1 mit
Referenzvektoren M sowie einer endlichen Menge Trainingsvektoren X:
SOM = (E, A, K, M, X)
(2.1)
mit
E = ℜm
A ⊆ ℜn
K = {k~i ∈ A | i ≤ l1 · l2 · . . . · ln }
M
= {m
~ i ∈ E | i ≤ l1 · l2 · . . . · ln }
X = {x~j ∈ E}
Die hier verwendeten Begriffe werden im folgenden Abschnitt näher erläutert.
2.1.2 Begriffserklärungen
Für die Erklärung des SOM-Algorithmus werden gleichermaßen neue Begriffe eingeführt und
bekannte Begriffe in einer von ihrer natürlichsprachigen Verwendung verschiedenen Bedeutung verwendet. Um das Verständnis des Algorithmus zu vereinfachen, sind diese Begriffe
im Folgenden erklärt.
Neuronen oder Knoten
Die Neuronen (im Weiteren als Knoten bezeichnet) einer SOM
bilden eine vereinfachte Repräsentation des Ausgaberaums (siehe unten): Sie sind hierbei in
einem rechteckigen oder hexagonalen Gitter angeordnet und bilden so diskrete, quantisierte
Koordinaten des Ausgaberaums ab. Jeder dieser Knoten ist mit jeweils einem so genannten
Referenzvektor verknüpft.
Attribuierung
Wird ein Objekt mit zusätzlichen Eigenschaften versehen, so dass diese auf
einfache Weise über dieses Objekt abrufbar sind, so spricht man von Attribuierung. Im Rah1
4
Das Wort „attribuieren“ (mit Attributen versehen) wird insbesondere in der Informatik häufig als Anglizismus „attributieren“ geschrieben. Die korrekte deutsche Schreibweise ist allerdings „attribuieren“ [dud06].
men des SOM-Algorithmus ist hiermit in der Regel das Attribuieren von Knoten mit auf
diese abgebildeten Trainingsdaten gemeint.
Referenzvektor
Ein Vektor mit gleicher Dimension wie Elemente des Eingaberaums. Alle
Knoten sind mit einem Referenzvektor attribuiert. Die Referenzvektoren sind hierbei analog
zu den Trainingsvektoren (das heißt sie haben den gleichen Aufbau, siehe Abschnitt 2.1.2:
Trainingsdaten) und werden durch den SOM-Algorithmus iterativ an diese angenähert. Im
verwendeten Beispiel ist der Eingaberaum der Raum aller RGB-Farben. Jeder Knoten hat
hier somit eine Farbinformation. Dies ermöglicht eine sehr einfache Visualisierung der SOM
als Rastergrafik, in der jeder Knoten einem Pixel entspricht (siehe Abbildung 2.3).
Eingaberaum Hochdimensionaler Raum der Eingabedaten. Zu diesem Raum gehören alle
Daten, die mit Hilfe der SOM abgebildet werden sollen. Im verwendeten Beispiel ist dies der
dreidimensionale Raum aller RGB-Farben mit den Komponenten Rot, Grün und Blau.
Ausgaberaum Niederdimensionaler Raum, auf welchen Eingabedaten projeziert werden.
Es gilt Dim(Eingaberaum) > Dim(Ausgaberaum). Die Knoten der SOM sind in diesem
Raum in einem Gitter angeordnet (siehe Abbildung 2.1) und bilden so die Koordinaten
der entstehenden Karte ab. Im verwendeten Beispiel ist dies der 2D-Raum, welcher sich
besonders einfach visualisieren lässt.
Trainingsdaten Diskrete Teilmenge aller Daten des Eingaberaums, welche zum initialen
Training der SOM verwendet werden. Mit Hilfe dieser Daten lernt der SOM-Algorithmus,
Elemente des Eingaberaums auf Knoten im Ausgaberaum abzubilden (siehe Abschnitt 2.1.4:
Training). Ein einzelnes Element der Trainingsdaten wird als Trainingselement bezeichnet,
eine entsprechende numerische Abbildung dessen als Trainingsvektor. Sind die Trainingsdaten bereits numerische Informationen, so bezeichnen die Begriffe Trainingselement und
Trainingsvektor das Gleiche. Handelt es sich aber im Gegensatz dazu bei den Trainingsdaten um nicht-numerische Daten, so meint Trainingselement ein Element dieser Originaldaten
und Trainingsvektor eine numerische Abbildung dieses Elements (siehe auch Abschnitt 2.2.1:
Bildung des Alphabets).
Training Der initialen Prozess, die Referenzvektoren der Knoten einer SOM iterativ an
die Traingsdaten anzugleichen, um eine nicht-lineare Projektion des Eingaberaums zu erreichen, wird Training genannt. Dabei werden einander ähnliche Trainingselemente in der SOM
räumlich nah beieinander abgebildet, so dass die Topologie (das heißt die Nachbarschafts-
5
beziehungen) des Eingaberaums weitestgehend erhalten bleibt und eine implizite Bündelung
der Daten entsteht (siehe Abschnitt 2.1.4: Training).
Best Matching Unit
Unter der Best Matching Unit (kurz BMU ) wird der Knoten verstan-
den, welcher in einem konkreten Trainingsschritt dem ausgewählten Trainingselement am
ähnlichsten ist (siehe Abschnitt 2.1.4.3: Bestimmung der Best Matching Unit). In der Regel
ist damit gemeint, dass der Referenzvektor der BMU die kleinste Euklidische Distanz (siehe
Gleichung 2.5) zum Trainingselement hat.
2.1.3 Topologischer Aufbau
Um das Verfahren des SOM-Algorithmus verstehen zu können, ist zunächst ein Verständnis
des topologischen Aufbaus einer Self Organizing Map nötig. Daher sollen hier noch vor der
Beschreibung des eigentlichen Algorithmus die einzelnen Elemente einer SOM und deren
Zusammenspiel erläutert werden.
}
Zweidimensionale (hier 8x8)
Struktur von Knoten, jeweils
mit Referenzvektor der
Dimension N attribuiert.
Alle Knoten sind mit allen
Eingangs-Daten verbunden
(siehe Pfeile), nicht aber
untereinander.
Liste von Eingangsvektoren der Dimension N
Abbildung 2.1: Topologie einer SOM
Eine Self Organizing Map besteht aus einem rechteckigen oder hexagonalen Gitter von Neuronen (vereinfacht Knoten genannt) im Ausgaberaum. Auch wenn das SOM -Verfahren aus
dem Gebiet der künstlichen neuronalen Netze kommt, gibt es nur wenig Gemeinsamkeiten
mit anderen Verfahren dieses Gebiets. Denn hier sind die Knoten untereinander nicht verbunden; außer ihrer räumlichen Anordnung gibt es keinerlei logischen Zusammenhang zwischen
einzelnen Knoten. Stattdessen ist jeder einzelne Knoten ki mit allen Trainings-Elementen
des Eingaberaums verknüpft (siehe Abbildung 2.1) und ist mit einem Referenzvektor mi
attribuiert, mit welchem er während des Lernprozesses verglichen wird.
6
2.1.4 Training
Nachdem die grundlegende Struktur einer SOM dargelegt wurde, wird im Folgenden das
Training der SOM beschrieben. Hierzu werden die mit den Knoten attribuierten Referenzvektoren iterativ an die Trainingsdaten angenähert, wobei einander ähnliche Werte örtlich
nahe beieinander abgebildet werden. Generell lässt sich das Training in folgende Schritte
unterteilen:
1. Initialisieren der Referenzvektoren
2. Wiederhole solange der Algorithmus nicht terminiert (siehe Abschnitt 2.1.4.5: Konvergenz
der SOM):
a) Wähle einen Trainingsvektor aus der Liste der Trainingselemente
b) Finde die Best Matching Unit (BMU) zum gewählten Trainingsvektor
c) Nähere die Referenzvektoren im Radius r um die BMU anhand der Abstandsfunktion h an Trainingsvektor an
2.1.4.1 Initialisieren der Referenzvektoren
Damit der Trainings-Algorithmus sinnvoll arbeiten kann, müssen die Referenzvektoren zunächst im Wertebereich aller Trainingsvektoren x~i initialisiert werden. Konkret bedeutet
dies, dass alle Elemente eines Referenzvektors zwischen den Werten zmin und zmax liegen
müssen, mit
zmin = min{xi,k }
(2.2)
zmax = max{xi,k }
(2.3)
i,k
i,k
wobei xi,k jeweils das k-te Element des i-ten Trainingsvektor ist. Es reicht, die Elemente der
Referenzvektoren mit Zufallszahlen innerhalb dieses Wertebereiches zu belegen, denn für das
Endergebnis spielen die initialen Werte der Karte keine Rolle. Es wurde allerdings gezeigt
[Koh01, Seite 142], dass das Konvergieren der SOM wesentlich beschleunigt werden kann,
wenn die Referenzvektoren initial in einer beliebigen Ordnung liegen. Hierzu wurden mehrere
Verfahren zur linearen Initialisierung entwickelt: Beispielsweise schlägt Kohonen selbst eine
lineare Interpolation auf Basis der Eigenvektoren der Autokorrelationsmatrix der Trainingsdaten vor [Koh01, Seiten 142ff] und in [MCSC02] wird eine Interpolation von signifikaten
Trainingselementen vorgeschlagen. Diese Verfahren übersteigen in ihrer Komplexität allerdings den Rahmen dieser Arbeit, weshalb sie hier nur der Vollständigkeit halber erwähnt
sind und nicht weiter betrachtet werden.
7
Statt dieser komplexen Verfahren hat sich in der Praxis ein wesentlich einfacheres bewährt
[KKL+ 01, Seiten 14ff]: Das Trainieren einer sehr kleinen SOM (beispielsweise 4 x 4 Knoten)
benötigt nur einen Bruchteil der Zeit, die für die Berechnung größerer Karten nötig ist. Die
dadurch entstehende Abbildung besitzt nicht die nötige Präzision, um als Bewertungsgrundlage für diese Arbeit zu dienen, kann aber mittels einfacher linearer Interpolation auf die
gewünschte Größe skaliert werden und bietet so eine fundierte Grundlage für die Initialwerte
der tatsächlich zu trainierenden Karte.
2.1.4.2 Wahl des Trainingselements
Es wird angenommen, dass es sich bei den Trainingselementen um eine bekannte, endliche
Liste aus Vektoren handelt, aus welcher für jeden Trainingsschritt ein Element entnommen
wird. Zu diesem wird im Folgeschritt die so genannte Best Matching Unit gesucht, um alle
Referenzvektoren in einem Radius um die BMU herum an das gewählte Trainingselement
anzunähern (siehe unten).
Auch wenn es mathematisch präziser wäre, dieses Element zufällig zu wählen, hat eine zyklische Wahl (das heißt iterativ vom ersten Element der Liste bis zum letzten; dann wieder von
vorne) praktisch keinen Nachteil [Koh01, Seite 160]. Da diese Auswahl zudem dem einfachen
Iterieren über die Liste entspricht und somit leichter zu implementieren ist, wird sie hier
bevorzugt.
2.1.4.3 Bestimmung der Best Matching Unit
Ist ein Trainingselement ausgewählt, so wird die zugehörige Best Matching Unit gesucht.
Umgangssprachlich formuliert, ist dies der Knoten, dessen Referenzvektor zum ausgewählten
Trainingsvektor am ähnlichsten ist.
Mathematisch lässt sich dieser Sachverhalt wie folgt formulieren: Zu einem Trainingsvektor xj der Knoten kc mit dem Referenzvektor mc gesucht wird, welcher zu xj die kleinste
Euklidische Distanz hat:
kx~j − m
~ c k = min {kx~j − m
~ i k}
i∈[0,n]
(2.4)
wobei n die Zahl aller Knoten ist und die Euklidische Distanz definiert ist als
v
u n
uX
k~
p − ~qk = t (pi − qi )2
i=1
8
(2.5)
2.1.4.4 Annäherung der Referenzvektoren
Nähert man die Referenzvektoren aller Knoten, welche im Knotengitter der SOM örtlich
nah zur BMU des ausgewählten Trainingselements sind, an dieses an, so erreicht man einen
lokalen Glättungseffekt. Dies bedeutet, dass diese Referenzvektoren einander ähnlicher werden (also die paarweise Euklidische Distanz geringer wird). Bei fortlaufendem Training führt
die wiederholte lokale Glättung der Knoten zu einer globalen Ordnung in der SOM : Einander ähnliche Referenzvektoren sind örtlich nah beieinander, stark verschiedene werden
weiter voneinander entfernt auf der Karte angeordnet. Es wird also zunehmend eine „nichtlineare Projektion“ des durch die Trainingsdaten definierten Eingaberaums auf den durch
die Knoten der SOM definierten Ausgaberaum erreicht [Koh01, Seite 110].
Für das Training der SOM bedeutet dies, dass alle Referenzvektoren m
~ i von Knoten innerhalb eines Radius r um die gefundene BMU mit dem Referenzvektor m
~ c gemäß einer
Abstandsfunktion h(t) an den Trainingsvektor angenähert werden:
m
~ i (t + 1) = m
~ i (t) + hci (t)[~x(t) − m
~ i (t)]
(2.6)
wobei t = {0, 1, 2, ..} die diskrete Zeitkoordinate ist, welche den aktuellen Iterationsschritt
des Trainings angibt. Die Abstandsfunktion hci (t) für den Referenzvektor m
~ c einer BMU
und den Referenzvektor m
~ i eines anderen Knotens lässt sich dabei definieren als
hci (t) =



 α(t)



0
wenn km
~c − m
~ i k ≤ r(t)
(2.7)
sonst
Hierbei ist α(t) der so genannte Lernratenfaktor mit 0 < α(t) < 1, welcher den Einfluss des
Trainingsvektors auf die Referenzvektoren skaliert. Der Initialwert dieses Faktors liegt in der
Regel nahe bei 1, um dann in Abhängigkeit zu t monoton zu fallen [Koh01, Seite 111]:
α(t) =
A
B+t
(2.8)
A und B sind hierbei entsprechend gewählte Konstanten, mit A ≤ B [Koh01, Seite 145]. Allgemein gilt: Je geringer der Lernraten-Faktor, insbesondere in den ersten Iterationen, desto
glatter die Karte. Wichtig ist hierbei, dass sowohl der Radius r(t) als auch der Lernratenfaktor α(t) monoton in Abhängigkeit zu t fallen, so dass lim hci (t) = 0 gilt und das Training
t→∞
konvergieren kann (siehe Abbildung 2.2 und Abschnitt 2.1.4.5: Konvergenz der SOM).
9
r
BMU
(a)
BMU
r
(b)
Abbildung 2.2: Beispiele der Abstandsfunktion bei steigendem t
Eine alternative Abstandsfunktion, bei der weiter von der BMU entfernte Knoten weniger
stark verändert werden, ist die Gaußsche Glockenkurve:
km
~c − m
~ i k2
hci (t) = α(t) · exp −
2r 2 (t)
!
(2.9)
Die in Rahmen dieser Arbeit durchgeführten Experimente haben allerdings gezeigt, dass
diese Abstandsfunktion in der Praxis nur zu marginalen Änderungen gegenüber der einfacheren Variante (Gleichung 2.7) führt, solange die SOM eine Größe von einigen hundert
Knoten nicht übersteigt (vergleiche hierzu auch [Koh01, Seite 111]). Da die Berechnung der
Gaußschen Glockenkurve zudem offensichtlich rechenaufwendiger als eine einfache Abstandsbestimmung ist, wurde Gleichung 2.7 in dieser Arbeit als Abstandsfunktion bevorzugt.
(a) Initiale Zufallswerte
(b) Nach 20 Interationen
(c) Nach 60 Iterationen
(d) Nach 100 Iterationen
(e) Nach 200 Iterationen
(f) Nach 400 Iterationen
Abbildung 2.3: Lernverhalten einer SOM zur Abbildung von Farbinformationen in verschiedenen Iterationsschritten
10
Beim verwendeten Beispiel ist die Menge der Trainingsvektoren X eine dreidimensionale
(RGB-)Repräsentation der Farben mit Zahlenwerten zwischen 0 (minimale Intensität) und
255 (maximale Intensität):
x = ([0, 0, 0]T (Schwarz), [255, 255, 255]T (Weiss), [255, 0, 0]T (Rot), [0, 255, 0]T (Grün), . . .)T
Dadurch lassen sich die Neuronen sehr einfach als Rasterbild visualisieren:
Jeder Referenzvektor entspricht genau einem Pixel und hat, zu Ganzahlen gerundet, seine
Elemente als RGB-Farbinformation. Der Status der SOM ist in Abbildung 2.3 für verschiedene Iterationsschritte auf diese Art dargestellt. Hier lässt sich einfach erkennen, dass in den
ersten Iterationen sehr große Änderungen vorgenommen werden, um aus den ungeordneten,
zufälligen Initialwerten eine grobe, globale Ordnung zu schaffen. Mit fortlaufender Iterationszahl wird der Einfluss-Radius r(t) der Änderungen und das Ausmaß der Änderungen α(t)
selbst immer kleiner, so dass auch feine Differenzen im Eingangsraum abgebildet werden und
die SOM schließlich zu einer nicht-linearen Projektion dessen konvergiert. Im Ergebnis lässt
sich zudem die implizite Datenbündelung (englisch: Clustering) des SOM-Algorithmus gut
erkennen: Ähnliche Farben sind örtlich nah beieinander. So wurde zum Beispiel die Farbe
Violett zwischen den Farben Blau und Rot abgebildet, da Violett sowohl rote als auch blaue
Komponenten beinhaltet.
2.1.4.5 Konvergenz der SOM
Bei einem Algorithmus, der sich iterativ an einen bestimmten Zustand annähert, spricht
man von Konvergenz, wenn dieser Zustand erreicht wurde [Koh01, Seite 129]. Das Training einer SOM gilt daher als konvergiert, wenn alle Referenzvektoren m
~ i während eines
Iterationsschritts im Vergleich zum vorherigen nicht verändert werden:
∀i, lim km
~ i (t + 1) − m
~ i (t)k = 0
t→∞
(2.10)
Da die Änderungen der Referenzvektoren in späten Iterationen nur minimal sind und somit
nur wenig zur Verbesserung der Qualität der SOM beitragen, kann das Training der SOM
bereits vor der tatsächlichen Konvergenz terminiert werden. Hierfür wird ein Toleranzwert
ǫ > 0 definiert und der Algorithmus terminiert, sobald der durschnittliche Änderungsbetrag
der Referenzvektoren diesen Wert unterschreitet:
ǫ>
Pn
~ i (t
i=0 km
+ 1) − m
~ i (t)k
n
(2.11)
wobei n die Anzahl aller Referenzvektoren ist.
11
2.1.4.6 Kalibrierung
Unter Kalibrierung versteht man das Attribuieren der berechneten Karte mit den Trainingsdaten, um bei einer visuellen Darstellung der SOM erkennen zu können, wo diese abgebildet
wurden. Im Falle von RGB-Farbinformationen, wie im verwendeten Beispiel, ist dies nicht
nötig, da die Referenzvektoren selbst leicht als Pixel eines Rasterbildes abzubilden sind.
Sollen allerdings andere Arten von Daten abgebildet werden, insbesondere nicht-numerische
Daten wie natürliche Sprache oder Zeichenketten, so geben die entstandenen Referenzvektoren selbst keinen für Menschen intuitiv lesbaren Aufschluss über die durch sie abgebildeten
Trainingsdaten. Daher ist es sinnvoll, hier noch einmal alle Trainingselemente zu durchlaufen,
jeweils die Best-Matching-Unit zu finden und diesen Knoten mit den zum Trainingselement
gehörenden Originaldaten zu attribuieren. Bei der visuellen Darstellung einer SOM lassen
sich so die zum Training verwendeten Originaldaten sozusagen als Etiketten der Knoten
verwenden, was die Lesbarkeit der Karte stark erhöht.
Siehe Abschnitt 4.3.4.2: Interaktive Visualisierung der kalibrierten Karte für ein Beispiel zur
Verwendung einer solchen Kalibrierung.
2.1.5 Alternativer Algorithmus: Die Batch-Map
Es existiert eine Abwandlung des originalen SOM-Algorithmus, welche keinen LernratenFaktor α(t) benötigt (siehe Abschnitt 2.1.4.4: Annäherung der Referenzvektoren) und daher
stabiler konvergiert [Koh01, Seiten 139ff]. Dieses Verfahren, Batch-Map genannt, verarbeitet
zudem alle Trainingselemente in jeder Iteration gemeinsam (statt sie einzeln zu durchlaufen)
und ist daher bei einer sehr großen Zahl solcher um ungefähr eine Größenordnung effizienter
als der Original-Algorithmus [Koh01, Seite 312]. Der Trainingsprozess des Algorithmus lässt
sich wie folgt beschreiben:
1. Initialisieren der Referenzvektoren
2. Solange das Training der SOM nicht terminiert:
a) Sammle für jeden Knoten ki mit dem Referenzvektor m
~ i eine Liste aller Trainingsvektoren x~i , für welche ki die Best-Matching-Unit ist
b) Setze den Durchschnittswert der Vereinigung aller Trainigsvektor-Listen in der
Nachbarschaft Ni als neuen Referenzvektor m
~i
Für die Bestimmung der Best-Matching-Unit und der Nachbarschaft Ni eines Knotens ki gelten die gleichen Verfahren, wie sie auch beim Original-Algorithmus (siehe Abschnitt 2.1.4:
Training) verwendet werden. Die Batch-Map ist also im Aufbau und Verhalten identisch
zum bisher beschriebenen, originalen Algorithmus; ausschließlich das Training unterscheidet sich. Statt die Differenz der Trainingsvektoren und BMU um α(t) skaliert schrittweise
12
2.2 Aufbereitung abstrakter Daten zu Trainings-Vektoren
einzurechnen, wird das arithmetische Mittel aller im Radius zutreffenden Trainingsvektoren
direkt als neuer Referenzvektor gesetzt. Das daraus resultierende Ergebnis ist zu dem des
Original-Algorithmus gleichwertig [Koh01, Seite 139].
Damit der letzte Schritt dieses Algorithmus gültig ist, darf allerdings keine Nachbarschaftsfunktion verwendet werden, die Referenzvektoren anhand ihrer Entfernung zur BMU gewichtet (wie beispielsweise Gleichung 2.9, die Gaußsche Glockenfunktion). Soll eine solche
verwendet werden, so muss der Algorithmus entsprechend angepasst werden (siehe [Koh01,
Seite 140]).
Da im Rahmen dieser Arbeit eine sehr große Zahl von Trainingsdaten ausgewertet werden
müssen (Apache-Zugriffsprotokoll-Dateien haben in der Regel mehrere zigtausende Zeilen),
wurde für alle Experimente dieser Batch-SOM -Algorithmus verwendet.
In seiner Reinform ist der SOM-Algorithmus offensichtlich nur in der Lage, numerische Daten
zu verarbeiten. Zwar ist es möglich, den Algorithmus entsprechend für eine andere Art
von Daten anzupassen (siehe [Koh01, Seiten 205ff] für eine Variante zur Verarbeitung von
Zeichenketten), allerdings würde dies den Algorithmus auf die Verwendung einer bestimmten
Form von Daten beschränken. Zur Verwendung von beliebigen, für den SOM-Algorithmus
abstrakten Daten ist daher einfacher, ein allgemeingültiges Verfahren zum Abbilden dieser
auf numerische Werte zu entwickeln.
Im Folgenden ist das für diese Arbeit verwendete Verfahren beschrieben.
2.2.1 Bildung des Alphabets
Möchte man den SOM-Algorithmus also verwenden, um nicht-numerische Daten abzubilden,
so müssen diese zunächst in ein numerisches (Vektor-)Format übertragen werden. Hierbei
ist es besonders wichtig, dass dieses Format keinerlei ungewünschte semantische Informationen über die Quelldaten abbildet: Im Fall von natürlichsprachigen Wörtern könnte man
beispielsweise auf die Idee kommen, diese mittels einer geeigneten Hash-Funktion 2 in numerische Daten umzurechnen. Dies hätte aber (je nach verwendeter Hash-Funktion) den
Nebeneffekt, dass ähnliche Wörter3 auch zu ähnlichen numerischen Werten führen würden.
2
Hash-Funktionen erzeugen zu einer Datenmenge einen so genannten Fingerabdruck, meist ein skalarer Wert
einer kleineren Zielmenge [Ste07, Seiten 221ff]
13
Dies ist für den SOM-Algorithmus entscheidend, da dieser die Wörter auch automatisch
örtlich nah beieinander auf der entstehenden Karte abbilden würde.
Soll diese Information aber nicht transportiert werden, etwa wenn man die Wörter nur anhand ihrer Verwendung abbilden möchte, so müssen die entstandenen Vektoren linear unabhängig sein. Da das Testen auf lineare Unabhängigkeit das Lösen eines komplexen linearen
Gleichungssystems erfordert, ist es hier geeigneter, lineare Unabhängigkeit durch Verwendung von paarweise orthogonale Vektoren zu erreichen [Hon97].
Paarweise orthogonale Vektoren lassen sich einfach erzeugen, indem man jedem eindeutigen
Quelldatum einen Achsenvektor zuweist:
x1 = [1, 0, 0, . . . , 0, 0]T
x2 = [0, 1, 0, . . . , 0, 0]T
...
xn = [0, 0, 0, . . . , 0, 1]T
Wobei n die Anzahl der eindeutigen Quelldaten ist, mehrfache Vorkommen des selben Quelldatums also nur einfach gezählt werden [Hon97]. Im Fall von natürlicher Sprache würde also
beispielsweise immer jeweils ein Wort durch einen Achsenvektoren in dieser Form eindeutig
abgebildet werden:
Baum
[1, 0, 0, 0, 0, 0, . . . , 0]T
hat
[0, 1, 0, 0, 0, 0, . . . , 0]T
Erdbeere
[0, 0, 1, 0, 0, 0, . . . , 0]T
Prozessor
[0, 0, 0, 1, 0, 0, . . . , 0]T
Element
[0, 0, 0, 0, 1, 0, . . . , 0]T
beginnt
[0, 0, 0, 0, 0, 1, . . . , 0]T
...
...
Anhang
[0, 0, 0, 0, 0, 0, . . . , 1]T
Tabelle 2.1: Abbildung von natürlichsprachigen Wörtern durch Achsenvektoren
3
Natürsprachliche Wörter gelten hier als ähnlich, wenn ihre Levenshtein-Distanz gering ist. Die LevenshteinDistanz misst die Anzahl an Zeichenmanipulationen, die zur Überführung eines Wortes in ein anderes nötig
ist [Dam64].
14
Diese Sammlung von repräsentativen Vektoren, die eindeutigen Elementen einer für den
SOM-Algorithmus abstrakten Quelldatenmenge zugeordnet sind, wird als Alphabet der SOM
bezeichnet, ein einzelner dieser Vektoren als Wortvektor [Hon97].
Diese Art der Abbildung hat allerdings den Nachteil, dass die Dimension der entstehenden
Vektoren (und damit die verbundenen Berechnungskosten im SOM-Algorithmus) linear mit
der Anzahl der abzubildenden Wörter steigt. Auch lässt sich im Nachhinein kein neues Wort
hinzufügen, da die Anzahl der Wörter bereits vor der Zuweisung bekannt sein muss, um die
Dimension der Vektoren zu bestimmen.
Natürlich existieren weitere Verfahren, um bestimmte Daten für die Verwendung in SOMs
in numerische Formate zu übertragen, mit ihren eigenen Vor- und Nachteilen. Beispielweise wurden für die Klassifizierung von Text-Dokumenten im so genannten WebSOM -Projekt
so genannte Worthistogramme verwendet, welche die relative Auftrittshäufigkeit von Wörtern abbilden, und somit ein numerisches Format ist [LKK04]. Für die Aufbereitung von
Zugrifflogs des Apache-Webservers wird allerdings eine 1:1-Abbildung der Zugriffe benötigt
(siehe auch Abschnitt 4.3.2.2: Alphabetgenerierung), weshalb solche Herangehensweisen nicht
in Frage kommen und im Rahmen dieser Arbeit oben genanntes Verfahren verwendet wird.
2.2.2 Semantische Aggregation
Möchte man den Zusammenhang von Quelldaten abbilden, so muss der semantische Kontext der Daten bei der Bildung von Trainingsvektoren berücksichtigt werden. Am einfachsten lässt sich dies am Beispiel von so genannten Wortkategorie-Karten erklären, welche den
semantischen Zusammenhang von natürlichsprachigen Wörtern abbilden: Inhaltlich zusammenhängende Wörter werden auf dieser Karte örtlich nah beieinander abgebildet [Hon97].
Als Trainingsdaten dienen hierbei eine möglichst große Menge an Fließtexten. Nach eventueller Entfernung von so genannten Stoppwörtern, also Füllworten ohne semantische Bedeutung
wie Artikel, wird hier nach oben genanntem Verfahren jedem auftretendem Wort ein Vektor
zugewiesen. Ausgehend davon werden nun die Fließtexte Wort für Wort durchschritten und
aus Dreiergruppen jeweils ein Kontextmuster nach folgender Form gebildet, welches dann als
konkreter Trainingsvektor für den SOM-Algorithmus verwendet wird:
Nehmen wir an, dass der Fließtext genau 7 verschiedene Wörter enthält, so lässt sich ein
einzelnes Wort durch einen Vektor ~z ∈ ℜ7 abbilden. Wenn nun z~i der Vektor ist, der das
Wort an der Position i im Fließtext repräsentiert, so lassen sich die Trainingsvektoren x~i wie
folgt beschreiben:
x~i = [zi−1
~ T , z~i T , zi+1
~ T ]T ∈ ℜ21
(2.12)
15
Das heißt , ein Trainingsvektor ~x ist jeweils die Konkatenation aus den Wortvektoren, die
das Wort vor dem aktuell betrachteten, das aktuell betrachtete und das nachfolgende Wort
abbilden [Koh01, Seite 284]. Dadurch haben Trainingsvektoren, die Vektoren gleicher Wörter
beinhalten, eine geringe Euklidische Distanz, so dass sie auf der SOM nah beieinander abgebildet werden. Dies führt dazu, dass eine Karte entsteht, auf der Wörter, die in ähnlichen
Kontexten verwendet werden (also semantische Gemeinsamkeiten haben), örtliche Ballungen
bilden [Hon97].
Da nur der Mittelteil der Trainingsvektoren die eigentlichen Wörter repräsentiert, ist auch
nur dieser für die Kalibrierung (siehe Abschnitt 2.1.4.6: Kalibrierung) relevant. Daher lassen
sich hierfür neue Vektoren der Form ~x = [⊘, z~i T , ⊘]T bilden, wobei ⊘ bedeutet, dass diese Teile nicht für die Abstandsberechnung beim Suchen der BMU (siehe Abschnitt 2.1.4.3:
Bestimmung der Best Matching Unit) berücksichtigt werden. Die gefundenen Knoten können so mit den eigentlichen Wörtern (statt Wort-Dreiergruppen) attribuiert werden [Koh01,
Seiten 284ff].
2.3 Verfahren zur Optimierung
Der SOM-Algorithmus (unabhängig von der Variante) ist nicht besonders komplex, lediglich
das Bestimmen der Best Matching Unit ist rechenintensiv, insbesondere wenn die Euklidische
Distanz als Kriterium verwendet wird:
Pro Vergleich werden hier mehrere komplexe Operationen durchgeführt, vor allem das nötige
Berechnen der Quadratwurzel treibt die Rechenzeit in die Höhe (vergleiche Gleichung 2.5).
Da die Anzahl der durchzuführenden Vergleiche pro Iteration exponentiell mit der Größe der
Karte und linear mit der Anzahl der Trainingselemente steigt, kann die Berechnung einer
SOM bei einer großen Menge (50000 und aufwärts) mehrere Stunden dauern:
V =w∗h∗N
(2.13)
Wobei V die Gesamtzahl der pro Iteration auszuführenden Vergleiche, w und h die Breite
und Höhe der Karte und N die Anzahl der verwendeten Trainingselemente bezeichnen.
Für die im Rahmen dieser Arbeit durchgeführten Experimente wurde in der Regel eine Karte der Größe 16 x 16 Knoten mit ∼64000 Trainingsvektoren verwendet, was also mehr als
16 Millionen Berechnungen der Euklidischen Distanz pro Iteration entspricht. Bedenkt man
zudem, dass eine SOM in diesen Experimenten durchschnittlich ∼1200 Iterationen bis zur
Terminierung benötigte, so ist leicht ersichtlich, dass eine Optimierung (beziehungsweise Vereinfachung) der BMU -Berechnung enormes Beschleunigungspotential für den Algorithmus
beinhaltet. Im Folgenden sind daher mehrere hierfür geeignete Verfahren vorgestellt.
16
Abbildung 2.4: Skalarproduktsverteilung von Zufallsvektoren [Kas98]
2.3.1 Dimensionsreduzierung durch Random Mapping
Die Komplexität des Kernelements der BMU -Bestimmung, der Abstandsvergleich mittels
Euklidischer Distanz, ist offensichtlich proportional zur Dimension der Referenz- und Trainingsvektoren, da sie direkt die Anzahl der nötigen Rechenoperationen bestimmt. Eine Reduzierung der Dimension führt also zu einem erheblichen Gewinn an Recheneffizienz, wenn es
dabei gelingt, die Orthogonalität (beziehungsweise Unabhängigkeit) der Trainingsvektoren
ausreichend zu erhalten. Ausgehend von der Überlegung, dass es in einem gegebenen Vektorraum wesentlich mehr fast paarweise orthogonale Vektoren als tatsächlich orthogonale
Vektoren gibt, liegt der Gedanke nahe, die in Abschnitt 2.2.1: Bildung des Alphabets gebildeten, vollständig linear unabhängigen Achsenvektoren auf nahezu paarweise orthogonale
Zufalls-Vektoren mit geringerer Dimension abzubilden [Kas98].
Dass hierbei eine erhebliche Dimensionsreduzierung möglich ist (zur Erinnerung: die Dimension der Achsenvektoren ist abhängig von der Wortzahl, liegt also beispielweise bei natürlicher Sprache im Tausenderbereich), zeigt Abbildung 2.4, welche das Verhältnis von
paarweisen Skalarprodukten von Zufallsvektoren in Bezug auf deren Dimension d zeigt. Das
Skalarprodukt ist hierbei ein Indikator für die Orthogonalität der Vektoren: Je näher dieses
0 ist, desto orthogonaler und damit voneinander unabhängiger ist ein Vektorenpaar.
Die Abbildung von hochdimensionalen Achsen-Vektoren ~n ∈ ℜN auf niederdimensionale
Zufallsvektoren ~x ∈ ℜd erfolgt dabei durch Multiplikation mit einer Matrix R ∈ ℜd×N :
~x = R~n
(2.14)
17
Wobei R eine Matrix mit Zufallswerten ist, deren Spalten auf Einheitsgröße normalisiert
wurden. Das Ergebnis sind daher zu jedem Achsen-Vektor eindeutige, normalisierte Zufallsvektoren.
2.3.2 Abgekürzte BMU-Suche
Während Dimensionsreduzierung die Effizienz der für die BMU -Bestimmung nötigen Abstandsberechnung erhöht, ändert sie noch nichts am eigentlichen Verfahren. Hier gibt es
mehrere optimierte Algorithmen, die versuchen, die Abstandsvergleiche auf in Frage kommende Knoten zu beschränken, statt in jedem Schritt alle Knoten mit dem aktuellen Trainingselement zu vergleichen (siehe Abschnitt 2.1.4.3: Bestimmung der Best Matching Unit).
Zwei davon wurden für diese Arbeit verwendet und sind daher hier vorgestellt.
2.3.2.1 Quick-Reaction-Algorithmus
Selbst bei einer Initialisierung mit zufälligen Werten erreichen die Referenzvektoren einer
SOM bereits nach wenigen Iterationsschritten eine ungefähre Ordnung [Koh01, Seite 129].
Der Quick-Reaction-Algorithmus nutzt diese Eigenschaft, um sich iterativ an die BMU anzunähern [Mon94]. Er spannt ein 3x3-Gitter über die SOM, bei dem jedes Element r des
Gitters einen Knoten wr der SOM repräsentiert. Für eine zweidimensionale SOM mit der
Breite w und der Höhe h verhält sich der Algorithmus wie folgt:
1. Zentrum eines 3x3 - Gitters m
~ = [w ÷ 2, h ÷ 2]T
2. Abstand der Gitterelemente sp = max(w, h) ÷ 3
3. Setze m
~ old := m
~
4. Solange sp > 1 und m
~ old 6= m
~
a) Bestimme Gitterelement wr , dessen Referenzvektor die geringste Euklidische Dinstanz zum aktuellen Trainingselement hat
b) Setze Koordinaten von wr als neues Gitterzentrum m
~
c) Wenn m
~ old = m,
~ dann setze sp als (sp ÷ 2)
d) Setze m
~ old := m
~
5. Knoten wm an den Koordinaten m
~ ist die BMU für das aktuelle Trainingselement
Sollte sich das Gitter in Schritt 4a am Rand der SOM befinden, so dass Gitter-Elemente
außerhalb der SOM liegen, so werden diese für den Vergleich nicht beachtet. Das Verhalten
des Algorithmus kann anhand Abbildung 2.5 nachvollzogen werden [Mon94]:
Abbildung 2.5a zeigt den Initialstatus des Algorithmus. Die Knoten des 3x3-Gitters sind
gelb markiert, der Knoten wr mit geringster Distanz zum aktuellen Trainingselement ist
18
(a)
(b)
(c)
(d)
Abbildung 2.5: Beispiel des Quick-Reaction-Algorithmus bei einer 10x10-SOM
grün eingefärbt. Die tatsächliche BMU für das Trainingselement in diesem Iterationsschritt
ist schwarz markiert. Da der gefundene Knoten wr nicht der aktuelle Mittelpunkt des Gitters
m
~ ist, wird das Gitter verschoben, so dass wr der neue Mittelpunkt ist. Dies ist in Abbildung
2.5b abgebildet. Hier bleibt wr der Mittelpunkt des Gitters, daher wird der Abstand sp
zwischen den Gitterelementen halbiert, so dass der Suchbereich des Algorithmus verkleinert
wird. Im nächsten Schritt (siehe Abbildung 2.5c) ist wr wieder am Rand des Gitters, so
dass es erneut verschoben wird. Da im Folgeschritt (siehe Abbildung 2.5d) der Abstand sp
der Gitterelemente bereits 1 beträgt, das Gitter also nicht weiter verkleinert werden kann,
und wr der Mittelpunkt des Gitters ist, endet der Quick-Reaction-Algorithmus. wm , das
Gitterelement im Mittelpunkt des Gitters, ist also die gesuchte BMU.
2.3.2.2 BMU-Caching
Abbildung 2.6: Suche im Radius um zuvor gefundener BMU [Koh01, Seite 171]
Geht man davon aus, dass alle Trainingsvektoren von Anfang an bekannt sind, diese also
eine geschlossene und endliche Menge sind (in allen in dieser Arbeit vorgestellten Beispielen
der Fall, vergleiche Abschnitt 2.1.4.3: Bestimmung der Best Matching Unit) und die Knoten
der SOM bereits einer Ordnung unterliegen, kann man davon ausgehen, dass die zu einem
19
Trainingselement gefundene BMU in der direkten Nähe des Knotens liegt, welcher in der
vorherigen Iteration als BMU gefunden wurde. Dies ist insbesondere in späten Iterationen
der Fall, in welchen die beeinflusste Nachbarschaft eines Knotens sehr klein ist, und die
SOM sich in der langen Phase der Feinabstimmung befindet [Koh01, siehe 171]. Speichert
man nun für jedes Trainingselement Zeiger auf die in der vorherigen Iteration gefundene
BMU, so reicht eine lokale Suche in einem kleinen Radius um diese herum. Nur wenn die
dadurch gefundene, neue BMU am Rand dieses Radius liegt, wird die Suche um diese herum
fortgesetzt, solange bis eine BMU im Mittelfeld des Radius gefunden wird (siehe Abbildung
2.6).
Auch wenn die hier vorgestellten Verfahren von einer bereits vorherrschenden Ordnung der
SOM ausgehen, wurde in [Mon94] gezeigt, dass sie auch bereits in den ersten Iterationen
einer zufällig initialisierten SOM verwendet werden können, da die hier durch die Verfahren entstehenden Fehler in der BMU -Bestimmung die Konvergenz des Algorithmus nicht
beeinträchtigen und trotzdem eine Ordnung entsteht.
20
3 Erkennung von automatisierten Zugriffen
anhand von Zugriffsprotokollen
Dieses Kapitel gibt einen Einblick in Verfahren und Kriterien, die ein Mensch anwenden
würde, um anhand von Zugriffsprotokollen automatisierte Zugriffe zu erkennen. Es wird
weiterhin ein Bezug zu Selbstorganisierenden Karten hergestellt und festgelegt, welche Informationen durch diese in welcher Weise abgebildet werden können, um mit Hilfe von SOMs
automatisierte Zugriffe ausfindig zu machen.
3.1 Apache-Webserver-Zugriffsprotokolle
Bevor auf die Erkennung von automatisierten Zugriffen eingegangen wird, soll zunächst
die allgemeine Struktur einer Zeile aus Zugriffsprotokollen des Apache-Webservers erläutert
werden.
Eine beispielhafte Zeile des Zugriffsprotokolls sieht (hier zur besseren Lesbarkeit auf mehrere
Zeilen aufgebrochen) wie folgt aus:
80.144.243.235 - - [26/Oct/2009:06:28:28 +0100] "GET / HTTP/1.1" 200 241
"http://www.google.de/" "Opera/9.80 (Windows NT 5.1; U; de)
Presto/2.2.15 Version/10.00"
Sie lässt sich in folgende, wichtige Teilinformationen gliedern [Apa]:
21
80.144.243.235
IP-Adresse des zugreifenden Benutzers
[26/Oct/2009:06:28:28 +0100]
Zeitpunkt des Zugriffs
"GET / HTTP/1.1"
Angeforderte relative URL (hier "‘/"’, zusammen mit
Zugriffs-Methode (GET oder POST [FGM+ 99, Abschnitt 9]) und Protokollangabe (hier HTTP Version
1.1) - im Weiteren Request genannt
"http://www.google.de/"
Herkunft des zugreifenden Benutzers, das heißt URL
der Seite, von der aus er zur angeforderten URL navigiert ist - im Weiteren Referer genannt
"Opera/9.80 [. . . ]"
Identifikations-Zeichenkette des vom Benutzer verwendeten Browsers (Browserkennung)
3.2 Definition von Bots
Unter Bots (eine in diesem Zusammenhang übliche Kurzform von Web-Roboter) werden hier
Programme verstanden, welche dazu entworfen wurden, Webinhalte automatisiert abzurufen
und zu verarbeiten [Wik10b]. Dies ist eine Einschränkung der üblichen Verwendung des
Begriffes, der allgemein Programme bezeichnet, die das Verhalten von Menschen nachahmen
beziehungsweise sich wiederholende Aufgaben automatisiert abarbeiten [Wik10a]. Für diese
Arbeit ist sind allerdings nur Bots von Interesse, die sich direkt auf den Zugriff auf Webseiten
beziehen.
3.3 Kriterien zur Erkennung
Für Menschen ist es offensichtlich, dass es sich bei einem protokollierten Benutzer um ein
automatisiert zugreifendes Programm handelt, wenn sich dieses verhält, wie ein Mensch
es nie könnte (siehe hierzu auch Anhang A). Dabei sind insbesondere folgende Kriterien
ausschlaggebend:
1. Der Benutzer hält sich nicht an den Klickpfad
2. Der Benutzer lädt nicht alle mit Webseiten verbundene Inhalte wie CSS-Stylesheets 4 ,
JavaScript 5 -Dateien und Bilder
4
Bei CSS-Stylesheets handelt es sich um über externe Dateien eingebundene Formatierungsangaben, die der
Browser zur Darstellung der Webseite auswertet [Mey07].
5
JavaScript ist eine einfache Script-Sprache, die in HTML-Dokumente eingebettet werden kann, um diese
zu manipulieren. Komplexere Scripte werden häufig in eigene Dateien ausgelagert [McD03].
22
3.3 Kriterien zur Erkennung
3. Der Benutzer folgt Hyperlinks oder verwendet Bedienelemente in einer Geschwindigkeit, wie sie für Menschen unmöglich oder untypisch ist
4. Die Browserkennung ist unüblich oder die Referer-Angabe fehlt / ist fehlerhaft
Diese sind im Folgenden im Detail erläutert:
3.3.1 Klickpfad
Unter Klickpfad wird eine Reihe von miteinander durch Hyperlinks verbundene Webseiten verstanden. Das heißt, dass eine Abfolge von Zugriffen auf Webseiten genau dann dem
Klickpfad folgt, wenn jeweils die Vorgängerseite mittels eines Hyperlinks (oder entsprechenden Strukturen) auf die aktuell betrachtete Seite verweist. Die Seiten sind also über einen
Pfad aus Klicks auf Hyperlinks erreichbar.
Allgemeiner gesagt, kann unter einem Klickpfad auch der Navigationsweg verstanden werden,
den menschliche Benutzer üblicherweise auf einer Webseite zurücklegen.
Folgt eine Zugriffsfolge diesem Klickpfad nicht (das heißt, die Seiten, auf die aufeinanderfolgend zugegriffen wird, sind nicht durch Hyperlinks verbunden), so handelt es sich bei dem
Benutzer eindeutig um einen Bot, da dieses Navigations-Verhalten für einen Menschen unmöglich ist. Die einzige Möglichkeit für einen Menschen, den Klickpfad zu verlassen, ist das
direkte Eingeben der URL von Webinhalten in die Adresszeile des Browsers. Dies ist nur
für Benutzer möglich, die die Struktur der Webseite gut kennen, und auch dann ein eher
unübliches Verhalten.
3.3.2 Fehlendes Laden zusätzlicher Inhalte
Für die automatisierte Analyse und Auswertung oder Bedienung von Webseiten sind zusätzliche Seiteninhalte wie CSS-Stylesheets, JavaScript-Dateien oder Bilder in der Regel nicht
nötig, da diese häufig einen reinen Präsentationszweck haben. Daher werden sie von Bots
meist nicht aufgerufen und Verweise auf sie ignoriert. Das fehlende (Nach-)Laden solcher
Inhalte ist also ein weiteres Kriterium für das Erkennen von Bots. Es darf aber nicht allein
verwendet werden, da dieses Verhalten auch bei menschlichen Benutzern auftreten kann,
wenn diese beispielweise JavaScript in ihrem Browser deaktiviert haben, mit mobilen Geräten auf die Webseite zugreifen, welche häufig keine Bildinhalte auswerten, oder diese Inhalte
vom Browser zwischengespeichert (gecached) wurden und deshalb nicht erneut aufgerufen
werden.
23
3.3.3 Zu hohe oder sonst unübliche Zugriffsgeschwindigkeit
Wenn Menschen durch eine Webseite navigieren, dann brauchen sie dafür Zeit, die Inhalte
zu lesen, die Navigationsstruktur zu erkennen und allgemein um zu entscheiden, was sie als
nächstes auf der Seite tun wollen. Ein Bot, der einem festgelegten Zweck oder Verhalten folgt,
hat keine dieser Bedürfnisse und kann Hyperlinks nahezu augenblicklich folgen, sobald er
diese erkannt hat. Zugriffsfolgen auf nicht zueinander gehörende Inhalte (das heißt Inhalte,
die von verschiedenen Bereichen der Webseite kommen, also nicht fast zeitgleich zusammen
angefordert und geladen werden), die direkt oder mit nur geringer Verzögerung aufeinander
folgen, sind also ein Garant dafür, dass es sich bei dem Benutzer um einen Bot handelt.
Einige Entwickler von Bots sind sich allerdings dieser Tatsache bewußt und statten ihre Programme daher mit einer künstlichen Verzögerung aus, um sie menschlicher wirken zu lassen.
Da diese Verzögerung aber künstlich ist und nicht durch den tatsächlichen Inhalt einer Seite
erzeugt wird, kann man solche Bots häufig daran erkennen, dass ihr Zugriffsverhalten zu
regelmäßig ist. Insbesondere bei Seiten, die Interaktion mit dem Benutzer erfordern (etwa
Formulare), sind diese Bots im Vergleich zu einem Menschen noch immer zu schnell. Gleichermaßen können zu langsam sein, insbesondere bei sehr einfachen Seiten, die von Menschen,
denen die Seitenstruktur vertraut ist, in wenigen Sekunden navigiert werden können.
Zusammenfassend lässt sich also sagen, dass man Bots erkennen kann, wenn ihr zeitliches
Zugriffsverhalten von dem normaler Menschen für die jeweilige Seite abweicht.
3.3.4 Unübliche Browserkennung oder Referer-Angabe
Wie oben beschrieben, handelt es sich bei der Browserkennung um eine Angabe über die Art
und Version des vom Benutzer zum Aufruf eines Inhaltes verwendeten Browsers. Da Bots
die Seiteninhalte selbst direkt abrufen, kann sich hier eine unübliche Bezeichnung finden, die
nicht zu einem bekannten Browser gehört, oder die Kennung fehlt ganz. Einige Bots, insbesondere solche von Suchmaschinen, die zur Indizierung von Webinhalten verwendet werden,
geben sich über die Browserkennung auch frei zu erkennen. Der Indizierungs-Bot von Google verwendet zum Beispiel diese Browserkennung: "Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)"
Da die meisten Browser ein Überschreiben dieser Kennung unterstützen und sie auch von
Bots frei gewählt werden kann, ist sie allerdings nur ein sehr schwaches Kriterium zum
Erkennen von automatisierten Zugriffen. Sie sollte nur verwendet werden, um Bots, die sich
darüber zu erkennen geben, entsprechend zu behandeln.
Die Referer-Angabe verhält sich ähnlich. Fehlt sie komplett, kann dies ein Anzeichen für
Bots sein. Genauso ist es aber möglich, dass ein menschlicher Benutzer einen Browser ver-
24
3.4 Verwendung der Kriterien in Selbstorganisierenden Karten
wendet, bei dem das Senden dieser Angabe unterdrückt wurde (viele Browser bieten dies
als Datenschutz-Option an, damit der Benutzer nicht preisgeben muss, von welcher Seite er
kommt). Lediglich eine fehlerhafte Referer-Zeichenkette, die sich nicht auf bekannte Webinhalte bezieht, ist ein sicheres Indiz für Bots. Derartige Angaben können aber nur entstehen,
wenn die Programmierung des Bots fehlerhaft ist - sie sind also eine sehr seltene Ausnahme.
Daher sollte auch dieses Kriterium sparsam und nur in Kombination mit anderen Indizen
verwendet werden.
Das Ziel dieser Arbeit ist es zu überprüfen, ob sich Selbstorganisierende Karten zur automatisierten Erkennung von Bots eignen. Wie eingangs erwähnt, soll dies ausschließlich durch
eine Definition des Normalzustands von menschlichem Zugriffsverhalten geschehen, als Alternative zu regelbasierten Ansätzen. Daher kommen hier auch nur Kriterien in Frage, die
nicht auf vordefinierten Regeln basieren. Die Beurteilung von Browserkennung oder RefererAngabe scheiden also aus, da diese einen direkten Vergleich mit bekannten und gültigen
Werten benötigten.
Im folgenden werden nun grundsätzliche Überlegungen beschrieben, wie sich die verbliebenen
Kriterien durch eine oder mehrere SOMs abbilden lassen.
3.4.1 Klickpfad
Betrachtet man den Klickpfad als das normale Navigationsverhalten menschlicher Benutzer,
so lässt er sich relativ einfach durch eine SOM abbilden. Statt die einzelnen Inhalte einer
Webseite auf verknüpfende Hyperlinks zu überprüfen, was ein regelbasierter Ansatz wäre,
kann einfach mittels semantischer Aggregation (vergleiche Abschnitt 2.2.2: Semantische Aggregation) abgebildet werden, welche Inhalte nacheinander abgerufen werden. Dabei kann
erwartet werden, dass Zugriffstupel aus aufeinanderfolgenden Zugriffen örtlich nah beieinander auf der entstehenden Karte abgebildet werden, wenn sie Zugriffe auf gleiche Inhalte
beinhalten: In diesem Fall bestehen die entstehenden Trainingsvektoren zum Teil aus den
gleichen repräsentativen Wortvektoren (vergleiche Abschnitt 2.2.1: Bildung des Alphabets),
weshalb ihre Euklidische Distanz (siehe Gleichung 2.5) geringer ist als die zweier völlig verschiedener Trainingsvektoren.
Geht man davon aus, dass automatisierte Zugriffe durch Bots nur einen sehr geringen Prozentsatz aller Zugriffe ausmachen, die für eine Webseite protokolliert werden, so kann das
Zugriffsprotokoll des Webservers unaufbereitet als Trainingsinformation für eine solche SOM
verwendet werden. Der Glättungseffekt des SOM-Algorithmus, insbesondere wenn die Zahl
25
der Trainingselemente die Zahl der Knoten um ein vielfaches übersteigt, sorgt für eine allgemeine Mittelung der abgebildeten Daten, wodurch einzelne Ausreißer nicht ins Gewicht
fallen. Selbst wenn diese auf die Karte abgebildet werden, belegen sie zudem andere Bereiche
als die Zugriffe von Menschen, da sie offensichtlich andere Zugriffsmuster beschreiben. Dies
kann für die spätere Auswertung der Karte hilfreich sein.
3.4.2 Fehlendes Laden zusätzlicher Inhalte
Die Überprüfung, ob ein Benutzer alle üblichen, zusätzlichen Inhalte einer Seite lädt, kann
auf die gleiche Art und Weise wie der Klickpfad durch eine SOM abgebildet werden. Denn
durch diesen ist bereits definiert, welche Inhalte zusammen gehören und üblicherweise gemeinsam geladen werden. Lässt ein Benutzer also Inhalte aus, die durch obige Abbildung
als Klickpfad definiert sind, so verlässt er diesen automatisch und wird daher in der Analyse
auffällig.
Werden zusätzliche Inhalte (insbesondere Bilder) einer Seite üblicherweise durch den Browser
des Benutzers zwischengespeichert und nicht erneut abgerufen, so kann es sinnvoll sein,
verschiedene SOMs zu trainieren, die verschiedene Inhaltstypen abbilden: Eine SOM, die
nur Aufrufe von HTML-Inhalten abbildet, kann verwendet werden, um den allgemeinen
Klickpfad zu definieren. Zusätzlich kann dann eine SOM trainiert werden, die Zugriffe jeder
Art oder nur solche auf kritische Inhalte (beispielsweise HTML und Bilder) abbildet, so
dass Zugriffsabbildungen auf der ersten SOM mit denen der zusätzlichen verglichen werden
können, um zu ermitteln, ob tatsächlich ein abweichendes Benutzerverhalten festzustellen
ist oder Inhalte nur zwischengespeichert wurden.
3.4.3 Zu hohe oder sonst unübliche Zugriffs-Geschwindigkeit
Während es trivial ist, die zeitlichen Intervalle zwischen Zugriffen auf Webinhalte anhand
der Zugriffsprotokolle mittels statistischer und regelbasierter Verfahren zu analysieren, ist
eine Abbildung dieser Information auf eine SOM mit Problemen behaftet. Man könnte auf
die Idee kommen, Paaren von Seitenaufrufen anhand ihrer Zeitdifferenz eindeutige Vektoren
zuzuweisen, um so eine SOM zu trainieren, die Beziehungen von Webinhalten nach ihren
üblichen Zugriffsintervallen gruppiert. Dieser Ansatz kann aber nicht zu sinnvollen Ergebnissen führen, da es sich bei der zeitlichen Komponente um eine eindimensionale Information
handelt, die hier auf eine zweidimensionale Karte projiziert werden soll. Damit wäre also die
Bedingung Dim(Eingaberaum) > Dim(Ausgaberaum) verletzt (vergleiche Abschnitt 2.1.2:
Ausgaberaum).
Diese zeitlichen Aufrufdistanzen müssen also mit der Information, welche Seiten aufgerufen
wurden, verknüpft werden, um als Trainingsvektoren geeignet zu sein. Hierfür können die
26
für Zugriffsabfolgen repräsentativen Trainingsvektoren (siehe oben) um die zeitliche Differenz als zusätzliche Dimension erweitert werden. Da die Trainingsvektoren selbst aber bereits
hochdimensional sind (vergleiche Abschnitt 2.2.1: Bildung des Alphabets und Abschnitt 2.3.1:
Dimensionsreduzierung durch Random Mapping), würde diese zusätzliche Dimension unter
Umständen nur wenig ins Gewicht fallen und dadurch die Bedeutung der zeitlichen Komponente zur Erkennung von automatisierten Zugriffen unterrepräsentieren. Genauso besteht
die Gefahr einer Überrepräsentation, wenn der Betrag der verwendeten Wortvektoren gering ist und die zeitliche Information im Vergleich zu diesem hohe Werte annimmt. Dies
ist beispielsweise der Fall, wenn es sich bei den Wortvektoren um Einheitsvektoren handelt,
die zeitliche Distanz aber unmodifiziert als Anzahl der zwischen zwei Aufrufen vergangenen
Sekunden mit diesen konkateniert wird. Ist diese Distanz größer als eine Sekunde, so ist
sie für die Berechnung der Euklidischen Distanz zweier Trainingsvektoren um ein vielfaches
entscheidender als die eigentlichen Wortvektoren. Die Information, welche Inhalte durch die
Trainingsvektoren repräsentiert werden, ginge also verloren.
Durch Skalierung der Komponente (etwa vielfache Verwendung in mehreren zusätzlichen
Dimensionen oder Multiplikation mit einem entsprechenden Skalar) kann dies natürlich umgangen werden. Es ist aber schwierig, die genau benötigte Größenordnung dieser Skalierung
zu bestimmen. Insbesondere da deren Auswirkungen erst nach dem vollständigen Training
einer entsprechenden SOM offenbar werden und auch dann nur im Vergleich mit anderen
Ergebnissen beurteilt werden können, kann sich hier nur durch mehrere Versuche an eine
geeignete Skalierung angenähert werden.
Zur Vemeidung dieses Problems wurde in dieser Arbeit zusätzlich ein alternativer Ansatz
verfolgt: Statt die zeitliche Komponente direkt als zusätzliche Dimension in die Trainingsvektoren einfließen zu lassen, wird davon ausgegangen, dass Zugriffsmuster mit unterschiedlicher
zeitlicher Differenz inhaltlich völlig verschiedene Informationen sind. Für das Training einer
SOM bedeutet dies, dass einem Aufruf, der eine zeitliche Distanz von unter einer Sekunde
zum vorherigen Aufruf des gleichen Benutzers hat, ein anderer Wortvektor zugewiesen wird,
als einem Aufruf mit beispielweise 15 Sekunden zeitlicher Distanz zum Vorgänger. Durch diese indirekte Einflussnahme der zeitlichen Komponente entsteht eine Karte, die sozusagen den
zeitlichen Klickpfad von Benutzern abbildet. Auf ihr sind die gleichen Zugriffsmuster mehrfach abgebildet, jeweils mit anderer zeitlicher Distanz. Dadurch lässt sich auf gleiche Weise
wie bei der Abbildung des reinen Klickpfads (siehe oben) beurteilen, ob ein Zugriffsmuster
dem üblichen Verhalten von menschlichen Benutzern folgt.
Für Details zur Implementierung der hier vorgestellten Ansätze siehe Abschnitt 4.3.2.4:
Kontext-Aggregation.
27
28
4 Prototyp einer Zugriffsprotokollanalyse auf
Basis von SOMs
Dieses Kapitel beschreibt das Konzept und die Architektur einer Implementierung des SOMAlgorithmus zur Analyse von Zugriffsprotokoll-Dateien eines Apache-Webservers. Es wurde
im Rahmen dieser Arbeit als beispielhafter Prototyp entwickelt, um die Eignung des Verfahrens zum Ermitteln von automatisierten Zugriffen auf Webseiten zu überprüfen. Daher
ist im Folgenden sowohl eine allgemeine Beschreibung der Herangehensweise als auch eine
kritische Bewertung dieser gegeben.
4.1 Analyse
Dieser Abschnitt beschreibt die Anforderungen und Rahmenbedingungen der Implementierungen.
4.1.1 Zielgruppendefinition
Die Implementierung ist ein reiner, exemplarischer Prototyp und nicht für den Produktiveinsatz gedacht. Sie soll aufzeigen, ob (und wenn ja unter welchen Bedingungen) der
SOM-Algorithmus geeignet ist, automatisierte Zugriffe auf Webseiten zu erkennen. Die Implementierung soll daher nur als Beispiel einer Lösung der Anforderungen verstanden werden,
weshalb ihre Zielgruppe selbst Softwareentwickler sind, die auf Basis der hier vorgestellten
Arbeit eine Anwendung zur Analyse von Apache-Zugriffsprotokoll-Dateien entwickeln wollen.
4.1.2 Wahl der Programmiersprache
Als Programmiersprache für die Beispiel-Implementierung wurde Python gewählt. Die klare und einfache Syntax dieser Sprache, zusammen mit einer großen Auswahl an SoftwareBibliotheken (insbesonders die Bibliothek SciPy für wissenschaftliche beziehungsweise mathematische Berechnungen), erlaubt eine sehr schnelle und fehlervermeidende Entwicklung
von Prototypen. Diese Eigenschaft wiegt eventuelle Laufzeiteinschränkungen durch die Tatsache, dass es sich bei Python um eine interpretierte Scriptsprache handelt, deutlich auf.
29
Für die Entwicklung einer für den Produktiv-Einsatz gedachten Anwendung, bei der LaufzeitOptimierung eine größere Rolle spielt als Lesbarkeit des Quellcodes oder EntwicklungsGeschwindigkeit, bietet es sich allerdings an, eine hardwarenahe, kompilierbare Sprache wie
C zu verwenden. Da Python das Einbinden von kompilierten C -Code erlaubt, könnten so
auch nur laufzeitkritische Teilelemente der Beispiel-Implementation neu umgesetzt werden.
4.1.3 Technische Rahmenbedingungen
Da die Anwendung zur Auswertung von Zugriffsprotokoll-Dateien eines Webservers verwendet wird, ist davon auszugehen, dass sie auf der gleichen oder ähnlichen Hardware und
Umgebung wie der Webserver selbst betrieben werden muss. Daher ist Plattformunabhängigkeit eine wichtige Bedingung: Es kann nicht vorhergesagt werden, welches Betriebsystem
für den Webserver verwendet wird.
Auch wenn der hier vorgestellte Prototyp eine eigenständige Anwendung darstellt, welche
losgelöst von anderen Prozessen des Servers operieren kann, sollte für den Produktiveinsatz
zudem eine direkte Schnittstelle mit dem Webserver angedacht werden. Die Verwendung
von Python als Programmiersprache bietet für beide Fälle eine Lösung: Es existiert für
jedes gängige Betriebsystem ein Interpretierer der Sprache und die Erweiterung mod_python
erlaubt eine direkte Kommunikation mit dem Apache-Webserver.
4.2 Anforderungen
In diesem Abschnitt werden die grundsätzlichen Anforderungen an die Implementation beschrieben. Es wird also die allgemeine Aufgabe der Software beschrieben, sowie auf zielsetzende Rahmenbedingungen des Anwendungsgebiets eingegangen.
4.2.1 Grundsätzliche Funktion
Die entwickelte Software soll aufzeigen, ob der SOM-Algorithmus grundsätzlich für die Erkennung von automatisierten Zugriffen auf Webseiten geeignet ist. Als Beispielumsetzung des
vorgestellten Verfahrens der SOM sollen die mir ihr berechneten Ergebnisse als Grundlage
für eine Bewertung verwendet werden können.
4.2.2 Präzision
Die Erkennung von automatisierten Zugriffen (Bots), insbesondere wenn sie als Kriterium für
sicherheitsrelevante Bereiche einer Seite verwendet werden soll, muss zuverlässig und präzise
30
4.2 Anforderungen
sein. Es dürfen weder offensichtlich erkennbare Bots für Menschen gehalten werden noch
dürfen menschliche Benutzer als Bots identifiziert werden. Ist das Verfahren nicht in der Lage,
eine hundertprozentiges Urteil über die Verhaltenseigenschaften eines Benutzers zu fällen,
so muss es zumindest eine Einschätzung des Verhaltens liefern (etwa eine Prozentangabe,
die angibt, wie wahrscheinlich es sich um einen Bot handelt). Nur so kann das Verfahren
verwendet werden, um die Erkennung von automatisierten Zugriffen zu unterstützen oder
gar zu automatisieren.
4.2.3 Laufzeit-Einschränkungen
Populäre Webseiten verzeichnen mehrere hundertausend Zugriffe täglich. Das Verfahren muss
daher in der Lage sein, diese effizient zu verarbeiten - nur wenn die Beurteilung eines Zugriffes
(beziehungsweise einer Zugriffsfolge) die Bereitstellung von Inhalten durch den Server nicht
beeinträchtigt, ist das Verfahren für den Produktiveinsatz geeignet. Die Verarbeitung kann
hierbei entweder sofort nach Sammlung der erforderlichen Daten, also live, oder gesammelt
zu regelmäßigen Zeiten als so genannter Batch-Prozess geschehen.
4.2.4 Aufbereitung der Ausgabedaten
Eine trainierte SOM ist in der Regel für Menschen nicht intuitiv verwendbar, da es sich
lediglich um eine unaufbereitete Sammlung von Vektoren handelt. Auch wenn die SOM
kalibriert wurde (siehe Abschnitt 2.1.4.6: Kalibrierung), bieten die mit den Knoten attribuierten Trainingselemente in diesem Fall noch keinerlei Aufschluss über die Auswertung
zukünftiger Zugriffe, die nicht für das Training der SOM verwendet wurden. Soll das Verfahren also als Vorfilter für eine manuelle Auswertung der Zugriffsdaten erfolgen, so muss
die Auswertung dieser in einem von Menschen lesbaren Format dargestellt werden. Wird es
hingegen zur automatisierten Erkennung verwendet, so müssen die Ausgabedaten in ein Format gebracht werden, dass von an das Verfahren anschließenden Prozessen der analysierten
Webseite verwendbar ist.
4.2.5 Erweiterbarkeit
Der SOM-Algorithmus und die damit verbundenen Verfahren existieren in vielen Varianten, jede mit eigenen Stärken und Schwächen. Je nach konkretem Anwendungsgebiet kann
es wichtig sein, diese Varianten dynamisch anpassen oder gar austauschen zu können, was
aktiv durch die Architektur der Implementierung unterstützt werden muss. Zum einen bedeutet dies, dass die Abhängigkeiten zwischen verschiedenen Modulen so gering wie möglich
gehalten werden müssen, damit diese eigenständig und zueinander transparent operieren
31
können. Zum anderen müssen kritische Kernprobleme, deren Lösung austauschbar sein soll,
entsprechend gekapselt werden - etwa durch die Anwendung des Strategie-Entwurfsmusters
[GHJV04].
4.2.6 Benutzerschnittstelle
Insbesondere wenn das Verfahren zur automatisierten Erkennung verwendet wird, kann es
nötig sein, dem Benutzer der Software grundlegende Konfigurationsmöglichkeiten zur Verfügung zu stellen. Per Konfigurationsdatei oder grafischer Oberfläche könnte so erlaubt werden, die Parameter der verwendeten Algorithmen genau auf die vorliegenden Anforderungen
anzupassen. Auch eine Einstellungsmöglichkeit direkt über die grafische Darstellung einer
trainierten SOM wäre denkbar, etwa um dem Benutzer zu erlauben, bestimmte Knoten,
auf die Zugriffe von bekannten und vertrauenswürdigen Quellen abgebildet werden, von der
Bewertung auszuschließen. Diese Funktionen gehen aber über die bloße Machbarkeitsstudie
dieser Arbeit hinaus und wurden daher in der hier präsentierten Beispielimplementierung
nicht berücksichtigt.
4.3 Komponenten
Dieser Abschnitt beschreibt die grundsätzliche Architektur der Implementierung. Es werden
die verwendeten Module sowie ihre Zusammenhänge erläutert.
Der Begriff Modul bezeichnet in der Informatik allgemein eine inhaltlich oder funktionell
zusammenhänge Gruppierung von Quelltext. So werden die in der objektorientierten Programmierung verwendeten Klassen unter Umständen auch als Module bezeichnet. Hier wird
der Begriff aber ausschließlich als Bezeichner für Gruppen von inhaltlich zusammenhängenden Klassen und Komponenten verwendet, um deren Struktur klar voneinander abzugrenzen.
4.3.1 Architektur
Abbildung 4.1 zeigt die vier grundsätzlichen Module der Implementierung:
Die Zugriffsprotokoll-Analyse wertet Zugriffsprotokoll-Dateien des Apache-Webservers aus
und generiert mittels einem aus mehreren zur Verfügung stehenden Verfahren daraus Trainingsvektoren, wie sie vom SOM-Algorithmus verwendet werden können.
Das Modul SOM-Algorithmus selbst beinhaltet verschiedene Umsetzungen des eigentlichen,
in Abschnitt 2.1: Der SOM-Algorithmus beschriebenen Verfahrens. An dieser Stelle findet
das Training der für weitere Schritte benötigten SOM statt.
32
4.3 Komponenten
Eine damit generierte und kalibrierte (vergleiche Abschnitt 2.1.4.6: Kalibrierung) SOM kann
nun mittels des Moduls Visualisierung für Endbenutzer oder zu Kontrollzwecken visuell
dargestellt werden.
Durch das Modul Evaluierung kann eine solche SOM wiederum qualitativ bewertet werden
- hier findet auch die Überprüfung statt, ob und wie weit die SOM in der Lage ist, automatisierte Zugriffe zu erkennen. Erkenntnisse, die hier gewonnen werden, können zudem zum
Teil wieder visualisiert werden.
4.3.2 Zugriffsprotokoll-Analyse
Abbildung 4.2 zeigt das Klassendiagramm des Zugriffsprotokoll-Analyse-Modules (dieses und
alle folgenden Klassendiagramme sind nach UML 2.0 Standard erstellt (siehe [Amb05])).
Es besteht aus der Hauptklasse LogAnalyzer, welche die Analyse von Zugriffsprotokollen
und die entsprechende Generierung von Trainingsvektoren verwaltet, sowie mehrere von ihr
verwendeten Komponenten.
Im Folgenden werden die einzelnen, dargestellten Gruppen und ihre Klassen nach ihrer inhaltlichen Verwendung erläutert.
4.3.2.1 Parser
Bestehend aus den Klassen LogParser und ParsedLogLine, kümmert sich der Parser um
das Einlesen von Zugriffsprotokollen das Webservers Apache. Wird der Funktion parse()
von LogParser der Pfad zu einer oder mehrerer Zugriffsprotokollen übergeben, so werden
diese zeilenweise durchschritten und für jede Zeile ein Objekt der Klasse ParsedLogLine
generiert. Diese ist eine reine Datenhaltungs-Klasse, welche alle Teilinformationen einer Zeile
bereithält, so dass diese von folgenden Prozessen einfach ausgewertet werden können.
Abbildung 4.1: Grundsätzliche Architektur der Implementierung
33
Die Funktion parse() der Klasse LogParser aktzeptiert zusätzlich als optionale Parameter
eine Reihe von Optionen, die das Filtern von bestimmten Protokollzeilen erlauben. Diese
Parameter bestehen aus einer Liste von Dateiendungen, die gegen jede Protokollzeile geprüft werden, sowie einer booleschen Schalter-Variablen, die bestimmt, ob nur Aufrufe von
Dateien mit einer dieser Endungen oder alle Aufrufe außer solchen zugelassen werden sollen. Eine derartige Filterung kann beispielsweise sinnvoll sein, um ausschließlich Zugriffe auf
HTML-Inhalte zu verarbeiten und Bild-Inhalte, CSS-Stylesheets und Javascript-Referenzen
zu ignorieren, welche eventuell vom Browser des Benutzers gecached (zwischengespeichert)
werden können und somit die Ergebnisse der Analyse verfälschen würden.
Der Aufbau und die Komponenten einer Zeile der Apache-Webserver-Zugriffsprotokolle ist
in Abschnitt 3.1: Apache-Webserver-Zugriffsprotokolle beschrieben.
Die hier generierten ParsedLogLine-Objekte werden zum Beispiel in der Alphabetgenerierung
und Gruppierung verwendet.
4.3.2.2 Alphabetgenerierung
Die Alphabetgenerierung beschreibt den Prozess, eindeutigen Wörtern vom SOM-Algorithmus verarbeitbare Vektoren zuzuweisen (vergleiche Abschnitt 2.2.1: Bildung des Alphabets).
Als Wort wird dabei jedes eindeutige Objekt bezeichnet, das es abzubilden gilt. Im Falle
der Analyse von Webseiten auf Basis von Zugriffsprotokollen sind dies in der Regel die
aufgerufenen URLs: Der Aufruf der Startseite eines Webinhalts soll inhaltlich beispielweise
vom Aufruf einer Kontaktseite oder ähnlichem unterschieden werden.
Konkret wird dies durch die Klasse UnitVectorGenerator erledigt, welche mittels ihrer Funktion generateUnitVectorDictForElements() zu einer übergebenen Liste aus Wörtern ein Verzeichnis (engl. Dictionary) erstellt, welches die Wörter zu eindeutigen Achsenvektoren abbildet.
Nach dem in Abschnitt 2.3.1: Dimensionsreduzierung durch Random Mapping beschriebenen
Verfahren wird anschließend die Dimension der entstandenen Vektoren reduziert. Die konkrete Implementierung RandomMapper der abstrakten Klasse DimensionalityReducer bietet
hierfür die Funktion mapVector(), welche einen übergebenen Vektor mit einer entsprechenden Zufallsmatrix multipliziert und das Ergebnis zurückliefert.
Der RandomMapper ist hier mittels des Strategie-Entwurfsmusters (vergleiche [GHJV04])
der Hauptklasse LogAnalyzer dieses Moduls zugewiesen, so dass er leicht durch eine andere
Form der Dimensionsreduzierung ausgetauscht werden kann.
34
Abbildung 4.2: Klassendiagramm der Zugriffsprotokoll-Analyse
4.3 Komponenten
35
4.3.2.3 Gruppierer
Für die Auswertung von Zugriffsprotokollen ist es wichtig, die einzelnen Zeilen des Protokolls nach Benutzer zu gruppieren. Denn möchte man das Zugriffsverhalten eines Benutzers
analysieren, spielen nur die Zeilen eine Rolle, die auch eindeutig die Zugriffe dieses Benutzers
protokollieren. Da in Apache-Zugriffsprotokollen die Zeilen allerdings ausschließlich chronologisch sortiert vorliegen, werden Zugriffe von verschiedenen Benutzern hier wild gemischt
festgehalten, solange die Benutzer zur selben Zeit auf die Webseite zugreifen (bei populären
Webinhalten der Regelfall).
Es werden also Kriterien zur Identifizierung eines Benutzers benötigt. Erstes Entscheidungskriterium ist hierbei die IP-Adresse, von der aus zugegriffen wird. Da allerdings nur die
wenigsten Benutzer über eine statische IP-Adresse verfügen, kann es vorkommen, dass verschiedene, zeitlich voneinander getrennte Benutzer von ihrem Internetdienstanbieter (engl.
Internet Service Provider, kurz ISP) die gleiche IP-Adresse zugewiesen bekommen. Daher
wird bei Zugriffen ausgehend von der gleichen Adresse, die eine halbe Stunde oder länger
auseinander liegen, zusätzlich angenommen, dass es sich um verschiedene Benutzer handelt.
Selbst wenn dies nicht der Fall ist sind derart weit auseinander liegende Zugriffe des gleichen
Benutzers mit an Sicherheit grenzender Wahrscheinlichkeit nicht inhaltlich zusammenhängend, weshalb dieses Kriterium auch hier zu sinnvollen Ergebnissen führt.
Weiterhin kann es sein, dass mehrere Benutzer gleichzeitig von der gleichen IP-Adresse aus
zugreifen, wenn diese sich über einen Router oder Proxy-Server eine gemeinsame Verbindung
teilen. Aus diesem Grund wird als weiteres Indentifikations-Kriterium die Browserkennung
hinzugezogen. Sollten diese Art von Benutzern nun identische Browser verwenden (etwa in
Rechenzentren der Fall), so würden sie fälschlicher Weise als ein einzelner Benutzer gewertet
werden. Eine genauere Aufschlüsselung der Benutzeridentifizierung wäre aber mit erhöhtem Aufwand verbunden (beispielweise denkbar ist ein Vergleich von Request und Referer
bei aufeinanderfolgenden Zugriffen). Da diese Art von Zugriff aber bei den für diese Arbeit
verwendeten Protokoll-Dateien der Ausnahmefall ist und statistisch ausreißende Trainingsvektoren beim SOM-Algorithmus automatisch durch den lokalen Glättungseffekt (vergleiche
Abschnitt 2.1.4.4: Annäherung der Referenzvektoren) herausgefiltert werden, wurde dieser
Sachverhalt hier nicht weiter behandelt. Soll die hier vorgestellte Implementierung allerdings zur Analyse von Zugriffen auf Webseiten, bei denen regelmäßig mit diesem Problem
zu rechnen ist, verwendet werden, so muss die Zeilen-Gruppierung entsprechend erweitert
oder angepasst werden.
Implementierung:
Ähnlich wie bei der Dimensionsreduzierung wird hier die konkrete Im-
plementierung IPAddressLineGrouper der abstrakten Klasse LineGrouper mittels des Strategie-Entwurfsmusters von der Hauptklasse LogAnalyzer verwendet. Sie setzt die oben be-
36
4.3 Komponenten
schriebenen Kriterien durch die Funktion groupLines() um, welche zu einer übergebenen
Liste von ParsedLogLines ein Verzeichnis zurückliefert, das einen eindeutigen Bezeichner
eines Benutzers einer Gruppe dieser ParsedLogLines zuordnet. Dieser Bezeichner setzt sich
zusammen aus der IP-Adresse, der Browserkennung und einem Zähler, der bei mehrfachen
Auftritten der gleichen Kombination aus IP-Adresse und Browserkennung diese Gruppen
durchnummeriert.
4.3.2.4 Kontext-Aggregation
Um das Zugriffsverhalten von Benutzern zu beurteilen, sind weniger die einzelnen Zugriffe als
ihr Zusammenhang interessant. Erst eine Abfolge von Zugriffen erlaubt eine Einschätzung,
ob ein Benutzer sich wie ein Mensch verhält. So lässt sich zum Beispiel daran erkennen, ob die
Zugriffe dem normalen Klickpfad der Webseite folgen, ob alle üblichen Inhalte (insbesondere
Javascript-Verweise und Bilder) zu einem Seitenaufruf geladen werden oder ob der Aufruf
bestimmter Seiten zu schnell erfolgt, als ein Mensch dies könnte (vergleiche Abschnitt 3.3:
Kriterien zur Erkennung).
Diese Informationen gilt es nun mittels der Kontext-Aggregation, entsprechend dem in Abschnitt 2.2.2: Semantische Aggregation beschriebenen Verfahren, abzubilden.
Einfache semantische Aggregation Unter semantischer Aggregation ist im Zusammenhang
mit Zugriffsprotokolldateien die Abbildung des Klickpfades zu verstehen. Hier wird der inhaltliche Zusammenhang zwischen Inhalten untersucht, so dass Aufrufe, welche in Folge aufeinander geschehen, örtlich nah beieinander auf der entstehenden Karte abgebildet werden.
Dieses ist gleichwertig mit der in Abschnitt 2.2.2: Semantische Aggregation beschriebenen
Wortkategorie-Karte:
Nehmen wir an, dass jedem eindeutigen Seiteninhalt bereits durch die Alphabetgenerierung
ein eindeutiger Vektor ~z zugewiesen wurde und die Zugriffsprotokolle durch das oben genannte Verfahren nach Benutzern gruppiert wurden und chronlogisch sortiert vorliegen. Wenn nun
z~i den Vektor beschreibt, der dem an Position i in einer Gruppe von Zugriffen aufgerufenen Inhalt zugewiesen wurde, so kann man die durch semantische Aggregation generierten
Trainingsvektoren x~i wie folgt beschreiben:
x~i = [~zi−1 , ~zi , ~zi+1 ]T
(4.1)
Das bedeutet natürlich, dass die ersten und letzten protokollierten Zugriffe einer Benutzergruppe nicht abgebildet werden können, da es für diese keinen zi−1
~ , beziehungsweise zi+1
~ ,
gibt. Dieser Informationsverlust fällt aber bei einer ausreichend großen Menge an Trainings-
37
daten nicht ins Gewicht, da davon ausgegangen werden kann, dass diese Inhalte durch andere
Gruppen abgedeckt werden.
Demzufolge können aber auch Benutzer-Gruppen, die weniger als drei Zugriffe beinhalten,
nicht berücksichtigt werden. Da Zugriffsmuster, die nur einzelne Inhalte abrufen (also beispielsweise nicht einmal Bilder nachladen), mit an Sicherheit grenzender Wahrscheinlichkeit
nicht von Menschen kommen, können diese Gruppen in diesem Schritt direkt als automatisierte Zugriffe protokolliert werden.
Dieses Verfahren wird hier durch die Funktion aggregateContext() der Klasse GroupedContextAggregator implementiert.
Gemittelte semantische Aggregation
Möchte man nur den Klickpfad betrachten, so kann
das Training der SOM stark beschleunigt werden, indem man die Trainingsvektoren bereits
im Vorfeld mittelt [Koh01, Seite 284]:
Der SOM-Algorithmus erzielt mit fortschreitender Iterationszahl eine Mittelung ähnlicher
Trainingsvektoren (siehe lokaler Glättungseffekt in Abschnitt 2.1.4.4: Annäherung der Referenzvektoren). Es liegt daher nahe, diese Mittelung bereits beim Erstellen der Trainingsvektoren zu berücksichtigen und so deren Anzahl stark zu reduzieren.
Sei jeder eindeutige Aufruf k durch einen Vektor repräsentiert und alle n Positionen dieses
Aufrufs in allen Benutzer-Gruppen durch f (k, i) gegeben, wobei f (k, 0) die erste Position des
Wortes in allen Gruppen beschreibt, f (k, 1) die zweite Position und so weiter. Ist nun r~j der
repräsentative Vektor eines Aufrufes an der Position j, so folgt für die Trainingsvektoren:
 Pn
~
r
i=0 f (k,i)−1

n


x~k = 
ǫz~k

 P
n

~
r
i=0 f (k,i)+1
n








(4.2)
So wird für jeden eindeutigen Aufruf k im Alphabet genau ein Trainingsvektor x~k erstellt, der
das arithmetische Mittel aller Vektoren zu allen Aufrufen beinhaltet, die in beliebigen Benutzergruppen direkt vor, beziehungsweise direkt nach k protokolliert sind. Dadurch ist hier
die Zahl der Trainingsvektoren identisch mit der Größe des Alphabets, wodurch im Vergleich
zur einfachen semantischen Aggregation, welche für jedes Vorkommen eines protokollierten
Aufrufes einen Trainingsvektor generiert, eine erhebliche Beschleunigung des Trainings der
SOM erreicht wird.
Ein weiterer Nebeneffekt ist, dass die Aufrufe nicht mehr nach ihrer Vorkommenshäufigkeit
gewichtet sind und damit häufig protokollierte Aufrufe keinen stärkeren Einfluss auf die SOM
38
4.3 Komponenten
haben als solche mit seltenem Vorkommen. Bei der einfachen semantischen Aggregation ist
dies der Fall, da hier häufig auftretende Aufrufe auch häufiger in Trainingsvektoren vertreten
sind.
Durch diese Eigenschaft ist die gemittelte semantische Aggregation allerdings für die Erkennung von automatisierten Zugriffen mit Problemen behaftet. Sie würde protokollierte
Zugriffe durch Bots gleichwertig zu denen von Menschen abbilden, was eine nachträgliche
Unterscheidung dieser erschwert.
Dieses Verfahren wird hier durch die Funktion aggregateContext() der Klasse AveragedContextAggregator implementiert.
Semantische Aggregation mit zeitlicher Unterscheidung
Weder die einfache semanti-
schen Aggregation noch die gemittelte semantischen Aggregation bilden die zeitliche Komponente von Zugriffen ab. Für diese Verfahren ist es gleichwertig, ob zwei Aufrufe in einer
Benutzer-Gruppe 0 Sekunden oder 25 Minuten auseinander liegen, solange die Zugriffe aufeinander folgen.
Diese Information ist aber zum Erkennen von automatisierten Zugriffen wichtig, da Bots
(sofern sie nicht künstlich verzögert werden) in der Regel Webinhalte wesentlich schneller
bearbeiten als Menschen dies könnten (siehe auch Abschnitt 3.3: Kriterien zur Erkennung).
Um diesen Sachverhalt abbilden zu können, wird deshalb hier davon ausgegangen, dass
zwei gleiche Zugriffsfolgen mit unterschiedlicher zeitlicher Distanz inhaltlich verschiedene
Informationen sind, die getrennt voneinander abzubilden sind.
Daher wurde für diese Art der Aggregation das Alphabet erweitert (vergleiche Abschnitt
4.3.2.2: Alphabetgenerierung): Das Alphabet-Verzeichnis bildet hier nicht mehr nur eindeutige Seiteninhalte, sondern ein Tupel aus dem Seiteninhalt und der zeitlichen Distanz zum
Vorgängeraufruf auf repräsentative Vektoren ab. Um das Alphabet nicht unnötig zu vergrößern, werden dabei nur die folgenden Situationen betrachtet:
1. Distanz zum Vorgängerzugriff ist kleiner als 10 Sekunden
4. Distanz zum Vorgängerzugriff ist größer als 30 Sekunden
5. Aktuell betrachteter Zugriff ist der erste einer Benutzer-Gruppe und hat daher keinen
Vorgänger
Das bedeutet also, dass jedem Seiteninhalt insgesamt fünf verschiedene, unabhängige Vektoren zugewiesen werden. Diese werden nun von der Aggregation verwendet, um kontextsensitive Trainingsvektoren zu erstellen, die zusätzlich die zeitliche Information indirekt abbilden.
39
Dabei wird identisch zur einfachen semantischen Aggregation verfahren, nur dass der Vektor z~i , der den Aufruf an der Protokoll-Position i repräsentiert, zusätzlich abhängig von der
zeitlichen Distanz zum Vorgängeraufruf ti−1 ist:

zi−1 (ti−2 )
 ~


x~i = 
zi (ti−1 )
 ~


~zi+1 (ti )








(4.3)
Der Trainingsvektor ist also die Konkatenation aus den repräsentativen Vektoren ~z von drei
aufeinander folgenden, protokollierten Zugriffen, wobei ~z von der zeitlichen Distanz zum
Vorgänger des jeweiligen Zugriffes abhängt und entsprechend oben genannter Situationsunterscheidungen auf einen von 5 möglichen Vektoren abgebildet wird.
Dieses Verfahren wird hier durch die Funktion aggregateContext() der Klasse TimeDistanceContextAggregator implementiert.
Zeitsensitive semantische Aggregation Wie in Abschnitt 3.4.3: Zu hohe oder sonst unübliche Zugriffs-Geschwindigkeit beschrieben, kann die zeitliche Komponente von Zugriffsmustern auch direkt als zusätzliche Dimension in die Trainingsvektoren integriert werden. Sie
muss dabei skaliert werden, um nicht unter- oder überrepräsentiert zu werden.
Verwendet man hier Zugriffspaare statt Dreiergruppen, um den Wechsel von Inhalt a auf den
Inhalt b mit der Zeitdifferenz t auszudrücken, so lässt sich eine Richtlinie für die Skalierung
wie folgt ausdrücken: Sind ~za und ~zb Wortvektoren, die die Inhalte a beziehungsweise b repräsentieren und nach dem in Abschnitt 4.3.2.2: Alphabetgenerierung gezeigten Verfahren als
Einheitsvektoren erstellt wurden, so ist der Betrag ihrer Konkatenation ∼ 1, 41. Damit die
Wortvektoren für die Berechnung der Euklidischen Distanz zweier Trainingsvektoren noch
genügend Gewicht haben, um dem SOM -Algorithmus eine Abbildung nach aufgerufenen
Inhalten zu erlauben, sollte die zeitliche Distanz auf einen Betrag dieser Größenordnung
skaliert werden. Es wird ein Maximum von 45 Sekunden angenommen und ein Betrag von
30 Sekunden als gleichwertig zu den Wortvektoren angenommen, so dass bei geringen Zeitdifferenzen die Wortvektoren Ausschlag über Abbildung des Trainingsvektors auf die SOM
geben, große zeitliche Distanzen zwischen Aufrufen aber stärker gewichtet werden:
tscaled =
40
1, 41 max(t, 45)
30
(4.4)
4.3 Komponenten
Für die Trainingsvektoren ergibt sich somit:

zi
 ~


x~i = 
zi+1
 ~


ti








(4.5)
Wobei ~zi den für Wortvektor des Aufrufs an Position i bezeichnet und ti die zeitliche Differenz
zwischen den Aufrufen an den Positonen i und i + 1 bezeichnet. Dieses Verfahren wird durch
die Funktion aggregateContext() der Klasse TimeSensitiveContextAggregator implementiert.
Implementierung:
Die Kontext-Aggregation ist als weiteres Strategie-Entwurfsmuster im-
plementiert, da sie in mehreren Varianten vorliegt, welche einfach austauschbar sein müssen. Die konkreten Klassen GroupedContextAggregator, AveragedContextAggregator, TimeDistanceContextAggregator und TimeSensitiveContextAggregator implementieren die abstrakte Schnittstelle ContextAggregator, welche über die Funktion aggregateContext() zu einer
übergebenen Liste aus nach Benutzer gruppierten Zugriffen eine entsprechende Liste aus
Trainingsvektoren zurückliefert. Diese sind zusätzlich mit der zugehörigen ParsedLogLine
attribuiert, um die Kalibrierung der SOM zu vereinfachen (vergleiche Abschnitt 2.1.4.6:
Kalibrierung).
Die Funktion filterTooSmallGroups() wird dabei verwendet, um Zugriffsgruppen, die für die
Aggregation zu klein sind (siehe oben), herauszufiltern und zu protokollieren.
4.3.3 SOM-Algorithmus
Abbildung 4.3 zeigt das Klassendiagramm des SOM-Algorithmus-Moduls. Es besteht aus
der Hauptklasse SelfOrganizingMap, welche den grundsätzlichen SOM-Algorithmus umsetzt,
sowie mehrere von ihr verwendeten Komponenten. Die hier implementierten SOMs gehen
von einem bidimensionalen Ausgaberaum aus (vergleiche Abschnitt 2.1.2: Ausgaberaum), so
dass die Größe der entstehenden Karte durch die Angabe ihrer Breite und Höhe bestimmt
wird.
Die Implementation des Algorithmus ist bewusst allgemein gehalten und macht daher keine
Annahmen über die Art und Herkunft der Trainingsvektoren. Dadurch können die hier beschriebenen Klassen zur Berechnung beliebiger SOMs verwendet werden und sind nicht auf
die Analyse von Zugriffsprotokollen beschränkt. Die in Abbildung 2.3 gezeigten Iterationsschritte einer Abbildung von Farben wurden beispielsweise ebenfalls mit dieser Implementierung erstellt.
41
Abbildung 4.3: Klassendiagramm des SOM-Algorithmus-Moduls
Im Folgenden werden die einzelnen Klassen nach ihrer inhaltlichen Verwendung erläutert.
4.3.3.1 Initialisierung
Die abstrakte Schnittstelle SOMInitializer stellt mittels der Funktion generateInitialValues()
durch ihre konkreten Implementierungen Funktionalitäten bereit, um die Referenzvektoren
der SOM mit sinnvollen Werten zu initialisieren. Anhand der übergebenen Parameter (Breite
und Höhe der SOM, sowie die Liste der zu verwendenden Trainingsvektoren) werden die
nötigen Rahmenbedingungen ermittelt und eine entsprechende Matrix aus Referenzvektoren
zurückgegeben (vergleiche auch Abschnitt 2.1.4.1: Initialisieren der Referenzvektoren).
Zufallsinitialisierung
Die konkrete Klasse RandomInitializer bildet das in Abschnitt 2.1.4.1:
Initialisieren der Referenzvektoren beschriebene Verfahren der Initialisierung mit Zufallswer-
42
4.3 Komponenten
ten ab. Abhängig von der gewählten Programmiersprache und deren Funktionsbibliotheken
kann es nötig sein, generierte Zufallswerte auf den Wertebereich der Trainingsvektoren zu
skalieren. Hierfür bestimmt die Funktion getFVRange()6 den Wertebereich, in dem sie den
minimalen Wert zmin und maximalen Wert zmax ermittelt. Sind diese bekannt und geht man
davon aus, dass der generierte Zufallswert r zwischen 0 und 1 liegt, so ist die Skalierung auf
den gewünschten Wert a ein einfacher Strahlensatz:
a = (zmax − zmin ) · r + zmin
Skalierte Initialisierung
(4.6)
Ausgehend von der Beobachtung, dass Initialwerte in einer belie-
bigen Ordnung die Konvergenz des Trainings der SOM enorm beschleunigen können [Koh01,
Seite 142], erstellt und trainiert die Funktion generateInitialValues() der konkreten Klasse
ScalingInitializer eine vollständige, aber sehr kleine SOM der Größe 4 × 4 Knoten. Dabei
werden die Referenzvektoren dieser SOM durch einen RandomInitializer zufällig initialisiert
und für das Training die selben Trainingsvektoren verwendet, wie sie auch für das Training
der eigentlich hier zu initialisierenden, größeren SOM gebraucht werden.
Dadurch ist die hier entstehende, kleine SOM bereits eine (sehr grobe) Abbildung des Eingangsraums auf den Ausgangsraum und kann nun durch einfache Interpolationstechniken
auf die Größe der zu initialisierenden SOM skaliert werden, um als Initialwerte für deren
Referenzvektoren verwendet zu werden.
Für diese Implementierung wurde eine einfache bilineare Interpolation verwendet. Eine bikubische Interpolation oder andere, höhergradige Verfahren würden zwar zu präziseren Ergebnissen führen, ihre höhere Laufzeit- und Implementierungskomplexität sind hier aber
unnötig, da eine grobe Annäherung an die Ordnung der trainierten SOM bereits ausreicht,
um die Konvergenz des Trainings zu beschleunigen (vergleiche [Sch02, Kapitel 4,6]).
4.3.3.2 BMU-Bestimmung
Durch die abstrakte Klasse BMUSelector wird, ähnlich der Initialisierung, eine Schnittstelle zur Definition von Verfahren zur Auswahl der Best Matching Unit definiert (vergleiche
Abschnitt 2.1.4.3: Bestimmung der Best Matching Unit). Die eigentlichen Verfahren werden
durch die entsprechenden konkreten Klassen implementiert (siehe unten), so dass auch diese
Komponente der SOM -Implementierung mittels des Strategie-Entwurfsmusters eingesetzt
und dynamisch ausgetauscht werden kann.
6
FV ist eine Abkürzung für Feature Vector, die im englischen Sprachgebrauch übliche Bezeichnung für
Trainingsvektoren.
43
Die Auswahl der BMU wird hierbei durch die Funktion selectBMU() realisiert, welche die
in der SOM verwendeten Knoten mit ihren Referenzvektoren, sowie das aktuell zu prüfende
Trainingselement als Parameter benötigt.
Brute-Force-Algorithmus
Die konkrete Klasse BruteForceBMUSelector implementiert das
nicht optimierte, in Abschnitt 2.1.4.3: Bestimmung der Best Matching Unit vorgestellte Verfahren, in welchem das aktuelle Trainingselement mit den Referenzvektoren aller Knoten
verglichen wird, um den mit der minimalen Euklidische Distanz zu bestimmen.
Der Name der Klasse leitet sich von so genannten Brute-Force-Algorithmen ab, welche durch
Testen aller Möglichkeiten zu einem Ergebnis kommen [Pre10]. Diese Algorithmen wenden
also „rohe Kraft“ (englisch: „brute force“) an, um eine Lösung zu finden.
Quick-Reaction-Algorithmus
Analog zum BruteForceBMUSelector implementiert die kon-
krete Klasse QuickReactionBMUSelector das in Abschnitt 2.3.2.1: Quick-Reaction-Algorithmus vorgestellte Verfahren zur beschleunigten BMU -Suche.
BMU-Caching
Die konkrete Klasse CachedBMUSelector implementiert das in Abschnitt
2.3.2.2: BMU-Caching vorgestellte Verfahren zur BMU -Suche, bei dem Ergebnisse aus früheren Iterationsschritten zwischengespeichert werden, damit folgende Suchvorgänge nur in
der unmittelbaren Umgebung der zuvor gefundenen BMU suchen müssen.
Sie verwendet eine Instanz des BruteForceBMUSelectors, um in der ersten Iteration die
Best Matching Units zu bestimmen, da hier noch keine zwischengespeicherten Ergebnisse
vorliegen.
4.3.3.3 SelfOrganizingMap
Die abstrakte Hauptklasse dieses Moduls, SelfOrganizingMap, implementiert alle Gemeinsamkeiten zwischen den beiden vorgestellten Varianten des SOM-Algorithmus. Diese unterscheiden sich nur in der Art des Trainings und werden durch die entsprechenden konkreten
Klassen OriginalAlgorithm und BatchAlgorithm implementiert.
Um eine SOM zu erstellen, benötigt der Konstruktor folgende Parameter, welche in entsprechenden lokalen Variablen gespeichert werden:
1. Breite und Höhe der gewünschten Karte (width, height)
2. Eine Liste der zu verwendenden Trainingsvektoren (FV_list)
3. Eine Angabe des gewünschten Lernratenfaktors als Fließkommazahl (learning_rate)
44
4.3 Komponenten
4. Eine Instanz der Klasse SOMInitializer (initializer)
5. Eine Instanz der Klasse BMUSelector (BMU_selector)
Ausgehend von der angegebenen Breite und Höhe wird nun ein zweidimensionales Feld (Array) initialisiert, welches die Referenzvektoren hält und mittels zweidimensionaler Indizierung auch gleichzeitig die Koordinaten der zugehörigen Knoten abbildet (Variable nodes). Die
Knoten sind daher hier durch die Koordinaten-Tupel (0, 0), (0, 1) . . . , (0, w), (1, 0) . . . (h, w)
definiert, wobei h die Höhe und w die Breite der Karte ist.
Das Initialisieren der Referenzvektoren, sowie das Bestimmen der BMU während des Trainings wird hier durch das Strategie-Entwurfsmuster in eigene Klassen ausgelagert. Diese sind
als initializer und BMU_selector Komponenten dieser SOM -Implementation (siehe oben).
Eine einfache Optimierung ist hier zudem durch die Funktion find_neighborhood() gegeben:
Sie bestimmt mittels der Manhattan-Distanz 7 alle Knoten, die ausgehend von einer gegebenen Knotenposition in einem gegebenen Radius um diese liegen. Dadurch lässt sich der
Einfluss des aktuellen Trainingelements in einem Iterationsschritt vereinfacht berechnen, da
die Abstandsfunktion h(t) (siehe Abschnitt 2.1.4.4: Annäherung der Referenzvektoren) nicht
auf alle Knoten angewendet werden muss, sondern nur auf solche, die auch tatsächlich für
eine Beeinflussung in Frage kommen.
Weitere wichtige Funktionen der SelfOrganizingMap-Klasse sind calibrate(), welche das in
Abschnitt 2.1.4.6: Kalibrierung beschriebene Verfahren der Kalibrierung einer SOM implementiert, sowie continue_training(), welche anhand übergebener Iterationszahl und zwischengespeicherter SOM erlaubt, ein bereits angefangenes Training dieser fortzusetzen. Dies
ist insbesondere für große SOMs mit einer hohen Anzahl an Trainingselementen wichtig (wie
in den Experimenten dieser Thesis verwendet), da deren Training über mehrere Tage hinweg
andauern kann (vergleiche Abschnitt 2.3: Verfahren zur Optimierung).
Originaler Algorithmus Die konkrete Klasse OriginalAlgorithm implementiert mit ihrer
Funktion train() das Training des originalen SOM-Algorithmus. Dieses ist in Abschnitt 2.1.4:
Training ausführlich beschrieben.
Batch-SOM Analog zur Klasse OriginalAlgorithm implementiert die konkrete Klasse BatchAlgorithm das Training des in Abschnitt 2.1.5: Alternativer Algorithmus: Die Batch-Map
beschriebenen Batch-SOM-Algorithmus.
7
Die Manhattan-Distanz ist eine vereinfachte Distanz-Rechnung, bei der die Distanz zwischen pei Punkten
als Betragssumme der Differenzen ihrer Koordinaten gesehen wird, welche vor allem für Wegstrecken in
schachbrettartigen Strukturen verwendet wird. Der Name leitet sich von dem gitterförmigen Straßennetz
Manhattans ab [Kra87].
45
Abbildung 4.4: Klassendiagramm der Visualisierungs- und Evaluierungs-Module
4.3.4 Visualisierung
Im Folgenden werden zwei Verfahren zur Visualisierung trainierter SOMs und deren Implementierung beschrieben. Abbildung 4.4 zeigt die Klassendiagramme dieses Moduls.
4.3.4.1 Rasterbild-Visualisierung
Die Klasse RasterImageDisplayer implementiert mittels ihrere Funktion printImage() ein
einfaches Verfahren zur Visualisierung einer SOM als ein Rasterbild. Hierbei wird ein leeres
Rasterbild mit den Ausmaßen des Knotengitters einer übergebenen SOM erstellt, so dass
jeder einzelne Knoten einem Pixel des Rasterbildes entspricht. Das in Abschnitt 2.1.4.4:
Annäherung der Referenzvektoren verwendete Beispiel, bei dem die Referenzvektoren dreidimensionale Farbinformationen in RGB-Repräsentation abbilden, erlaubt eine direkte Darstellung der entsprechenden Knoten als Pixel. Aber auch für andere Arten von Referenzvektoren ist eine einfache Darstellung des Clusterings als Graustufenbild möglich:
Anhand einer gegebenen, kalibrierten SOM (repräsentiert durch die Variable map) wird
zuerst durch die Funktion getMaxElementCount() die maximale Anzahl an mit einem Knoten
attribuierten Trainingselementen amax bestimmt (vergleiche Abschnitt 2.1.4.6: Kalibrierung).
Dieser Wert wird nun als Weiß (Graustufenwert mit maximaler Intensität 255) gesetzt;
entsprechend repräsentieren Knoten komplett ohne attribuierte Trainingselemente die Farbe
Schwarz (Graustufenwert mit minimaler Intensität 0). Ausgehend davon ist die Darstellung
eines Knoten mit der Anzahl a an attribuierten Trainingselementen als Graustufenwert c,
welcher für alle Komponenten einer RGB-Farbrepräsentation gilt, ein einfacher Strahlensatz:
c=
46
255
∗a
amax
(4.7)
4.3 Komponenten
Hat eine SOM viele Knoten mit geringer Anzahl an attribuierten Trainingselementen, so
kann es sinnvoll sein, den berechneten Graustufenwert aller Knoten um einen Skalar z nach
oben zu skalieren (mit Weiß als Maximum), um die Sichtbarkeit dieser zu verbessern:
cscaled =



 c∗z |z >1



255
wenn c ∗ z < 255
(4.8)
sonst
(a)
(b)
Abbildung 4.5: Beispiele einer Rasterbild-Visualisierung
Ausgehend von einer derartigen Visualisierung können bereits erste Annahmen über die
Qualität der Projektion des Eingaberaums auf den Ausgaberaum (vergleiche Abschnitt 2.1.2:
Begriffserklärungen) einer SOM getroffen werden: 8 :
Abbildung 4.5a zeigt die Visualisierung einer kalibrierten SOM, die mit Trainingsvektoren
trainiert wurde, welche mit Hilfe des in Abschnitt 4.3.2.4: Semantische Aggregation mit
zeitlicher Unterscheidung beschriebenen Verfahrens erstellt wurden. Die attribuierten Trainingselemente liegen über den Großteil der Karte verstreut, häufig gruppiert in bestimmten
Bereichen (Datenbündel, englisch: Cluster). Dieses Verhalten ist zu erwarten, da die Wortvektoren der für diese Thesis verwendeten Trainingsvektoren nahezu paarweise orthogonal
sind (vergleiche Abschnitt 4.3.2.2: Alphabetgenerierung). Man kann also davon ausgehen,
dass die Trainingsvektoren selbst untereinander ebenfalls unabhängig sind. Dies gilt, solange
zwischen ihnen nicht eine semantische Beziehung besteht, sie also nicht die gleichen Wortvektoren beinhalten. Es lässt sich also folgern, dass eine Projektion dieser Trainingsvektoren
auf eine SOM zur oben ersichtlichen Streuung führt.
8
Hier wird das Wort Projektion verwendet, wenn eine inhaltiche Abbildung der Trainingsvektoren auf die
Referenzvektoren einer SOM gemeint ist, um Verwirrung mit der Visualisierung zu vermeiden, welche
selbst eine grafische Abbildung ist. Vergleiche auch Abschnitt 2.1.4.4: Annäherung der Referenzvektoren
für eine Erklärung der nicht-linearen Projektion des SOM-Algorithmus.
47
In Abbildung 4.5b hingegen ballen sich die attribuierten Trainingselemente auf wenige Bereiche. Damit es zu einem solchen Verhalten kommen kann, müssen die verwendeten Trainingsvektoren einander sehr ähnlich sein - die oben formulierte Unabhängigkeit ist also nicht
gegeben. In diesem Fall handelt es sich um die Visualisierung einer SOM, deren Trainingsvektoren durch das in Abschnitt 3.4.3: Zu hohe oder sonst unübliche Zugriffs-Geschwindigkeit
im ersten Absatz beschriebene Verfahren erstellt wurden. Dort wurde bereits gezeigt, dass
dieses Verfahren zu keinen sinnvollen Ergebnissen führen kann.
Berücksichtigt man also die Bedingungen, die an Trainingsvektoren gestellt werden, kann
man bereits anhand der Visualisierung einer SOM erkennen, ob diese eine verwendbare
Projektion des Eingaberaums darstellt.
4.3.4.2 Interaktive Visualisierung der kalibrierten Karte
Abbildung 4.6: Interaktive Darstellung einer kalibrierten SOM
Während oben beschriebene Visualisierung als Rasterbild bereits einen Aufschluss über die
Abbildungsstruktur der SOM gibt, ist daraus nicht ersichtlich, welche Trainingselemente
nun tatsächlich auf welche Knoten abgebildet wurden. Daher wurde mit der Klasse SOMDisplayer eine interaktive Visualisierung implementiert, welche, analog zur Visualisierung
als Rasterbild, die attribuierten Knoten einer übergebenen, kalibrierten SOM als Gitter aus
Quadraten darstellt. Diese sind entsprechend der Anzahl der mit dem jeweiligen Knoten attribuierten Trainingselementen mit einem Graustufenwert eingefärbt (siehe Gleichung 4.7).
Klickt man nun mit der Maus auf eines dieser Quadrate, so werden in einer zusätzlichen
Ansicht alle mit dem durch dieses Quadrat dargestellten Knoten attribuierten Trainingselemente aufgelistet. Dies ist in Abbildung 4.6 dargestellt.
48
4.3 Komponenten
Inbesonders bei gemittelter semantischer Aggregation (siehe Abschnitt 4.3.2.4: Gemittelte
semantische Aggregation) lassen sich hier die semantischen Beziehungen von Seiteninhalten, abgebildet durch den vereinfachten Klickpfad, gut erkennen, da Aufrufe von inhaltlich
zusammengehörigen Inhalten bei dieser Art von Trainingsvektoren örtlich nah beieinander
abgebildet werden (siehe Abschnitt 3.4.1: Klickpfad). Bei anderen Aggregationsverfahren, die
eine wesentlich größere Zahl an Trainingsvektoren erzeugen, wird diese Ansicht aber schnell
unübersichtlich, da die Kalibrierung hier häufig zu viele Trainingselemente mit einem Knoten
attribuiert, als dass inhaltliche Zusammenhänge noch offensichtlich wären.
Im konkreten Fall des für diese Arbeit entwickelten Prototypen wurde diese Visualisierung mit Hilfe der Benutzerschnittstellen-Bibliothek wxPython (eine Kapselung der C++Bibliothek wxWidgets für Python) erstellt. Die hier beschriebene Darstellungsart ist aber
allgemeingültig und damit nicht an diese Bibliothek gebunden.
Darstellung von Kontrolldaten
Zur Auswertung der berechneten Karten wurden per Hand
gefilterte Zugriffsprotokolle als Kontrolldaten geschaffen: Eine Protokolldatei, die ausschließlich protokollierte Zugriffe von Bots beinhaltet, sowie eine Datei, die ausschließlich Zugriffe
von Menschen protokolliert.
Die Klasse BotDisplayer, eine Spezialisierung der Klasse SOMDisplayer, erlaubt nun die
Darstellung dieser Kontrolldaten im Kontext einer auf ungefilterten Protokollen basierten
SOM :
Abbildung 4.7: Einfärbung von Knoten, auf die Kontrolldaten abgebildet werden
Der Konstruktor der Klasse benötigt zwei kalibrierte Karten als Parameter. Die erste ist die
auf üblichem Weg erzeugte Karte, wie sie auch von den oben genannten, anderen Verfahren
visualisiert wird. Bei der zweiten handelt es sich um die gleiche Karte, welche allerdings nachträglich durch die Klasse BotEvaluator (siehe Abschnitt 4.3.5.1: Kalibrierung mit fremden
Daten) mit den Kontrolldaten kalibriert wurde.
49
Es wird nun die erste Karte dargestellt, analog zur oben beschriebenen interaktiven Visualsierung, zusätzlich jedoch werden Quadrate, die Knoten repräsentieren, welche auch auf der
zweiten Karte mit Trainingselementen attribuiert sind, rot eingefärbt (siehe Abbildung 4.7).
Dadurch lässt sich leicht erkennen, auf welche Bereiche der Karte die Kontrolldaten abgebildet werden - unterscheiden diese sich signifikant von den Abbildungsbereichen der normalen
Trainingsdaten, so lässt sich bereits anhand dessen ein Kriterium für das Erkennen von Bots
anhand einer Selbstorganisierenden Karte ableiten. Entgegen erster Erwartungen war dies
bei den im Rahmen dieser Arbeit durchgeführten Experimenten aber nicht der Fall.
4.3.5 Evaluierung
Das Modul Evaluierung kapselt alle Verfahren zur Bewertung und Auswertung trainierter
und kalibrierter SOMs. Im Folgenden werden daher gleichermaßen Verfahren beschrieben,
welche als Indikator für die Qualität einer Abbildung durch eine SOM dienen, wie auch
solche, die zur Erkennung von Bots verwendet wurden.
Abbildung 4.4 zeigt die Klassendiagramme dieses Moduls.
4.3.5.1 Kalibrierung mit fremden Daten
Wie zuvor erwähnt, wurden zur Auswertung der SOMs Kontrolldaten erstellt, um das Abbildungsverhalten von ausschließlich menschlichen, beziehungsweise ausschließlich automatisierten Zugriffen kontrolliert testen zu können. Hierfür wurden die zum Training der Karten
verwendeten protokollierten Zugriffe per Hand in solche, bei denen es sich nach den in Abschnitt 3.3: Kriterien zur Erkennung beschriebenen Kriterien eindeutig um automatisiert
erfolgende Zugriffe handelt, und solche, die eindeutig durch menschliche Benutzer getätigt
wurden, sortiert.
Um nun herauszufinden, auf welche Bereiche einer bereits trainierten Karte diese Kontrolldaten abgebildet werden, muss die SOM mit diesen fremden 9 Daten kalibriert werden. Hierfür
wird aus den Kontrolldaten durch das gleiche Verfahren, mit dem auch die Trainingsdaten der
Karte zu Trainingsvektoren aufbereitet wurden, Kontrollvektoren gebildet (siehe Abschnitt
4.3.2.4: Kontext-Aggregation). Die dafür verwendeten Wortvektoren werden allerdings nicht
neu erzeugt, sondern aus dem bereits für das Training der Karte erzeugten Alphabet entnommen. Enthält dieses zu einer in den Kontrolldaten vorkommenden URL keinen Wortvektor,
so kann der entsprechende Aufruf nicht für diese Kalibrierung verwendet werden.
9
Protokollierte Zugriffe, die nicht für das Training der SOM verwendet, sondern nachträglich zu ihrer Bewertung auf die Karte abgebildet werden, werden zum einfacheren Verständnis in dieser Arbeit als fremde
Daten bezeichnet.
50
4.3 Komponenten
Zu den so erstellten Kontrollvektoren werden auf der Karte jeweils Best Matching Units gesucht, welche mit den durch Trainingsvektoren repräsentierten, protokollierten Zugriffen aus
den Kontrolldaten attribuiert werden. Auf diese Weise entsteht eine Karte, die ausschließlich mit den Kontrolldaten kalibriert ist, obwohl diese nicht direkt zum Training der Karte
verwendet wurden.
Dieses Verfahren wird durch die Klasse BotEvaluator implementiert. Ihr Konstruktor erfordert die Knoten einer trainierten SOM (Variable nodes), sowie das zu ihrem Training
verwendete Alphabetverzeichnis (Variable alphabet) als Parameter. Die Funktion getCalibratedMapForLines() berechnet nun eine entsprechende Karte, die mit den an diese Funktion
als Parameter übergebenen Zugriffsprotokollzeilen attribuiert ist.
4.3.5.2 Qualitäts-Berechnung
Da das Endergebnis einer SOM von vielen Parametern abhängt (beispielweise von dem verwendeten Lernratenfaktor, dem initialen Radius oder der Größe der Karte, siehe Abschnitt
2.1.4.4: Annäherung der Referenzvektoren), ist es leicht ersichtlich, dass mit verschiedenen
Parametern trainierte SOMs den gleichen Eingaberaum unterschiedlich genau abbilden können [Koh01, Seite 161]. Dies gilt insbesondere, wenn die Referenzvektoren mit zufälligen
Werten initialisiert wurden.
Die Klasse SomQualityCalculator implementiert daher zwei Funktionen, um die Abbildungsqualität einer trainierten SOM anhand übergebener Knoten und verwendeter Trainingsvektoren zu beurteilen:
Quantisierungsfehler Die Funktion getQuantizationError() berechnet den so genannten
Quantisierungsfehler [Koh01, Seite 161]. Hierbei handelt es sich um das arithmetische Mittel
q der Differenzbeträge aus den n Trainingsvektoren ~xi und den Referenzvektoren der jeweils
zugehörigen BMUs m
~ ci (vergleiche Abschnitt 2.1.4.3: Bestimmung der Best Matching Unit):
q=
Pn
xi
i=0 k~
−m
~ ci k
n
(4.9)
Der Quantisierungsfehler gibt hier also den mittleren Fehler bei der Abbildung der Trainingsvektoren an: Je kleiner dieser Wert, desto präziser die Abbildung.
Topologieerhaltung
Es existieren mehrere Methoden, um die Genauigkeit der topologi-
schen Abbildung (also dem Erhalt der Nachbarschaftsbeziehungen zwischen Elementen des
Eingaberaums) zu bestimmen [Koh01, Seite 161]. Die für diese Arbeit verwendete Methode
51
ist der Vergleich des Knotens mit dem Referenzvektor, der zu einem Trainingsvektor die geringste Euklidische Distanz hat (die Best Matching Unit), mit jenem, welcher zum gleichen
Trainingsvektor die zweitkleinste Euklidische Distanz hat (die Second Best Matching Unit).
Sind diese Knoten keine direkten Nachbarn, so wurde die Topologie des Eingaberaums durch
die Abbildung der SOM verzerrt [Koh01, Seite 161].
Bezeichnet der Vektor ~kdi die Knotenposition der Second Best Matching Unit zum Trainingsvektor ~xi auf der Karte und ~kci die der Best Matching Unit, so lässt sich die TopologieErhaltung t als arithmetisches Mittel der Entfernungen dieser zueinander ausdrücken:
t=
Pn
~
i=0 kkdi
− ~kci k
n
(4.10)
Werden die Knoten einer SOM, wie in der in Abschnitt 4.3.3.3: SelfOrganizingMap beschriebenen Implementierung, als zweidimensionales Feld mit ganzzahligen Indizes gehalten, so
gibt es für zwei direkt benachbarte Knoten zwei mögliche Entfernungen: Genau 1, 0, wenn
die Knoten horizontal oder vertikal benachbart sind, oder ∼ 1, 41, wenn sie diagonal gegenüber liegen. Übersteigt t also hier diese Beträge, so sind beim Training der SOM topologische
Abbildungsfehler entstanden.
Auch hier gilt: Je kleiner der Wert, desto präziser die Abbildung.
4.3.5.3 Distanz-Berechnung
Wurde eine der in Abschnitt 4.3.2.4: Kontext-Aggregation beschriebenen Generierungsarten
für Trainingsvektoren verwendet, so bildet eine damit trainierte SOM eine Form des Klickpfad der zu analysierenden Webseite ab (vergleiche Abschnitt 3.3: Kriterien zur Erkennung).
Es werden also sich ähnelnde Zugriffsmuster örtlich nah beieinander auf der Karte abgebildet.
Wird nun analog zur Kalibrierung mit fremden Daten (siehe oben) die Best Matching Units
zu fremden Zugriffsmustern eines menschlichen Benutzers, der sich naturgemäß an diesen
zeitlichen Klickpfad hält, ermittelt, so ist davon auszugehen, dass die BMUs zu aufeinanderfolgenden Zugriffsmustern ebenfalls örtlich nah beieinander liegen. Entsprechend ist zu
erwarten, dass dies bei Zugriffsmustern eines Bots, der diesen Klickpfad nicht befolgt, nicht
der Fall ist. Hieraus lässt sich ein Kriterium zum Erkennen von automatisierten Zugriffen
anhand von auf obige Art trainierten SOMs ableiten:
Ist das arithmetische Mittel a der Knotenabstände von BMUs aufeinander folgender Zugriffsmuster eines Benutzers nah genug an 0 oder einem Abstandsmaximum amax , so handelt es
sich bei dem Benutzer um einen Bot. Ein Abstandsmittel nahe an 0 bedeutet hierbei, dass
die Zugriffsmuster des Benutzers immer wieder zu der selben BMU führen. Das ist nur möglich, wenn auch immer wieder die gleichen Webinhalte aufgerufen werden - beispielsweise
52
4.3 Komponenten
dann, wenn zusätzliche Inhalte wie Bilder und CSS-Stylesheets nicht geladen werden und
der Bot sich nur innerhalb der selben Seite bewegt, etwa weil er zur Navigation benötigtes
JavaScript oder Ähnliches nicht auswertet.
Ist das arithmetische Mittel der Abstände hingegen nahe am Abstandsmaximum amax , so
ruft der Benutzer offensichtlich Inhalte nacheinander auf, die nicht durch den Klickpfad
miteinander verbunden sind, oder die zeitlichen Distanzen der Zugriffe sind für diese Inhalte
unüblich (siehe oben).
Das Abstandsmaximum amax lässt sich nun auf zweierlei Art bestimmen: Entweder, es wird
tatsächlich das Maximum aller auftretenden Abstände von zu Zugriffsmustern gehörenden
BMUs genommen, was eine Auswertung aller protokollierten Zugriffe einer Zugriffsprotokolldatei vor der eigentlichen Analyse erfordern würde. Oder aber es genügt eine Schätzung
dieses Wertes anhand der Größe der verwendeten SOM, etwa durch folgenden Ausdruck:
amax =
h+w
3
(4.11)
Damit lässt sich das Kriterium als folgende aussagenlogische Formel beschreiben:
((a − ǫ) ≤ 0) ∨ ((a + ǫ) ≥ amax )
(4.12)
Wobei ǫ eine Konstante ist, welche die erlaubte Differenz des Abstandsmittels zu 0 oder amax
angibt, bei der der Benutzer noch als Bot gewertet wird.
Alternativ zu einer absoluten Aussage kann der Differenzbetrag der Minimal- beziehungsweise Maximalwerte zum Abstandsmittel auch als pronzentuale Angabe interpretiert werden,
die die Wahrscheinlichkeit angibt, mit der es sich bei einem Benutzer um einen Bot handelt.
Reicht die Präzision der Erkennung nicht für eine automatisierte Auswertung aus, so kann
diese Prozentangabe verwendet werden, um die manuelle Bewertung von Zugriffsprotokollen
zu unterstützen.
Dieses Verfahren wird im Folgenden als mittlere Abbildungsdistanz bezeichnet und vorrangig
zur Bewertung trainierter SOMs verwendet.
53
54
In diesem Kapitel sind die im Rahmen dieser Arbeit durchgeführte Experimente zur Analyse
der Eignung des SOM -Algorithmus zur Erkennung automatisierter Zugriffe auf Webseiten
im Detail beschrieben und kritisch bewertet.
5.1 Beschreibung der Testumgebung
Dieser Abschnitt beschreibt die zur Durchführung der im Folgenden beschriebenen Experimente verwendete Testumgebung. Sie setzt sich zusammen aus der Plattform, auf der die
entsprechenden SOMs und Trainingsvektoren berechnet wurden, und der Quelle der für die
Experimente verwendeten Zugriffsprotokolle.
5.1.1 Plattform
Tabelle 5.1 listet die relevanten Daten der für die Durchführung der Experimente verwendeten Testplattform auf. Die in diesem Kapitel beschriebene Laufzeiten beziehen sich auf diese
Konfiguration.
Prozessor
R
Intel
CoreTM 2 Duo P8400 @ 2.26GHz
Arbeitsspeicher
3,0 GiB DDR2 SDRAM
Betriebssystem
Ubuntu Linux 9.10 - Karmic Koala
Python-Interpreter
Python 2.6.4
SciPy-Bibliothek
SciPy 0.7.0
Tabelle 5.1: Technische Daten der Testplattform
5.1.2 Quelle der Testdaten
Alle in dieser Arbeit verwendeten Zugriffsprotokolle entstammen der E-Commerce-Webseite
www.cereal-club.de. Hierbei handelt es sich um eine komplexe Webseite mit dynamischen In-
55
halten, welche an vielen Stellen JavaScript und AJAX 10 verwendet, um die Benutzerführung
und Präsentation aufzubereiten.
Die in dieser Arbeit vorgestellte Bewertungen der Ergebnisse müssen also daher vor dem
Hintergrund einer derartigen Seitenstruktur betrachtet werden, lassen sich aber in der Regel
auch auf andere Arten von Webseiten übertragen.
5.2 Präsentation ausgewählter Experimente
Im Folgenden ist eine beispielhafte Auswahl der im Rahmen dieser Arbeit durchgeführten
Experimente aufgeführt. Es handelt sich dabei nur um eine kleine Teilmenge der Experimente, welche die Auswirkungen der vorgestellten Verfahren und ihre Wirksamkeit für die
Erkennung automatisierter Zugriffe zeigen. Ähnliche Experimente, die sich nur in der Wahl
bestimmter Parameter unterscheiden, aber für diese Thesis keine zusätzlichen Informationen
erbringen, sind daher nicht aufgeführt.
Die folgenden Tabellen geben jeweils Aufschluss über die Eigenschaften der jeweiligen SOMs
und ihrer Bedeutung für die Erkennung automatisierter Zugriffe. Sie sind in jeweils drei
Abschnitte unterteilt:
Der erste Abschnitt der jeweiligen Tabellen bezieht sich auf die Konfiguration der SOM und
gibt Angaben über laufzeitrelevante Eigenschaften der verwendeten Trainingsvektoren. Da
das Training der SOMs aufgrund der hohen Laufzeiten an mehreren Stellen unterbrochen
wurde, ist die angegebene Gesamtlaufzeit des Trainings der jeweiligen SOM eine gerundete
Schätzung, ermittelt aus der durchschnittlichen Dauer einzelner Iterationen.
Bei den Angaben zu den Quantisierungs- und Topologiefehlern handelt es sich um Kennzahlen zur Qualität der SOM, welche nach dem in Abschnitt 4.3.5.2: Qualitäts-Berechnung
beschriebenen Verfahren berechnet wurden.
Als letzter Abschnitt der Tabelle folgt die prozentuelle Aussage, wie viele der in den Kontrolldaten aufgeführten Bots durch die jeweilige SOM korrekt erkannt wurden. Zur Bestimmung dieses Wertes wurde das in Abschnitt 4.3.5.3: Distanz-Berechnung beschriebe Verfahren verwendet. Darauf aufbauend gibt die Fehlerquote das Verhältnis von insgesamt als
Bots erkannten Benutzern zu fälschlicherweise als Bots erkannte an. Wurden beispielsweise
vier Benutzer als Bot erkannt, wovon aber zwei tatsächlich menschliche Benutzer waren, so
beträgt die Fehlerquote 50%.
Alle hier vorgestellten SOMs benötigten etwa 1000 Iterationen bis zur Terminierung.
10
AJAX ist ein Akronym für Asynchronous JavaScript and XML und bezeichnet eine Technik, um Seiteninhalte dynamisch nachzuladen, ohne einen erneuten Seitenaufruf zu benötigen [UD07, Seiten 2ff].
56
5.2.1 Einfache semantische Aggregation
Größe in Knoten
16 × 16
Anzahl der Trainingsvektoren
111791
Dimension der Trainingsvektoren
78
Gesamtlaufzeit des Trainings
37 Stunden
Filterung der Zugriffsprotokolle
Keine
Topologiefehler
2,36
Quantisierungsfehler
1,46
Erkennung von Bots
13,92%
Fehlerquote
21,42%
Tabelle 5.2: Klickpfad-SOM ohne zeitliche Komponente
Die Trainingsvektoren, die für das Training der in Tabelle 5.2 dargestellten SOM verwendet
wurden, wurden durch das in Abschnitt 4.3.2.4: Einfache semantische Aggregation beschriebene Verfahren erstellt. Den dadurch abgebildeten Zugriffsmustern fehlt also jegliche zeitliche
Information, wodurch ausschließlich das Erkennen von Bots möglich ist, die sich nicht an
den Klickpfad halten (siehe Abschnitt 3.3.1: Klickpfad) oder nur einzelne Inhalte abrufen.
Entsprechend ist es nicht verwunderlich, dass dieses Verfahren nur ∼ 14% aller in den Kontrolldaten aufgeführten Bots als solche erkennt: Viele dieser Bots sind so genannte Crawler,
die zur Analyse (etwa zur Indizierung für Suchmaschinen) einer Webseite den dort angegebenen Hyperlinks folgen und sich somit an den Klickpfad der Seite halten [Wik10a]. Da sich
die meisten dieser Bots als solche zu erkennen geben, kann diese Klickpfad-SOM als unterstüzendes Werkzeug in Kombination mit regelbasierten Verfahren wie einer Auswertung der
Browserkennung und statistischen Analyse der Zugriffsgeschwindigkeit verwendet werden.
Bei den (im Verhältnis zu anderen Experimenten) geringen Fehlerkennungen von menschlichen Benutzern als Bots handelt es sich um zwei Benutzer, die durch die manuelle Eingabe
der URL einer Unterseite den Klickpfad durchbrochen haben, sowie um einen Benutzer aus
dem AOL-Netzwerk11 . Durch das Einführen von Sonderregeln zur Behandlung dieser Art
11
Benutzer aus dem AOL (früher America Online) - Netzwerk beziehen ihren Internetzugang über einen
gemeinsam genutzten Proxy-Server, welcher Inhalte zwischenspeichert und nur unbekannte oder veraltete
Inhalte neu abruft [AO04]. Dadurch können Zugriffe des gleichen AOL-Benutzers auf unterschiedliche
57
von Benutzern, welche sich beispielsweise über die Referer-Information beziehungsweise die
Browserkennung erkennen lassen, könnten auch diese Fehlerkennungen verhindert werden.
5.2.2 Gemittelte semantische Aggregation
Größe in Knoten
16 × 16
4395
150
6 Stunden
Keine
Topologiefehler
2,23
0,99
Erkennung von Bots
20,25%
Fehlerquote
44,82%
Tabelle 5.3: Gemittelte Klickpfad-SOM ohne zeitliche Komponente
Für die in Tabelle 5.3 dargestellte SOM gelten die gleichen Beurteilungen, wie für die zuvor genannte. Die Trainingsvektoren wurden hier mit dem in Abschnitt 4.3.2.4: Gemittelte
semantische Aggregation vorgestellten Verfahren erstellt. Zugriffsmuster von Bots sind also
gleichwertig zu denen von menschlichen Benutzern abgebildet.
Anders als zuvor vermutet, bereitet diese gleichwertige Abbildung keine Probleme bei der
Erkennung. Im Gegenteil wird durch dieses Verfahren ein größerer Anteil der in den Kontrolldaten aufgeführten Bots erkannt, als durch die einfache semantische Aggregation. Allerdings
ist hier auch die Fehlerquote deutlich höher, was sich dadurch erklären lässt, dass menschliche Benutzer mit unregelmäßigem Verhalten (etwa AOL-Benutzer) aufgrund der gemittelten
Aggregation eher auf Knoten abgebildet werden, welche zuvor durch in den Trainingsdaten
vorhandene Bot-Zugriffe geprägt wurden. Diese lassen sich gut in der Visualisierung erkennen: Die außen und mittig liegenden, grau eingefärbten Knoten entsprechen den Zugriffsmustern von Bots, während die Ballung von hell dargestellten Knoten im unteren Bereich
der Karte aus dem Zugriffsverhalten von menschlichen Benutzern resultiert. Dadurch ist
die mittlere Abbildungsdistanz aufeinanderfolgender Zugriffe dieser abweichenden Benutzer
höher als die solcher, die sich ausschließlich in der unteren Ballung bewegen.
IP-Adressen verteilt sein und das Anfordern ganzer Inhaltsgruppen überspringen, was für diese Analyse
wie ein Verlassen des Klickpfades wirkt.
58
Dementsprechend sind über 60% der fehlerhaft als Bot erkannten Zugriffe solche aus dem
AOL-Netzwerk.
Anhand der Visualisierung lässt sich zudem eine große Streuung der mit Trainingselemente
attribuierten Knoten erkennen. Daraus folgt, dass diese SOM für die geringe Anzahl an
Trainingsvektoren zu groß ist und eine kleinere Karte eine präzisere Abbildung darstellen
könnte. Der Topologiefehler ist mit einem Wert von 2,23 (Werte im Bereich von 1,0 bis 1,41
wären optimal, vergleiche auch Abschnitt 4.3.5.2: Topologieerhaltung) allerdings (besonders
im Vergleich zu unten aufgeführten Experimenten) noch unbedenklich. Der Zeitaufwand
einer erneuten Berechnung dieser SOM ist daher nicht gerechtfertigt.
5.2.3 Semantische Aggregation mit zeitlicher Unterscheidung
Größe in Knoten
32 × 24
20181
21
30 Stunden
Keine
Topologiefehler
9,5
0,76
Erkennung von Bots
3,79%
Fehlerquote
25%
Tabelle 5.4: Klickpfad-SOM mit Zeitdistanz-Unterscheidung 1
In Tabelle 5.4 ist eine SOM dargestellt, welche mit Trainingsvektoren trainiert wurde, die
durch das in Abschnitt 4.3.2.4: Semantische Aggregation mit zeitlicher Unterscheidung vorgestellte Verfahren erstellt wurde. Es ist offensichtlich, dass dieses Verfahren nicht zum erwarteten Präzisionsgewinn durch Berücksichtigung der zeitlichen Komponente führt, was
sich durch eine Reihe von Gründen erklären lässt:
Die Größe der SOM sorgt für eine sehr starke Streuung nur leicht verschiedener Trainingselemente, was der sehr große Topologiefehler von 9,5 verdeutlicht. Dadurch kommt es, wie
oben beschrieben, zu Unregelmäßigkeiten in der mittleren Abbildungsdistanz.
Dies allein erklärt aber noch nicht die verschwindend geringe Erkennungsquote. Der Grund
hierfür liegt im Verfahren selbst: Werden Zugriffe auf gleiche Inhalte mit unterschiedlicher,
59
zeitlicher Distanz auf völlig verschiedene Wortvektoren abgebildet, so ist die Wahrscheinlichkeit hoch, dass auch daraus entstehende Trainingsvektoren für gleiche Zugriffsmuster
verschieden sind. Der SOM -Algorithmus bildet diese also auf verschiedene Bereiche der Karte ab, die mitunter weit voneinander entfernt sein können.
Je nach der zeitlichen Distanz von Zugriffen eines Benutzers kann dies dazu führen, dass
zwei aufeinander folgende Zugriffe auf weit voneinander entfernte Knoten abgebildet werden,
obwohl die Zugriffe dem Klickpfad folgen. Die mittlere Abbildungsdistanz ist hier daher kein
Kriterium für die Erkennung automatisierter Zugriffe.
Größe in Knoten
16 × 16
111734
129
32 Stunden
Keine
Topologiefehler
5,16
1,51
Erkennung von Bots
1,26%
Fehlerquote
92,85%
Tabelle 5.5 zeigt eine SOM, bei der durch die Verkleinerung der Größe und Erhöhung der
Dimension der Trainingsvektoren versucht wurde, die im vorherigen Abschnitt beschriebenen
Probleme zu korrigieren.
Obwohl dies erwartungsgemäß zu einer Verringerung des Topologiefehlers führte, ist hier die
Erkennungsquote noch schlechter als zuvor. Zusammen mit einer fast einhundertprozentigen
Fehlerquote zeigt dies, dass die semantische Aggregation mit zeitlicher Unterscheidung für
die Erkennung automatisierter Zugriffe gänzlich ungeeignet ist.
In Tabelle 5.6 ist ein letzter Versuch gezeigt, mit dieser Art von Trainingsvektorgenerierung
verwertbare Resultate zu erzeugen. Hierfür wurden die Zugriffsprotokolle so gefiltert, dass
nur Zugriffe auf HTML-Inhalte für die Analyse berücksichtigt werden. Protokollierte Aufrufe
von JavaScript-Dateien, CSS-Stylesheets und Bilder wurden also ignoriert.
60
Größe in Knoten
16 × 16
20181
75
9 Stunden
Nur HTML
Topologiefehler
3,66
0,82
Erkennung von Bots
15.18%
Fehlerquote
82,08%
Durch eine derartige Beschränkung wurde erwartet, dass die oben beschriebene Streuung
weniger ins Gewicht falle und eine Auswertung durch Berechnung der mittleren Abbildungsdistanz vereinfacht würde.
Dies ist aber nur zum Teil der Fall: Zwar wird eine größere Anzahl der in den Kontrolldaten
aufgeführten Bots erkannt, die Fehlerquote ist mit 82% allerdings noch immer unbrauchbar
hoch. Vor allem, da es sich beim Großteil der fälschlicherweise als Bot erkannten Benutzer
um menschliche Benutzer mit gewöhnlichem Zugriffsverhalten handelt (im Gegensatz zu
oben beschriebenen Ergebnissen auf Basis einer Aggregation ohne zeitliche Komponente),
unterstreicht dieses Ergebnis nur die zuvor gefällte Beurteilung der semantische Aggregation
mit zeitlicher Unterscheidung als ungeeignet.
5.2.4 Zeitsensitive semantische Aggregation
Die Trainingsvektoren, die zum Training der in Tabelle 5.7 vorgestellten SOM verwendet
wurden, sind mit dem in Abschnitt 4.3.2.4: Zeitsensitive semantische Aggregation beschriebenen Verfahren erstellt worden. Dabei wird die zeitliche Distanz zwischen zwei Zugriffen
eines Benutzers als zusätzliche Dimension in die Trainingsvektoren skaliert eingefügt, statt
wie im oben verwendeten Verfahren für unterschiedliche Zeitdistanzen auch verschiedene
Trainingsvektoren zu generieren.
Wird diese Zeitdistanz dabei auf einen Wert skaliert, so dass sie gleichwertig zu den die
aufgerufenen Inhalte repräsentierenden Wortvektoren ist, so werden Trainingsvektoren zu
inhaltlich verwandten Zugriffsmustern durch den SOM -Algorithmus auch örtlich nah bei-
61
Größe in Knoten
16 × 16
112446
21
17 Stunden
Keine
Topologiefehler
5,40
1,05
Erkennung von Bots
28,74%
Fehlerquote
34,28%
(17,85%)
Tabelle 5.7: Klickpfad-SOM mit integrierter Zeitdifferenz 1
einander abgebildet (vergleiche Abschnitt 3.4.3: Zu hohe oder sonst unübliche Zugriffs-Geschwindigkeit).
In der hier gezeigten SOM ist dies der Fall. Da sich so eine Abbildung des Klickpfads
menschlicher Benutzer mit integrierter, zeitlicher Information bildet, weist diese SOM die
im Vergleich zu anderen höchste Erkennungsquote auf: Fast ein Drittel der in den Kontrolldaten aufgeführten Bots wurden erkannt. Nicht erkannte Bots sind hierbei, wie auch
bei der einfachen semantischen Aggregation ohne zeitliche Komponente, zu großen Teilen
Crawler, deren Zugriffsverhalten dem von Menschen sehr ähnlich ist, aber durch einfache,
regelbasierte Verfahren erkannt werden können.
Die Fehlerquote ist hier ebenfalls vergleichbar mit der der einfachen semantischen Aggregation. Ignoriert man bei der Berechnung der Fehlerquote zudem Zugriffe von Benutzern
aus dem AOL-Netzwerk (siehe oben), so reduziert sie sich auf 17,85% (in Tabelle 5.7 in
Klammern angegeben).
Die Präzision dieses Verfahren ist jedoch nicht ausreichend, um Zugriffe durch Bots automatisiert zu behandeln, da hier zu viele menschliche Benutzer fälschlicherweise als Bots
klassifiziert würden. Für eine Unterstützung einer manuellen Auswertung von Zugriffsprotokollen ist es aber durchaus verwertbar.
Tabelle 5.8 zeigt eine SOM, die verdeutlich, wie entscheidend auch die Betrachtung der
Visualisierung für die Bewertung ist. Der optimale Betrag des Topologiefehlers von 1,0 und
die fast einhundertprozentige Erkennung von Bots lässt zunächst ein traumhaftes Ergebnis
62
Größe in Knoten
16 × 16
112446
53
17 Stunden
Keine
Topologiefehler
1,0
10,21
Erkennung von Bots
93,75%
Fehlerquote
85,40%
Tabelle 5.8: Klickpfad-SOM mit integrierter Zeitdifferenz 2
vermuten. Lediglich die Fehlerquote von 85% und der Quantisierungsfehler von 10,21 geben
Anlass zur Verwunderung.
Durch einen Blick auf die Visualisierung ist aber schnell klar, dass hier durch die Kalibrierung
nur ein einziger Knoten mit allen Trainingselementen attribuiert wurde. Dies ist dadurch zu
erklären, dass die zeitliche Distanz zwischen zwei Zugriffen hier nicht ausreichend skaliert
und daher überrepräsentiert wurde. Die Wortvektoren, welche die aufgerufenen Inhalte repräsentieren, fallen somit für die Berechnung der Euklidischen Distanz zweier Trainingsvektoren nicht mehr ins Gewicht, was die durch den SOM -Algorithmus erzielte Abbildung auf
eine eindimensionale Information reduziert (vergleiche Abschnitt 3.4.3: Zu hohe oder sonst
unübliche Zugriffs-Geschwindigkeit).
63
64
In diesem Kapitel wird die vorliegende Arbeit zusammenfassend dargestellt und eine abschließende Beurteilung der Ergebnisse präsentiert. Es wird auf aus den Experimenten offensichtliche Probleme bei der Verwendung des SOM -Algorithmus zur Erkennung automatisierter Zugriffe eingegangen und es werden Anregungen zur eventuellen Behebung dieser
durch zukünftige Arbeiten gegeben.
6.1 Zusammenfassung
Um die Eignung des Self-Organizing Map-Algorithmus zur Erkennung von automatisierten
Zugriffen auf Webseiten zu ermitteln, wurde in der vorliegenden Arbeit eine detaillierte Erklärung des Algorithmus präsentiert. Es wurden die Eigenschaften des Verfahrens, seine Besonderheiten und sinnvolle Varianten zu Teilaspekten gezeigt. Mehrere Methoden zur Abbildung von Zugriffsprotokollen des Apache-Webservers durch den SOM -Algorithmus wurden
erarbeitet und nach ihrer Eignung zur Klassifizierung von protokollierten Zugriffsmustern
menschlicher und automatisierter Benutzer (Bots) bewertet. Anhand einer beispielhaften
Software-Architektur wurde zudem gezeigt, wie eine Software zur Verwendung dieser Verfahren und ihrer Bewertung gestaltet werden kann.
6.2 Bewertung der Ergebnisse
In diesem Abschnitt werden die durch das in der vorliegenden Arbeit präsentierte Verfahren
gewonnenen Erkenntnisse kritisch betrachtet und auf dabei aufgetretene Probleme erläutert.
6.2.1 Präzision
Die in Abschnitt 5.2: Präsentation ausgewählter Experimente vorgestellten Auswertungen
zeigen deutlich auf, dass der SOM -Algorithmus nicht für eine automatisierte Erkennung
und anschließender Verarbeitung von automatisierten Zugriffen auf Webseiten geeignet ist.
Insbesondere die mangelnde Erkennungsquote von Bots (im besten Fall nicht einmal 30%),
65
zusammen mit häufigen Fehlerkennungen, erfordern eine anschließende, manuelle Bewertung
der Ergebnisse des vorgestellten Verfahrens.
Im genannten Abschnitt wurde allerdings auch gezeigt, dass der größte Teil nicht erkannter
Bots und fälschlicherweise als Bots erkannter, menschlicher Benutzer durch eine Kombination
des SOM -Verfahrens mit regelbasierten Kriterien (vergleiche Abschnitt 3.3: Kriterien zur
Erkennung) ausgeschlossen werden kann. Da in dieser Arbeit aber ausschließlich die Eignung
des SOM -Algorithmus als Alternative zu regelbasierten Verfahren ermittelt wurde, müsste
eine Kombination beider weiter untersucht werden, um eine endgültige Aussage zu fällen.
Der SOM -Algorithmus ist zudem kein klassisches Klassifizierungsverfahren an sich, sondern ist lediglich dazu geeignet, komplexe Quelldaten in eine einfachere, niederdimensionale
Darstellungsform zu übertragen. Daher ist nicht auszuschließen, dass es neben den in dieser Arbeit vorgestellten Verfahren noch andere Möglichkeiten gibt, Zugriffsprotokolle durch
SOMs abzubilden und auszuwerten.
Aufgrund der in dieser Arbeit gewonnenen Erkenntnisse kann ein weiteres Studium des SOM Algorithmus zu diesem Zweck aber nicht empfohlen werden. Es ist anzunehmen, dass die
Verwendung von anderen Verfahren, die direkt für die Klassifizierung von hochdimensionalen
Daten konzipiert wurden (zum Beispiel Support Vector Maschines, siehe [Kar08] für eine
detaillierte Erläuterung des Verfahrens), deutlich zielführender ist.
6.2.2 Laufzeit
Die mit der in dieser Arbeit präsentierten Beispielimplementation berechneten Experimente
benötigten für das Training einer SOM mehrere Stunden Berechnungszeit, in einigen Fällen sogar mehrere Tage. Da das zur Erstellung der Trainingsvektoren benötigte Alphabet
von Wortvektoren (vergleiche Abschnitt 4.3.2.2: Alphabetgenerierung) direkt von der Anzahl
eindeutiger Seiteninhalte abhängt, müsste eine entsprechende SOM bei jeder Änderung der
Seitenstruktur neu trainiert werden. Für Webseiten, deren Struktur sich regelmäßig ändert
(etwa bei solchen mit dynamischen oder tagesaktuellen Inhalten), ist eine solche Trainingszeit
nicht aktzeptabel.
Allerdings ist bei dieser Betrachtung zu berücksichtigen, dass der im Rahmen dieser Arbeit
entwickelte Prototyp auch nur in geringem Maße algorithmisch in Bezug auf die Laufzeit
optimiert wurde (siehe Abschnitt 2.3: Verfahren zur Optimierung). Eine Implementierung
der algorithmischen Kernelemente in C oder einer vergleichbaren, hardwarenahen Sprache,
würde die Laufzeit des Verfahrens stark reduzieren. Wie bereits in Abschnitt 4.1.2: Wahl
der Programmiersprache beschrieben, kann dies auch durch einzelne Module geschehen, welche von der Python-Implementierung des Prototyps verwendet werden können. Zusätzlich
zu solchen Optimierungen ist es möglich, den SOM -Algorithmus und die zu ihm gehören-
66
den Verfahren zu parallelisieren, so dass die benötigten Berechnungen auf mehrere CPUs
aufgeteilt werden können. Dadurch kann, bei geschickter Skalierung, eine weitere, enorme
Laufzeitreduzierung erzielt werden. Eine entsprechende Architektur ist in [LAR99] vorgestellt.
Trotz der oben beschriebenen Probleme ist der SOM -Algrithmus grundsätzlich geeignet, um
komplexe und nur schwer lesbare Zugriffsprotokolle eines Webservers in ein von Menschen
les- und auswertbares Format zu bringen. Die damit verbundenen Verfahren zur Erkennung
automatisierter Zugriffe sind zwar nicht geeignet, um Protokolldateien automatisiert auszuwerten, können aber eine manuelle Beurteilung von Zugriffsmustern durch eine Aufbereitung
und erste Bewertung stark erleichtern.
Für einen entsprechenden Produktiveinsatz ist aber insbesondere eine Optimierung der Laufzeit und der Präsentation der Ergebnisse des hier vorgestellten Prototyps nötig.
67
68
Dies ist ein Ausschnitt der zur Beurteilung des vorgestellten Verfahrens verwendeten Kontrolldaten. Es handelt sich um die protokollierten Zugriffe eines einzelnen, offensichtlich
automatisierten Benutzers. Die Protokollzeilen wurden zur besseren Lesbarkeit auf die wesentlichen Informationen gekürzt.
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
-
[22:16:33]
[22:16:33]
[22:16:33]
[22:16:35]
[22:16:36]
[22:16:36]
[22:16:37]
[22:16:37]
[22:16:37]
[22:16:38]
[22:16:38]
[22:16:39]
[22:16:39]
[22:16:39]
[22:16:40]
[22:16:41]
[22:16:41]
[22:16:41]
[22:16:42]
[22:16:42]
[22:16:42]
[22:16:42]
[22:16:42]
[22:16:44]
[22:16:44]
[22:16:44]
[22:16:44]
[22:16:45]
[22:16:46]
[22:16:46]
[22:16:49]
[22:16:50]
[22:16:52]
[22:16:52]
[22:16:54]
[22:16:55]
[22:16:55]
[22:16:55]
[22:16:55]
[22:16:56]
[22:16:56]
[22:16:57]
[22:16:57]
[22:16:59]
[22:16:59]
[22:17:00]
[22:17:00]
[22:17:00]
[22:17:01]
[22:17:01]
[22:17:03]
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
/ HTTP/1.1" 301 194 "-" "Java/1.6.0_16"
/ HTTP/1.1" 200 19825 "-" "Java/1.6.0_16"
/ HTTP/1.1" 200 19841 "-" "Java/1.6.0_16"
/muesli/%22 HTTP/1.1" 404 19791 "-" "Java/1.6.0_16"
/muesli/%22 HTTP/1.1" 404 19771 "-" "Java/1.6.0_16"
/faq HTTP/1.1" 200 20583 "-" "Java/1.6.0_16"
/faq HTTP/1.1" 301 200 "-" "Java/1.6.0_16"
/imprint HTTP/1.1" 200 12885 "-" "Java/1.6.0_16"
/faq HTTP/1.1" 200 20583 "-" "Java/1.6.0_16"
/js/new_slotmachine.js HTTP/1.1" 200 7206 "-" "Java/1.6.0_16"
/muesli-blog/index.php HTTP/1.1" 301 - "-" "Java/1.6.0_16"
/muesli-blog/ HTTP/1.1" 200 95281 "-" "Java/1.6.0_16"
/js/new_slotmachine.js HTTP/1.1" 200 7206 "-" "Java/1.6.0_16"
/terms HTTP/1.1" 301 204 "-" "Java/1.6.0_16"
/terms HTTP/1.1" 200 17609 "-" "Java/1.6.0_16"
/terms HTTP/1.1" 200 17609 "-" "Java/1.6.0_16"
/firmenkunden HTTP/1.1" 301 218 "-" "Java/1.6.0_16"
/firmenkunden/5/weihnachtsmuesli.html HTTP/1.1" 200 12974 "-" "Java/1.6.0_16"
/js/main.js HTTP/1.1" 200 7746 "-" "Java/1.6.0_16"
/js/main.js HTTP/1.1" 200 7746 "-" "Java/1.6.0_16"
/presse HTTP/1.1" 200 18248 "-" "Java/1.6.0_16"
/muesli-blog/index.php HTTP/1.1" 301 - "-" "Java/1.6.0_16"
/muesli-blog HTTP/1.1" 301 246 "-" "Java/1.6.0_16"
/presse HTTP/1.1" 301 206 "-" "Java/1.6.0_16"
/presse HTTP/1.1" 200 18248 "-" "Java/1.6.0_16"
/muesli/cereal_creator HTTP/1.1" 301 236 "-" "Java/1.6.0_16"
/muesli-blog/xmlrpc.php HTTP/1.1" 200 42 "-" "Java/1.6.0_16"
/js/drag_drop_animation.js HTTP/1.1" 200 3105 "-" "Java/1.6.0_16"
/muesli-blog/?p=3056 HTTP/1.1" 301 - "-" "Java/1.6.0_16"
/muesli-blog/2009/10/halloween-musli-gruseln-und-gewinnen/ HTTP/1.1" 200 47712 "-" "Java/1.6.0_16"
/js/draggable_ext.js HTTP/1.1" 200 32348 "-" "Java/1.6.0_16"
/muesli/cereal_lounge HTTP/1.1" 302 234 "-" "Java/1.6.0_16"
/muesli/cereal_show HTTP/1.1" 301 230 "-" "Java/1.6.0_16"
/js/drag_drop_animation.js HTTP/1.1" 200 3105 "-" "Java/1.6.0_16"
/js/draggable_ext.js HTTP/1.1" 200 32348 "-" "Java/1.6.0_16"
/muesli/cereal_lounge HTTP/1.1" 302 236 "-" "Java/1.6.0_16"
/muesli/zutaten HTTP/1.1" 301 222 "-" "Java/1.6.0_16"
/cereal_pedia/2/fertigmueslis.html HTTP/1.1" 301 260 "-" "Java/1.6.0_16"
69
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
70
-
[22:17:04]
[22:17:05]
[22:17:08]
[22:17:10]
[22:17:11]
[22:17:12]
[22:17:12]
[22:17:13]
[22:17:15]
[22:17:15]
[22:17:15]
[22:17:16]
[22:17:16]
[22:17:17]
[22:17:19]
[22:17:19]
[22:17:19]
[22:17:20]
[22:17:20]
[22:17:21]
[22:17:23]
[22:17:23]
[22:17:25]
[22:17:25]
[22:17:25]
[22:17:25]
[22:17:26]
[22:17:27]
[22:17:27]
[22:17:30]
[22:17:31]
[22:17:32]
[22:17:32]
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
/muesli/faq/%22 HTTP/1.1" 404 19856 "-" "Java/1.6.0_16"
/muesli/imprint/%22 HTTP/1.1" 404 19829 "-" "Java/1.6.0_16"
/muesli/faq/%22 HTTP/1.1" 404 19820 "-" "Java/1.6.0_16"
/muesli/imprint/%22 HTTP/1.1" 404 19832 "-" "Java/1.6.0_16"
/muesli/terms/%22 HTTP/1.1" 404 19844 "-" "Java/1.6.0_16"
/cereal_pedia/3/sportlermueslis.html HTTP/1.1" 200 14069 "-" "Java/1.6.0_16"
/images/bookmarking/facebook.png HTTP/1.1" 200 2938 "-" "Java/1.6.0_16"
/muesli-blog/feed HTTP/1.1" 301 - "-" "Java/1.6.0_16"
/muesli/firmenkunden/%22 HTTP/1.1" 404 19906 "-" "Java/1.6.0_16"
/firmenkunden/1/firmenmuesli.html HTTP/1.1" 301 258 "-" "Java/1.6.0_16"
/muesli-blog/feed/ HTTP/1.1" 200 55408 "-" "Java/1.6.0_16"
/firmenkunden/1/firmenmuesli.html HTTP/1.1" 200 16301 "-" "Java/1.6.0_16"
/firmenkunden/2/einzelhandel.html HTTP/1.1" 301 258 "-" "Java/1.6.0_16"
/firmenkunden/2/einzelhandel.html HTTP/1.1" 200 14052 "-" "Java/1.6.0_16"
/muesli-blog/kundenmeinungen HTTP/1.1" 301 - "-" "Java/1.6.0_16"
/firmenkunden/3/gastronomie_und_hotellerie.html HTTP/1.1" 301 286 "-" "Java/1.6.0_16"
/muesli-blog/kundenmeinungen/ HTTP/1.1" 200 42982 "-" "Java/1.6.0_16"
/firmenkunden/3/gastronomie_und_hotellerie.html HTTP/1.1" 200 15471 "-" "Java/1.6.0_16"
/muesli-blog/partner HTTP/1.1" 301 - "-" "Java/1.6.0_16"
/muesli-blog/partner/ HTTP/1.1" 200 46672 "-" "Java/1.6.0_16"
/firmenkunden/4/mueslipromotion.html HTTP/1.1" 301 264 "-" "Java/1.6.0_16"
/muesli-blog/sponsoring HTTP/1.1" 301 - "-" "Java/1.6.0_16"
/muesli-blog/sponsoring/ HTTP/1.1" 200 43556 "-" "Java/1.6.0_16"
/firmenkunden/4/mueslipromotion.html HTTP/1.1" 200 15834 "-" "Java/1.6.0_16"
/muesli-blog/wp-includes/wlwmanifest.xml HTTP/1.1" 200 1053 "-" "Java/1.6.0_16"
/images/bookmarking/facebook.png HTTP/1.1" 200 2938 "-" "Java/1.6.0_16"
/muesli/presse/%22 HTTP/1.1" 404 19799 "-" "Java/1.6.0_16"
/presse/10/bildmaterial_zum_download.html HTTP/1.1" 301 274 "-" "Java/1.6.0_16"
/presse/10/bildmaterial_zum_download.html HTTP/1.1" 200 23596 "-" "Java/1.6.0_16"
Dies ist ein Ausschnitt der zur Beurteilung des vorgestellten Verfahrens verwendeten Kontrolldaten. Es handelt sich um die protokollierten Zugriffe eines einzelnen, menschlichen
Benutzers. Die Protokollzeilen wurden zur besseren Lesbarkeit auf die wesentlichen Informationen gekürzt.
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
-
[17:48:37]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:38]
[17:48:39]
[17:50:02]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
[17:50:03]
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
/firmenkunden/5/weihnachtsmuesli.html HTTP/1.1" 200 4403 "-" "Mozilla/4.0 ..."
/sf/prototype/js/scriptaculous.js HTTP/1.1" 200 2404 "-" "Mozilla/4.0 ..."
/js/main.js HTTP/1.1" 200 7746 "-" "Mozilla/4.0 ..."
/sf/prototype/js/builder.js HTTP/1.1" 200 4638 "-" "Mozilla/4.0 ..."
/css/news_comment.css HTTP/1.1" 200 1460 "-" "Mozilla/4.0 ..."
/css/b2b.css HTTP/1.1" 200 322 "-" "Mozilla/4.0 ..."
/sf/prototype/js/effects.js HTTP/1.1" 200 37872 "-" "Mozilla/4.0 ..."
/css/tcc.css HTTP/1.1" 200 35118 "-" "Mozilla/4.0 ..."
/sf/prototype/js/prototype.js HTTP/1.1" 200 71261 "-" "Mozilla/4.0 ..."
/sf/prototype/js/slider.js HTTP/1.1" 200 10403 "-" "Mozilla/4.0 ..."
/sf/prototype/js/controls.js HTTP/1.1" 200 28980 "-" "Mozilla/4.0 ..."
/sf/prototype/js/dragdrop.js HTTP/1.1" 200 30645 "-" "Mozilla/4.0 ..."
/images/Basics.jpg HTTP/1.1" 200 1326 "-" "Mozilla/4.0 ..."
/images/Cereals.jpg HTTP/1.1" 200 1417 "-" "Mozilla/4.0 ..."
/images/BasicsRed.jpg HTTP/1.1" 200 1547 "-" "Mozilla/4.0 ..."
/images/CerealsRed.jpg HTTP/1.1" 200 1685 "-" "Mozilla/4.0 ..."
/images/Choco.jpg HTTP/1.1" 200 1336 "-" "Mozilla/4.0 ..."
/images/ChocoRed.jpg HTTP/1.1" 200 1564 "-" "Mozilla/4.0 ..."
/images/Fruits.jpg HTTP/1.1" 200 1321 "-" "Mozilla/4.0 ..."
/images/FruitsRed.jpg HTTP/1.1" 200 1529 "-" "Mozilla/4.0 ..."
/images/Nuts.jpg HTTP/1.1" 200 1550 "-" "Mozilla/4.0 ..."
/images/NutsRed.jpg HTTP/1.1" 200 1904 "-" "Mozilla/4.0 ..."
/images/Specials.jpg HTTP/1.1" 200 1512 "-" "Mozilla/4.0 ..."
/images/SpecialsRed.jpg HTTP/1.1" 200 1824 "-" "Mozilla/4.0 ..."
/images/ajax-loader.gif HTTP/1.1" 200 3720 "-" "Mozilla/4.0 ..."
/images/logo.gif HTTP/1.1" 200 5795 "-" "Mozilla/4.0 ..."
/images/Creator.gif HTTP/1.1" 200 1178 "-" "Mozilla/4.0 ..."
/images/Show.gif HTTP/1.1" 200 1195 "-" "Mozilla/4.0 ..."
/images/Lounge.gif HTTP/1.1" 200 1340 "-" "Mozilla/4.0 ..."
/images/Search.gif HTTP/1.1" 200 833 "-" "Mozilla/4.0 ..."
/images/Search-Bg.gif HTTP/1.1" 200 174 "-" "Mozilla/4.0 ..."
/images/top.gif HTTP/1.1" 200 364 "-" "Mozilla/4.0 ..."
/images/Pedia-KA.gif HTTP/1.1" 200 1434 "-" "Mozilla/4.0 ..."
/favicon.ico HTTP/1.1" 200 617 "-" "Mozilla/4.0 ..."
/muesli-blog/tag/wintermuesli/ HTTP/1.1" 200 11087 "-" "Mozilla/4.0 ..."
/muesli-blog/wp-includes/js/tw-sack.js?ver=1.6.1 HTTP/1.1" 200 4969 "-" "Mozilla/4.0 ..."
/muesli-blog/wp-content/plugins/wp-polls/polls-js-packed.js?ver=2.40 HTTP/1.1" 200 2690 "-" "Mozilla/4.0 ..."
/muesli-blog/wp-content/plugins/wp-polls/polls-css.css?ver=2.40 HTTP/1.1" 200 2835 "-" "Mozilla/4.0 ..."
/muesli-blog/wp-includes/images/smilies/icon_smile.gif HTTP/1.1" 200 174 "-" "Mozilla/4.0 ..."
/uploads/news/default/d4b4be8ef9ca99b583b7a4a1d2fc0d5f.jpg HTTP/1.1" 200 6846 "-" "Mozilla/4.0 ..."
/uploads/news/default/48d9053581601ed61f90fee1b9c4e128.jpg HTTP/1.1" 200 9291 "-" "Mozilla/4.0 ..."
/muesli-blog/wp-content/uploads/2008/11/wellfit_logo_kl.jpg HTTP/1.1" 200 3331 "-" "Mozilla/4.0 ..."
/muesli-blog/wp-content/themes/cerealclub/style.css HTTP/1.1" 200 36327 "-" "Mozilla/4.0 ..."
/uploads/news/default/7424dc363bfb03ef049b2c4e2cc5afbd.jpg HTTP/1.1" 200 19759 "-" "Mozilla/4.0 ..."
/bilder/extern/facebook_blog.jpg HTTP/1.1" 200 4297 "-" "Mozilla/4.0 ..."
/bilder/extern/Flickr_blog.jpg HTTP/1.1" 200 2120 "-" "Mozilla/4.0 ..."
/bilder/extern/soupio_blog.gif HTTP/1.1" 200 845 "-" "Mozilla/4.0 ..."
/bilder/extern/twitter_blog.jpg HTTP/1.1" 200 8601 "-" "Mozilla/4.0 ..."
/muesli-blog/wp-content/plugins/wp-polls/images/loading.gif HTTP/1.1" 200 771 "-" "Mozilla/4.0 ..."
/images/bookmarking/misterwong.gif HTTP/1.1" 200 642 "-" "Mozilla/4.0 ..."
/images/bookmarking/yigg.gif HTTP/1.1" 200 1026 "-" "Mozilla/4.0 ..."
71
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
<IP>
72
-
[17:50:03]
[17:50:03]
[17:50:04]
[17:50:04]
[17:50:04]
[17:50:04]
[17:50:04]
[17:50:04]
[17:50:04]
[17:50:04]
[17:50:04]
[17:50:04]
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
"GET
/images/bookmarking/google.gif HTTP/1.1" 200 314 "-" "Mozilla/4.0 ..."
/images/bookmarking/myspace.gif HTTP/1.1" 200 910 "-" "Mozilla/4.0 ..."
/images/bookmarking/facebook.png HTTP/1.1" 200 2938 "-" "Mozilla/4.0 ..."
/images/bookmarking/reddit.gif HTTP/1.1" 200 289 "-" "Mozilla/4.0 ..."
/images/bookmarking/webnews.gif HTTP/1.1" 200 173 "-" "Mozilla/4.0 ..."
/images/bookmarking/icio.gif HTTP/1.1" 200 1081 "-" "Mozilla/4.0 ..."
/images/bookmarking/favoriten.gif HTTP/1.1" 200 353 "-" "Mozilla/4.0 ..."
/images/bookmarking/linkarena.ico HTTP/1.1" 200 894 "-" "Mozilla/4.0 ..."
/images/bookmarking/infopirat.gif HTTP/1.1" 200 618 "-" "Mozilla/4.0 ..."
/images/bookmarking/delicious.gif HTTP/1.1" 200 113 "-" "Mozilla/4.0 ..."
/images/bookmarking/stumbleupon.gif HTTP/1.1" 200 250 "-" "Mozilla/4.0 ..."
/favicon.ico HTTP/1.1" 200 617 "-" "Mozilla/4.0 ..."
[Amb05]
Ambler, Scott W.: The Elements of UML 2.0 Style. Cambridge University
Press, Cambridge, UK, 2005.
[AO04]
America Online, Inc.: Webmaster.Info : AOL Proxy Info, 2004. URL http://
webmaster.info.aol.com/proxyinfo.html, Abgerufen am 21. Februar 2010.
[Apa]
Apache Software Foundation: Log Files - Apache HTTP Server. URL
http://httpd.apache.org/docs/2.0/logs.html, Abgerufen am 15. Januar
2010.
[Dam64]
Damerau, Fred J.: A technique for computer detection and correction of spelling errors. Communications of the ACM, 7(3):171–176, März 1964.
[dud06]
Duden Deutsches Universal Worterbuch. Bibliographisches Institut & FA Brockhaus AG, October 2006.
[FGM+ 99] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach
und T. Berners-Lee: Hypertext Transfer Protocol – HTTP/1.1. RFC 2616,
Juni 1999. Updated by RFC 2817.
[GHJV04] Gamma, E., R. Helm, R. Johnson und J. Vlissides: Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software. Addison Wesley Verlag,
Bonn, Juli 2004.
[Hon97]
Honkela, Timo: Self-Organizing Maps In Natural Language Processing. Doktorarbeit, Helsinki University of Technology, Neural Networks Research Centre,
1997.
[Kar08]
Karafiat, Helga: Support Vector Machine zur Gender Recognition mit Visualisierung des Lernprozesses. Diplomarbeit, Fachhochschule Wedel, Feldstrasse
143, 22880 Wedel, Deutschland, Juni 2008.
[Kas98]
Kaski, Samule: Dimensionality Reduction by Random Mapping: Fast Similarity Computation for Clustering. Neural Networks Proceedings, IEEE World
Congress on Computational Intelligence, 1(1):413–418, Mai 1998.
[KKL+ 01] Kohonen, Teuvo, Samuel Kaski, Krista Lagus, Jarkko Salojarvi, Vesa Paatero und Antti Saarela: Self Organization of a Massive Document
Collection. IEEE Transactions on Neural Networks, 11:574–585, 2001.
[Koh01]
Kohonen, Teuvo: Self-Organizing Maps. Springer, Berlin / Heidelberg, 3. Auflage, 2001.
[Kra87]
Krause, Eugene F.: Taxicab Geometry. Dover, 1987.
[LAR99]
Lawrence, R. D., G. S. Almasi und H. E. Rushmeier: A Scalable Parallel Algorithm for Self-Organizing Maps with Applicationsto Sparse Data Mining
Problems. Data Mining and Knowledge Discovery, 3(2):171–195, 1999.
73
[LKK04]
Lagus, Krista, Samuel Kaski und Teuvo Kohonen: Mining massive document collections by the WEBSOM method. Information Sciences, 163/1-3:135–
156, 2004.
[McD03]
McDuffie, Tina Spain: JavaScript Concepts and Techniques: Programming
Interactive Web Sites. Franklin, Beedle and Associates, 2003.
[MCSC02] Mu-Chun Su, Ta-Kang Liu und Hsiao-Te Chang: Improving the SelfOrganizing Feature Map Algorithm Using an Efficient Initialization Scheme.
Tamkang Journal of Science and Engineering, 5(1):35–48, Februar 2002.
[Mey07]
Meyer, Eric: Cascading Style Sheets: The Definitive Guide. O’Reilly, Sebastopol, 3. Auflage, 2007.
[Mon94]
Monnerjahn, Jürgen: Speeding-up Self-organizing Maps: The Quick Reaction.
Proceedings of the International Conference on Artificial Neural Networks, 1(12):326–329, Mai 1994.
[Pre10]
Preiss, Bruno R.: Brute-Force and Greedy Algorithms, 2010. URL http://
www.brpreiss.com/books/opus4/html/page441.html, Abgerufen am 16. Februar 2010.
[Sch02]
Schatzman, M.: Numerical Analysis. Clarendon Press, Oxford, 2002.
[Ste07]
Stein, Clifford: Algorithmen – Eine Einführung. Oldenbourg Wissenschaftsverlag, München, 2. Auflage, 2007.
[UD07]
Ullman, Chris und Lucinda Dykes: Beginning Ajax. wrox, März 2007.
[Wik10a]
Wikipedia: Bot — Wikipedia, Die freie Enzyklopädie, 2010. URL http://de.
wikipedia.org/w/index.php?title=Bot&oldid=69200658, Abgerufen am 05.
Februar 2010.
[Wik10b]
Wikipedia: Internet bot — Wikipedia, The Free Encyclopedia, 2010.
URL
http://en.wikipedia.org/w/index.php?title=Internet_bot&
oldid=340962112, Abgerufen am 05. Februar 2010.
74
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne
Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe; die aus fremden Quellen
direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit
wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungskommission vorgelegt
und auch nicht veröffentlicht.
Datum, Ort
John Freytag
75

verlinkt - wortzwei

Transcription

Similar documents

Grundzüge der Informatik II - Technische Universität Darmstadt

Bericht

TechnicalReport - SFB 876

Evaluation von kartografischen Werkzeugen in ArcGIS zur

Klassifizierung mit Self-Organizing Maps

3M Werkstatt

Geschäfts- und Nachhaltigkeitsbericht 2012

ecomplexx - opentext

Plagiarism Detection Software - VSR