Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

Cisco PIX und ASA Firewall Workshop Teil 1 - Basiskonfiguration

Anleitung Sicherheit Firewall

Mitglied: spacyfreak

spacyfreak (Level 2) - Jetzt verbinden

03.06.2008 um 16:51 Uhr, 31842 Aufrufe

Wo muss man klicken damit es tut?

Wir wollen eine PIX Firewall zwischen zwei Router klemmen und damit den Traffic filtern.
Hier mal die Basis-Konfiguration ... Fortsetzung folgt!

Testumgebung

eeacf5243875c1d16f5c6e0ffe0fa10a-pixnet - Klicke auf das Bild, um es zu vergrößern

INTRANET Router Konfiguration


Wir konfigurieren auf dem internen INTRANET Router das Interface an das die PIX angeschlossen ist.

01.
router>enable 
02.
router#configure terminal 
03.
router(config)#hostname INTRANET 
04.
INTRANET(config)#interface FastEthernet 1/0 
05.
INTRANET(config-if)#ip address 1.1.1.1 255.255.255.252 
06.
INTRANET(config-if)#description UPLINK ZUR PIX INSIDE INTERFACE e0 
07.
INTRANET(config-if)#no shut 
08.
INTRANET(config-if)#exit

INTERNET Router Konfiguration


Wir konfigurieren nun den externen INTERNET Router damit er mit der PIX kommunizieren kann:

01.
router>enable 
02.
router#configure terminal 
03.
router(config)#hostname INTERNET 
04.
INTERNET(config)#interface FastEthernet 1/0 
05.
INTERNET(config-if)#ip address 2.2.2.1 255.255.255.252 
06.
INTERNET(config-if)#description UPLINK ZUR PIX OUTSIDE INTERFACE e1 
07.
INTERNET(config-if)#no shut 
08.
INTERNET(config-if)#exit

PIX Basiskonfiguration


Hintergrundwissen PIX Sicherheitsphilosophie


Die PIX / ASA hat eine spezielle "Sicherheitsphilosophie" die man erstmal verstehen muss um damit arbeiten zu können und in annehmbarer Zeit zu Ergebnissen kommen zu können.

NAT-CONTROL

Alle Verbindungen von drinnen nach draussen und umgekehrt müssen ge"nat"tet werden.
Die PIX legt zugrunde dass man für alle Verbindungen NAT oder PAT Regeln definiert.
Um dieses Verhalten abzuschalten, benutzt man den Befehl "no nat-control".

Nat-control ist jedoch ein "Sicherheitsfeature", das einige Vorteile mit sich bringt:

  • bei den NAT-Verbindungen wird die TCP Sequenznummer "rundomized" was es erschwert von aussen zu erkennen mit welchen Betriebssystemen man es bei von extern erreichbaren Servern zu tun hat.

  • bei der NAT Konfiguration kann man die Anzahl gleichzeitig erlaubter halb-offener TCP Verbindungen limitieren ("embryonic") und damit Denial-of-Service Attacken verhindern die auf der Bombardierung der PIX mit halboffenen TCP Sessions basieren.

Wir werden uns später noch intensiver mit den NAT- und PAT Features der PIX befassen.
Jetzt schalten wir die nat-control erstmal aus damit wir uns mit der grundsätzlichen Herangehensweise vertraut machen.


01.
no nat-control
Security-Levels

Die PIX/ASA arbeiten mit so genannten "Security Levels".
Für jedes PIX Interface muss ein Security Level definiert sein.

Das Security Level ist ein Bereich zwischen 0 und 100.

Security Level 0 bekommen "unsichere" Interfaces, bzw. das OUSIDE Interface das uns mit dem "bösen" Internet verbindet.

Security Level 100 bekommen "sichere" Interfaces, bzw. das INSIDE Interface das uns mit dem "vertrauenswürdigen" Intranet verbindet.

Wenn man noch ein DMZ Interface betreiben will kann man diesem beispielsweise Security Level 50 verpassen.

Nun verhält es sich so, dass Traffic, der von einem UNSICHEREN Interface (z. B. OUTSIDE) in Richtung SICHERES Interface (INSIDE) wandert, per default geblockt wird.
Daten Traffic, der von einem SICHEREN Interface (INSIDE) in Richtung eines UNSICHEREN Interfaces (OUTSIDE) wandert wird per default nicht beblockt.


Da die PIX / ASA "Statefull Inspection Firewalls" sind, "merken" sie sich wenn von einem SICHEREN Interface aus Traffic zu einem UNSICHEREN Interface wandert, und lassen den Antwort-Traffic passieren.

PIX Interface Konfiguration

Zunächst mal werden INSIDE und OUTSIDE Interface definiert und konfiguriert.

01.
pixfirewall> 
02.
pixfirewall> ena 
03.
Password: 
04.
pixfirewall# conf t 
05.
pixfirewall(config)# hostname PIX 
06.
PIX(config)# interface e0 
07.
PIX(config-if)# nameif INSIDE 
08.
PIX(config-if)# security-level 100 
09.
PIX(config-if)# ip address 1.1.1.2 255.255.255.252 
10.
PIX(config-if)# description UPLINK ZU INTRANET ROUTER Fe1/0 
11.
PIX(config-if)# no shut 
12.
PIX(config-if)# exit 
13.
PIX(config)# interface e1 
14.
PIX(config-if)# nameif OUTSIDE 
15.
PIX(config-if)# security-level 0 
16.
PIX(config-if)# ip address 2.2.2.1 255.255.255.252 
17.
PIX(config-if)# description UPLINK ZU INTERNET ROUTER Fe1/0 
18.
PIX(config-if)# no shut
Das wars erstmal.

Beide Router können mit der PIX kommunizieren.
Vom INTRANET Router aus müsste man den INTERNET Router pingen können (da ja Traffic von einem Interface mit HÖHEREM Security Level zu einem Interface mit NIEDRIGEN Security Level per default erlaubt ist!).
Wir testen das am besten mal...

01.
INTRANET#ping 2.2.2.1 
02.
 
03.
Type escape sequence to abort. 
04.
Sending 5, 100-byte ICMP Echos to 2.2.2.1, timeout is 2 seconds: 
05.
..... 
06.
Success rate is 0 percent (0/5)
Ups! Nix wars mit Ping! Warum können wir den INTERNET Router nicht pingen?
Weil der INTRANET Router die Route nicht kennt. Er weiss nicht wohin er die ICMP (PING) Pakete schicken soll!
Also prüfen wir mal schnell das Routing auf dem INTRANET Router...

01.
INTRANET#show ip route 
02.
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP 
03.
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
04.
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
05.
       E1 - OSPF external type 1, E2 - OSPF external type 2 
06.
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 
07.
       ia - IS-IS inter area, * - candidate default, U - per-user static route 
08.
       o - ODR, P - periodic downloaded static route 
09.
 
10.
Gateway of last resort is not set 
11.
 
12.
     1.0.0.0/30 is subnetted, 1 subnets 
13.
C       1.1.1.0 is directly connected, FastEthernet1/0 
14.
 
Aha! Wie wir sehen - sehen wir nichts.
Der INTRANET Router kennt nur das Netz 1.1.1.0 weil es "directly connected" ist und damit automatisch einen Routing-Eintrag in die Routingtabelle fabriziert.

Wir sehen auch dass keine Default-Route gesetzt ist.
Die Default Route benutzt der Router immer dann, wenn ihm für ein bestimmtes Netzwerkziel die Route fehlt - dann benutzt er die Default Route.

Also konfigurieren wir mal schnell die Default Route.
Wir möchten erreichen, dass der INTRANET Router alle Pakete für die er keine Route hat, an die PIX sendet. Bei statischen Routen gibt man immer den "Next Hop" an, nach der Syntax

01.
ip route <zielnetz> <zielsubnetzmaske> <Next-Hop-IP-Adresse>
Auf dem INTRANET Router setzen wir die Default Route folgender maßen:
01.
INTRANET(config)#ip route 0.0.0.0 0.0.0.0 1.1.1.2
Auch auf dem INTERNET Router setzen wir eine statische Route damit die Pakete den Weg ins Netz 1.1.1.0/30 finden können.

01.
INTERNET(config)#ip route 1.1.1.0 255.255.255.252 2.2.2.2
Wir können vom INTRANET Router aus den INTERNET Router jedoch immernoch nicht pingen!
Wo klemmts?
Die PIX ist eine Firewall - wir müssen also erstmal Firewall Regeln definieren, die den PING zulassen. Die PIX wird per default zwar ICMP Pakete vom sicheren Netz (1.1.1.0) ins unsichere Netz (2.2.2.0) zulassen - sie lässt jedoch die ICMP Antwortpakete nicht durch!
Warum das? Die PIX ist doch eine "Statefull Inspection Firewall" und wird daher die Antwortpakete aus dem unsicheren "OUTSIDE" Netz ins sichere Netz "INSIDE" durchlassen?
Normalerweise ist das so - nicht aber bei ICMP!
Cisco sagt: "Inbound ICMP through the PIX/ASA is denied by default. Outbound ICMP is permitted, but the incoming reply is denied by default."

Also schreiben wir eine ACL auf der PIX, die auf dem OUTSIDE Interface in EINKOMMENDER RICHTUNG ICMP Pakete durchlässt.

Schreiben von Firewallregeln (access-lists) auf der PIX


01.
PIX(config)# access-list OUTSIDE_IN permit icmp any any
So damit haben wir eine prima Firewall-Regel geschrieben!
Die Regel hat den Namen "OUTSIDE_IN" weil dieser Regelsatz (der beliebig viele "Statements" enthalten kann) filtern soll, was auf dem OUTSIDE Interface HEREIN ("in") kommt.

Dennoch kann 1.1.1.1 keinen Ping absenden an 2.2.2.1.
Woran klemmts?
Richtig! Die Firewall-Regel muss noch an ein Interface gebunden werden!
Und zwar ans OUTSIDE Interface, in EINKOMMENDER Richtung!

01.
PIX(config)# interface ethernet 1 
02.
PIX(config-if)# access-group OUTSIDE_IN in interface OUTSIDE
Und JETZT klappts auch mit dem Ping!

Natürlich würden wir in einer echten Firma nicht gerade mit Lob überschüttet werden wenn wir global den Ping auf alle internen Ressourcen zulassen würden! Geht schliesslich die ganze Welt nichts an welche Rechner wir in unserem schönen Intranet beherbergen.

Wir können freilich auch beliebige andere Regeln schreiben.
Zum Beispiel wollen wir den internen Webserver 10.10.10.10 auf Port 80 und 443 TCP von extern erreichbar machen.
Was tun?

01.
PIX(config)# access-list OUTSIDE_IN permit tcp any host 10.10.10.10 eq 80 
02.
PIX(config)# access-list OUTSIDE_IN permit tcp any host 10.10.10.10 eq 443 
03.
PIX(config)# access-list OUTSIDE_IN deny any any 
04.
PIX(config)#interface ethernet 1 
05.
PIX(config-if)#access-group OUTSIDE_IN in interface OUTSIDE 
06.
PIX(config-if)#exit 
07.
PIX#write memory
Die Synthax der Firewall Regeln ist zu kapieren, dann wird es ganz leicht

Prinzipiell sieht es so aus:

access-list <NAME> <permit oder deny> <tcp oder udp oder icmp> <Quell-IP oder Quell-Netz> <Subnetz-Maske> <Ziel-IP oder Ziel-Netz> <Subnetz-Maske> eq <PORT>

Das ist nur eine Variante, zeigt jedoch die grundsätzliche Synthax.

Die ACL kann beliebig viele Statements (Regeln) beinhalten.
Die ACL muss an ein Interface gebunden werden, einkommend (in) oder ausgehend (out) um einkommende oder ausgehende Pakete an diesem Interface an das sie gebunden ist zu filtern!

Ausserdem zu beachten:
Am Ende jeder ACL steht eine "unsichtbare" "deny any any" Regel die alles andere verbietet das nicht explizit erlaubt wurde! Es ist jedoch ratsam selbst unter seinen Regelsatz nochmal die Regel "access-list <name> deny any any" einzufügen damit man zum einen diese unsichtbare Regel nicht "vergisst", zum anderen - wegen des Hítcounts! Wir sehen dann nämlich ob und wieviele Treffer auf der Regel landen wenn wir sie angeben. Wenn wir die Regel nicht angeben sehen wir goarnix.

Absicherung der PIX Firewall


Auch die PIX selbst muss abgesichert werden. Wir wollen sicher nicht dass jeder ohne Passwort auf die PIX zugreifen kann und nach belieben die Firewallregeln ändert oder sonstigen Unfug treibt.

Herunterfahren nicht benutzter Interfaces

Jedes Interface das aktiviert ist stellt eine potentielle Gefahr dar. Je nachdem wie das Interface konfiguriert ist kann ein potentieller Angreifer (der auch ein gelangweilter Praktikant sein könnte) auf das Netz oder gar auf ALLE Netze zugreifen (bei Trunkports).

01.
PIX(config)#interface ethernet 2 
02.
PIX(config-if)#shutdown 
03.
PIX(config-if)#exit

Setzen eines "enable" Passwortes

Das Wechseln von "user exec" zu "privileged mode" per "enable" sollte man mit einem Passwort absichern.
Um in den "global config mode" zu gelangen gibt man den Befehl "configure terminel" ein oder "conf t".

01.
PIX> 
02.
PIX> ena 
03.
PIX>password ****** 
04.
PIX# 
05.
PIX#conf t 
06.
PIX(config)# enable password pa55w0rd level 15
Wenn man auf die PIX zugreift ist man erstmal im "User exec Mode" in dem man nichts konfigurieren kann, sondern nur einige wenige Analyse-Befehle absondern kann.
01.
PIX>
Um in den "Privileged Mode" zu gelangen muss man den Befehl "enable" eingeben.
01.
PIX>enable 
02.
PIX>Password ******* 
03.
PIX#

Lokale Admin-User anlegen

01.
PIX# conf t 
02.
PIX(config)# username admin password pa55w0rd privilege 15

Management Zugriff beschränken

01.
PIX(config)# management-access INSIDE

SSH Zugriff konfigurieren

Damit man nicht per telnet (unverschlüsselt) auf die PIX zugreifen muss kann man stattdessen SSH verwenden. Es muss ein Schlüsselpaar generiert und anschliessend der Zugriff per SSH aktiviert werden.
Zusätzlich soll der SSH Zugriff auf einen IP-Bereich beschränkt sein, im Beispiel soll nur aus dem Netz 10.10.10.0/24 per ssh auf die PIX zugegriffen werden können.

01.
PIX(config)# crypto key generate rsa general-keys modulus 2048 
02.
PIX(config)# ssh 10.10.10.0 255.255.255.0 INSIDE 
03.
PIX(config)# aaa authentication ssh console LOCAL

Idle-Timeout konfigurieren

Wenn man "mal kurz" das Büro verlässt und eine Konsolen- oder SSH-Session ist noch offen besteht die Gefahr dass die Cisco-affine Putzfrau mal eben die PIX reloadet. Damit das nicht passiert machen Idle-timeouts Sinn, die nach einigen Minuten Nicht-Aktivität die Verbindung automatisch schliessen.

01.
PIX(config)# console timeout 10 
02.
PIX(config)# ssh timeout 10

Router und PIX Konfiguration speichern


Wenn die Router oder die PIX neu booten würden, wäre die bisherige Config im Nirwana verloren!
Damit die momentane von uns kreierte Konfiguration aus dem Arbeitsspeicher bzw. RAM (running-config) in den nicht-flüchtigen Speicher Flash bzw. NVRAM (startup-config) gespeichert wird um beim nächsten Reboot eingelesen werden zu können, speichert man lokal die Konfiguration mit folgenden Befehlen:

Lokales Config Backup Cisco Router

01.
router#copy running-config startup-config

Lokales Config Backup Cisco PIX

01.
PIX#write memory

Backup der Config auf einen TFTP Server


01.
PIX(config)#  copy run tftp://10.10.10.10/cisco/pix-backups/pix-1

Widerherstellen der Config von einem TFTP Server


01.
PIX(config)#copy tftp://10.10.10.10/cisco/pix-backups/pix-1 startup-config

Troubleshooting-Tip: PIX Packet-Tracer


Der Packet-Tracer ist ein prima Hilfsprogramm das uns hilft herauszufinden, ob Pakete - wenn sie kommen würden - die PIX passieren können, oder nicht. Die PIX testet mit Hilfe dieses Tools ob ACLs die Verbindung blockieren, ob das Routing stimmt usw.

Beim Packet-Tracer geben wir ein, zu testen, ob EINKOMMENDE ("input") PING-Pakete ("icmp") von der Quell-IP 1.1.1.1 an die Ziel-IP 2.2.2.1 durchkommen "würden" oder nicht.
Die "1 1" steht für den ICMP Type.

01.
PIX# packet-tracer input INSIDE icmp 1.1.1.1 1 1 2.2.2.1 
02.
 
03.
Phase: 1 
04.
Type: FLOW-LOOKUP 
05.
Subtype: 
06.
Result: ALLOW 
07.
Config: 
08.
Additional Information: 
09.
Found no matching flow, creating a new flow 
10.
 
11.
Phase: 2 
12.
Type: ROUTE-LOOKUP 
13.
Subtype: input 
14.
Result: ALLOW 
15.
Config: 
16.
Additional Information: 
17.
in   2.2.2.0         255.255.255.252 OUTSIDE 
18.
 
19.
Phase: 3 
20.
Type: IP-OPTIONS 
21.
Subtype: 
22.
Result: ALLOW 
23.
Config: 
24.
Additional Information: 
25.
 
26.
Phase: 4 
27.
Type: INSPECT 
28.
Subtype: np-inspect 
29.
Result: ALLOW 
30.
Config: 
31.
Additional Information: 
32.
 
33.
Phase: 5 
34.
Type: FLOW-CREATION 
35.
Subtype: 
36.
Result: ALLOW 
37.
Config: 
38.
Additional Information: 
39.
New flow created with id 240, packet dispatched to next module 
40.
 
41.
Phase: 6 
42.
Type: ROUTE-LOOKUP 
43.
Subtype: output and adjacency 
44.
Result: ALLOW 
45.
Config: 
46.
Additional Information: 
47.
found next-hop 2.2.2.1 using egress ifc OUTSIDE 
48.
adjacency Active 
49.
next-hop mac address ca01.0b54.001c hits 35 
50.
 
51.
Result: 
52.
input-interface: INSIDE 
53.
input-status: up 
54.
input-line-status: up 
55.
output-interface: OUTSIDE 
56.
output-status: up 
57.
output-line-status: up 
58.
Action: allow 
59.
 
60.
PIX#
Neuester Wissensbeitrag
Windows 10

Powershell 5 BSOD

(8)

Tipp von agowa338 zum Thema Windows 10 ...

Ähnliche Inhalte
LAN, WAN, Wireless
Cisco ASA Priority Queue via ACL (2)

Frage von maxmax zum Thema LAN, WAN, Wireless ...

LAN, WAN, Wireless
gelöst Cisco ASA hinter Router mit NAT (2)

Frage von maxmax zum Thema LAN, WAN, Wireless ...

Firewall
gelöst Cisco ASA - Wechsel der Outside IP Adresse auf der Remote Site ASA (3)

Frage von tweishaar zum Thema Firewall ...

Heiß diskutierte Inhalte
Microsoft
Ordner mit LW-Buchstaben versehen und benennen (20)

Frage von Xaero1982 zum Thema Microsoft ...

Outlook & Mail
gelöst Outlook 2010 findet ost datei nicht (19)

Frage von Floh21 zum Thema Outlook & Mail ...

Netzwerkmanagement
gelöst Anregungen, kleiner Betrieb, IT-Umgebung (18)

Frage von Unwichtig zum Thema Netzwerkmanagement ...