134058
15.08.2017, aktualisiert am 17.08.2017
4855
20
0
Cisco Zone Based Firewall (stateful packet inspection) mit NAT, IPv4 - zusätzliche ACLs sinnvoll?
Hallo liebe Damen und Herren im Forum!
Offensichtlich bin ich dann mal die Neue und grüße euch alle ganz herzlich! Natürlich habe ich mich angemeldet um zu fragen. (Aber auch, um anderen zu helfen - so ich kann.)
Problem:
Ich habe einen Cisco 891F (IOS 15.4) sicher zu konfigurieren. Cisco Zone Based Firewall ist fertig und fuktioniert.
Nun frage ich euch, inwiefern zusätzliche Access-Lists zu Stateful Packet Inspection der ZBFW mit NAT (IPv4) sinnvoll/erforderlich sind. Ich stehe gedanklich etwas auf dem Schlauch und brauche paar Anregungen, "Schubse" in die richtige Richtung.
Konkret zum WAN-Interface des Cisco 891F:
1.
Ist eine zusätzliche ACL inbound gegen Bogon Networks (reservierte und private) heutzutage mit SPI/ZBFW und NAT noch sinvoll? ACL etwa so: https://www.seanmancini.com/index.php/2012/12/22/applying-bogon-access-l ...
Eigentlich sind ja durch NAT und ZBFW/SPI nur Verbindungen LAN--> Internet möglich?! IP-Spoofing mit ZBFW/SPI/NAT überhaupt möglich? https://de.wikipedia.org/wiki/IP-Spoofing
2.
Ist eine zusätzliche ACL outbond gegen (alt-) bekannte Exploits noch sinnvoll? Also etwa so nach https://www.sans.org/reading-room/whitepapers/firewalls/egress-filtering ...
3. Ist eine zusätzliche ACL inbound gegen alte DOS-Angriffe noch sinnvoll? Etwa so:
nach: https://www.sans.org/reading-room/whitepapers/networkdevs/easy-steps-cis ...
Wie kommt Mann/Frau zu aktuellen "Best Practices"? (IDS/IPS-System ist für die Firma nicht akzeptabel.)
4. Existiert eine "Best Practice" für eine Routerkonfiguration mit Hosts, die nicht unbedingt Angriffsziel sind. Also eine kleine Firma hinter Cisco 891F (IOS 15.4) mit ZBFW/SPI und NAT und ohne öffentlich erreichbare Server. Link auf aktuelle "Best Practices"wäre nett.
Ich habe ein Problem mit ZBFW und alten Empfehlungen für ACLs. Wo finde ich aktuelle Empfehlungen für ZBFW gegen aktuelle Angriffe von innen (eventuelle Viren, "quatschende" Smartphones) und außen (DoS)? Klar, man hält Hosts im LAN sauber - aber ich will wissen, wenn die "dreckig" sind (Logs von ACLs) - um sie notfalls sauber zu machen.
Erst mal danke für das Lesen/Gedankenmachen über mein Anliegen!
Offensichtlich bin ich dann mal die Neue und grüße euch alle ganz herzlich! Natürlich habe ich mich angemeldet um zu fragen. (Aber auch, um anderen zu helfen - so ich kann.)
Problem:
Ich habe einen Cisco 891F (IOS 15.4) sicher zu konfigurieren. Cisco Zone Based Firewall ist fertig und fuktioniert.
Nun frage ich euch, inwiefern zusätzliche Access-Lists zu Stateful Packet Inspection der ZBFW mit NAT (IPv4) sinnvoll/erforderlich sind. Ich stehe gedanklich etwas auf dem Schlauch und brauche paar Anregungen, "Schubse" in die richtige Richtung.
Konkret zum WAN-Interface des Cisco 891F:
1.
Ist eine zusätzliche ACL inbound gegen Bogon Networks (reservierte und private) heutzutage mit SPI/ZBFW und NAT noch sinvoll? ACL etwa so: https://www.seanmancini.com/index.php/2012/12/22/applying-bogon-access-l ...
Eigentlich sind ja durch NAT und ZBFW/SPI nur Verbindungen LAN--> Internet möglich?! IP-Spoofing mit ZBFW/SPI/NAT überhaupt möglich? https://de.wikipedia.org/wiki/IP-Spoofing
2.
Ist eine zusätzliche ACL outbond gegen (alt-) bekannte Exploits noch sinnvoll? Also etwa so nach https://www.sans.org/reading-room/whitepapers/firewalls/egress-filtering ...
ip access-list extended Traffic-to-Internet
20 deny tcp any any range 135 139 log
30 deny udp any any range 135 139 log
!MS RPC, NETBIOS
40 deny tcp any any 445 log
!SMB/IP
50 deny udp any any 6 log
!TFTP
60 deny udp any any 514 log
!Syslog
70 deny udp any any range 161 162 log
!SNMP
80 deny tcp any any 25 log
!SMTP
90 deny tcp any any range 6660 6669 log
!IRC
100 deny tcp any any range 1027 1032 log
110 deny tcp any any 5190
!ICQ
120 deny tcp any any 25 log
!SMTP
130 permit ip 192.168.139.32 0.0.0.31
!erlaubt Hosts von .33 bis .62 (.33 = Gateway des Providers)
140 deny ip any any log
exit
2. Block well known Distributed Denial Of Service (DDOS) ports:
2.1 Serbian badman/backdoor.subseven21 (6669/tcp, 2222/tcp, 7000/tcp)
2.2 Subseven (16959/tcp, 27374/tcp, 6711/tcp, 6712/tcp, 6776/tcp)
2.3 Stacheldrant (16660/tcp, 65000/tcp)
2.4 Trinoo communication ports (27665/tcp, 31335/udp and 27444/udp)
2.5 Trinity v 3 (33270/tcp, 39168/tcp)
Example of inbound access list:
access-list
1xx deny tcp any any eq 16959
access-list 1xx deny udp any any eq 27444
Wie kommt Mann/Frau zu aktuellen "Best Practices"? (IDS/IPS-System ist für die Firma nicht akzeptabel.)
4. Existiert eine "Best Practice" für eine Routerkonfiguration mit Hosts, die nicht unbedingt Angriffsziel sind. Also eine kleine Firma hinter Cisco 891F (IOS 15.4) mit ZBFW/SPI und NAT und ohne öffentlich erreichbare Server. Link auf aktuelle "Best Practices"wäre nett.
Ich habe ein Problem mit ZBFW und alten Empfehlungen für ACLs. Wo finde ich aktuelle Empfehlungen für ZBFW gegen aktuelle Angriffe von innen (eventuelle Viren, "quatschende" Smartphones) und außen (DoS)? Klar, man hält Hosts im LAN sauber - aber ich will wissen, wenn die "dreckig" sind (Logs von ACLs) - um sie notfalls sauber zu machen.
Erst mal danke für das Lesen/Gedankenmachen über mein Anliegen!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 346364
Url: https://administrator.de/contentid/346364
Ausgedruckt am: 09.11.2024 um 01:11 Uhr
20 Kommentare
Neuester Kommentar
Hallo,
Generell gilt mal, solange wir den Rest der config nicht kennen ist das nicht mit ja oder nein zu beantworten.
Bei ACL's, zumindest bei Cisco, gilt aber das am Ende immer ein 'deny any any' steht. Ob du es nun schreibst oder nicht.
Daher ist die Bogon ACL eigentlich sinnlos, unter der Annahme das der Rest deiner config sauber ist. Und das gilt inbound wie Outbound.
Brammer
Generell gilt mal, solange wir den Rest der config nicht kennen ist das nicht mit ja oder nein zu beantworten.
Bei ACL's, zumindest bei Cisco, gilt aber das am Ende immer ein 'deny any any' steht. Ob du es nun schreibst oder nicht.
Daher ist die Bogon ACL eigentlich sinnlos, unter der Annahme das der Rest deiner config sauber ist. Und das gilt inbound wie Outbound.
Brammer
Hallo,
Sorry, aber ich werde nicht deine Hausaufgaben machen.
Wenn du inbound nur explizit zulässt was du erlauben willst, also in deiner ACL steht und Outbound genauso.... wieso verbietest du dann explizit...
Hier gilt ganz einfach die Regel erlaube was du erlauben musst.... alles andere ist verboten....
Deny any any verbietet alles was nicht explizit erlaubt ist.
Brammer
Nimm eine saubere Konfiguration an und
begründe bitte ersten Teilsatz und letzten Satz!
begründe bitte ersten Teilsatz und letzten Satz!
Sorry, aber ich werde nicht deine Hausaufgaben machen.
Wenn du inbound nur explizit zulässt was du erlauben willst, also in deiner ACL steht und Outbound genauso.... wieso verbietest du dann explizit...
Hier gilt ganz einfach die Regel erlaube was du erlauben musst.... alles andere ist verboten....
Deny any any verbietet alles was nicht explizit erlaubt ist.
Brammer
Hallo,
Okay, dann nochmal die Frage wieso willst du etwas explizit verbieten obwohl es schon generell verboten Ist?
Das wäre als ob du auf der Autobahn rechts überholen für Fahrzeuge mit weniger als 100 PS verbietet. Obwohl rechts überholen generell schon verboten ist.
Was passiert den in der Praxis?
Du konstruierst ein Regelwerk in dem du jeweils einzeln Protokolle verbreitest.
Wenn du aber nur das erlaubst was du zwingend brauchst und alles andere durch deny any any verboten ist, hast du mit weniger Konfigurationsaufwand erreicht was du willst.
Das einzige was du damit erreichst ist das deine Firewall mehr zu tun hat... was kontraproduktiv ist.
Interessant wird das Konzept erst wenn du Traffic, unabhängig davon ob inbound oder outbound, in Teile deines internen Netzes zulassen musst (inbound oder outbound) dann kannst du mit deinem Konzept erreichen was du willst. Beispielsweise wenn du Telnet für Wartungszwecke zulassen musst.... dann lässt du das halt nur von einer Source zu einer Destination mit nur 2 Ports zu.... das kann man mit ACL's absichern.... wobei ich das anders machen würde.
Brammer
Okay, dann nochmal die Frage wieso willst du etwas explizit verbieten obwohl es schon generell verboten Ist?
Das wäre als ob du auf der Autobahn rechts überholen für Fahrzeuge mit weniger als 100 PS verbietet. Obwohl rechts überholen generell schon verboten ist.
Was passiert den in der Praxis?
Du konstruierst ein Regelwerk in dem du jeweils einzeln Protokolle verbreitest.
Wenn du aber nur das erlaubst was du zwingend brauchst und alles andere durch deny any any verboten ist, hast du mit weniger Konfigurationsaufwand erreicht was du willst.
Das einzige was du damit erreichst ist das deine Firewall mehr zu tun hat... was kontraproduktiv ist.
Interessant wird das Konzept erst wenn du Traffic, unabhängig davon ob inbound oder outbound, in Teile deines internen Netzes zulassen musst (inbound oder outbound) dann kannst du mit deinem Konzept erreichen was du willst. Beispielsweise wenn du Telnet für Wartungszwecke zulassen musst.... dann lässt du das halt nur von einer Source zu einer Destination mit nur 2 Ports zu.... das kann man mit ACL's absichern.... wobei ich das anders machen würde.
Brammer
ACLs brauchst du nur wenn du z.B. Zugriff auf VPN Funktionen des Routers benötigst oder z.B. der Router auch NTP Server ist.
Alles andere löst die Application aware Firewall der ZFW.
Details dazu findest du wie immer im hiesigen Cisco Tutorial:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Alles andere löst die Application aware Firewall der ZFW.
Details dazu findest du wie immer im hiesigen Cisco Tutorial:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Vielleicht nochmal die Grundlagen zu ZBF lesen. Lieber zuviel Gedanken, als zu wenig ;)
source:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configura ...
-When an interface is a member of a security zone, all traffic to and from that interface is blocked unless you configure an explicit interzone policy on a zone pair involving that zone.
-Traffic cannot flow between an interface that is a member of a security zone and an interface that is not a member of a security zone because a policy can be applied only between two zones.
&
-An ACL on an interface that is a zone member should not be restrictive (strict)
have fun
source:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configura ...
-When an interface is a member of a security zone, all traffic to and from that interface is blocked unless you configure an explicit interzone policy on a zone pair involving that zone.
-Traffic cannot flow between an interface that is a member of a security zone and an interface that is not a member of a security zone because a policy can be applied only between two zones.
&
-An ACL on an interface that is a zone member should not be restrictive (strict)
have fun
Weitere Protokolle wegen Tests. telnet, who ...
Hier hast du wohl einen gehörigen Denkfehler. Diese Protkolle werden keineswegs "freigegeben" sondern lediglich stateful inspiziert.Return Traffic kommt nur durch zu den etablierten Sessions. Niemals aber kann er von außen initiiert werden.
Lies dir dazu nochmal den ZFW Design Guide durch, da ist alles explizit erklärt !
Somit möchte ich outgoing per ACL auf WAN-Interface zusätzlich einschränken:
Das macht man wenn überhaupt mit einer inbound ACL auf dem LAN Port wo man diese Ports blockt damit sie nicht ins Internet kommen.Incoming möchte ich nur "sichere" ICMP-Antworten zulassen (ACL unten),
Das tust du ja schon da du ICMP in die Inspection aufgenommen hast. Diese ICMP ACL ist damit sinnfrei.Dein ganzes Konzept klingt etwas wirr weil du scheinbar nicht richtig verstanden hast wie die ZFW funktioniert und intern arbeitet. Der Design Guide ist da erste Anlaufstelle.
Oder mache ich mir viel zu viele Gedanken auf Grund alter Dokumente
Eindeutig ja...
ICMP redirects sollte man dann, outgoing auf dem internen interface per acl verbieten und alles andere erlauben.
Incoming auf dem WAN interface geht zwar auch, beißt sich aber mit der ZBF bzw macht es kompliziert, da man dann allen anderen Traffic erlauben müsste, damit die ZBF ihren Job machen kann.
so long...
Incoming auf dem WAN interface geht zwar auch, beißt sich aber mit der ZBF bzw macht es kompliziert, da man dann allen anderen Traffic erlauben müsste, damit die ZBF ihren Job machen kann.
so long...
Hallo,
Diese Adressbereich sind im "Internet nicht routingfähig.
Damit Pakete aus diesen Adressbereichen kommen könnten müssten dein Provider diese Pakete ja zu dir routen. Wieso sollte er das machen?
Brammer
Komisch, dass Bogon- und private Netzwerke
nach eurer einhelligen Ansicht nicht explizit
gesperrt werden.
nach eurer einhelligen Ansicht nicht explizit
gesperrt werden.
Diese Adressbereich sind im "Internet nicht routingfähig.
Damit Pakete aus diesen Adressbereichen kommen könnten müssten dein Provider diese Pakete ja zu dir routen. Wieso sollte er das machen?
Brammer
Tatsächlich kann man das ganze auch mit ZBF realisieren. In der pol out-in/out-self den traffic einfach droppen. Habe leider keinen Hinweis zur Priorität der Abarbeitung gefunden(Als Beleg). Aber es macht Sinn das zuerst die OUT-IN pol und dann die IN-OUT CONNECTION-SESSIONS angewendet werden.
Hier mal ein Beispiel wie es für icmp zum router (self zone) realisiert wurde:
http://www.dslreports.com/faq/15839
Wobei man, wenn es um die self-zone geht, das nach dem ZBF Guide eigentlich über CoPP realisieren sollte.
Was die Bogon Netze betrifft habe ich folgendes gefunden:
https://www.ifconfig.it/hugo/post/2016-03-28-dropbogons/
Wobei ich mir vorstellen kann das dem Cisco 891F da schnell die Puste ausgeht ;)
Was address spoofing in deinem eigenen Netz angeht kannst du dir ja mal uRPF anschauen
So long...
Hier mal ein Beispiel wie es für icmp zum router (self zone) realisiert wurde:
http://www.dslreports.com/faq/15839
Wobei man, wenn es um die self-zone geht, das nach dem ZBF Guide eigentlich über CoPP realisieren sollte.
Was die Bogon Netze betrifft habe ich folgendes gefunden:
https://www.ifconfig.it/hugo/post/2016-03-28-dropbogons/
Wobei ich mir vorstellen kann das dem Cisco 891F da schnell die Puste ausgeht ;)
Was address spoofing in deinem eigenen Netz angeht kannst du dir ja mal uRPF anschauen
So long...
Zitat von @134058:
Wobei man, wenn es um die self-zone geht, das nach dem ZBF Guide eigentlich über CoPP realisieren sollte.
Guter Hinweis: Habe darufhin White Papers gefunden:
https://www.cisco.com/c/en/us/products/collateral/security/ios-network-f ...
sowie ein Dokument speziell zu ICMP und ZBFW:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configura ...
Entsprechend "Table 1 ICMPv4 Packet Types" werden nicht alle ICMP-Typen bearbeitet. Wo ACL 102 eingesetzt wird, finde ich nicht. Dokument bezieht sich auch nicht auf IOS15.4.
Zitat von @TheMasterofdisaster:
Tatsächlich kann man das ganze auch mit ZBF realisieren. In der pol out-in/out-self den traffic einfach droppen. Habe leider keinen Hinweis zur Priorität der Abarbeitung gefunden(Als Beleg). Aber es macht Sinn das zuerst die OUT-IN pol und dann die IN-OUT CONNECTION-SESSIONS angewendet werden.
Hier mal ein Beispiel wie es für icmp zum router (self zone) realisiert wurde:
http://www.dslreports.com/faq/15839
Danke für die ausführliche Vorlage. Lesezeichen gespeichert. Tatsächlich kann man das ganze auch mit ZBF realisieren. In der pol out-in/out-self den traffic einfach droppen. Habe leider keinen Hinweis zur Priorität der Abarbeitung gefunden(Als Beleg). Aber es macht Sinn das zuerst die OUT-IN pol und dann die IN-OUT CONNECTION-SESSIONS angewendet werden.
Hier mal ein Beispiel wie es für icmp zum router (self zone) realisiert wurde:
http://www.dslreports.com/faq/15839
Wobei man, wenn es um die self-zone geht, das nach dem ZBF Guide eigentlich über CoPP realisieren sollte.
https://www.cisco.com/c/en/us/products/collateral/security/ios-network-f ...
sowie ein Dokument speziell zu ICMP und ZBFW:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configura ...
Entsprechend "Table 1 ICMPv4 Packet Types" werden nicht alle ICMP-Typen bearbeitet. Wo ACL 102 eingesetzt wird, finde ich nicht. Dokument bezieht sich auch nicht auf IOS15.4.
Eine Anwendung der 102 ACL kann ich auch nicht finden. In den Steps wird diese auch nicht erwähnt...Ich denke die acl wurde zur Überprüfung/Bestätigung auf dem internen Interface ausgehend benutzt (siehe src/dst und matches)
Was die Bogon Netze betrifft habe ich folgendes gefunden:
https://www.ifconfig.it/hugo/post/2016-03-28-dropbogons/
Wobei ich mir vorstellen kann das dem Cisco 891F da schnell die Puste ausgeht ;)
Elegant, Import von aktuellen Dateien. Wobei ich meine, ACLs tun es auch. Einträge/Austräge sind schnell getätigt.https://www.ifconfig.it/hugo/post/2016-03-28-dropbogons/
Wobei ich mir vorstellen kann das dem Cisco 891F da schnell die Puste ausgeht ;)
ACLs kann man ja gut in ZBFW integrieren:
Sequentielle Mehrfach-Inspektion (First Match): https://networklore.com/zone-based-firewall-basic-configuration/
Verkettete Mehrfachinspektion Protokolle (Any) + ACLs (Any) -> (Match All):
https://aitaseller.wordpress.com/2012/11/05/cisco-zone-based-firewall/
(ZBF policy 2)
Jedenfalls funktioniert eine ACL inbound auf WAN bestens und wird vor ZBFW abgearbeitet. Outbound ACL auf WAN habe ich noch nicht getestet, logisch erscheint mir eine Abarbeitung nach ZBFW-Inspektion. Für elegant halte ich nach wie vor den Einsatz von ACLs auf WAN-Interface bei erwünschter Wirkung auf ALLE Zonen und Schutz vor ZBFW-Konfigurationsfehlern. ZBFW-Konfig ist wegen der Mappings und Beachtung von mindestens 2 Zonen + self-Zone (= 6 Paare) nicht unbedingt übersichtlich.
Klar sind ACL's einfacher zu lesen aber in der Handhabung umständlicher. Was ZBF betrifft gibt es ein nützlichen Befehl "show policy-map type inspect zone-pair XYZ".
Was address spoofing in deinem eigenen Netz angeht kannst du dir ja mal uRPF anschauen
Werde ich mir ansehen, damit habe ich noch nicht gearbeitet: https://www.cisco.com/c/en/us/about/security-center/unicast-reverse-path ...Eine Alternative zu ZBFW und ACLs bezüglich Bogon Networks sind wohl entsprechende Routen zu einem Null-Interface (geringer CPU-Overhead): http://www.w3service.net/ccna_zertifizierung/INFOs/sem2/Access-Listen-0 ...
(Seite 19) und beachten:
"Q. Does NAT occur before or after routing?
A. The order in which the transactions are processed using NAT is based on whether a packet is going from the inside network to the outside network or from the outside network to the inside network. Inside to outside translation occurs after routing, and outside to inside translation occurs before routing. Refer to NAT Order of Operation for more information. "
https://www.cisco.com/c/en/us/support/docs/ip/network-address-translatio ...
Vergleichen:
show ip nat translations
show ip route
So long...
Herzlichen Dank! Kannst ja noch mal was zum Text sagen ...Dritte interessiert der Thread vlt. auch irgendwann. Deshalb meine Links.
Edit
Unterdrücken Bogon:
"When administrators use Unicast RPF in loose mode, the source address must appear in the routing table. Administrators can change this behavior using the allow-default option, which allows the use of the default route in the source verification process. Additionally, a packet that contains a source address for which the return route points to the Null 0 interface will be dropped. An access list may also be specified that permits or denies certain source addresses in Unicast RPF loose mode.
...
Unicast RPF loose mode can be used on an uplink network interface that has a default route associated with it.
...
Addresses that should never appear on a network can be dropped by entering a route to a null interface. The following command will cause all traffic received from the 10.0.0.0/8 network to be dropped even if Unicast RPF is enabled in loose mode with the allow-default option: ip route 10.0.0.0 255.0.0.0 Null0"
https://www.cisco.com/c/en/us/about/security-center/unicast-reverse-path ...
Dies müsste meinem Fall (WAN-If = DHCP-Client + NAT) mit Default-Route und privater WAN-IP entsprechen.
Klar, machbar...route>>dev0 in Kombination mit uRPF kann dazu verwendet werden unerwünschte Pakete anhand der src zu verwerfen. Aber auch hier, eine weitere Fehlerquelle. Ich würde von solchen gefriggel abstand nehmen. Nach zwei Jahren kann das keiner mehr Nachvollziehen. Lieber klare Strukturen, eine Anlaufstelle für ein Aufgabenberreich. Wenn man eh ZBF am laufen hat, kein Performance Gewinn ,eher das Gegenteil, längere Routingtabelle und einen zusätzlichen Dienst.
Hab uRPF nur erwähnt, weil ich dachte es könnte dich interessieren. Bei einem internen Netz jetzt nicht unbedingt super sinnvoll ;)
Have fun ;)