|
|
|
Scripte ..
|
| Access-Listen |
Access
Listen
Was
Sie schon immer über Cisco Access Listen wissen
wollten, aber nicht zu fragen wagten.
Zusammenfassung
Es wird die Konfiguration
von erweiterten IP Access-Listen (extended IP access
lists) für Router mit cisco IOS erläutert.
Die allgemeine Syntax von erweiterten Access Listen
ist für den Anfänger etwas unüberschaubar.
Es wird deshalb versucht, den Zusammenhang der verschiedenen
Filtermechanismen mit den Feldern innerhalb eines IP
(UDP, TCP) Paketes zu verdeutlichen. Nach der Lektüre
dieser Einführung sind Sie in der Lage, komplexe
Access Listen zum Schutz Ihres Netzes gegen verschiedene
Arten von Mißbrauch zu konfigurieren.
Allgemeines
zu erweiterten Access Listen
Die
folgenden Punkte sind dazu gedacht, Ihnen das "Drumrum",
also alles jenseits der puren Syntax der Access Listen,
näher zu bringen. Es mag auf den ersten Blick viel
kompakte Information auf einmal sein, aber nachdem wir
die ersten drei Access Listen konfiguriert haben, geht
uns die Terminologie und der Ablauf schon in Fleisch
und Blut über.
- Access
Listen können für jedes Interface verschieden
sein.
- Die
erweiterten IP Access Listen (und nur um diese geht
es hier) haben die Nummern 100 bis 199 und werden
im globalen Konfigurationsmodus mit
access-list
100 ...
konfiguriert.
Ab IOS 11.3 oder 12.0 soll es auch benannte Access
Listen geben.
- Pro
Interface kann man je eine Access Liste für eingehende
und ausgehende Pakete konfigurieren. Dies geschieht
mit
interface
Ethernet0
ip access-group 100 in ! Filter für eingehende
ip access-group 101 out ! und ausgehende Pakete
-
Eine Access List enthält null oder mehr
permit und deny
Angaben mit einer Bedingung, die der Reihe nach abgearbeitet
werden. Die erste zutreffende Bedingung legt die Wirkung
der Access List auf ein Paket fest. Trifft eine deny
Bedingung zu oder wird das Ende der Access Liste erreicht,
wird das Paket verworfen.
-
Neue Bedingungen für Access Listen werden immer
am Ende der Liste eingefügt. Es ist daher fast
immer nötig, bei Änderungen die Liste zunächst
mit
no access-list
100
zu entfernen und neu zu schreiben.
-
Eine leere oder nichtkonfigurierte Access Liste hat
(bei Interface Access Groups) den gleichen Effekt,
wie ein generelles deny
auf alle Pakete. Aus diesem Grund muß vor Änderungen
an Access Listen zunächst mit
interface
Ethernet0
no ip access-group 100 in
die Konfiguration auf den entsprechenden Interfaces
entfernt werden. (Und natürlich nach erfolgter
Änderung wieder eingetragen.)
-
Die Anzahl der Pakete, die auf eine Bedingung zugetroffen
haben, kann man sich mit
show access-lists
100
ansehen.
Bauen
wir einen einzelnen Access Listen-Eintrag Schritt für
Schritt auf. Unser Ziel sei zunächst, email des
bekannten Spammers 42.6.6.6 an Rechner in unserem Class
C Netz 192.124.255.0/24 zu unterbinden. Wir nehmen die
Access Liste Nummer 100, also muß es heißen
access-list
100 ...
Danach
folgt die Wirkung der noch zu bestimmenden Bedingung,
permit
oder deny.
Weil
wir an bestimmten Paketen nicht interessiert sind heißt
es also
access-list
100 deny ...
Access
Listen können entweder auf jedes Paket angewandt
werden, das einen Router betritt oder verläßt
oder nur auf Pakete eines bestimmten Protokolls.
Die Angabe des Protokolls bezieht sich auf das protocol
Feld im IP Header (Abbildung 1). Hier muß also
eine Zahl von 0 bis 255 angegeben werden; einige wichtige
Protokolle kann man auch als Namen angeben: icmp, udp,
tcp, gre um die gängigsten zu nennen. Eine Aufzählung
aller Protokolle mit Nummer und Namen findet sich bei
der Internet Assigned Number Authority (IANA)
unter protoco
l-numbers.
Abbildung 1: Felder im IP Header
Wenn
wir alle Pakete ungeachtet des Protokolls filtern
wollen, dann geben wir den Pseudoprotokollnamen ip
an.
Da
SMTP über TCP implementiert ist, wählen wir
als Protokoll tcp (wir können auch die Protokollnummer
6 verwenden):
access-list
100 deny tcp ...
Als
nächstes folgt eine Angabe, die mit der 32bit Quelladresse
im IP Header verglichen wird. Dies kann auf drei Arten
geschehen:
any
trifft
auf alle Adressen zu
host
A.B.C.D
trifft
für genau diese Hostadresse zu
A.B.C.D E.F.G.H
Trifft
zu, wenn die Quelladresse undiert mit dem Eins-Komplement
von E.F.G.H die Adresse A.B.C.D ergibt. (Ich weiß
auch nicht, was Cisco sich dabei gedacht hat.) Man benutzt
diese Form, um Adressbereiche (Netze, Subnetze) zu spezifizieren.
Eigentlich ist es ganz einfach. Alle Hosts im Class
C Netz 1.2.3.0 würde man durch 1.2.3.0 0.0.0.255
angeben, denn wenn wir die Quelladresse 1.2.3.42 mit
dem Eins-Komplement 255.255.255.0 undieren, bekommen
wir 1.2.3.0, voilà!
(Ein halbes Class C Netz hätte E.F.G.H = 0.0.0.127,
ein Viertel Class C hätte 0.0.0.63 und so weiter.
Zwei aufeinanderfolgende hätten ggfs. 0.0.1.255).
Vielleicht hilft Ihnen auch die Vorstellung, daß
die durch 0.0.0.255 angegebenen Bits ignoriert (auf
0 gesetzt) und dann mit 1.2.3.0 verglichen werden. Also:
access-list
100 deny tcp host 42.6.6.6
Äquivalent
dazu wäre die Schreibweise
access-list
100 deny tcp 42.6.6.6 0.0.0.0
Da
wir als Protocol TCP haben, könnten wir noch eine
Quellport-Nummer folgen lassen. Da der Quellport aber
bei SMTP nicht festgelegt ist, entfällt diese Angabe.
Ohne diese Angabe trifft die Bedingung auf alle Quellports
zu.
Auf
die gleiche Art spezifizieren wir die Zieladressen,
nämlich unser Class C Netz:
access-list
100 deny tcp host 42.6.6.6 192.124.255.0 0.0.0.255
Ports
werden durch einen Operator und eine Nummer oder Namen
spezifiziert. Die Operatoren sind
lt
(less
than)
gt
(greater
than)
eq
(equal)
neq
(not
equal)
range
(inclusive
range, 2 Nummern folgen)
Die
Namen von Ports erhalten wir, wenn wir ein Fragezeichen
nach dem Operator eingeben. SMTP ist Port 25, also entweder
access-list
100 deny tcp host 42.6.6.6 192.124.255.0 0.0.0.255 eq
smtp
oder
access-list
100 deny tcp host 42.6.6.6 192.124.255.0 0.0.0.255 eq
25
Sind
wir damit bereit, die Access-Liste auf unseren Interface
zum WAN scharf zu machen? Nein!
Wie anfangs in den Anmerkungen erwähnt, steht am
Ende der Access-Liste ein implizites
access-list
100 deny ip any any
was
zur Folge hätte, daß wir die gesamte
Konnektivität verlören. Wenn wir also lediglich
diesen einen Spammer fernhalten wollen, dann sieht die
vollständige Access-Liste so aus:
access-list
100 deny tcp host 42.6.6.6 192.124.255.0 0.0.0.255 eq
smtp
access-list 100 permit ip any any
Die
Access-Liste müßte dann auf dem Interface
zum WAN in eingehender Richtung aktiviert werden. Rekapitulieren
wir: Eine Access-Liste hat die Form
access-list
Nr permit|deny Protokoll
Quelladresse
Zieladresse
Wenn
das Protokoll tcp oder udp ist, können optional
Portnummern angegeben werden (vgl. die Abbildungen 2
und 3; die Farben korrespondieren mit den entsprechenden
Feldern in den Headern):
access-list
Nr permit|deny
Protokoll Quelladresse
[Quellport]
Zieladresse [Zielport]
Wenn
das Protokoll tcp ist, kann optional noch 'established'
angegeben werden:
access-list
Nr permit|deny Protokoll
Quelladresse [Quellport]
Zieladresse][Zielport]
established
Ein
Paket gehört zu einer 'established' TCP Verbindung,
wenn das ACK oder RST Bit (oder beide) gesetzt sind
(siehe Abbildung 3). Das erste Paket einer TCP Verbindung
hat nur das SYN Bit gesetzt, trifft also nicht au 'established'
zu. Wie können wir 'established' vorteilhaft in
Access-Listen einsetzen? Erinnern wir uns an die sequentielle
Abarbeitung der Access-Liste. Wenn wir als erstes eine
allgemeine 'established' Bedingung haben,
access-list
100 permit tcp any any established
dann
müssen alle Pakete etablierter TCP Verbindungen
nur mit einem Access-Listen Eintrag verglichen werden.
(Dies ist für die Performance bedeutsam, besonders
wenn Access-Listen länger werden. Als Faustregel
gilt: oft zutreffende Bedingungen möglichst nahe
an den Anfang setzen.) Die deny Bedingungen können
danach folgen. Wenn wir zum Beispiel eingehendes telnet
verbieten wollen,
access-list
100 permit tcp any any established
access-list 100 deny tcp any 192.124.255.0 0.0.0.255
eq telnet
access-list 100 permit ip any any
dann
wird das erste (SYN) Paket eines telnet-Versuchs durch
den 2. Eintrag verworfen. Eine telnet-Verbindung kann
somit nie etabliert werden
Abbildung
2: Felder im TCP Header
Abbildung
3: Felder im UDP Header
Beispiele aus der wirklichen Welt
In
diesem Abschnitt wollen wir einige wirksame Mittel gegen
Denial-of-Service (DoS) Angriffe entwickeln, wie sie
täglich vom DFN Network Operation Center im Wissenschaftsnetz
beobachtet werden. Wir empfehlen dringend, diese Filter
zu konfigurieren!
Es sind in vielen Fällen nicht nur einzelne Organisationen
betroffen, sondern oftmals alle Kunden, z.B. wenn durch
einen Angriff die Transatlantikleitung gesättigt
wird. Dieses Szenario ist besonders bei der sogenannten
SMURF Attacke (auch ping-flood genannt) zu beobachten.
SMUR
F-anfällig
sind alle Netze, die Hosts enthalten, welche auf Broadcast
bzw. Netzadressen antworten. Unsere erste Real World
Access-Liste beschäftigt sich also mit dem
Problem:
Angriffe unter Ausnutzung von Broadcast- und Netzadressen
Lösung: Lassen Sie keinen Verkehr auf diese
Adressen in Ihr Netz.
Angenommen,
Unser LAN besteht aus 2 Class C Netzen, von denen eines
in 2 Subnetze von je 128 Adressen unterteilt ist, etwa
wie folgt:
Netz
in CIDR Netzadresse Broadcastadresse
192.124.255.0/24 192.124.255.0 192.124.255.255
193.175.51.0/25 193.175.51.0 193.175.51.127
193.175.51.128/25 193.175.51.128 193.175.51.255
Auf
die Access-Liste des Interfaces zum WAN kommen dann
die deny Statements
!
Keine Pakete an unsere 3 Netzadressen:
!
VON ZU
access-list 100 deny ip any host 192.124.255.0
access-list 100 deny ip any host 193.175.51.0
access-list 100 deny ip any host 193.175.51.128
! Keine Pakete an unsere 3 Broadcastadressen:
access-list 100 deny ip any host 192.124.255.255
access-list 100 deny ip any host 193.175.51.127
access-list 100 deny ip any host 193.175.51.255
Wenn
Ihre Organisation ein oder mehrere Class B Netze hat,
die in hunderte Class C Netze aufgeteilt sind (und die
zu allem Unglück auch noch dezentral administriert
werden) hilft Ihnen -- dem Wächter über den
WAN Zugang -- eventuell ein pauschales deny auf *.0
und *.255:
!
Keine Pakete an Class C Subnetz/Broadcastadressen (*.0,
*.255):
access-list 100 deny ip any 0.0.0.0 255.255.255.0
access-list 100 deny ip any 0.0.0.255 255.255.255.0
Noch
ein
Problem:
Pakete mit gefälschten Absenderadressen (IP Spoofing)
Lösung: Lassen Sie nur Pakete mit Ihren
Absenderadressen ins WAN und akzeptieren Sie keine Pakete
mit Ihren Absenderadressen aus dem WAN.
Beachten
Sie also, daß IP Spoofing in beiden Richtungen
auftreten kann: gefälschte Pakete können in
Ihrem LAN entstehen und den Weg ins WAN suchen, als
auch an Ihr LAN geschickt werden. Gefälschte Pakete
aus dem WAN können in derselben Access Liste, die
auch Schutz gegen Broadcastangriffe beinhaltet, konfiguriert
werden. Gefälschte Pakete aus dem LAN müssen
aber in einer separaten Access Liste konfiguriert werden,
weil sie in out Richtung filtern. Also:
!
Keine Pakete mit unseren Adressen als Absender ins LAN
lassen:
VON
ZU
access-list 100 deny ip 192.124.255.0 0.0.0.255 any
access-list 100 deny ip 193.175.51.0 0.0.0.255
any
Beachten
Sie, daß wir die 2 Subnetze in 193.175.51.0 nicht
getrennt aufführen, sondern zum Class C Netz zusammenfassen.
Sollten Sie mehrere aufeinanderfolgende Netze haben,
sollten diese aggregiert werden, d.h. zu den größtmöglichen
Blöcken zusammengefaßt werden. Das hält
die Listen klein und die Performance hoch.
!
Nur Pakete mit unseren Adressen als Absender ins WAN
lassen:
! VON
ZU
access-list 101 permit ip 192.124.255.0 0.0.0.255 any
access-list 101 permit ip 193.175.51.0 0.0.0.255
any
access-list 101 deny ip any any
Eine
Randbemerkung: In einigen LANs werden für Verbindungen
auch Adressen aus dem privaten Adressbereich verwendet,
z.B. 10.0.0.x für Verbindungen zwischen Routern.
Verschiedene Anwendungen (Path MTU Discovery), die von
solcherart konfigurierten Netztwerkknoten ausgehen,
können Absenderadressen aus diesem Bereich erfordern.
In diesem Fall müssen Sie in die Access Liste 101
auch permit Statements für den entsprechenden privaten
Adressbereich aufnehmen.
Tips
und Tricks
Treffer
anzeigen
Ob
eine Access Liste greift und wenn ja, wie oft, können
sie wie folgt feststellen:
router#
show access-lists 101
Extended IP access list 101
permit ip 192.124.255.0 0.0.0.255 any (23423 matches)
permit ip 193.175.51.0 0.0.0.255 any (2649 matches)
deny ip any any (4 matches)
Vorsicht
ist die Mutter der Porzellankiste
Konfigurieren
Sie alle Listen zunächst ausschließlich mit
permit statements -- selbst jene, die Sie eigentlich
verbieten wollen. Dann schauen Sie sich die matches
der einzelnen Zeilen genau an. Sollte eine als deny
vorgesehene Zeile ungewöhnlich viele matches aufweisen,
könnte das ein Anzeichen für eine Fehlkonfiguration
in Ihrer Liste sein. Der Vorteil ist, daß Sie
in diesem Fall niemandem die Konnektivität genommen
haben -- eventuell Ihnen selbst!
Logging
Durch
das Anhängsel log als letzten Eintrag einer Bedingung
können Treffer mit etwas mehr Information (Adressen,
Ports, Zeit) an einen Loghost geschickt werden. Logging
wird durch das Kommando 'logging IP_Adresse'
konfiguriert. Log Messages werden dann an den syslog
Port (514, UDP) der angegeben Adresse geschickt. Die
sogenannte syslog facility ist in der Voreinstellung
local7 und kann mit 'logging facility facility-type'
geändert werden. Die Konfiguration des syslog einer
Workstation ist in den man-pages zu syslog.conf und
syslog näher erläutert.
Performance
Gewinn
Wie
oben schon erwähnt, sollten Sie die Einträge
so anordnen, daß häufig zutreffende Bedingungen
weit vorne stehen. Beachten Sie
allerdings, daß die Reihenfolge die Semantik bestimmt--Sie
sollten nicht blind nach der Anzahl der Treffer sortieren.
Performance
Verlust
Die
Bearbeitung von Access Listen kostet CPU Zeit, die von
mehreren Faktoren stark abhängt, u.a. Accesslistenlänge,
Anordnung, Anzahl der tatsächlich verworfenen Pakete
(weil für jedes verworfene Paket eine ICMP Host
Unreachable Message erzeugt und zurückgeschickt
wird), Boardarchitektur und Switching Modus.
Für
ausgehende Accesslisten und eingehende auf bestimmte
Bus Typen ist unter Umständen ein Performanceverlust
zu erwarten, denn (Doku zu ip access-group):
When
you enable outbound access lists, you automatically
disable autonomous switching for that interface. When
you enable input access lists on any cBus or CxBus interface,
you automatically disable autonomous switching for all
interfaces (with one exception; an SSE configured with
simple access lists can still switch packets, on output
only.)
Bei
Einsatz von VIP Boards auf deren Interfaces ausgehende
Access Listen konfiguriert sind, ist kein distributed
switching mehr möglich.
Ob
Ihr Router dadurch in die Knie gezwungen wird, sehen
Sie mit 'show processes cpu'. Als Faustregel gilt, daß
man nicht über 70% im 5 Minutenmittel liegen sollte.
Seien Sie etwas konservativer, wenn periodisch CPU intensive
Arbeiten anstehen, wie das Abholen von Accounting Daten
in Abständen kürzer als eine Stunde o.ä.
Referenzen
Erweiterte
IP Access Listen werden in der Cisco Dokumentation im
Band IV, Network Protocols - Command Reference - Part
I, unter dem Stichwort "access-list (extended)"
beschrieben. In der gedruckten Version von IOS 11.1
ist dies auf Seite IV-187. Die Online Version auf dem
Cisco Server ist hier,
bereitgestellt von: Nostro | am: 07-Dec-2002
|
|
Hier finden Sie eine Menge an Freeware. Diese Freewaretools sind für jeden frei zum download verfügbar. Nähere Informationen zu den Freeware-Tools finden sie direct auf der Downloadseite dieses Freeware-Tools. In den einzelnen Kategorien werden diese Freeware und Sharewares einzeln sortiert aufgelistet.
Nutzen sie auch die Suchoption in der Database, um ihr Freeware-Tool finden zu können.
Für Hilfe und Support zu den Freeware und Sharewares sind wir im Forum gerne breit, Ihnen kostenlose Unterstützung zu bieten.
Brechen Sie den Download nicht ab, da Sie sonst unter Umständen diese Tools nicht ordnungsgemäß öffnen können.
Jeder registrierte User hat auch selber die Möglichkeit, selber bei uns Freewareprogramme in die Datenbank posten zu können. Dazu ist zu beachten, daß dort nur Freeware und Shareware eingetragen werden dürfen.
Viel Spaß beim durchstöbern unserer Freewaredatenbank.
|
|
|
