19
Context-Based Access Control auf Cisco 871 Router anyone?
Hallo Zusammen,
vllt kann mir ein Cisco-Spezi hiermit weiterhelfen: ich möchte auf diesem Gerät stateful-firewalling per 'ip inspect ...' nutzen, aber bisher habe ich diese option nicht erfolgreich implementieren können. Ansonsten funktioniert alles, https-surfen und mail.
Die recht ausführliche cisco-infoseite geht zwar sehr detailliert darauf ein, aber trotzdem habe ich keine erfolgreiche cbac-config schreiben können -.-
https://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configu ...
Meine LAN-Topologie:
<10.1.1.0/24>----[(vlan1)10.1.1.1-((Cisco871))-(fe4)192.168.0.11]------<192.168.0.0/24>-----[192.168.0.1-((ISP-Router))--(DHCP)] .... also doppel-nat...
Die Besonderheit in meinem Netz ist, dass ich im <lan> _kein_ DHCP nutze sowie _kein_lokales_ dns - sondern dns-over-https für web und mail.
Im Folgenden meine aktuelle config mit stateless-filterung per access-listen, ohne 'ip inspect':
ROM: System Bootstrap, Version 12.3(8r)YI4, RELEASE SOFTWARE
ROM: Cisco IOS Software, C870 Software (C870-ADVIPSERVICESK9-M), Version 12.3(8)YI2, RELEASE SOFTWARE (fc1)
!
version 12.3
no parser cache
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
no service timestamps debug uptime
no service timestamps log uptime
service password-encryption
no service dhcp
!
hostname krauter
!
boot-start-marker
boot-end-marker
!
security authentication failure rate 10 log
security passwords min-length 6
logging buffered 4096 debugging
logging console critical
enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
enable password 7 xxxxxxxxxxxxxxxxxxxxxxxxx
!
username xxxxxxxxxxxxx password 7 xxxxxxxxxxxxxxxxxxxxxxxxxxxx
aaa new-model
!
aaa authentication login local_auth local
aaa session-id common
ip subnet-zero
no ip source-route
no ip gratuitous-arps
ip cef
!
no ip bootp server
ip ips po max-events 100
login block-for 99 attempts 3 within 99
no ipv6 source-route
no ftp-server write-enable
!
interface FastEthernet0
no ip address
no cdp enable
!
interface FastEthernet1
switchport access vlan 10
no ip address
shutdown
no cdp enable
!
interface FastEthernet2
switchport access vlan 10
no ip address
shutdown
no cdp enable
!
interface FastEthernet3
switchport access vlan 20
no ip address
shutdown
no cdp enable
!
interface FastEthernet4
ip address 192.168.0.11 255.255.255.0
ip access-group WANin in
ip access-group WANout out
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
ntp disable
no cdp enable
!
interface Vlan1
ip address 10.1.1.1 255.255.255.0
ip access-group LANout out
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly
ntp disable
!
interface Vlan10
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
shutdown
!
ip classless
no ip forward-protocol nd
no ip forward-protocol udp
ip route 0.0.0.0 0.0.0.0 192.168.0.1
!
no ip http server
no ip http secure-server
ip nat inside source list LANnat interface FastEthernet4 overload
!
ip access-list extended LANnat
deny ip 10.1.1.0 0.0.0.255 host 10.1.1.1
deny ip 10.1.1.0 0.0.0.255 192.168.0.0 0.0.255.255
permit tcp 10.1.1.0 0.0.0.255 any eq 443
permit tcp 10.1.1.0 0.0.0.255 any eq 995
permit tcp 10.1.1.0 0.0.0.255 any eq 465
deny ip any any
ip access-list extended LANout
deny ip 192.168.0.0 0.0.255.255 10.1.1.0 0.0.0.255
permit tcp any eq 443 10.1.1.0 0.0.0.255 gt 1023
permit tcp any eq 995 10.1.1.0 0.0.0.255 gt 1023
permit tcp any eq 465 10.1.1.0 0.0.0.255 gt 1023
deny ip any any
ip access-list extended WANin
deny tcp any any match-all +ack +fin +psh +rst +syn +urg
deny tcp any any match-all +rst +syn
deny tcp any any match-all +fin +rst +syn
deny tcp any any match-all +ack +fin +rst +syn
deny tcp any any match-all +fin +syn
deny tcp any any match-all +ack +fin +syn
deny ip any 10.1.1.0 0.0.0.255
deny ip 192.168.0.0 0.0.255.255 host 192.168.0.11
permit tcp any eq 443 host 192.168.0.11 gt 1023 established
permit tcp any eq 995 host 192.168.0.11 gt 1023 established
permit tcp any eq 465 host 192.168.0.11 gt 1023 established
deny ip any any
ip access-list extended WANout
deny ip 10.1.1.0 0.0.0.255 any
deny ip host 192.168.0.11 192.168.0.0 0.0.255.255
permit tcp any gt 1023 any eq 443
permit tcp any gt 1023 any eq 995
permit tcp any gt 1023 any eq 465
deny ip any any
...
Bin auch dankbar für Tips, wie man den Regelsatz noch verbessern könnte ~ insbesondere auch mit funktionierendem CBAC-Firewalling. Ich weiss, dass mein 871er nicht die letzte Firmware hat, aber da ich keinen Support-Vertrag mit Cisco habe :/ ... Eine 12.5+ Firmware hätte ggf. sogar Zone-Based-Firewalling, hm ...
Grüße aus Recklinghausen
vllt kann mir ein Cisco-Spezi hiermit weiterhelfen: ich möchte auf diesem Gerät stateful-firewalling per 'ip inspect ...' nutzen, aber bisher habe ich diese option nicht erfolgreich implementieren können. Ansonsten funktioniert alles, https-surfen und mail.
Die recht ausführliche cisco-infoseite geht zwar sehr detailliert darauf ein, aber trotzdem habe ich keine erfolgreiche cbac-config schreiben können -.-
https://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configu ...
Meine LAN-Topologie:
<10.1.1.0/24>----[(vlan1)10.1.1.1-((Cisco871))-(fe4)192.168.0.11]------<192.168.0.0/24>-----[192.168.0.1-((ISP-Router))--(DHCP)] .... also doppel-nat...
Die Besonderheit in meinem Netz ist, dass ich im <lan> _kein_ DHCP nutze sowie _kein_lokales_ dns - sondern dns-over-https für web und mail.
Im Folgenden meine aktuelle config mit stateless-filterung per access-listen, ohne 'ip inspect':
ROM: System Bootstrap, Version 12.3(8r)YI4, RELEASE SOFTWARE
ROM: Cisco IOS Software, C870 Software (C870-ADVIPSERVICESK9-M), Version 12.3(8)YI2, RELEASE SOFTWARE (fc1)
!
version 12.3
no parser cache
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
no service timestamps debug uptime
no service timestamps log uptime
service password-encryption
no service dhcp
!
hostname krauter
!
boot-start-marker
boot-end-marker
!
security authentication failure rate 10 log
security passwords min-length 6
logging buffered 4096 debugging
logging console critical
enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
enable password 7 xxxxxxxxxxxxxxxxxxxxxxxxx
!
username xxxxxxxxxxxxx password 7 xxxxxxxxxxxxxxxxxxxxxxxxxxxx
aaa new-model
!
aaa authentication login local_auth local
aaa session-id common
ip subnet-zero
no ip source-route
no ip gratuitous-arps
ip cef
!
no ip bootp server
ip ips po max-events 100
login block-for 99 attempts 3 within 99
no ipv6 source-route
no ftp-server write-enable
!
interface FastEthernet0
no ip address
no cdp enable
!
interface FastEthernet1
switchport access vlan 10
no ip address
shutdown
no cdp enable
!
interface FastEthernet2
switchport access vlan 10
no ip address
shutdown
no cdp enable
!
interface FastEthernet3
switchport access vlan 20
no ip address
shutdown
no cdp enable
!
interface FastEthernet4
ip address 192.168.0.11 255.255.255.0
ip access-group WANin in
ip access-group WANout out
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
ntp disable
no cdp enable
!
interface Vlan1
ip address 10.1.1.1 255.255.255.0
ip access-group LANout out
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly
ntp disable
!
interface Vlan10
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
shutdown
!
ip classless
no ip forward-protocol nd
no ip forward-protocol udp
ip route 0.0.0.0 0.0.0.0 192.168.0.1
!
no ip http server
no ip http secure-server
ip nat inside source list LANnat interface FastEthernet4 overload
!
ip access-list extended LANnat
deny ip 10.1.1.0 0.0.0.255 host 10.1.1.1
deny ip 10.1.1.0 0.0.0.255 192.168.0.0 0.0.255.255
permit tcp 10.1.1.0 0.0.0.255 any eq 443
permit tcp 10.1.1.0 0.0.0.255 any eq 995
permit tcp 10.1.1.0 0.0.0.255 any eq 465
deny ip any any
ip access-list extended LANout
deny ip 192.168.0.0 0.0.255.255 10.1.1.0 0.0.0.255
permit tcp any eq 443 10.1.1.0 0.0.0.255 gt 1023
permit tcp any eq 995 10.1.1.0 0.0.0.255 gt 1023
permit tcp any eq 465 10.1.1.0 0.0.0.255 gt 1023
deny ip any any
ip access-list extended WANin
deny tcp any any match-all +ack +fin +psh +rst +syn +urg
deny tcp any any match-all +rst +syn
deny tcp any any match-all +fin +rst +syn
deny tcp any any match-all +ack +fin +rst +syn
deny tcp any any match-all +fin +syn
deny tcp any any match-all +ack +fin +syn
deny ip any 10.1.1.0 0.0.0.255
deny ip 192.168.0.0 0.0.255.255 host 192.168.0.11
permit tcp any eq 443 host 192.168.0.11 gt 1023 established
permit tcp any eq 995 host 192.168.0.11 gt 1023 established
permit tcp any eq 465 host 192.168.0.11 gt 1023 established
deny ip any any
ip access-list extended WANout
deny ip 10.1.1.0 0.0.0.255 any
deny ip host 192.168.0.11 192.168.0.0 0.0.255.255
permit tcp any gt 1023 any eq 443
permit tcp any gt 1023 any eq 995
permit tcp any gt 1023 any eq 465
deny ip any any
...
Bin auch dankbar für Tips, wie man den Regelsatz noch verbessern könnte ~ insbesondere auch mit funktionierendem CBAC-Firewalling. Ich weiss, dass mein 871er nicht die letzte Firmware hat, aber da ich keinen Support-Vertrag mit Cisco habe :/ ... Eine 12.5+ Firmware hätte ggf. sogar Zone-Based-Firewalling, hm ...
Grüße aus Recklinghausen
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: 559003
Url: https://administrator.de/contentid/559003
Ausgedruckt am: 25.11.2024 um 19:11 Uhr
19 Kommentare
Neuester Kommentar
Das hiesige Cisco Tutorial mit Detailinfos zu beiden Themen CBAC und ZFW Firewalling hast du genau durchgelesen und verstanden ??
Siehe auch: Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Das mit deinen ACLs ist kontraproduktiv und auch gefährlich. Besser ist ein CBAC oder ZFW Konzept mit richtigem SPI Firewalling zu nutzen was du mit einfachen ACLs schlicht nicht hast.
Das Tutorial erklärt dir für beide Verfahren genau wie.
Siehe auch: Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Das mit deinen ACLs ist kontraproduktiv und auch gefährlich. Besser ist ein CBAC oder ZFW Konzept mit richtigem SPI Firewalling zu nutzen was du mit einfachen ACLs schlicht nicht hast.
Das Tutorial erklärt dir für beide Verfahren genau wie.
aber da ich keinen Support-Vertrag mit Cisco habe
Einfach mal bei Dr. Google nach dem Image Dateinamen suchen. 
scheint für mich nicht zu funktionieren - in bleibe bei meiner oben genannten konfig (zumal hinter einem stateful-nat-router des isp..)
ip inspect name fw tcp time-out 10
fa4
ip access-list wanout out
ip inspect fw out
es gibt matches für die accesliste, aber das wars auch schon... sh ip inspect all zeigt mir ständig nur an, dass eine session initiert wurde, aber es wird kaum eine seite geladen - oder nach gefühlt minuten ...
Session 82A14D54 (10.1.1.12:53270)=>(52.85.104.110:443) tcp SIS_OPEN (unabhängig davon ob inspect in oder outbound..)
meine vermutung: dieser alte router will die tls1.2 verbindungen inspizieren, _obwohl_ ich nur generic-tcp fahre? *kopfkratz
ich habe ehrlich gesagt keine lust mehr auf diesen 871...
schaue mich derweil nach einer asa5505 um. sollte man vllt eine bestimmte hw-version bevorzugen? auf ebay werden v02 bis v16 verkauft *augenroll
thx & grüße
ps: für mich soll eine firewall gar kein deep-packet-inspection machen, sondern sich nur um die verbindungsrichtungen kümmern, bis osi-layer4. dpi macht keinen sinn, da ich nur ssl/tls fahre inkl. encrypted-sni.
pps: ist mein dritter tag mit diesem router, hatte davor keine cisco cli-erfahrung...
ip inspect name fw tcp time-out 10
fa4
ip access-list wanout out
ip inspect fw out
es gibt matches für die accesliste, aber das wars auch schon... sh ip inspect all zeigt mir ständig nur an, dass eine session initiert wurde, aber es wird kaum eine seite geladen - oder nach gefühlt minuten ...
Session 82A14D54 (10.1.1.12:53270)=>(52.85.104.110:443) tcp SIS_OPEN (unabhängig davon ob inspect in oder outbound..)
meine vermutung: dieser alte router will die tls1.2 verbindungen inspizieren, _obwohl_ ich nur generic-tcp fahre? *kopfkratz
ich habe ehrlich gesagt keine lust mehr auf diesen 871...
schaue mich derweil nach einer asa5505 um. sollte man vllt eine bestimmte hw-version bevorzugen? auf ebay werden v02 bis v16 verkauft *augenroll
thx & grüße
ps: für mich soll eine firewall gar kein deep-packet-inspection machen, sondern sich nur um die verbindungsrichtungen kümmern, bis osi-layer4. dpi macht keinen sinn, da ich nur ssl/tls fahre inkl. encrypted-sni.
pps: ist mein dritter tag mit diesem router, hatte davor keine cisco cli-erfahrung...
zumal hinter einem stateful-nat-router des isp..
Dann doppeltes NAT und Firewall in einer Kaskade...na ja kann man machen, ist aber bekanntlich nicht eben das Gelbe vom Ei...scheint für mich nicht zu funktionieren
Das ist dann aber ein reines PEBKAC Problem. Am Cisco liegt es ganz sicher nicht. Aber ohne das du mal deine Konfig hier postest kann man so oder so nichts sagen wo ggf. der Fehler ist. Da hilft dann nur raten oder die Kristallkugel. 
CBAC sollte aber immer gehen !
Oben machst du weder CBAC noch ZFW sondern arbeitest schlicht nur mit ACL was FW technsich gesehen eher Steinzeit ist.
sh ip inspect all zeigt mir ständig nur an
Ist für dich auch komplett sinnfrei weil du ja gar kein CBAC machst. Da kann das dann logischerweise auch nix anzeigen...meine vermutung: dieser alte router will die tls1.2 verbindungen inspizieren
Nein, das macht er nicht.ich habe ehrlich gesagt keine lust mehr auf diesen 871...
Dann kaufe dir einen 886 oder 831 bei eBay https://www.ebay.de/itm/Cisco-881-K9-Ethernet-Security-Router/2532030244 ...
https://www.ebay.de/itm/Cisco-C881-K9/264669309555?hash=item3d9f852a73:g ...
Der macht das mit Links. Siehe Tutorial !
Dein 871 aber auch. Ist ja das gleiche IOS drin.sondern sich nur um die verbindungsrichtungen kümmern, bis osi-layer4.
Auch das macht dein 871er mit links mit der entsprechenden CBAC Konfig. Wie gesagt...PEBKAC ?!P.S.: Deine Shift Taste ist defekt !
Also wie gewünscht meine Testkonfig, die nicht funktioniert. Es wird bsw. heise.de geladen, aber bis die Seite sichtbar wird, vergehen... Minuten (!)
Für mich ist CBAC auf diesem Cisco 871 BROKEN. Grüße
PS: ein 800er kommt mir nicht mehr ins Haus! ASA5505 kosten max 50 eur, aber ich habe keine Ahnung bzgl. der HW-Revisionen...
!
version 12.3
no parser cache
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
no service timestamps debug uptime
no service timestamps log uptime
service password-encryption
no service dhcp
!
hostname krauter
!
aaa authentication login local_auth local
aaa session-id common
ip subnet-zero
no ip source-route
no ip gratuitous-arps
ip cef
!
ip tcp synwait-time 5
no ip bootp server
ip inspect alert-off
ip inspect name INSPECT_TCP tcp timeout 10
ip ips po max-events 100
login block-for 99 attempts 3 within 99
no ipv6 source-route
no ftp-server write-enable
!
interface FastEthernet0
no ip address
no cdp enable
!
interface FastEthernet1
switchport access vlan 10
no ip address
shutdown
no cdp enable
!
interface FastEthernet2
switchport access vlan 10
no ip address
shutdown
no cdp enable
!
interface FastEthernet3
switchport access vlan 20
no ip address
shutdown
no cdp enable
!
interface FastEthernet4
ip address 192.168.0.11 255.255.255.0
ip access-group DENY_ALL in <= alles andere als deny-all macht hier keinen sinn für mich.
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip inspect INSPECT_TCP out <= inspect solle doch zur deny-all directive dynamische permit-regeln hinzufügen...?!
ip virtual-reassembly
duplex auto
speed auto
ntp disable
no cdp enable
!
interface Vlan1
ip address 10.1.1.1 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly
ntp disable
!
interface Vlan10
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
shutdown
!
ip classless
no ip forward-protocol nd
no ip forward-protocol udp
ip route 0.0.0.0 0.0.0.0 192.168.0.1
!
no ip http server
no ip http secure-server
ip nat inside source list LANnat interface FastEthernet4 overload
!
ip access-list extended LANnat
deny ip 10.1.1.0 0.0.0.255 host 10.1.1.1
deny ip 10.1.1.0 0.0.0.255 192.168.0.0 0.0.255.255
permit tcp 10.1.1.0 0.0.0.255 any eq 443
permit tcp 10.1.1.0 0.0.0.255 any eq 995
permit tcp 10.1.1.0 0.0.0.255 any eq 465
deny ip any any
ip access-list extended DENY_ALL
deny ip any any
!
logging trap debugging
logging facility local2
no cdp run
!
control-plane
!
krauter#sh ip inspect all
Session audit trail is disabled
Session alert is disabled
one-minute (sampling period) thresholds are [400:500] connections
max-incomplete sessions thresholds are [400:500]
max-incomplete tcp connections per host is 50. Block-time 0 minute.
tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec
tcp idle-time is 3600 sec -- udp idle-time is 30 sec
dns-timeout is 5 sec
Inspection Rule Configuration
Inspection name INSPECT_TCP
tcp alert is off audit-trail is off timeout 10
Interface Configuration
Interface FastEthernet4
Inbound inspection rule is not set
Outgoing inspection rule is INSPECT_TCP
tcp alert is off audit-trail is off timeout 10
Inbound access list is DENY_ALL
Outgoing access list is not set
Established Sessions
Session 82A15414 (10.1.1.12:53617)=>(52.85.104.110:443) tcp SIS_OPEN
Session 82A15FE4 (10.1.1.12:53619)=>(212.34.186.8:443) tcp SIS_OPEN
Session 82A15264 (10.1.1.12:53618)=>(45.90.28.0:443) tcp SIS_OPEN
Für mich ist CBAC auf diesem Cisco 871 BROKEN. Grüße
PS: ein 800er kommt mir nicht mehr ins Haus! ASA5505 kosten max 50 eur, aber ich habe keine Ahnung bzgl. der HW-Revisionen...
!
version 12.3
no parser cache
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
no service timestamps debug uptime
no service timestamps log uptime
service password-encryption
no service dhcp
!
hostname krauter
!
aaa authentication login local_auth local
aaa session-id common
ip subnet-zero
no ip source-route
no ip gratuitous-arps
ip cef
!
ip tcp synwait-time 5
no ip bootp server
ip inspect alert-off
ip inspect name INSPECT_TCP tcp timeout 10
ip ips po max-events 100
login block-for 99 attempts 3 within 99
no ipv6 source-route
no ftp-server write-enable
!
interface FastEthernet0
no ip address
no cdp enable
!
interface FastEthernet1
switchport access vlan 10
no ip address
shutdown
no cdp enable
!
interface FastEthernet2
switchport access vlan 10
no ip address
shutdown
no cdp enable
!
interface FastEthernet3
switchport access vlan 20
no ip address
shutdown
no cdp enable
!
interface FastEthernet4
ip address 192.168.0.11 255.255.255.0
ip access-group DENY_ALL in <= alles andere als deny-all macht hier keinen sinn für mich.
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip inspect INSPECT_TCP out <= inspect solle doch zur deny-all directive dynamische permit-regeln hinzufügen...?!
ip virtual-reassembly
duplex auto
speed auto
ntp disable
no cdp enable
!
interface Vlan1
ip address 10.1.1.1 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly
ntp disable
!
interface Vlan10
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
shutdown
!
ip classless
no ip forward-protocol nd
no ip forward-protocol udp
ip route 0.0.0.0 0.0.0.0 192.168.0.1
!
no ip http server
no ip http secure-server
ip nat inside source list LANnat interface FastEthernet4 overload
!
ip access-list extended LANnat
deny ip 10.1.1.0 0.0.0.255 host 10.1.1.1
deny ip 10.1.1.0 0.0.0.255 192.168.0.0 0.0.255.255
permit tcp 10.1.1.0 0.0.0.255 any eq 443
permit tcp 10.1.1.0 0.0.0.255 any eq 995
permit tcp 10.1.1.0 0.0.0.255 any eq 465
deny ip any any
ip access-list extended DENY_ALL
deny ip any any
!
logging trap debugging
logging facility local2
no cdp run
!
control-plane
!
krauter#sh ip inspect all
Session audit trail is disabled
Session alert is disabled
one-minute (sampling period) thresholds are [400:500] connections
max-incomplete sessions thresholds are [400:500]
max-incomplete tcp connections per host is 50. Block-time 0 minute.
tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec
tcp idle-time is 3600 sec -- udp idle-time is 30 sec
dns-timeout is 5 sec
Inspection Rule Configuration
Inspection name INSPECT_TCP
tcp alert is off audit-trail is off timeout 10
Interface Configuration
Interface FastEthernet4
Inbound inspection rule is not set
Outgoing inspection rule is INSPECT_TCP
tcp alert is off audit-trail is off timeout 10
Inbound access list is DENY_ALL
Outgoing access list is not set
Established Sessions
Session 82A15414 (10.1.1.12:53617)=>(52.85.104.110:443) tcp SIS_OPEN
Session 82A15FE4 (10.1.1.12:53619)=>(212.34.186.8:443) tcp SIS_OPEN
Session 82A15264 (10.1.1.12:53618)=>(45.90.28.0:443) tcp SIS_OPEN
Deine Konfig ist auch vollkommen FALSCH, denn du machst gar kein CBAC !! Die Definition der CBAC Sessions fehlt vollkommen in deiner Konfig und deshalb kann das so niemals was werden !
Richtig wäre:
!
service timestamps log datetime localtime
!
hostname krauter
!
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip subnet-zero
no ip source-route
no cdp run => (Deaktiviert CDP global !)
!
ip inspect name myfw http
ip inspect name myfw https
ip inspect name myfw pop3s
ip inspect name myfw imaps
ip inspect name myfw esmtp
ip inspect name myfw icmp router-traffic
ip inspect name myfw tcp router-traffic
ip inspect name myfw udp router-traffic
!
!
interface FastEthernet0
no ip address
!
interface FastEthernet1
no ip address
shutdown
!
interface FastEthernet2
no ip address
shutdown
!
interface FastEthernet3
no ip address
shutdown
!
interface FastEthernet4
ip address 192.168.0.11 255.255.255.0
ip access-group DENY_ALL in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip inspect myfw out
ip virtual-reassembly
duplex auto
speed auto
ntp disable
!
interface Vlan1
ip address 10.1.1.1 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly
ntp disable
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.0.1
!
no ip http server
no ip http secure-server
ip nat inside source list LANnat interface FastEthernet4 overload
!
ip access-list extended LANnat
deny ip 10.1.1.0 0.0.0.255 host 10.1.1.1
deny ip 10.1.1.0 0.0.0.255 192.168.0.0 0.0.255.255
permit tcp 10.1.1.0 0.0.0.255 any eq 53
permit udp 10.1.1.0 0.0.0.255 any eq 53
permit tcp 10.1.1.0 0.0.0.255 any eq 80
permit tcp 10.1.1.0 0.0.0.255 any eq 443
permit tcp 10.1.1.0 0.0.0.255 any eq 995
permit tcp 10.1.1.0 0.0.0.255 any eq 465
deny ip any any
!
ip access-list extended DENY_ALL
permit icmp any any administratively-prohibited
permit icmp any any echo-reply
permit icmp any any packet-too-big
permit icmp any any time-exceeded
permit icmp any any unreachable
deny ip any any
!
So und nicht anders wird ein Schuh draus !!
Deine NAT Liste hat auch einen gravierenden Fehler, denn sie lässt DNS Pakete nicht ins Internet. Sprich Clients im lokalen LAN können DNS nicht auflösen.
Ebenso unverschlüsseltes HTTP.
Gibts sogar neu bei Real:
https://www.real.de/product/340340674/
Richtig wäre:
!
service timestamps log datetime localtime
!
hostname krauter
!
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip subnet-zero
no ip source-route
no cdp run => (Deaktiviert CDP global !)
!
ip inspect name myfw http
ip inspect name myfw https
ip inspect name myfw pop3s
ip inspect name myfw imaps
ip inspect name myfw esmtp
ip inspect name myfw icmp router-traffic
ip inspect name myfw tcp router-traffic
ip inspect name myfw udp router-traffic
!
!
interface FastEthernet0
no ip address
!
interface FastEthernet1
no ip address
shutdown
!
interface FastEthernet2
no ip address
shutdown
!
interface FastEthernet3
no ip address
shutdown
!
interface FastEthernet4
ip address 192.168.0.11 255.255.255.0
ip access-group DENY_ALL in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip inspect myfw out
ip virtual-reassembly
duplex auto
speed auto
ntp disable
!
interface Vlan1
ip address 10.1.1.1 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly
ntp disable
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.0.1
!
no ip http server
no ip http secure-server
ip nat inside source list LANnat interface FastEthernet4 overload
!
ip access-list extended LANnat
deny ip 10.1.1.0 0.0.0.255 host 10.1.1.1
deny ip 10.1.1.0 0.0.0.255 192.168.0.0 0.0.255.255
permit tcp 10.1.1.0 0.0.0.255 any eq 53
permit udp 10.1.1.0 0.0.0.255 any eq 53
permit tcp 10.1.1.0 0.0.0.255 any eq 80
permit tcp 10.1.1.0 0.0.0.255 any eq 443
permit tcp 10.1.1.0 0.0.0.255 any eq 995
permit tcp 10.1.1.0 0.0.0.255 any eq 465
deny ip any any
!
ip access-list extended DENY_ALL
permit icmp any any administratively-prohibited
permit icmp any any echo-reply
permit icmp any any packet-too-big
permit icmp any any time-exceeded
permit icmp any any unreachable
deny ip any any
!
So und nicht anders wird ein Schuh draus !!
Deine NAT Liste hat auch einen gravierenden Fehler, denn sie lässt DNS Pakete nicht ins Internet. Sprich Clients im lokalen LAN können DNS nicht auflösen.
Ebenso unverschlüsseltes HTTP.
PS: ein 800er kommt mir nicht mehr ins Haus!
Dann nimmst du besser einen modernen C926 der supportet VDSL2 mit Profil 35b.Gibts sogar neu bei Real:
https://www.real.de/product/340340674/
Ok... Aber ICMP kommt mir genauso wenig ins Haus wie ein Router mit integriertem Modem.
b) ich habe nur TCP-Verbindungen im LAN; alle als ssl/tls getunnelt (!)
c) ip inspect name myfw tcp router-traffic <= 871 unterstützt nur ip inspect name myfw tcp mit der 12.3er fw....
d) wie bereits zu Anfag geschildert habe ich nur TCP/443 im lan (!). -dhcp -dns -udp -icmp .. Namensauflösung erfolgt stets nur über die Anwendung (browser/mail), extern per dns-over-https - ergo kein Eyesdropping durch den ISP möglich (inkl encrypted-sni)...
e) wird es wirklich an der fehlenden zeit-config liegen?! *seufz
Bzgl internem Modem: ich will später keinen 300eur Briefbeschwerer haben, nur weil der ISP sein vdsl2-protokoll geändert habe oder aber das Modem einfach druchbrennt (wahrscheinlicher)... Um Layer2 soll sich bitte der ISP kümmern, inkl kostenfreiem Modem...
30-40 eur für eine ASA5505 - mehr braucht kein Mensch privat idR.
grüße
ps: es ist eigentlich good practice, ins WAN überhaupt keine stateless protokolle durchzulassen, wenn die datenpakete nicht verschlüsselt werden.. in udp-gekapselte esp/gre pakete ja, blankes udp und icmp NEIN!
das gilt sowohl für kleinste wie auch größte unternehmensnetze, denke ich.
pps:
ip inspect name myfw http <= brauche ich nicht
ip inspect name myfw https <= unterstützt der 871 nicht...
ip inspect name myfw pop3s <= nicht gebraucht
ip inspect name myfw imaps <= dito
ip inspect name myfw esmtp <= dito
ip inspect name myfw icmp router-traffic <= router-traffic keine option beim 871 & icmp nicht gebraucht
ip inspect name myfw tcp router-traffic <= testweise gesetzt mit ip inspect name INSPECT_TCP tcp timeout 10 ...
ip inspect name myfw udp router-traffic <= dito & udp nicht gebraucht
PPPS:
für mich ist zumindest auf dem cisco 871 cbac-stateful-firewalling für https BROKEN
b) ich habe nur TCP-Verbindungen im LAN; alle als ssl/tls getunnelt (!)
c) ip inspect name myfw tcp router-traffic <= 871 unterstützt nur ip inspect name myfw tcp mit der 12.3er fw....
d) wie bereits zu Anfag geschildert habe ich nur TCP/443 im lan (!). -dhcp -dns -udp -icmp .. Namensauflösung erfolgt stets nur über die Anwendung (browser/mail), extern per dns-over-https - ergo kein Eyesdropping durch den ISP möglich (inkl encrypted-sni)...
e) wird es wirklich an der fehlenden zeit-config liegen?! *seufz
Bzgl internem Modem: ich will später keinen 300eur Briefbeschwerer haben, nur weil der ISP sein vdsl2-protokoll geändert habe oder aber das Modem einfach druchbrennt (wahrscheinlicher)... Um Layer2 soll sich bitte der ISP kümmern, inkl kostenfreiem Modem...
30-40 eur für eine ASA5505 - mehr braucht kein Mensch privat idR.
grüße
ps: es ist eigentlich good practice, ins WAN überhaupt keine stateless protokolle durchzulassen, wenn die datenpakete nicht verschlüsselt werden.. in udp-gekapselte esp/gre pakete ja, blankes udp und icmp NEIN!
das gilt sowohl für kleinste wie auch größte unternehmensnetze, denke ich.
pps:
ip inspect name myfw http <= brauche ich nicht
ip inspect name myfw https <= unterstützt der 871 nicht...
ip inspect name myfw pop3s <= nicht gebraucht
ip inspect name myfw imaps <= dito
ip inspect name myfw esmtp <= dito
ip inspect name myfw icmp router-traffic <= router-traffic keine option beim 871 & icmp nicht gebraucht
ip inspect name myfw tcp router-traffic <= testweise gesetzt mit ip inspect name INSPECT_TCP tcp timeout 10 ...
ip inspect name myfw udp router-traffic <= dito & udp nicht gebraucht
PPPS:
für mich ist zumindest auf dem cisco 871 cbac-stateful-firewalling für https BROKEN
Ok... Aber ICMP kommt mir genauso wenig ins Haus wie ein Router mit integriertem Modem.
Na ja von deme der Modelle gibt es auch eine Ethernet ONLX Version wenn du mal ins Produkt Datenblatt siehst.Und ICMP kannst du ja unterbinden wenn du es verbietest in der CBAC ACL 111 !
ich habe nur TCP-Verbindungen im LAN; alle als ssl/tls getunnelt (!)
Gut, was soll uns das jetzt sagen ??Wenn du das Einschänken willst dann machst du es in einer Inbound ACL auf dem LAN Interface oder der PAT ACL.
wie bereits zu Anfag geschildert habe ich nur TCP/443 im lan (!)
OK, aber das spielt ja für die Konfig keinerlei Rolle. Wenn du es etwas strikter halten willst schränkst du den TCP 443 Traffic outbound dann ein über eine Inbound ACL auf dem LAN Interface oder der PAT ACL.unterstützt nur ip inspect name myfw tcp mit der 12.3er fw....
OK, kein Problem auch das kannst du nehmen...!Namensauflösung erfolgt stets nur über die Anwendung (browser/mail), extern per dns-over-https
Gut, dann lässt du halt TCP/UDP in der PAT ACL weg !wird es wirklich an der fehlenden zeit-config liegen?!
Vermutlich ?!Die o.a. Konfig rennt auf einem 871 wasserdicht und stabil.
nur weil der ISP sein vdsl2-protokoll geändert habe oder aber das Modem einfach druchbrennt
Ist natürlich Unsinn, denn Cisco supportet alle weltweiten Standards mit dem Modem. Zumal das ja auch nur Modem Firmware ist die man nachladen bzw. patchen kann. Die Annahme ist also unsinnig.Ohne Modem nimmst du dann halt immer ein Ethernet Breitband Modell.
mehr braucht kein Mensch privat idR.
Nee, da hast du recht aber wenn du ehrlich bist reicht da dann auch ein kleiner 20 Euro Mikrotik:https://www.varia-store.com/de/produkt/33635-mikrotik-routerboard-rb941- ...
es ist eigentlich good practice, ins WAN überhaupt keine stateless protokolle durchzulassen
In so einem Szenario wie dem deinen mit rein nur TCP 443 und sonst nix kann man das natürlich problemlos machen und das vorab per ACL filtern. Der gemeine Otto Normaluser kann das aber logischerweise nicht, denn der hat noch Voice, Email usw.<= unterstützt der 871 nicht...
Du solltest dringenst die Firmware updaten...oder was neues beschaffen für mich ist zumindest auf dem cisco 871 cbac-stateful-firewalling für https BROKEN
Nöö, rennt hier fehlerlos mit einem aktuellen Image. Aber auch wenn... Dann machst du eben rein nur TCP Inspection, die wuppt dann auch TCP 443 problemlos
meine konfig ist ebenso fehlerfrei. sowohl die mit stateless filtern als auch nach dem umbau für ip inspect. nur: bei mir läuft es nicht und die seiten bauen sehr träge auf, wenn überhaupt..
welche firmware nutzt du? könntest du sie hochladen? ...
mfg
welche firmware nutzt du? könntest du sie hochladen? ...
mfg
IOS 15 latest...
https://www.alcatron.net/cisco877/ios/
https://www.alcatron.net/cisco877/ios/
thx soweit. nach einer op am offenen herzen (austausch der firmwares durch löschen und kopieren vom ftp..) läuft der router bei mir nun wie gewünscht mit cbac-firewalling 
dabei hat der router seinen ipv6-stack verloren, da die letzte advipservices-fw nicht mehr in den flash passt... aber das kommt mir eh entgegen, da ich ipv6 möglichst blocken will. im nachhinein kann ich nicht mehr genau sagen, woran genau es gelegen hat - zumal meine ip-inspect definitionen nun umfangreicher sind (und weil die neue firmware mehr bietet ;). im anschluss die running-config mit meinem senf dazu.
!
version 15.1
no parser cache
no service pad
no service timestamps debug uptime
no service timestamps log uptime
service password-encryption
no service dhcp
!
hostname krauter
!
boot-start-marker
boot system flash c870-advsec.bin
boot-end-marker
!
no ip source-route
no ip gratuitous-arps
!
ip cef <== deaktivieren per no ip cef keine gute idee, sinkt dann die bandbreite beim test @ https://fast.com/de/# auf ~ 9.5 Mbit !
ip inspect alert-off
ip inspect max-incomplete low 10
ip inspect max-incomplete high 100
ip inspect one-minute low 5
ip inspect one-minute high 50
ip inspect tcp idle-time 5
ip inspect tcp finwait-time 1 <== NSA-empfehlung
ip inspect tcp synwait-time 2
ip inspect tcp block-non-session <== die mächtigste regel auf dem gerät :D
ip inspect name INSPECT tcp timeout 5
option router-traffic habe ich bewusst weggelassen. spekulation: was der router selbst an paketen als 'telefonieren-nach-hause' über das externe interface raushaut, bekommt keinen rückkanal aka permit-eintrag in der WANinbound access-list.
diese option ist bsw. nur sinnvoll. wenn der router von sich selbst aus namensauflösung macht für url-filtering oder fürs verkünden von routen per bgp (tcp/179) etc. an andere router. haben wir nicht, also ist unser gerät keine plaudertasche.
https://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_cbac_fw/configurat ...
weiterhin habe ich _keine_ ip inspect https regel erstellt, obwohl mein traffic nur aus https/ssl/tls besteht ;) sprich, den router geht es n ### an, was ich übertrage, er soll nur die states/verbindungsrichtung kontrollieren...
ip options drop <== idr sind pakete mit gesetzten optionen ungut - insbesondere wenn sie aus dem internet kommen!
no dot11 syslog <== komisch, mit neuer fw gesetzt. der router strahlt aber garnicht mit wlan - also weg damit
no ip bootp server
no ip domain lookup <== router soll doof bleiben, da nur ip-accesslisten. keine namensauflösung durch den router erwünscht.
login block-for 99 attempts 3 within 99
!
ip tcp synwait-time 5
!
interface FastEthernet0
no ip address
no cdp enable
!
interface FastEthernet1
switchport access vlan 10
no ip address
shutdown
no cdp enable
!
interface FastEthernet2
switchport access vlan 10
no ip address
shutdown
no cdp enable
!
interface FastEthernet3
switchport access vlan 20
no ip address
shutdown
no cdp enable
!
CBAC aktiviert auf der äußeren Schnittstelle (hier zum subnet des isp-routers...) es wird jedes paket _aus_ dem router inspiziert. ist es ein tcp-paket, wird dafür automatisch ein permit in der access-liste WANinbound hinzugefügt
interface FastEthernet4
ip address 192.168.0.11 255.255.255.0
ip access-group WANinbound in
ip access-group WANout out
no ip redirects
no ip unreachables
no ip proxy-arp
ip inspect INSPECT out
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
ntp disable <== ntp zeitdienst hat insb. auf einem router/fw am internet nichts zu suchen. unsicheres protokoll! in sicherheitskritischen umgebungen holt man sich die exakte atomzeit nicht per internet sondern entkoppelt per funkantenne...
no cdp enable <== der router soll nicht nach anderen cisco-geräten suchen! mit no cdp run global unterbunden...
!
interface Vlan1
ip address 10.1.1.1 255.255.255.0
ip access-group LANout out <== mit aktivem CBAC wird diese access-liste nicht mehr inspiziert / keine matches laut sh ip access-lists
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly in
ntp disable
!
interface Vlan10
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
shutdown
!
no ip forward-protocol nd
no ip forward-protocol udp <== konsequentes blocken von udp durch den router hindurch. keine chance auch außerhalb von sessions
no ip http server
no ip http secure-server
!
ip nat inside source list LANnat interface FastEthernet4 overload
ip route 0.0.0.0 0.0.0.0 192.168.0.1
!
wir wollen ja nicht alles aus dem vertrauenswürdigen LAN durch den router lassen (nur https und tls-pop3/-smtp) gedroppt werden verbindungsversuche aus dem lokalen netz zum router selbst sowie ins benachbarte äußere subnet (des bösen isp-routers..)
p access-list extended LANnat
deny ip 10.1.1.0 0.0.0.255 host 10.1.1.1
deny ip 10.1.1.0 0.0.0.255 192.168.0.0 0.0.255.255
permit tcp 10.1.1.0 0.0.0.255 any eq 443
permit tcp 10.1.1.0 0.0.0.255 any eq 995
permit tcp 10.1.1.0 0.0.0.255 any eq 465
deny ip any any
ip access-list extended LANout <== eigentlich obsolet mit aktivem CBAC-firewalling (keine matches mehr laut show ip access-lists)
deny ip 192.168.0.0 0.0.255.255 10.1.1.0 0.0.0.255
permit tcp any eq 443 10.1.1.0 0.0.0.255 gt 1023
permit tcp any eq 995 10.1.1.0 0.0.0.255 gt 1023
permit tcp any eq 465 10.1.1.0 0.0.0.255 gt 1023
deny ip any any
CBAC funktioniert! die regel deny ip any any hat hier als einzige matches. eigentlich könnte ich mir die regeln gegen böse tcp-flags sparen, da die permit-regeln immer an erster stelle in diese access-liste dynamisch eingefügt werden ~ aber sie stören auch nicht ;)
ip access-list extended WANinbound
deny tcp any any match-all +ack +fin +psh +rst +syn +urg
deny tcp any any match-all +rst +syn
deny tcp any any match-all +fin +rst +syn
deny tcp any any match-all +ack +fin +rst +syn
deny tcp any any match-all +fin +syn
deny tcp any any match-all +ack +fin +syn
deny ip any 10.1.1.0 0.0.0.255
deny ip 192.168.0.0 0.0.255.255 host 192.168.0.11
deny ip any any
ip access-list extended WANout <== nur bestimmten traffic aus dem cisco-router zulassen (ähnlich LANnat-regelsatz)
deny ip 10.1.1.0 0.0.0.255 any
deny ip host 192.168.0.11 192.168.0.0 0.0.255.255
permit tcp any gt 1023 any eq 443
permit tcp any gt 1023 any eq 995
permit tcp any gt 1023 any eq 465
deny ip any any
!
logging trap debugging
logging facility local2
no cdp run <== dank neuer firmware nun global konfigurierbar ;)
!
line con 0
exec-timeout 5 0
login authentication local_auth
no modem enable
transport output none
line aux 0
login authentication local_auth
no exec <== blockiert login, nur noch per lokaler console möglich
transport output none
line vty 0 4
password 7 11584055424A5B4F567A7974
login authentication local_auth
no exec <== blockiert login, nur noch per lokaler console möglich
transport input none
transport output none
!
fürs erste reicht mir das nun, dieses zonen-basierte firewalling brauche ich eigentlich nicht - auch wenn ich es nun dank neuer fw konfen könnte :] außerdem finde ich es schon erschreckend, dass die firmware quasi um das zweifache in mb fetter geworden ist...
erfreulich ist aber, dass die neue firmware anscheinend die ausgehenden access-listen berücksichtigt - und bsw. ping vom router ausgehend blockiert (über den exec-prompt...) während die orig. diese einfach ignorierte und durchließ ...
naja, vierten tag mit cisco überstanden ^^
thx & grüße
ps: folgende links/howtos waren fürs flashen hilfreich:
https://filezilla-project.org/
https://www.routergeek.net/general/how-to-upgrade-ios-on-a-cisco-router/
https://www.cisco.com/c/en/us/support/docs/routers/10000-series-routers/ ...
dabei hat der router seinen ipv6-stack verloren, da die letzte advipservices-fw nicht mehr in den flash passt... aber das kommt mir eh entgegen, da ich ipv6 möglichst blocken will. im nachhinein kann ich nicht mehr genau sagen, woran genau es gelegen hat - zumal meine ip-inspect definitionen nun umfangreicher sind (und weil die neue firmware mehr bietet ;). im anschluss die running-config mit meinem senf dazu.!
version 15.1
no parser cache
no service pad
no service timestamps debug uptime
no service timestamps log uptime
service password-encryption
no service dhcp
!
hostname krauter
!
boot-start-marker
boot system flash c870-advsec.bin
boot-end-marker
!
no ip source-route
no ip gratuitous-arps
!
ip cef <== deaktivieren per no ip cef keine gute idee, sinkt dann die bandbreite beim test @ https://fast.com/de/# auf ~ 9.5 Mbit !
ip inspect alert-off
ip inspect max-incomplete low 10
ip inspect max-incomplete high 100
ip inspect one-minute low 5
ip inspect one-minute high 50
ip inspect tcp idle-time 5
ip inspect tcp finwait-time 1 <== NSA-empfehlung
ip inspect tcp synwait-time 2
ip inspect tcp block-non-session <== die mächtigste regel auf dem gerät :D
ip inspect name INSPECT tcp timeout 5
option router-traffic habe ich bewusst weggelassen. spekulation: was der router selbst an paketen als 'telefonieren-nach-hause' über das externe interface raushaut, bekommt keinen rückkanal aka permit-eintrag in der WANinbound access-list.
diese option ist bsw. nur sinnvoll. wenn der router von sich selbst aus namensauflösung macht für url-filtering oder fürs verkünden von routen per bgp (tcp/179) etc. an andere router. haben wir nicht, also ist unser gerät keine plaudertasche.
https://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_cbac_fw/configurat ...
weiterhin habe ich _keine_ ip inspect https regel erstellt, obwohl mein traffic nur aus https/ssl/tls besteht ;) sprich, den router geht es n ### an, was ich übertrage, er soll nur die states/verbindungsrichtung kontrollieren...
ip options drop <== idr sind pakete mit gesetzten optionen ungut - insbesondere wenn sie aus dem internet kommen!
no dot11 syslog <== komisch, mit neuer fw gesetzt. der router strahlt aber garnicht mit wlan - also weg damit
no ip bootp server
no ip domain lookup <== router soll doof bleiben, da nur ip-accesslisten. keine namensauflösung durch den router erwünscht.
login block-for 99 attempts 3 within 99
!
ip tcp synwait-time 5
!
interface FastEthernet0
no ip address
no cdp enable
!
interface FastEthernet1
switchport access vlan 10
no ip address
shutdown
no cdp enable
!
interface FastEthernet2
switchport access vlan 10
no ip address
shutdown
no cdp enable
!
interface FastEthernet3
switchport access vlan 20
no ip address
shutdown
no cdp enable
!
CBAC aktiviert auf der äußeren Schnittstelle (hier zum subnet des isp-routers...) es wird jedes paket _aus_ dem router inspiziert. ist es ein tcp-paket, wird dafür automatisch ein permit in der access-liste WANinbound hinzugefügt
interface FastEthernet4
ip address 192.168.0.11 255.255.255.0
ip access-group WANinbound in
ip access-group WANout out
no ip redirects
no ip unreachables
no ip proxy-arp
ip inspect INSPECT out
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
ntp disable <== ntp zeitdienst hat insb. auf einem router/fw am internet nichts zu suchen. unsicheres protokoll! in sicherheitskritischen umgebungen holt man sich die exakte atomzeit nicht per internet sondern entkoppelt per funkantenne...
no cdp enable <== der router soll nicht nach anderen cisco-geräten suchen! mit no cdp run global unterbunden...
!
interface Vlan1
ip address 10.1.1.1 255.255.255.0
ip access-group LANout out <== mit aktivem CBAC wird diese access-liste nicht mehr inspiziert / keine matches laut sh ip access-lists
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly in
ntp disable
!
interface Vlan10
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
shutdown
!
no ip forward-protocol nd
no ip forward-protocol udp <== konsequentes blocken von udp durch den router hindurch. keine chance auch außerhalb von sessions
no ip http server
no ip http secure-server
!
ip nat inside source list LANnat interface FastEthernet4 overload
ip route 0.0.0.0 0.0.0.0 192.168.0.1
!
wir wollen ja nicht alles aus dem vertrauenswürdigen LAN durch den router lassen (nur https und tls-pop3/-smtp) gedroppt werden verbindungsversuche aus dem lokalen netz zum router selbst sowie ins benachbarte äußere subnet (des bösen isp-routers..)
p access-list extended LANnat
deny ip 10.1.1.0 0.0.0.255 host 10.1.1.1
deny ip 10.1.1.0 0.0.0.255 192.168.0.0 0.0.255.255
permit tcp 10.1.1.0 0.0.0.255 any eq 443
permit tcp 10.1.1.0 0.0.0.255 any eq 995
permit tcp 10.1.1.0 0.0.0.255 any eq 465
deny ip any any
ip access-list extended LANout <== eigentlich obsolet mit aktivem CBAC-firewalling (keine matches mehr laut show ip access-lists)
deny ip 192.168.0.0 0.0.255.255 10.1.1.0 0.0.0.255
permit tcp any eq 443 10.1.1.0 0.0.0.255 gt 1023
permit tcp any eq 995 10.1.1.0 0.0.0.255 gt 1023
permit tcp any eq 465 10.1.1.0 0.0.0.255 gt 1023
deny ip any any
CBAC funktioniert! die regel deny ip any any hat hier als einzige matches. eigentlich könnte ich mir die regeln gegen böse tcp-flags sparen, da die permit-regeln immer an erster stelle in diese access-liste dynamisch eingefügt werden ~ aber sie stören auch nicht ;)
ip access-list extended WANinbound
deny tcp any any match-all +ack +fin +psh +rst +syn +urg
deny tcp any any match-all +rst +syn
deny tcp any any match-all +fin +rst +syn
deny tcp any any match-all +ack +fin +rst +syn
deny tcp any any match-all +fin +syn
deny tcp any any match-all +ack +fin +syn
deny ip any 10.1.1.0 0.0.0.255
deny ip 192.168.0.0 0.0.255.255 host 192.168.0.11
deny ip any any
ip access-list extended WANout <== nur bestimmten traffic aus dem cisco-router zulassen (ähnlich LANnat-regelsatz)
deny ip 10.1.1.0 0.0.0.255 any
deny ip host 192.168.0.11 192.168.0.0 0.0.255.255
permit tcp any gt 1023 any eq 443
permit tcp any gt 1023 any eq 995
permit tcp any gt 1023 any eq 465
deny ip any any
!
logging trap debugging
logging facility local2
no cdp run <== dank neuer firmware nun global konfigurierbar ;)
!
line con 0
exec-timeout 5 0
login authentication local_auth
no modem enable
transport output none
line aux 0
login authentication local_auth
no exec <== blockiert login, nur noch per lokaler console möglich
transport output none
line vty 0 4
password 7 11584055424A5B4F567A7974
login authentication local_auth
no exec <== blockiert login, nur noch per lokaler console möglich
transport input none
transport output none
!
fürs erste reicht mir das nun, dieses zonen-basierte firewalling brauche ich eigentlich nicht - auch wenn ich es nun dank neuer fw konfen könnte :] außerdem finde ich es schon erschreckend, dass die firmware quasi um das zweifache in mb fetter geworden ist...
erfreulich ist aber, dass die neue firmware anscheinend die ausgehenden access-listen berücksichtigt - und bsw. ping vom router ausgehend blockiert (über den exec-prompt...) während die orig. diese einfach ignorierte und durchließ ...
naja, vierten tag mit cisco überstanden ^^
thx & grüße
ps: folgende links/howtos waren fürs flashen hilfreich:
https://filezilla-project.org/
https://www.routergeek.net/general/how-to-upgrade-ios-on-a-cisco-router/
https://www.cisco.com/c/en/us/support/docs/routers/10000-series-routers/ ...
läuft der router bei mir nun wie gewünscht mit cbac-firewalling
👍ip cef <== deaktivieren per no ip cef keine gute idee
Weiss man aber auch als Cisco User, denn das schaltet das schnelle Fast Switching ab und macht dann Process Switching über die CPU. Das das dann langsamer ist weiss auch ein Netzwerk Laie. sprich, den router geht es n ### an, was ich übertrage,
Richtig, allerdings gilt dann auch das er damit keinerlei HTTPS spezifische Anomalien, Angriffsmuster etc. mehr erkennen kann. Aber wenn dir das reicht ist reine TCP Inspection auch OK.folgende links/howtos waren fürs flashen hilfreich:
Ist eigentlich Unsinn, denn Cisco üblich macht man das immer mit einem TFTP Server.Entweder dem klassischen TFTP32: https://tftpd32.jounin.net oder dem Pumpkin: http://kin.klever.net/pumpkin wenn man mit Winblows arbeitet !
Dann copy tftp flash: und der Rest ist menügeführt wie üblich.
Unverständlich was du da mit FTP frickelst, aber egal. Was zählt ist ja das es nun rennt wie es soll.
Eine ZFW Firewall bringt dir bei der alten Hardware auch nicht wirklich einen Vorteil.
Zitat von @aqui:
nun, was der router nicht weiss, macht ihn nicht heiß. sprich, weniger cpu-last auf dieser alten hardware (233mhz oder so...). außerdem denke ich würde diese cia-hardware ohnehin nur nach den sni-headern der ssl-pakete sniffen, um zu wissen, _wohin_ die verbindung geht ~ welche bei mir aber verschlüsselt sind...sprich, den router geht es n ### an, was ich übertrage,
Richtig, allerdings gilt dann auch das er damit keinerlei HTTPS spezifische Anomalien, Angriffsmuster etc. mehr erkennen kann. Aber wenn dir das reicht ist reine TCP Inspection auch OK.folgende links/howtos waren fürs flashen hilfreich:
Ist eigentlich Unsinn, denn Cisco üblich macht man das immer mit einem TFTP Server.Entweder dem klassischen TFTP32: https://tftpd32.jounin.net oder dem Pumpkin: http://kin.klever.net/pumpkin wenn man mit Winblows arbeitet !
Dann copy tftp flash: und der Rest ist menügeführt wie üblich.
Unverständlich was du da mit FTP frickelst, aber egal. Was zählt ist ja das es nun rennt wie es soll.
1) tftp arbeitet mit udp. und dabei hört für mich schon die argumentation auf. udp-müll will ich nicht bei wichtigen datenübertragungen. und beim flash-vorgang kommts mir auch nicht auf die sekunden an...
2) ich habe zwar bisher kein tftp gebraucht, aber laut youtube-vids soll ftp (zumindest filezilla) sogar schneller sein?
https://www.youtube.com/watch?v=sf2Mr-V7rmA
"FileZilla FTP Server setup, FTP transfer, IOS Router upgrade, IOS file and storage manipulation"
auch habe ich irgendwo gelesen, dass tftp probleme machen soll mit binaries größer 16MB oder so...
man bricht sich auch nicht die finger dabei, wenn man auf der console 'copy ftp://user:password@ftp-server-ip/firmware.bin flash:' eingibt...
Eine ZFW Firewall bringt dir bei der alten Hardware auch nicht wirklich einen Vorteil.
ja, schätze dieses policy-firewalling basiert ohnehin auf cbac/stateful-sessions. sehe darin keinen mehrwert außer die config unübersichtlich zu machen. tatsächlich ist es sogar so, dass ZBF eine default-self-zone auf dem router einrichtet, wodurch der router von sich aus überall ungehindert funken kann... also die sicherheit/privatsphäre wird gegenüber CBAC aufgeweicht! in kleinen umgebungen mit wenigen schnittstellen macht insofern ZBF kaum sinn. und ich würde allein aufgrund der kontrolle aller interfaces auch bei komplizierteren dmz-settings nur cbac einsetzen...dazu siehe https://mellowd.co.uk/ccie/cbac-vs-zbf/ : "...When using ZBF, their is a ‘self’ zone created. By default all traffic is allowed to and from this zone..."
mfg
udp-müll will ich nicht bei wichtigen datenübertragungen.
Ist aber bei Cisco kein Thema denn der macht im Hintergrund einen Checksummen Vergleich. Die im Image embeddete Checksumme muss mit der des übertragenen Files übereinstimmen ansonsten sichert er das Image erst gar nicht im Flash. Ist also absolut wasserdicht auch mit TFTP.aber laut youtube-vids soll ftp (zumindest filezilla) sogar schneller sein?
Technischer Unsinn, denn der Session Overhead von TCP allein macht die Übertragung ja per se langsamer. Das sagt einem aber auch der gesunde IP Verstand. dass tftp probleme machen soll mit binaries größer 16MB oder so...
Nein, nicht 16MB aber 32MB. Da ist bei den meisten TFTP Servern das Limit !Nicht aber beim TFTP32 oben, der hat das Limit nicht !
schätze dieses policy-firewalling basiert ohnehin auf cbac/stateful-sessions
Nein, das ist falsch !Es ist vollkommen neu geschriebener Code im IOS und kommt aus der PIX/ASA Ecke. Das nutzt gar nichts mehr von CBAC.
CBAC wird bei Cisco nicht mehr weiterentwickelt und wird laut Ankündigung aus dem Development langfristig zugunsten der ZFW aus dem IOS Code vollkommen verschwinden.
wodurch der router von sich aus überall ungehindert funken kann
Auch das ist eine falsche Annahme. Jedenfalls wenn man die Self Zone mit Regeln belegt was man ja normalerweise in einer Firewall in jedem Falle macht.Zeigt eher das du dich wenig bis gar nicht mit der ZFW beschäftigt hast.
auch bei komplizierteren dmz-settings nur cbac einsetzen...
Eine grundfalsche Einstellung und auch im Hinblick auf die Zukunft von CBAC der völlig falsche Weg.By default all traffic is allowed to and from this zone..."
Yes, but as far as there is one single rule, which is quite mandatory in modern firewall concepts, all traffic will be blocked by default then.Das hiesige_Tutorial setzt deshalb auch konsequent Regeln in der Self Zone.
Auch der Engländer hat nur die Hälfte des ZFW Design Guides gelesen oder verstanden.
alles klar, chef
bevor ich an ipsec auf dem cisco denke:
https://seclists.org/oss-sec/2019/q4/122
https://www.golem.de/news/unix-artige-systeme-sicherheitsluecke-ermoegli ...
seltsamerweise auf heise.de dazu garnix :D
dieser angriff ist als kritisch einzustufen - denn im fall der fälle ist dieses "übernommene" netzwerkgerät der heimische isp-router (ob durch geheimdienst/isp/hacker)...!
wie verhalten sich cisco router der serien 800/900 und eben asa hinsichtlich dieses angriffsvektors auf vpn, indem ein angreifer über ein (gekapertes) gerät innerhalb der wegstrecke des vpn-tunnels (bsw. wlan-accesspoint oder anderer router) tcp-syn-ack pakete auf gut glück an die virtuelle tunnel-ip des vpn-servers/endpoints schickt und je nach betriebssystem das angegriffene system mit unverschlüsselt über das eigene physische interface systeminfo offenbart?
wobei dieser angriff auf den ersten blick wohl eher remote-clients wie vor allem smartphones anvisiert...
unter linux kann man das ja eig. sehr easy verhindern, indem man einfach rp_filter=1 setzt (leider bei vielen distros heute default-off...). damit dürfen dann die antwortpakete nur über das interface raus, über welches sie empfangen wurden - und damit würde das os die anfrage von außen an die virtuelle vpn-ip als martian droppen...
gibt es auf cisco hw eine ähnliche config zu linux' rp-filter-option?
https://forum.golem.de/kommentare/security/unix-artige-systeme-sicherhei ...
Autor: damluk 07.12.19 - 11:28
Der Angreifer muss keine verschlüsselten Pakete verschicken. Alles dreht sich darum, dass der Netzwerkstack Pakete auf allen Interfaces annimmt, solange die Ziel-IP-Adresse einem seiner Interfaces gehört ("non-strict rp_filter").
Wenn man ohne VPN online ist, hat man mindestens eine IP-Adresse. Wählt man sich dann ins VPN ein, hat man i.d.R eine zusätzliche. Die erste ("äußere") braucht man weiterhin, um verschlüsselte Pakete zum VPN-Server zu schicken, die neue Adresse ist die getunnelte ("innere") IP-Adresse.
Das Gesamzszenario setzt nun erstens voraus, dass ein Angreifer Pakete "von außen" an die "innere" IP-Adresse schicken kann, und zweitens die äußere Verbindung beobachten kann.
Dazu müssen mehrere Dinge zusammenkommen. Es gibt Edge-Cases, in denen beide Punkte erfüllbar sind, selbst wenn der Angreifer nicht im gleichen (W)LAN wie das Opfer hängt, wenn aber beide im gleichen (W)LAN sind, vereinfacht es die Sache.
In einem (W)LAN adressiert der Angreifer das Opfer mit seiner MAC-Adresse. Die Quell- und Ziel-IP-Adresse kann beliebig sein, der Switch oder der AP stellt das Paket zu, solange die Ziel-MAC-Adresse stimmt. Im non-strict rp_filter Modus, akzeptiert der Netzwerkstack Pakete an die "innere" IP-Adresse auf dem "äußeren" Netzwerkinterface und verarbeitet sie ganz regulär.
In der ersten Phase des beschriebenen Angriffs nutzt der Angreifer seine normale (W)LAN-Adresse als Quell-IP. Für diese Phase ist es nicht notwendig zwischen dem VPN-Server und dem Opfer zu hängen. Die (W)LAN-Netzroute ist spezieller als die Default-Route über das VPN, so dass das Opfer dem Angreifer ganz regulär über das unverschlüsselte (W)LAN antworten wird.
Das passive Lesen der verschlüsselten VPN-Pakete ist in den späteren Angriffsphasen nötig, nämlich wenn der Angreifer TCP-Pakete produziert, und dazu erzeugte Antwortpakete über den VPN-Tunnel geroutet werden. Dann lassen sich rein aus der Aktivität der äußeren VPN-Verbindung Rückschlüsse ziehen, ohne die Verschlüsselung aufzubrechen.<<
mfg
ps: auch ein grund, warum ich auf WAN nie rst konfe sondern strikt drop - wozu unbekannten info über ip-stack offenbaren?!
bevor ich an ipsec auf dem cisco denke:
https://seclists.org/oss-sec/2019/q4/122
https://www.golem.de/news/unix-artige-systeme-sicherheitsluecke-ermoegli ...
seltsamerweise auf heise.de dazu garnix :D
dieser angriff ist als kritisch einzustufen - denn im fall der fälle ist dieses "übernommene" netzwerkgerät der heimische isp-router (ob durch geheimdienst/isp/hacker)...!
wie verhalten sich cisco router der serien 800/900 und eben asa hinsichtlich dieses angriffsvektors auf vpn, indem ein angreifer über ein (gekapertes) gerät innerhalb der wegstrecke des vpn-tunnels (bsw. wlan-accesspoint oder anderer router) tcp-syn-ack pakete auf gut glück an die virtuelle tunnel-ip des vpn-servers/endpoints schickt und je nach betriebssystem das angegriffene system mit unverschlüsselt über das eigene physische interface systeminfo offenbart?
wobei dieser angriff auf den ersten blick wohl eher remote-clients wie vor allem smartphones anvisiert...
unter linux kann man das ja eig. sehr easy verhindern, indem man einfach rp_filter=1 setzt (leider bei vielen distros heute default-off...). damit dürfen dann die antwortpakete nur über das interface raus, über welches sie empfangen wurden - und damit würde das os die anfrage von außen an die virtuelle vpn-ip als martian droppen...
gibt es auf cisco hw eine ähnliche config zu linux' rp-filter-option?
https://forum.golem.de/kommentare/security/unix-artige-systeme-sicherhei ...
Re: Wie funktioniert die Verschlüsselung
Der Angreifer muss keine verschlüsselten Pakete verschicken. Alles dreht sich darum, dass der Netzwerkstack Pakete auf allen Interfaces annimmt, solange die Ziel-IP-Adresse einem seiner Interfaces gehört ("non-strict rp_filter").
Wenn man ohne VPN online ist, hat man mindestens eine IP-Adresse. Wählt man sich dann ins VPN ein, hat man i.d.R eine zusätzliche. Die erste ("äußere") braucht man weiterhin, um verschlüsselte Pakete zum VPN-Server zu schicken, die neue Adresse ist die getunnelte ("innere") IP-Adresse.
Das Gesamzszenario setzt nun erstens voraus, dass ein Angreifer Pakete "von außen" an die "innere" IP-Adresse schicken kann, und zweitens die äußere Verbindung beobachten kann.
Dazu müssen mehrere Dinge zusammenkommen. Es gibt Edge-Cases, in denen beide Punkte erfüllbar sind, selbst wenn der Angreifer nicht im gleichen (W)LAN wie das Opfer hängt, wenn aber beide im gleichen (W)LAN sind, vereinfacht es die Sache.
In einem (W)LAN adressiert der Angreifer das Opfer mit seiner MAC-Adresse. Die Quell- und Ziel-IP-Adresse kann beliebig sein, der Switch oder der AP stellt das Paket zu, solange die Ziel-MAC-Adresse stimmt. Im non-strict rp_filter Modus, akzeptiert der Netzwerkstack Pakete an die "innere" IP-Adresse auf dem "äußeren" Netzwerkinterface und verarbeitet sie ganz regulär.
In der ersten Phase des beschriebenen Angriffs nutzt der Angreifer seine normale (W)LAN-Adresse als Quell-IP. Für diese Phase ist es nicht notwendig zwischen dem VPN-Server und dem Opfer zu hängen. Die (W)LAN-Netzroute ist spezieller als die Default-Route über das VPN, so dass das Opfer dem Angreifer ganz regulär über das unverschlüsselte (W)LAN antworten wird.
Das passive Lesen der verschlüsselten VPN-Pakete ist in den späteren Angriffsphasen nötig, nämlich wenn der Angreifer TCP-Pakete produziert, und dazu erzeugte Antwortpakete über den VPN-Tunnel geroutet werden. Dann lassen sich rein aus der Aktivität der äußeren VPN-Verbindung Rückschlüsse ziehen, ohne die Verschlüsselung aufzubrechen.<<
mfg
ps: auch ein grund, warum ich auf WAN nie rst konfe sondern strikt drop - wozu unbekannten info über ip-stack offenbaren?!
wie verhalten sich cisco router der serien 800/900 und eben asa hinsichtlich dieses angriffsvektors auf vpn
Ist mit dem aktuellen 16er IOS Image gefixt !
ok... d.h. mein router ist dafür noch anfällig... wie sieht es aber aktuell mit sicheren zufälligen tcp-isn aus? hält cisco dieses wichtige tcp-feature nur seinen asa vor?
ist zwar aktuell in meiner doppel-nat konfig derzeit nicht sooo wichtig, aber spätestens wenn ich den isp-router in bridge-modus umstelle...
mfg
ps: welche asa firmwares haben den vpn-bug nicht mehr?
ist zwar aktuell in meiner doppel-nat konfig derzeit nicht sooo wichtig, aber spätestens wenn ich den isp-router in bridge-modus umstelle...
mfg
ps: welche asa firmwares haben den vpn-bug nicht mehr?
hält cisco dieses wichtige tcp-feature nur seinen asa vor?
Nein die aktuellen IOS-XE Modelle wie C926, C1112 bzw. die ganze Modellreihe haben das auch. Im aktuellen T (Technology) Release Train von IOS ist es aber auch inkludiert über die gesamte IOS Produktpalette.
ahja, ich habe von deiner kryptischen schreibe kaum was vestanden. egal, ich werde in zukunft wohl kaum auf cisco setzen sondern linux oder openbsd für ne konkrete firewall.
zumal ich nach kurzer überlegung den umstand doch nicht so cool finde, dass ausgerechneet eine cisco firewall die isn austauscht.
insofern vertraue ich diesbezüglich heute viel mehr dem betriebssystem als irgendeiner propietären hardware als man-in-the-middle - und damit werde ich auch keine hunderter einer neuen cisco hw nachwerfen, sondern höchsten 35 eur einem 891, welcher schneller sein dürfte als ne asa5505...
grüße
zumal ich nach kurzer überlegung den umstand doch nicht so cool finde, dass ausgerechneet eine cisco firewall die isn austauscht.
insofern vertraue ich diesbezüglich heute viel mehr dem betriebssystem als irgendeiner propietären hardware als man-in-the-middle - und damit werde ich auch keine hunderter einer neuen cisco hw nachwerfen, sondern höchsten 35 eur einem 891, welcher schneller sein dürfte als ne asa5505...
grüße
sondern linux oder openbsd für ne konkrete firewall.
Dann bist du hier richtig aufgehoben: Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
