134058
15.08.2017, aktualisiert am 17.08.2017
4929
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 27444Wie 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!
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: 346364
Url: https://administrator.de/forum/cisco-zone-based-firewall-stateful-packet-inspection-mit-nat-ipv4-zusaetzliche-acls-sinnvoll-346364.html
Ausgedruckt am: 22.12.2024 um 18:12 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
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,
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
Meine Hausaufgaben kann ich schon selber. 
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?
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
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!
Da habe ich wohl doch zu wenig Angaben geliefert. Also von LAN -> WAN per ZBFW freigegeben sind:
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:
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:
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:
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!
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.
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
exitUDP 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 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
10 deny ip 0.0.0.0 0.255.255.255 any log
20 deny ip 10.0.0.0 0.255.255.255 any log
30 deny ip 100.64.0.0 0.63.255.255 any log
40 deny ip 127.0.0.0 0.255.255.255 any log
50 deny ip 169.254.0.0 0.0.255.255 any log
60 deny ip 172.16.0.0 0.15.255.255 any log
70 deny ip 192.0.0.0 0.0.0.255 any log
80 deny ip 192.0.2.0 0.0.0.255 any log
90 deny ip 192.168.0.0 0.0.255.255 any log
100 deny ip 198.18.0.0 0.1.255.255 any log
110 deny ip 198.51.100.0 0.0.0.255 any log
120 deny ip 203.0.113.0 0.0.0.255 any log
130 deny ip 224.0.0.0 31.255.255.255 any log
140 permit icmp any any administratively-prohibited
150 permit icmp any any packet-too-big
160 permit icmp any any time-exceeded
170 permit icmp any any unreachable
180 permit icmp any any echo-reply
190 deny icmp any any log
200 permit ip any any
exit"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:
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)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
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...Zitat von @aqui:
Return Traffic kommt nur durch zu den etablierten Sessions. Niemals aber kann er von außen initiiert werden.
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. 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.
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.(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...
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.
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,
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 @brammer:
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
Etwas Wunschdenken? Hallo,
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
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. 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.
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.
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:
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 ;)
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
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.
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
exitDamit 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.
