Aug 15, 2017, updated at Aug 17, 2017 (UTC)

4655

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 ...

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 

3. Ist eine zusätzliche ACL inbound gegen alte DOS-Angriffe noch sinnvoll? Etwa so:

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

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!

Please also mark the comments that contributed to the solution of the article

Content-Key: 346364

Url: https://administrator.de/contentid/346364

Printed on: April 23, 2024 at 18:04 o'clock

20 Comments

Latest comment

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

Hallo,

Hier noch ein link zum Cisco Guide to Harden Cisco IOS Devices

Brammer

Zitat von @brammer:

Generell gilt mal, solange wir den Rest der config nicht kennen ist das nicht mit ja oder nein zu beantworten.

Geht um Konzeptionen. Konfiguration leicht änderbar und unabhängig von vorgeschlagenen Konzeptionen.

Bei ACL's, zumindest bei Cisco, gilt aber das am Ende immer ein 'deny any any' steht. Ob du es nun schreibst oder nicht.

Ist bekannt.

Daher ist die Bogon ACL eigentlich sinnlos, unter der Annahme das der Rest deiner config sauber ist. Und das gilt inbound wie Outbound.

Nimm eine saubere Konfiguration an und begründe bitte ersten Teilsatz und letzten Satz!

> Hier noch ein link zum Cisco Guide to Harden Cisco IOS Devices ...

Ebenfalls bekannt. Welchen Absatz des Dokumentation bezüglich meiner Fragen meinst du genau - oder warum der Link auf ein Gesamtdokument/Introduction? Link so nicht hilfreich.

Hallo,

Nimm eine saubere Konfiguration an und
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

Meine Hausaufgaben kann ich schon selber.

Wenn du inbound nur explizit zulässt was du erlauben willst, also in deiner ACL steht und Outbound genauso.... wieso verbietest du dann explizit...

Mir geht es darum, die konfigurierte Zone Based Firewall (SPI+NAT) mit ACLs auf WAN-Interface eventuell weiter (inbound+outbound, bogon/DoS) einzuschränken. Siehe 1. Beitrag. ACLs sind feiner granulierbar als ZBFW (dort vorrangig Protokolle) insbesondere Quelladressen (bogon) auf WAN inbound und spezielle Port-Sperren zum Log eventueller Virentaetigkeit outbound.

Mir geht es rein darum, deine/eure Ansichten für ZBFW + Kombination mit ACLs dazu zu lesen. Konzeption halt, Konfiguration passe ich entsprechend plausibel begründeter Antworten/Links an.

Vielleicht liest du noch mal den 1. Beitrag?

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

Guten Morgen brammer! Und vielen Dank für deine bisherige Mühe!

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.

Da habe ich wohl doch zu wenig Angaben geliefert. Also von LAN -> WAN per ZBFW freigegeben sind:

class-map type inspect match-any CMAP-Trusted-to-Internet-Protocols
 match protocol https
 match protocol http
 match protocol ntp
 match protocol imaps
 match protocol pop3s
! match protocol smtp
 match protocol ftps
 match protocol telnet
 match protocol who
 match protocol finger
 match protocol tcp
 match protocol udp
 match protocol icmp
exit

TCP musste ich freigeben wegen Mail-Ausgang per SSL/TLS Port 465 und weitere Gründe.
UDP wegen traceroute mit User-Rechten. Weitere Protokolle wegen Tests. telnet, who ...
Damit würde doch alles nicht vorher Inspizierte in TCP/UDP reinfallen, genehmigt sein.

Somit möchte ich outgoing per ACL auf WAN-Interface zusätzlich einschränken:

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 und DHCP-Server) -> also nur nur mögliche WAN-Adressen des Routers
 140 deny ip any any log
exit 

entsprechend Empfehlung von: https://www.sans.org/reading-room/whitepapers/firewalls/egress-filtering ...
Des Weiteren Schutz vor IP-Spoofing: Nur mögliche WAN-Adressen des Routers (vom Provider per DHCP zugewiesen) outgoing erlaubt:
130 permit ip 192.168.139.32 0.0.0.31

Incoming möchte ich nur "sichere" ICMP-Antworten zulassen (ACL unten), sowie keine Adressen, die im LAN verwendet werden. Da kann ich auch gleich noch alle privaten und Bogon-NWs sperren:

ip access-list extended Traffic-from-Internet
deny ip 0.0.0.0 0.255.255.255 any log
deny ip 10.0.0.0 0.255.255.255 any log
deny ip 100.64.0.0 0.63.255.255 any log
deny ip 127.0.0.0 0.255.255.255 any log
deny ip 169.254.0.0 0.0.255.255 any log
deny ip 172.16.0.0 0.15.255.255 any log
deny ip 192.0.0.0 0.0.0.255 any log
deny ip 192.0.2.0 0.0.0.255 any log
deny ip 192.168.0.0 0.0.255.255 any log
deny ip 198.18.0.0 0.1.255.255 any log
deny ip 198.51.100.0 0.0.0.255 any log
deny ip 203.0.113.0 0.0.0.255 any log
deny ip 224.0.0.0 31.255.255.255 any log
permit icmp any any administratively-prohibited 
permit icmp any any packet-too-big
permit icmp any any time-exceeded
permit icmp any any unreachable
permit icmp any any echo-reply
deny icmp any any log
permit ip any any
exit

Damit sollte kein IP-Spoofing möglich sein, zumindest erschwert werden:
"Paketfilter sind eine mögliche Gegenmaßnahme gegen IP-Spoofing. Das Gateway zu einem Netzwerk sollte eine eingehende Filterung vornehmen: Von außen kommende Pakete, die Quelladressen von innenliegenden Rechnern haben, werden verworfen. Dies verhindert, dass ein externer Angreifer die Adresse einer internen Maschine fälschen kann. Idealerweise sollten auch ausgehende Pakete gefiltert werden, wobei dann Pakete verworfen werden, deren Quelladresse nicht innerhalb des Netzwerks liegt; dies verhindert, dass IP-Adressen von externen Maschinen gespooft werden können ..."
https://de.wikipedia.org/wiki/IP-Spoofing

Bleibt noch die letzte Frage nach Sinn bzw. Logs weiterer Portsperren (Inbound/outbound) bekannter Malware (evtl. im LAN) trotz ZBFW/SPI und NAT. Also etwa so:

 
Block well-known Distributed Denial Of Service (DDOS) ports:
1 Serbian badman/backdoor.subseven21 (6669/tcp, 2222/tcp, 7000/tcp)
2 Subseven (16959/tcp, 27374/tcp, 6711/tcp, 6712/tcp, 6776/tcp)
3 Stacheldrant (16660/tcp, 65000/tcp)
4 Trinoo communication ports (27665/tcp, 31335/udp and 27444/udp) 
5 Trinity v 3 (33270/tcp, 39168/tcp)

Wobei die Empfehlung von https://www.sans.org/reading-room/whitepapers/networkdevs/easy-steps-cis ...
aus 2001 stammt und mich aktuelle Links auf "Best Practices" der Praktiker interessieren.

Oder mache ich mir viel zu viele Gedanken auf Grund alter Dokumente (vor Cisco ZBFW) und Praktiker wissen mehr?

Also erst mal danke 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

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

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...

Zitat von @aqui:

Weitere Protokolle wegen Tests. telnet, who ...

Sorry, falsche Wortwahl meinerseits. Mit "freigegeben" meinte ich den Eintrag in der Liste zu inspizierender Protokolle. Ohne Eintrag ist ja auch kein von innen initiierter Traffic für das fehlende Protokoll möglich.

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.

Okay, ich lasse die ACLs weg. Evtl. für LAN inbound.

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.

Frage: Angenommen, ein Host im LAN sendet an einen "bösen" Host im Internet ICMP-Anfragen. Die Antworten werden auf Zugehörigkeit zur intern initierten Verbindung inspiziert (stateful). Damit werden doch auch AWs des "bösen" Internet-Hosts zugelassen, die man nicht haben möchte (ICMP Redirect, etc.)?
(Das wollte ich per ACL incoming auf WAN-If zusätzlich zur SPI der ZBFW verhindern, auf wenige ICMP-Antwort-Typen einschränken ... )

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...

Yepp. Deswegen hatte ich die ACL "Traffic-from-Internet" so geplant. Letzte Zeile erlaubt den Rest für die Policy des Zonenpaars.

Komisch, dass Bogon- und private Netzwerke nach eurer einhelligen Ansicht nicht explizit gesperrt werden. Die PFSense hat trotz SPI ein extra Häkchen dafür ... Aber gut, von WAN->LAN sind ja durch SPI (neben NAT) keine von WAN initiierten Verbindungen möglich.

Hallo,

Komisch, dass Bogon- und private Netzwerke
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...

Zitat von @brammer:

Hallo,

Komisch, dass Bogon- und private Netzwerke
nach eurer einhelligen Ansicht nicht explizit
gesperrt werden.

Etwas Wunschdenken?

Geht um die Verhinderung von IP-Spoofing, also nicht um allseits korrekte Konfigurationen.
"Paketfilter sind eine mögliche Gegenmaßnahme gegen IP-Spoofing. Das Gateway zu einem Netzwerk sollte eine eingehende Filterung vornehmen: Von außen kommende Pakete, die Quelladressen von innenliegenden Rechnern haben, werden verworfen. Dies verhindert, dass ein externer Angreifer die Adresse einer internen Maschine fälschen kann. Idealerweise sollten auch ausgehende Pakete gefiltert werden, wobei dann Pakete verworfen werden, deren Quelladresse nicht innerhalb des Netzwerks liegt; dies verhindert, dass IP-Adressen von externen Maschinen gespooft werden können und ist eine bereits lange bestehende Forderung von Sicherheitsfachleuten gegenüber Internetdienstanbietern (ISP): Wenn jeder ISP konsequent ausgehende Pakete filtern würde, die laut ihrer Quelladresse nicht aus dem eigenen Netz stammen, wäre massenhaftes IP-Spoofing (häufig in Verbindung mit Denial-of-Service-Attacken) ein wesentlich geringeres Problem als es heute im Internet ist." https://de.wikipedia.org/wiki/IP-Spoofing
Andere Dokumente empfehlen das auch für Edge-Router.

Eigene Erfahrung:
Es gibt auch (kleine WISP-) Provider auf Dörfern, die DHCP-Zugänge schaffen, wo mehrere Kunden teils nur per WLAN-Bridge an einem gemeinsamen IP-Segment des Providers "hängen". Also mehrere Kunden haben das gleiche private Netzwerk zumindest WAN-seitig und konfigurieren nicht immer korrekt. BOGON-Blocking läuft dann wenigstens auf das Blocken selbst benutzter NW im LAN (hinter NAT) hinaus. Und nein, ein Anbieterwechsel ist in manchen Dörfen unmöglich. Auch kann man/frau Konfigurationsfehler (neben aktueller und künftiger Malware) selber machen, doppelt genäht hält besser, nobody is perfect ...

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.

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.

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.
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.

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.

Zitat von @134058:

Danke für die ausführliche Vorlage. Lesezeichen gespeichert.

Wobei man, wenn es um die self-zone geht, das nach dem ZBF Guide eigentlich über CoPP realisieren sollte.

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 ;)

Das kann man so oder so sehen. ACL plus ZBF ist ein Fehlerquelle mehr die es zu checken gibt. Und bei der man die Logiken verknüpfen und die Unterschiede beachten muss. Z.B. bei ACL muss NAT nicht beachtet werden, bei ZBF schon. Wenn ich ein Sache ändere muss ich die andere gegenchecken usw usf. Bei ZBF ist die Einrichtung vielleicht ein wenig aufwendiger aber dafür im Betrieb einfacher zu handhaben. Anstatt die komplette ACL zu bearbeiten und ggf an verschiedene IP's anzupassen, können bei ZBF die Attribute einfach bearbeitet, abgeändert, kopiert und mehrfach genutzt werden. So wie ich das sehe hast du zZ. nur mit einem internen und einen externen interface zu tun, lass es mal mehr werden...

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

So long...

Herzlichen Dank! Kannst ja noch mal was zum Text sagen ...
Dritte interessiert der Thread vlt. auch irgendwann. Deshalb meine Links.

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 ;)

Hallo MasterOfDisaster,

danke für deine ausführlichen Antworten. Ich habe entsprechend deinem und anderer Rat meine Konfig. vereinfacht, ACLs auf WAN-IF entfernt. Mit uRPF habe ich folgende einfache Konfiguration gefunden:

Theorie:
https://www.digitaltut.com/unicast-reverse-path-forwarding
Konfigurationsbespiel mit ACL für WAN-IF = DHCP-Client:
http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/865- ...

WAN-IF = DHCP-Client
ACL-Check erfolgt nach fehlgeschlagener Prüfung Reverse-Route zur Quelladresse (= Ausnahme)
keine named ACL möglich

access-list 101 permit udp any eq bootps any eq bootpc
interface GigabitEthernet8
 !description "Internet"  
 ip verify unicast source reachable-via rx allow-default 101
exit

Damit werden doch elegant Pakete von extern mit Quelladressen, die intern verwendet werden, geblockt: Speziellere Rückroute zu internen, direct connected networks bevorzugt gegenüber Default-Route.

Des Weiteren Pakete von intern ohne Rückroute über interne IFs - also gespoofte IP-Adressen.

-> Strict Mode mit Prüfung Rückroute UND Quell-Interface einer Quell-Adresse.

Ich denke, gemeinsam haben wir eine elegante Lösung gefunden und danke hiermit allen Helfern! Zum Nutzen von mitlesenden Dritten habe ich nur den wesentlichsten Beitrag als Lösung gekennzeichnet.

German solved Question Routers, Routing Networks

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments

Wireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments