DANDRO PHOTOGALERIE

Transcription

DANDRO PHOTOGALERIE

WIMS – WLAN Intrusion Detection and Monitoring System
- WLAN INTRUSION DETECTION AND
MONITORING SYSTEM -
KONZEPT
Autoren:
Datum:
Status:
Version:
Institution:
Verteiler:
09.07.2004
Daniel Walther, Sandro Dähler
9. Juli 2004
Fertig gestellt
1.0
Hochschule für Technik und Informatik Biel, Telscom AG
Franz Meyer, Gerhard Schwab, Sathya Rao (Telscom AG), Daniel Walther, Sandro Dähler
1/27
INHALTSVERZEICHNIS
Inhaltsverzeichnis.........................................................................................................................................2
1. Einleitung ..................................................................................................................................................3
2. Systemanforderungen ..............................................................................................................................4
3. Systemarchitektur.....................................................................................................................................4
3.1 Detaillierter Aufbau........................................................................................................................4
3.2 Subsysteme ......................................................................................................................................4
4. Prototyp.....................................................................................................................................................9
4.1 Access Point Service ....................................................................................................................11
4.2 Wireless IDS..................................................................................................................................13
4.3 Betriebssystem ..............................................................................................................................15
4.4 Serial Port ......................................................................................................................................15
4.5 Netzwerk Interface 1 ...................................................................................................................15
4.6 Netzwerk Interface 2 ...................................................................................................................15
4.7 Soekris Net4521............................................................................................................................15
4.8 Management Service ....................................................................................................................16
4.9 Integration in NetWACS.............................................................................................................18
5. Anhang ....................................................................................................................................................20
5.1 Skript Root Zertifikat...................................................................................................................20
5.2 Skript Server Zertifikat ................................................................................................................21
5.3 Skript Client Zertifikat.................................................................................................................22
5.4 Settings xpextensions...................................................................................................................22
5.5 Firewall...........................................................................................................................................23
5.6 UML Diagramm Integration NetWACS Datasource .............................................................24
5.7 UML Diagramm Integration NetWACS OC2TabIn..............................................................25
6. Abbildungsverzeichnis ..........................................................................................................................26
7. Referenzen ..............................................................................................................................................27
09.07.2004
2/27
1. EINLEITUNG
Dieser Bericht zu der Phase Konzept dient zur Verfeinerung des gewählten Lösungsvorschlages. Dies ermöglicht eine genaue Beurteilung des Lösungsvorschlags.
In den Dokumenten Fertigprodukte und Marktanalyse gehen wir tiefer auf die verwendeten
Produkte und die auf dem Markt erhältlichen Produkte ein.
09.07.2004
3/27
2. SYSTEMANFORDERUNGEN
Die im Dokument „Proposal“ definierten Anforderungen werden mit dieser Systemarchitektur
abgedeckt.
3. SYSTEMARCHITEKTUR
3.1 Detaillierter Aufbau
RADIUS Server
NetWACS
Monitoring, Controling, Alerting
IDS,
MGMT
Service,
Access
Point
WLAN
IDS,
MGMT
Service,
Access
Point
IDS,
MGMT
Service,
Access
Point
IDS,
MGMT
Service,
Access
Point
Abb. 1: Detaillierter Aufbau
3.2 Subsysteme
Die diversen Möglichkeiten unseres Systems können in folgende Subsysteme unterteilt und
beschrieben werden.

Access Point
Der Access Point Service übernimmt die Anbindung der Wireless Clients an das Wireless
Netzwerk. Durch eine Authentifizierung am Wireless Netzwerk kann die Sicherheit dieses
Netzwerkes erhöht werden und ungebetene Gäste können nicht auf das Wireless Netzwerk
zugreifen.
Weiter bietet das System auch die Möglichkeit den Einsatz in einer IPv4 und IPv6
Umgebung. Es kann weiter noch in Erwägung gezogen werden, ob der Access Point auch
ein IPv6-to-IPv4 Tunneling durchführen soll. Dies würde ermöglichen, dass alle Wireless
09.07.2004
4/27
Clients IPv6 Adressen bekommen, der Access Point aber noch an einem IPv4 Netzwerk
angeschlossen ist. Sollte dieses Tunneling nicht aktiviert sein, haben die Wireless Clients
keine Möglichkeit auf das IPv4 Netzwerk zuzugreifen.
o Authentifizierung und Authorisierung
Um eine gewisse Sicherheit und Schutz vor ungebetenen Gästen zu bieten ist es ein
Muss die Wireless Clients authentifizieren zu können. In unserem System geschieht
dies mit der Hilfe vom IEEE 802.1x Standard. Daraus verwenden wir die Methode
EAP/TLS. Dies bedeutet, die Wireless Clients werden anhand eines zuvor
verteilten Zertifikates authentifiziert. Dieses Zertifikat wird dabei vom Radius
Server überprüft. Wird dieses Zertifikat als Korrekt eingestuft, wird dem Wireless
Client den Zugang zum Wireless Netzwerk gewährt (Authorisierung).
Abb. 2: Authorisierungsvorgang EAP/TLS
09.07.2004
5/27
Da im Juni 2004 der neue IEEE 802.11i Standart abgesegnet und veröffentlicht
wird, werden wir zukünftig die Authentifizierung mit diesem Standart durchführen.
Bei diesen Standart basiert die Verschlüsselung auf dem AES Algorithmus und ist
daher sicherer gestaltet werden.
Abb. 3: 802.11i
Bei dem genauen Studium vom IEEE Standart 802.11i fällt einem sofort auf,
dass die Änderung der Authentifizierung nur gering ist. Der wohl grösste
Unterschied die Entfernung von der schwachen RC4 Implementation. Wie schon
erwähnt wurde dieser mit dem AES Algorithmus ausgetauscht.

Intrusion Detection System
Da die Sicherheit bei einem Wireless Netzwerk das grösste Problem ist, enthält unser
System auch ein Intrusion Detection System. Dieses System ermöglicht es dem
Administrator das Wireless Netzwerk genau zu überwachen. Ein solches System muss
mindestens folgende Probleme erkennen:
-
Falsche Access Point (Rogue Access Points)
-
Einbruchversuche (Attacken, DoS)
-
Entdecken von Wardrivern
Umso mehr ein solches System entdecken kann umso sicherer kann dieses eingestuft
werden. Da die Angriffe von ungebetenen Gästen sehr rasch entdeckt werden und darauf
reagiert werden kann.
09.07.2004
6/27

Management Service und Konsole
Ein Management Dienst ist in heutigen grösseren Wireless Netzwerken nicht mehr
wegzudenken. Dieser Dienst ermöglicht es uns zu jedem Zeitpunkt den Status des Wireless
Netzwerkes abzufragen. Darunter fallen Informationen wie „angeschlossene“ Clients,
Überwachung und Administration der Access Points (Konsole). Darüber hinaus bestünde
auch die Möglichkeit weitere Informationen von Clients zu erhalten (z.B. installierte
Patches, Firewallsoftware, Anti-Viren Software, usw.).
Die dazugehörende Managementkonsole soll ebenso einfach wie möglich als auch
unabhängig sein. Dies heisst, dass diese Konsole als Standalone Applikation betrieben
werden kann, aber auch die Möglichkeit bietet, diese ins Netwacs-System einzubinden. So
ist es Möglich beide System auch getrennt laufen zu lassen.

Logging
Da bei all diesen Aufgaben sehr viele Daten anfallen werden, ist es unmöglich diese Daten
alle lokal auf dem Access Point zu speichern. Daher wird für alle Log-Files und Alerts ein
externes System benötigt. Diese Daten werden dazu in einer Datenbank gespeichert und
können von dort aus weiterverwendet werden (z.B. Netwacs). Ausserdem ermöglicht ein
zentrales Logging das korrelieren der gesammelten Daten. Daher kann jederzeit eine
komplette Analyse und Statusberichte vom gesamten Wireless Netzwerk erstellt werden.

Optionales Security feature: Quarantäne
Um die Sicherheit eines Wireless Netzwerkes nochmals zu erhöhen, wäre es möglich einen
Nessus oder NMAP Scanner auf unserem Access Point zu installieren. Ein solcher Scanner
würde jeden Client vor der Verbindung mit dem Wireless Netzwerk auf gewissen
Schwachstellen bzw. offene Ports prüfen. Besteht der Client die Überprüfung dieser
„Security Policy“ wird ihm Zugang zum Wireless Netzwerk gestattet, andernfalls nicht.
Folgendes Beispiel soll dieses Feature kurz beschreiben:
Abb. 4: Integration einer Quarantäne
1. Der Wireless Client nimmt die Verbindung zum Access Point auf und authentifiziert
sich.
2. Nach erfolgreicher Authentifizierung erhält der Wireless Client vom Access Point eine
IP Adresse. Diese IP Adresse wird dynamisch mittels IPTables auf dem Access Point
gesperrt. So wird verhindert, dass der Wireless Client auf das Netzwerk zugreifen kann.
3. Der Access Point überprüft mit Nessus oder NMAP den Wireless Client und stellt fest
ob der Wireless Client der gegebenen Security Policy genügt. Ist diese Überprüfung
09.07.2004
7/27
erfolgreich, wird die IP Adresse wieder dynamisch aus den IPTables gelöscht und damit
wird der Weg frei um auf das Netzwerk zugreifen zu können.
4. Der Wireless Client hat die Security Policy Überprüfung erfolgreich überstanden und hat
nun vollen Zugang zum Netzwerk.
09.07.2004
8/27
4. PROTOTYP
In diesem Kapitel wird die genaue Implementation und Funktionsweise des Access Points
beschrieben. Im folgenden Bild wird der Access Point dargestellt und nachfolgend werden alle
Funktionen des Access Point und dessen Software Implementation beschrieben.
3
7
1
2
6 5
4
Abb. 5: WimS Access Point
4.1. Access Point Service
4.2. Wireless IDS
4.3. Betriebssystem
4.4. Serial Port
4.5. Netzwerk Interface 1
4.6. Netzwerk Interface 2
4.7. Soekris Net4521
09.07.2004
9/27
Weiter wird hier auch die Software Implementation von WimS beschrieben. Hier wird auch die
Implementation von WimS in das bestehende NetWACS Projekt beschrieben.
WimS Server
LAN
NetWACS Database
WLAN
NetWACS Server
OC2
Abb. 6: WimS Integration
4.8 Management Service
4.9 Integration in NetWACS
09.07.2004
10/27
4.1 Access Point Service
Diese Wireless Karte basiert auf dem PRISM-Chipsatz. Dies ermöglicht uns die Open Source
Software HostAP zu gebrauchen. Diese Software erlaubt uns einen Access Point zu erstellen. Mit
der Hilfe des HostAP Daemon, haben wir ausserdem die Möglichkeit unser Wireless LAN vor
fremden zugriffen zu schützen. Wie schon erwähnt basiert unsere Authentifizierung auf dem
EAP/TLS Prinzip. Durch dieses Verfahren wird ein dynamischer WEP Key generiert welcher
alle 300 Sekunden erneuert wird.
Hier ein Beispiel der Konfiguration vom Hostap Daemon (Auszug):
...
##### IEEE 802.1X (and IEEE 802.1aa/D4) related configuration #################
# Require IEEE 802.1X authorization
ieee8021x=1
# Use internal minimal EAP Authentication Server for testing IEEE 802.1X.
# This should only be used for testing since it authorizes all users that
# suppot IEEE 802.1X without any keys or certificates.
minimal_eap=0
# Optional displayable message sent with EAP Request-Identity
eap_message=hello
# WEP rekeying (disabled if key lengths are not set or are set to 0)
# Key lengths for default/broadcast and individual/unicast keys:
# 5 = 40-bit WEP (also known as 64-bit WEP with 40 secret bits)
# 13 = 104-bit WEP (also known as 128-bit WEP with 104 secret bits)
wep_key_len_broadcast=13
wep_key_len_unicast=13
# Rekeying period in seconds. 0 = do not rekey (i.e., set keys only once)
wep_rekey_period=300
# EAPOL-Key index workaround (set bit7) for WinXP Supplicant (needed only if
# only broadcast keys are used)
eapol_key_index_workaround=0
##### RADIUS configuration ####################################################
# for IEEE 802.1X with external Authentication Server, IEEE 802.11
# authentication with external ACL for MAC addresses, and accounting
# The own IP address of the access point (used as NAS-IP-Address)
own_ip_addr=147.87.70.60
# Optional NAS-Identifier string for RADIUS messages. When used, this should be
# a unique to the NAS within the scope of the RADIUS server. For example, a
# fully qualified domain name can be used here.
#nas_identifier=ap.example.com
# RADIUS authentication server
auth_server_addr=147.87.70.184
auth_server_port=1812
auth_server_shared_secret=secret
...
Dazu gebrauchen wir ausserdem noch einen RADIUS Server und eine Certification Authority
(CA). Beide Dienste sind auf einem externen Server. Dies ermöglicht uns eine zentrale
09.07.2004
11/27
Verwaltung Der RADIUS Server ist mit FreeRadius (Version 0.9.3) und die CA mit OpenSSL
(Version 0.9.7d) implementiert. Um die Zertifikate schnell und einfach zu erstellen, haben wir
drei verschiedene Skripts welche uns dies ermöglichen. Diese Skripts sind im Anhang angefügt.
Weiter ist bei der Erstellung der Zertifikate darauf zu achten, dass bei jedem Zertifikat der
Common Name (CN) einzigartig ist, ansonsten können die Zertifikate nicht Ordnungsgemäss
erstellt werden.
Sobald sich ein Client an unserem Wireless LAN anmelden will, wird das Client Zertifikat mit
dem Server Zertifikat überprüft. Weiter wird auf dem Client das Server Zertifikat des RADIUS
Servers überprüft. Stimmen beide dieser Zertifikate überein, wird dem Client der Zutritt zum
Wireless LAN gewährt. Die Authentifizierungsmethode EAP/TLS ist ziemlich sicher, da sich der
Client am Server wie auch umgekehrt authentifiziert.
Hier ein Beispiel der Konfiguration vom RADIUS Server um eine EAP/TLS
Authentifizierung machen zu können (Auszug):
modules {
...
#
For all EAP related authentications
eap {
#
Invoke the default supported EAP type when
#
EAP-Identity response is received.
#
The incoming EAP messages DO NOT specify which EAP
#
type they will be using, so it MUST be set here.
#
For now, only one default EAP type may be used at a time.
default_eap_type = tls
#
Default expiry time to clean the EAP list, It is
#
maintained to correlate the EAP-Response for each
#
EAP-request sent.
timer_expire
= 60
# Supported EAP-types
...
## EAP-TLS is highly experimental EAP-Type at the moment.
# Please give feedback on the mailing list.
tls {
private_key_password = whatever
private_key_file = /usr/local/openssl-certgen/lausanne.pem
#
If Private key & Certificate are located in
#
the same file, then private_key_file &
#
certificate_file must contain the same file name.
certificate_file = /usr/local/openssl-certgen/lausanne.pem
#
Trusted Root CA list
CA_file = /usr/local/openssl-certgen/root.pem
dh_file = /usr/local/openssl-certgen/DH
random_file = /usr/local/openssl-certgen/random
09.07.2004
#
This can never exceed the size of a RADIUS
#
packet (4096 bytes), and is preferably half
#
that, to accomodate other attributes in
#
RADIUS packet.
On most APs the MAX packet
12/27
#
length is configured between 1500 - 1600
#
In these cases, fragment size should be
#
1024 or less.
fragment_size = 1024
...
#
include_length is a flag which is
#
by default set to yes If set to
#
yes, Total Length of the message is
#
included in EVERY packet we send.
#
If set to no, Total Length of the
#
message is included ONLY in the
#
First packet of a fragment series.
include_length = yes
}
}
...
}
Um den Status der Access Points verfolgen zu können werden alle Syslog Daten auf einem
externen Syslog Server in einer Datenbank (PostgreSQL) gespeichert. So können Fehlverhalten
und Meldungen der Access Points untersucht werden. Diese Daten werden nicht mit dem
„normalen“ Syslog gespeichert. Dies aus dem Grund weil Syslog über UDP kommuniziert und so
die Daten leicht gefälscht und eingesehen werden können. Daher kommt hier der SyslogNG zum
Einsatz. Dieser Daemon erstellt die Verbindung via TCP.
4.2 Wireless IDS
Diese Wireless Karte wird im Monitor Mode betrieben. Dies ermöglicht uns allen vorhandenen
Traffic in der Luft zu erfassen. Daher haben wir die Möglichkeit diverse Unstimmigkeiten in
unserem Wireless Netzwerk zu entdecken (Wardrivers, Rouge Access Point, usw.) und können
dementsprechend handeln.
Dazu gebrauchen wir das Open Source Projekt Snort Wireless. Dieses Intrusion Detection
System ermöglicht uns eine genaue Analyse des Netzwerktraffics. Da Snort Wireless schon eine
Menge an Patterns anbietet und die Erstellung neuer Patterns sehr einfach ist, ist dies die ideale
Lösung für uns.
Konfigurationsfile Snort-Wireless (Auszug):
...
# Configure your wireless AP lists.
This allows snort to look for attacks
# against your wireless network, such as rogue access points or adhoc wireless
# networks. Also specify what channels your access points are setup on.
# Ex:
# var ACCESS_POINTS XX:XX:XX:XX:XX:XX
# var CHANNELS X OR
# var ACCESS_POINTS [XX:XX:XX:XX:XX:XX, YY:YY:YY:YY:YY:YY, ....]
# var CHANNELS [X, Y, ....]
var ACCESS_POINTS FF:FF:FF:FF:FF:FF
var CHANNELS 11
...
09.07.2004
13/27
# RogueAP
#--------------------------------------------# RogueAP detects rogue APs and AdHoc networks
# Arguments:
# scan_flag [0 | 1]
=> toggles scanning of multiple channels *NOT IMPLEMENTED*
# scan_timeout [num]
=> time in seconds between channel scans *NOT IMPLEMENTED*
# expire_timeout [num] => time in seconds before a BSSID is removed from the rogue list
preprocessor rogue_ap: $ACCESS_POINTS, $CHANNELS, scan_flag 1, scan_timeout 1800,
expire_timeout 3600
# AntiStumbler
#--------------------------------------------# AntiStumbler detects possible Netstumbler activity
# Arguments:
# probe_reqs [num]
=> number of probe requests that triggers an alert
# probe_period [num]
=> time period in seconds that NULL SSID probe requests are counted
# expire_timeout [num] => time in seconds before a STA is removed from the stumbler list
preprocessor antistumbler: probe_reqs 90, probe_period 30, expire_timeout 3600
...
include $RULE_PATH/wifi.rules
...
Rules Snort-Wireless (Auszug):
...
alert wifi any -> any (msg:"Association Request"; stype:STYPE_ASSOCREQ;)
alert wifi any -> any (msg:"Association Response"; stype:STYPE_ASSOCRESP;)
alert wifi any -> any (msg:"Reassociation Request"; stype:STYPE_REASSOC_REQ;)
alert wifi any -> any (msg:"Reassociation Response"; stype:STYPE_REASSOC_RESP;)
alert wifi any -> any (msg:"Probe Request"; stype:STYPE_PROBEREQ;)
alert wifi any -> any (msg:"Probe Response"; stype:STYPE_PROBERESP;)
alert wifi any -> any (msg:"Beacon"; stype:STYPE_BEACON;)
alert wifi any -> any (msg:"ATIM"; stype:STYPE_ATIM;)
alert wifi any -> any (msg:"Disassociation"; stype:STYPE_DISASSOC;)
alert wifi any -> any (msg:"Authentication"; stype:STYPE_AUTH;)
alert wifi any -> any (msg:"Deauthentication"; stype:STYPE_DEAUTH;)
...
Diese Regeln können ohne weiteres editiert und erweitert werden. Da diese Rules in einem
separaten File gespeichert sind, ist eine solche Änderung problemlos.
Um die anfallenden Alerts ohne Probleme speichern und verwalten zu können, werden die
Daten in einer externen Datenbank gespeichert. Diese Datenbank wird so zentral wie möglich
gehalten, so dass alle vorhandenen Access Points die Alerts dort speichern können. Dieser Server
wird wie schon erwähnt auch für die Syslog Daten der Access Points gebraucht. Durch die
Korrelation der Alerts in der Datenbank, kann ein konkretes Bild des Problems gemacht werden.
09.07.2004
14/27
4.3 Betriebssystem
Unser Access Point wird von einem Mini Linux (80 MegaByte) betrieben. Da unsere Hardware
eine PC ähnliche Struktur hat, ist es nicht nötig jeweils ein Cross-Compiling zu machen. Unser
Linux basiert auf der Debian Distribution und enthält den Kernel 2.4.26.
Wir haben uns für diese Kernel Version entschieden, weil die momentan erhältliche Software
auf dieser Kernel Version problemlos betrieben werden kann. Wir haben unser System auch mit
der Kernel Version 2.6.5 getestet. Dabei mussten wir jedoch feststellen, dass die Kompatibilität
und die Stabilität noch nicht so ausgereift ist, wie bei der Kernel Version 2.4.26.
Weiter wird unser Linux nur in einem Read-Only Modus betrieben. Dies bedeutet, dass das
gesamte Filesystem vor Schreibzugriffen geschützt ist. Dies wurde uns durch ein Tutorial von
http://www.ultimeth.net/linux/ ermöglicht. Da es für diverse Programme dennoch nötig ist,
diverse Daten während dem Betrieb in Log-Files zu schreiben, wird beim booten des Systems
dynamisch eine RAM-Disk mit der Grösse von 10 MegaByte erstellt. Da auf unserem System
diverse Applikationen wie zum Beispiel gcc nicht installiert ist, ist es nötig sämtliche Software auf
einem externen Computer statisch zu kompilieren. Bei der statischen kompilierung werden
jeweils alle verwendeten Bibliotheken auch mit kompiliert. Weiter kann auf unserem System mit
dem „apt-get“ Befehl diverse Software nachinstalliert werden.
Das gesamte Linux wird auf einer Compact Flash Speicherkarte gespeichert und wird von
unserem System als Harddisk erkannt. Den Zugriff auf unser System wird jeweils mittels SSH
getätigt.
4.4 Serial Port
Der Serial Port ermöglicht es uns, auf das BIOS des System zuzugreifen. Weiter kann dadurch
auch auf unser Linux System zugegriffen werden. Dies ist meistens der Fall wenn nicht alle
Module korrekt geladen wurden oder beim booten ein Fehler auftritt. Ist dies der Fall, könnten
wir bei einem solchen Fehler mit SSH nicht mehr auf unser System zugreifen.
4.5 Netzwerk Interface 1
Dieses Interface verbindet das Netzwerk mit dem Wireless Netzwerk. In diesem
Netzwerksegement ist weiter auch der RADIUS Server installiert welcher uns die
Authentifizierung erlaubt. Um den Traffic vom Wireless Netzwerk ins interne Netzwerk
weiterleiten zu können haben wir ein IPTables Skript geschrieben, welches das Forwarding und
auch gerade diverse Firewall Rules implementiert hat. Dieses Skript ist im Anhang zu finden. Es
wird jeweils beim booten des Systems ausgeführt.
Weiter unterstützt dieses Netzwerk Interface „Power over Ethernet“ (PoE). Dies bedeutet für
uns, dass wir den nötigen Strom direkt mit dem Netzwerkkabel einspeisen können und nicht
noch ein weiteres Netzteil benötigen.
4.6 Netzwerk Interface 2
Dieses Netzwerk Interface ist momentan noch ohne Funktion. Dies könnte aber als DMZ
dienen. Dies bedeutet, dass diverse Dienste welche kleineren Schutz als das interne Netzwerk
nötig haben, in dieser DMZ platziert werden könnten.
4.7 Soekris Net4521
Als Hardware Grundlage haben wir uns für den Mini Computer von der Firma Soekris
(http://www.soekris.com) entschieden. Dieses System bietet uns die nötige Infrastruktur und
verzichtet auf den überflüssigen Schnickschnack. Da dieses System ausserdem auf einem AMD
Prozessor aufbaut und nicht auf einem ARM, haben wir bei der Linux Wahl schon viel mehr
Möglichkeiten, da das Cross-Compiling wegfällt.
09.07.2004
15/27
Hier noch die genauen Spezifikationen:
•
•
•
•
•
•
•
•
•
100/133 Mhz AMD ElanSC520
64 Mbyte SDRAM, on board
1 Mbit BIOS/BOOT Flash
CompactFLASH Type I/II socket, 8 Mbyte FLASH to 1Gbyte IBM Microdrive
2 10/100 Mbit Ethernet ports, RJ-45
1 Serial port, DB9.
Mini-PCI type III socket.
2 PC-Card/Cardbus slots, for wireless adapters
Supports Power over Ethernet according to the 802.3af standard
4.8 Management Service
Der Management Service ermöglicht ein zentrales Management sämtlicher Access Point im
Netzwerk.
Bei einer solchen zentralen Managementstation ist es nötig folgende Einstellungen der Access
Points ändern zu können:
Einstellung
Allgemein Individuell
Channel
X
SSID
X
MAC Filter
X
Gruppen
X
IEEE 802.1x / 802.11i enable
X
WEP Key length
X
Rekeying period (IEEE 802.1x)
X
1. RADIUS Server (Auth)
X
(X)
1. RADIUS Server (Acc)
X
(X)
2. RADIUS Server (Auth)
X
(X)
2. RADIUS Server (Acc)
X
(X)
IP Adresse
X
X
Subnetzmaske
X
(X)
Gateway
(X)
X
DNS Server
X
(X)
DHCP Server Einstellung
(X)
(X)
(Access Point Dienst aktivieren)
(X)
Diese Einstellungen können mit einem GUI (Java basierend) editiert und übermittelt werden.
Dieses GUI wird in verschiedene Tab’s unterteilt um eine klare Trennung der verschiedenen
Einstellungen zu machen. Weiter wird im ersten Tab dieses GUI eine Übersicht aller registrierten
Access Points mit deren Status (aktiv, inaktiv, usw.) zu sehen sein. Weiter existiert neben allen
Tab’s welche für die Einstellungen da sind, auch ein Tab’s welche die Daten des Intrusion
09.07.2004
16/27
Detection System und die Daten von den Syslogmeldungen darstellt. So hat man ein komplettes
zentrales Verwaltungsinstrument des gesamten Wireless Netzwerkes.
Weiter bietet die Managementkonsole die Möglichkeit, verschiedene Access Points in Gruppen
zusammenzufassen. Dies ermöglicht die getrennte Konfiguration der verschiedenen Gruppen. So
kann zum Beispiel eine Gruppe von Access Points für das interne Wireless Netzwerk konfiguriert
werden und eine weitere Gruppe kann als HotSpots konfiguriert werden.
Um eine sichere Verbindung zu den Access Points zu haben, wird ein SSL Tunnel über eine
TCP - Verbindung aufgebaut. Der Management Service der Access Points erstellt bei sich ein
Server Socket welches auf dem TCP Port 9467 zu erreichen ist. Bei einer Änderung der
Einstellungen werden die Daten mit einem Client Socket auf der zentralen Managementstation zu
den Access Points gesendet. Es werden bei einer Änderung immer alle Einstellungen zum Access
Point übertragen. So kann verhindert werden, dass diverse Änderungen verloren gehen. Dies
heisst für den Management Service auf dem Access Point, dass dieser jeweils die wirklichen
Änderungen an den Config Files vornehmen muss. Die betroffenen Config Files werden jeweils
noch den gewünschten Einstellungen abgesucht und dort eingetragen. Nach der Änderung der
Einstellungen, wird der Status an die zentrale Managementstation gesendet. Erst nach dem Erhalt
dieser Meldung wird das Socket wieder geschlossen. Um keine Probleme mit den Verbindungen
zu erhalten, werden die Änderungen nicht allen Access Points zusammen übertragen, sondern
nacheinander.
Nachfolgend ein kleines Beispiel wie die Managementkonsole aussehen könnte. Dies ist
allerdings nur eine Studie die unsere Ideen veranschaulichen soll.
WimS Management
WimS Overview
AP Settings
Security Settings
Groups
Management
WimS Overview
Name
WimS_AP_01
IP Address
192.168.111.10
Status
Online
WimS_AP_02
192.168.111.11
WimS_AP_03
Change Status
On
Off
Online
On
Off
192.168.111.12
Online
On
Off
WimS_AP_04
192.168.111.13
Online
On
Off
WimS_AP_05
192.168.111.14
Offline
On
Off
Confirm
Cancel
Abb. 7: GUI Managementkonsole
09.07.2004
17/27
4.9 Integration in NetWACS
Das vorher beschriebene GUI wird so transparent wie möglich implementiert. Dies ermöglicht
eine problemlose Einbindung in das bestehende Projekt NetWACS.
Um alle Daten auch mit dem NetWACS System zu verwalten wird eine oder mehrere
zusätzlich Datasources im NetWACS Server nötig. Diese Datasources enthalten die
Verbindungsdaten zu den entsprechenden Datenquellen (Wireless IDS, Management). Sobald
eine solche Verbindung erstellt worden ist, kann NetWACS die Daten vom WimS System
erhalten. Diese werden durch die verschiedenen Rule Engines verarbeitet und generieren je nach
Fall einen Alert im NetWACS System.
Alle erhaltenen Daten in der WimS Datasource werden in ein NetWACS kompatibles Format
gebracht. Diese Form wird in NetWACS „Event Mapping Table“ genannt. Um alle Events bzw.
Alerts richtig verwalten zu können, werden mindestens zwei Datasources gebraucht. Eine
Datasource ist für die Syslog Daten der WimS Access Points zuständig und die zweite
Datasource ist für die Wireless-Snort Daten zuständig.
Event Mapping Table WimS-Syslog-Datasource:
ID
Name
0
Time
1
Date
2
Host
3
Program
4
Msg
5
Facility
6
Priority
Event Mapping Table WimS-Snort-Datasource:
Die Folgende Tabelle zeigt, wie die Daten von Snort Wireless in der Datenbank gespeichert
werden. Da die Analyse von einem IEEE 802.11 im Layer 2 vorgenommen wird, widerspricht es
eigentlich dem Grundsatz von Snort da dieses IDS auf dem Layer 3 aufbaut. Daher ist es beim
momentanen Entwicklungsstand nicht möglich die Daten „korrekt“ in die Datenbank zu
speichern.
Sig_id
1
2
3
4
5
6
7
8
sig_name
Rogue AP detected (BSSID 00:A0:C5:B6:FC:18)
Management Frame
Beacon
Probe Response
Probe Request
Detected Netstumbler traffic from 00:02:8A:4A:D9:F2
Detected Netstumbler traffic from 00:02:2D:61:1B:0E
Data Frame
sig_class_id
sig_priority
2
sig_rev
1
sig_sid
1
2
2
1
1
1
1
Um diese Daten korrekt in eine Datenbank schreiben zu können ist es nötig, dass wir die
Daten, welche wir von Wireless Snort erhalten, neu zu strukturieren. Dazu werden wir ein
eigenes Datenbank Plug-In für Wireless Snort entwickeln um die gewünschte Datenstruktur zu
haben.
09.07.2004
18/27
ID
Name
1
Time
2
Date
3
Sensor
4
Source (MAC Adress)
5
Additional information
6
Signature
7
Priority
Um das Management GUI komplett in das OC2 von NetWACS einbinden zu können, muss
das gesamte GUI von der NetWACS Klasse „OC2TabIn“ abgeleitet werden. Da beim GUI für
die verschiedenen Möglichkeiten auch einzelne Tab’s erstellt wurden, besteht in NetWACS die
Möglichkeit diese mit Benutzerrechten zu verknüpfen.
Siehe Anhang für die UML Diagramme der Integration in NetWACS.
Abb. 8: Integration NetWACS
09.07.2004
19/27
5. ANHANG
5.1 Skript Root Zertifikat
Dieses Skript ermöglicht uns die schnelle und einfache Erstellung eines Root Zertifikates.
#!/bin/sh
SSL=/usr/local/openssl-certgen
export PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH}
export LD_LIBRARY_PATH=${SSL}/lib
# needed if you need to start from scratch otherwise the CA.pl -newca command doesn't copy the
# new
# private key into the CA directories
rm -rf demoCA
echo
echo
echo
echo
echo
"*********************************************************************************"
"Creating self-signed private key and certificate"
"When prompted override the default value for the Common Name field"
"*********************************************************************************"
# Generate a new self-signed certificate.
# After invocation, newreq.pem will contain a private key and certificate
# newreq.pem will be used in the next step
openssl req -new -x509 -keyout newreq.pem -out newreq.pem -passin pass:whatever -passout
pass:whatever -days 365
echo
echo
echo
echo
echo
echo
echo
echo
echo
echo
#
#
#
#
"*********************************************************************************"
"Creating a new CA hierarchy (used later by the "ca" command) with the certificate"
"and private key created in the last step"
"*********************************************************************************"
"newreq.pem" | /etc/ssl/misc/CA.pl -newca >/dev/null
"*********************************************************************************"
"Creating ROOT CA"
"*********************************************************************************"
Create a PKCS#12 file, using the previously created CA certificate/key"newreq
The certificate in demoCA/cacert.pem is the same as in newreq.pem. Instead of
using "-in demoCA/cacert.pem" we could have used "-in newreq.pem" and then omitted
the "-inkey newreq.pem" because newreq.pem contains both the private key and certificate
openssl pkcs12 -export -in newreq.pem -inkey newreq.pem -out root.p12 -cacerts -passin
pass:whatever -passout pass:whatever
# parse the PKCS#12 file just created and produce a PEM format certificate and key in root.pem
openssl pkcs12 -in root.p12 -out root.pem -passin pass:whatever -passout pass:whatever
# Convert root certificate from PEM format to DER format
openssl x509 -inform PEM -outform DER -in root.pem -out root.der
#Clean Up
rm -rf newreq.pem
09.07.2004
20/27
5.2 Skript Server Zertifikat
Dieses Skript erlaubt uns die Erstellung eines Serverzertifikats.
#!/bin/sh
echo
echo
echo
echo
echo
"*********************************************************************************"
"Creating server private key and certificate"
"When prompted enter the server name in the Common Name field."
"*********************************************************************************"
# Request a new PKCS#10 certificate.
# First, newreq.pem will be overwritten with the new certificate request
openssl req -new -keyout newreq.pem -out newreq.pem -passin pass:whatever -passout
# Sign the certificate request. The policy is defined in the openssl.cnf file.
# The request generated in the previous step is specified with the -infiles option and
# the output is in newcert.pem
# The -extensions option is necessary to add the OID for the extended key for server
#authentication
openssl ca -policy policy_anything -out newcert.pem -passin pass:whatever -key whatever extensions xpserver_ext -extfile xpextensions -infiles newreq.pem
#openssl ca -policy policy_anything -out newcert.pem -passin pass:whatever -key whatever infiles newreq.pem
# Create a PKCS#12 file from the new certificate and its private key found in newreq.pem
# and place in file specified on the command line
openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out $1.p12 -clcerts -passin
# parse the PKCS#12 file just created and produce a PEM format certificate and key in
#certsrv.pem
openssl pkcs12 -in $1.p12 -out $1.pem -passin pass:whatever -passout pass:whatever
# Convert certificate from PEM format to DER format
openssl x509 -inform PEM -outform DER -in $1.pem -out $1.der
# Clean Up
rm -rf newert.pem newreq.pem
09.07.2004
21/27
5.3 Skript Client Zertifikat
Dieses Skript erlaubt uns die Erstellung eines Client Zertifikats.
#!/bin/sh
echo
echo
echo
echo
echo
echo
"*********************************************************************************"
"Creating client private key and certificate"
"When prompted enter the client name in the Common Name field. This is the same"
" used as the Username in FreeRADIUS"
"*********************************************************************************"
# Request a new PKCS#10 certificate.
# First, newreq.pem will be overwritten with the new certificate request
openssl req -new -keyout newreq.pem -out newreq.pem -passin pass:whatever -passout
# Sign the certificate request. The policy is defined in the openssl.cnf file.
# The request generated in the previous step is specified with the -infiles option and
# the output is in newcert.pem
# The -extensions option is necessary to add the OID for the extended key for client
#authentication
openssl ca -policy policy_anything -out newcert.pem -passin pass:whatever -key whatever extensions xpclient_ext -extfile xpextensions -infiles newreq.pem
#openssl ca -policy policy_anything -out newcert.pem -passin pass:whatever -key whatever #infiles newreq.pem
# Create a PKCS#12 file from the new certificate and its private key found in newreq.pem
# and place in file specified on the command line
openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out $1.p12 -clcerts -passin
# parse the PKCS#12 file just created and produce a PEM format certificate and key in
#certclt.pem
openssl pkcs12 -in $1.p12 -out $1.pem -passin pass:whatever -passout pass:whatever
# Convert certificate from PEM format to DER format
openssl x509 -inform PEM -outform DER -in $1.pem -out $1.der
# clean up
rm -rf newcert newreq.pem
5.4 Settings xpextensions
Diese Settings warden jeweils ins Server und ins Client Zertifikat eingebunden. Dies ist nötig
weil es ansonsten Windows Clients nicht möglich ist, diese Zertifikate zu gebrauchen.
[xpclient_ext]
extendedKeyUsage = 1.3.6.1.5.5.7.3.2
[xpserver_ext]
extendedKeyUsage = 1.3.6.1.5.5.7.3.1
09.07.2004
22/27
5.5 Firewall
Mit diesem Skript ermöglich wir das Forwarding zwischen dem Ethernet und dem Wireless
Netzwerk Interface. Ausserdem haben wir hier bereits diverse Rules, welche diversen Traffic
unterbinden.
#!/bin/bash
#Firewall Script for WimS Access Point
#Restricting access from the Wireless LAN to the wired LAN
LAN_IP="147.87.70.60"
LAN_IFACE="eth0"
WLAN_IP="192.168.89.1"
WLAN_IFACE="wlan0"
WLAN_NET_ADDR="192.168.89.0/24"
WLAN_BCAST_ADDR="255.255.255.0"
IPTABLES="/sbin/iptables"
#enable forwarding
echo "1" > /proc/sys/net/ipv4/ip_forward
#Chain policies gets set up before any bad packets gets trough
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP
#Clear all chain rules
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
$IPTABLES -F -t nat
#ICMP Rules, used in Forward chain
echo "ICMP Rules"
$IPTABLES
$IPTABLES
$IPTABLES
$IPTABLES
$IPTABLES
$IPTABLES
-A
-A
-A
-A
-A
-A
FORWARD
FORWARD
FORWARD
FORWARD
FORWARD
FORWARD
$IPTABLES
$IPTABLES
$IPTABLES
$IPTABLES
$IPTABLES
$IPTABLES
-A
-A
-A
-A
-A
-A
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
$IPTABLES
$IPTABLES
$IPTABLES
$IPTABLES
$IPTABLES
$IPTABLES
-A
-A
-A
-A
-A
-A
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
-p
-p
-p
-p
-p
-p
-p
-p
-p
-p
-p
-p
-p
-p
-p
-p
-p
-p
icmp
icmp
icmp
icmp
icmp
icmp
icmp
icmp
icmp
icmp
icmp
icmp
icmp
icmp
icmp
icmp
icmp
icmp
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
--icmp-type
0 -j ACCEPT
8 -j ACCEPT
3 -j ACCEPT
4 -j ACCEPT
11 -j ACCEPT
12 -j ACCEPT
0 -j ACCEPT
8 -j ACCEPT
3 -j ACCEPT
4 -j ACCEPT
11 -j ACCEPT
12 -j ACCEPT
0 -j ACCEPT
8 -j ACCEPT
3 -j ACCEPT
4 -j ACCEPT
11 -j ACCEPT
12 -j ACCEPT
#Postrouting chain in the nat table
#Enable IP masquerading, WLAN -> LAN
echo "nat and Postrouting"
$IPTABLES -A POSTROUTING -t nat -o $LAN_IFACE -s $WLAN_NET_ADDR -j MASQUERADE
#Loopback interface
echo "Loopback rules"
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT
#Forward chain
echo "FORWARD chain"
$IPTABLES -A FORWARD -t filter -i $WLAN_IFACE -m state --state NEW,ESTABLISHED,RELATED -j
ACCEPT
09.07.2004
23/27
$IPTABLES -A FORWARD -t filter -i $LAN_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT
#DNS
echo "DNS1"
$IPTABLES -A
echo "DNS2"
$IPTABLES -A
$IPTABLES -A
$IPTABLES -A
$IPTABLES -A
$IPTABLES -A
$IPTABLES
$IPTABLES
$IPTABLES
$IPTABLES
-A
-A
-A
-A
OUTPUT -p udp -o $LAN_IFACE --dport 53 --sport 1024:65535 -j ACCEPT
INPUT -p udp -i $LAN_IFACE --sport 53 --dport 1024:65535 -j ACCEPT
OUTPUT -p tcp -o $LAN_IFACE --dport 1813 --sport 1024:65535 -j ACCEPT
OUTPUT -p tcp -o $LAN_IFACE --dport 1812 --sport 1024:65535 -j ACCEPT
INPUT -p tcp -i $LAN_IFACE --sport 1813 --dport 1024:65535 -j ACCEPT
INPUT -p tcp -i $LAN_IFACE --sport 1812 --dport 1024:65535 -j ACCEPT
#SSH to AP
$IPTABLES -A OUTPUT -o $LAN_IFACE -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
echo "ssh1"
$IPTABLES -A INPUT -p tcp -i $LAN_IFACE --dport 22 --sport 1024:65535 -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT
5.6 UML Diagramm Integration NetWACS Datasource
Abb. 9: UML NetWACS Datasource
09.07.2004
24/27
5.7 UML Diagramm Integration NetWACS OC2TabIn
Abb. 10: UML NetWACS TabIn
09.07.2004
25/27
6. ABBILDUNGSVERZEICHNIS
Abb. 1: Detaillierter Aufbau .......................................................................................................................4
Abb. 2: Authorisierungsvorgang EAP/TLS.............................................................................................5
Abb. 3: 802.11i..............................................................................................................................................6
Abb. 4: Integration einer Quarantäne .......................................................................................................7
Abb. 5: WimS Access Point........................................................................................................................9
Abb. 6: WimS Integration .........................................................................................................................10
Abb. 7: GUI Managementkonsole...........................................................................................................17
Abb. 8: Integration NetWACS .................................................................................................................19
Abb. 9: UML NetWACS Datasource......................................................................................................24
Abb. 10: UML NetWACS TabIn.............................................................................................................25
09.07.2004
26/27
7. REFERENZEN
- WimS Project Proposal
- WimS Projektantrag
- WimS Projekthandbuch
- WimS Fertigprodukte
- NetWACS Design Guide
09.07.2004
27/27

DANDRO PHOTOGALERIE

Transcription

Similar documents

Das 2.4 GHz Veranstaltungs-How-To

Java für Fortgeschrittene Proseminar im Sommersemester