0
Cisco PIX und ASA Firewall Workshop Teil 1 - Basiskonfiguration
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!
Wir konfigurieren auf dem internen INTRANET Router das Interface an das die PIX angeschlossen ist.
Wir konfigurieren nun den externen INTERNET Router damit er mit der PIX kommunizieren kann:
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.
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:
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.
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.
Zunächst mal werden INSIDE und OUTSIDE Interface definiert und konfiguriert.
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...
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...
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
Auf dem INTRANET Router setzen wir die Default Route folgender maßen:
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.
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.
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!
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?
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.
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.
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).
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".
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.
Um in den "Privileged Mode" zu gelangen muss man den Befehl "enable" eingeben.
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.
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.
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:
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.
Wir wollen eine PIX Firewall zwischen zwei Router klemmen und damit den Traffic filtern.
Hier mal die Basis-Konfiguration ... Fortsetzung folgt!
Inhaltsverzeichnis
Testumgebung
INTRANET Router Konfiguration
Wir konfigurieren auf dem internen INTRANET Router das Interface an das die PIX angeschlossen ist.
router>enable
router#configure terminal
router(config)#hostname INTRANET
INTRANET(config)#interface FastEthernet 1/0
INTRANET(config-if)#ip address 1.1.1.1 255.255.255.252
INTRANET(config-if)#description UPLINK ZUR PIX INSIDE INTERFACE e0
INTRANET(config-if)#no shut
INTRANET(config-if)#exitINTERNET Router Konfiguration
Wir konfigurieren nun den externen INTERNET Router damit er mit der PIX kommunizieren kann:
router>enable
router#configure terminal
router(config)#hostname INTERNET
INTERNET(config)#interface FastEthernet 1/0
INTERNET(config-if)#ip address 2.2.2.1 255.255.255.252
INTERNET(config-if)#description UPLINK ZUR PIX OUTSIDE INTERFACE e1
INTERNET(config-if)#no shut
INTERNET(config-if)#exitPIX 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.
no nat-controlSecurity-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.pixfirewall>
pixfirewall> ena
Password:
pixfirewall# conf t
pixfirewall(config)# hostname PIX
PIX(config)# interface e0
PIX(config-if)# nameif INSIDE
PIX(config-if)# security-level 100
PIX(config-if)# ip address 1.1.1.2 255.255.255.252
PIX(config-if)# description UPLINK ZU INTRANET ROUTER Fe1/0
PIX(config-if)# no shut
PIX(config-if)# exit
PIX(config)# interface e1
PIX(config-if)# nameif OUTSIDE
PIX(config-if)# security-level 0
PIX(config-if)# ip address 2.2.2.1 255.255.255.252
PIX(config-if)# description UPLINK ZU INTERNET ROUTER Fe1/0
PIX(config-if)# no shutDas 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...
INTRANET#ping 2.2.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.1, timeout is 2 seconds:
.....
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...
INTRANET#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/30 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, FastEthernet1/0Aha! 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
ip route <zielnetz> <zielsubnetzmaske> <Next-Hop-IP-Adresse>Auf dem INTRANET Router setzen wir die Default Route folgender maßen:
INTRANET(config)#ip route 0.0.0.0 0.0.0.0 1.1.1.2Auch auf dem INTERNET Router setzen wir eine statische Route damit die Pakete den Weg ins Netz 1.1.1.0/30 finden können.
INTERNET(config)#ip route 1.1.1.0 255.255.255.252 2.2.2.2Wir 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
PIX(config)# access-list OUTSIDE_IN permit icmp any anySo 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!
PIX(config)# interface ethernet 1
PIX(config-if)# access-group OUTSIDE_IN in interface OUTSIDEUnd 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?
PIX(config)# access-list OUTSIDE_IN permit tcp any host 10.10.10.10 eq 80
PIX(config)# access-list OUTSIDE_IN permit tcp any host 10.10.10.10 eq 443
PIX(config)# access-list OUTSIDE_IN deny any any
PIX(config)#interface ethernet 1
PIX(config-if)#access-group OUTSIDE_IN in interface OUTSIDE
PIX(config-if)#exit
PIX#write memoryDie 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).PIX(config)#interface ethernet 2
PIX(config-if)#shutdown
PIX(config-if)#exitSetzen 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".
PIX>
PIX> ena
PIX>password ******
PIX#
PIX#conf t
PIX(config)# enable password pa55w0rd level 15Wenn 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.
PIX>Um in den "Privileged Mode" zu gelangen muss man den Befehl "enable" eingeben.
PIX>enable
PIX>Password *******
PIX#Lokale Admin-User anlegen
PIX# conf t
PIX(config)# username admin password pa55w0rd privilege 15Management Zugriff beschränken
PIX(config)# management-access INSIDESSH 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.
PIX(config)# crypto key generate rsa general-keys modulus 2048
PIX(config)# ssh 10.10.10.0 255.255.255.0 INSIDE
PIX(config)# aaa authentication ssh console LOCALIdle-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.PIX(config)# console timeout 10
PIX(config)# ssh timeout 10Router 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
router#copy running-config startup-configLokales Config Backup Cisco PIX
PIX#write memoryBackup der Config auf einen TFTP Server
PIX(config)# copy run tftp:{{comment_single_line_double_slash:0}}Widerherstellen der Config von einem TFTP Server
PIX(config)#copy tftp:{{comment_single_line_double_slash:0}}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.
PIX# packet-tracer input INSIDE icmp 1.1.1.1 1 1 2.2.2.1
Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 2.2.2.0 255.255.255.252 OUTSIDE
Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 240, packet dispatched to next module
Phase: 6
Type: ROUTE-LOOKUP
Subtype: output and adjacency
Result: ALLOW
Config:
Additional Information:
found next-hop 2.2.2.1 using egress ifc OUTSIDE
adjacency Active
next-hop mac address ca01.0b54.001c hits 35
Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: allow
PIX#
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 89044
Url: https://administrator.de/contentid/89044
Ausgedruckt am: 21.11.2024 um 19:11 Uhr
