topic Blocking outside access to router in Network Security

Blocking outside access to router

jeremy0463 — Sun, 31 Dec 2023 02:28:24 GMT

I have setup NAT and firewall on my C1111-8w8p router and I believe it is correct. Let me know if you see any other problems here. I am still learning. But now I need to block access to the router. Port scan of public ip shows 22, 80, 443, and 1720 open. Not sure how to do that the best way. Please help. Here is my configuration:

Sat Dec 30 2023 20:20:06 GMT-0600 (Central Standard Time)

===================================================================================

#sh run

Building configuration...

Current configuration : 9958 bytes

! Last configuration change at 02:18:43 UTC Sun Dec 31 2023 by admin

! NVRAM config last updated at 00:16:50 UTC Sun Dec 31 2023 by admin

version 17.9

service timestamps debug datetime msec

service timestamps log datetime msec

service call-home

platform qfp utilization monitor load 80

no platform punt-keepalive disable-kernel-core

platform hardware throughput crypto 50000

hostname Edge_Router

boot-start-marker

boot system bootflash:c1100-universalk9.17.09.04a.SPA.bin

boot system bootflash:c1100-universalk9_ias.16.10.01b.SPA.bin

boot-end-marker

aaa new-model

aaa session-id common

ip name-server 8.8.8.8 1.1.1.1

ip domain name lewishome.local

ip dhcp excluded-address 192.168.1.0

ip dhcp excluded-address 192.168.1.1 192.168.1.99

ip dhcp excluded-address 192.168.1.200 192.168.1.255

ip dhcp pool default

network 192.168.1.0 255.255.255.0

default-router 192.168.1.1

dns-server 8.8.8.8 1.1.1.1

lease infinite

subscriber templating

vtp version 1

multilink bundle-name authenticated

crypto pki trustpoint TP-self-signed-2829415558

enrollment selfsigned

subject-name cn=IOS-Self-Signed-Certificate-2829415558

revocation-check none

rsakeypair TP-self-signed-2829415558

crypto pki trustpoint SLA-TrustPoint

enrollment pkcs12

revocation-check crl

crypto pki certificate chain TP-self-signed-2829415558

certificate self-signed 01

30820330 30820218 A0030201 02020101 300D0609 2A864886 F70D0101 05050030

31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274

69666963 6174652D 32383239 34313535 3538301E 170D3233 31303331 30333530

31365A17 0D333030 31303130 30303030 305A3031 312F302D 06035504 03132649

4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D32 38323934

31353535 38308201 22300D06 092A8648 86F70D01 01010500 0382010F 00308201

0A028201 0100D4C8 D205F41D 87D75235 3BF6112F A419AA75 DD5BEBA3 F65A51E0

F9D66305 D7D3EFEA AFE0CE68 B51807E7 ABAD93C8 7D2CB2F0 127DDD3A 81D0A65C

28D4AAED 6C723B45 BD33EC5E 4CA33DC0 013E4C52 1912A7B0 3D7DB305 1C3B0C6B

C1CBBC69 D36E5C8F 561A2334 57BC4BA4 F96E74C9 26C1DF87 8A72BB74 E41675D0

1BC7179F 4E1AC770 9C168634 BBA41693 4197748B 17348D43 E56D3E5F A92BCC94

449D42D1 C8CA05FE DBD014C2 F5E87F73 8FFD1F87 16A46317 1AB5A4F6 BDEF2A13

9091FDAC 4674D656 D0011D59 01D72939 FF7BE161 AE4861DA 27288373 3ECDBB9A

D3224C19 F57D213F 1E66E96A 134CC8C3 459566A9 1603B84A 475A4242 B2B4CC78

DAE84745 0F670203 010001A3 53305130 0F060355 1D130101 FF040530 030101FF

301F0603 551D2304 18301680 148196B9 201E83D1 82D6F51B C348A36B FC92075D

AC301D06 03551D0E 04160414 8196B920 1E83D182 D6F51BC3 48A36BFC 92075DAC

300D0609 2A864886 F70D0101 05050003 82010100 53BA30C3 805BB3D6 30F9E106

38A164A3 9B6B48D0 5DFD2DA9 940A9F79 945B4E20 A878F406 CCE22730 63C7F7ED

3657AADE 2AB34739 1EA13AF6 49E40C27 C3E8BC1B 50B5F0F0 CEB49998 CA0ECE1E

AFE2B08A 6B011A4C B4579FCF 7CE42025 AE227792 08141E61 99C90838 AA135E4C

D2D29867 7CDA5B54 7E66A31A AA6BDC3D 027327F9 CAF90986 3ED52D07 69A86D69

B48E3F2A 4ACDFD93 9784B856 27C122A5 E01CACFB AEE35360 432CC6E5 35A5EF6C

DA17AA22 AB79F9DD 40AA1110 0D32B60A FF386552 9254FEC4 389B1E6C C9C0A4A6

E08CC317 D3FC7267 2C0ADD07 096DFB7E E3070723 78D056D0 FF2226C5 C0E5BEEC

9C091A72 CFBA7897 A588FD2F 53E91932 7C56826A

quit

crypto pki certificate chain SLA-TrustPoint

certificate ca 01

30820321 30820209 A0030201 02020101 300D0609 2A864886 F70D0101 0B050030

32310E30 0C060355 040A1305 43697363 6F312030 1E060355 04031317 43697363

6F204C69 63656E73 696E6720 526F6F74 20434130 1E170D31 33303533 30313934

3834375A 170D3338 30353330 31393438 34375A30 32310E30 0C060355 040A1305

43697363 6F312030 1E060355 04031317 43697363 6F204C69 63656E73 696E6720

526F6F74 20434130 82012230 0D06092A 864886F7 0D010101 05000382 010F0030

82010A02 82010100 A6BCBD96 131E05F7 145EA72C 2CD686E6 17222EA1 F1EFF64D

CBB4C798 212AA147 C655D8D7 9471380D 8711441E 1AAF071A 9CAE6388 8A38E520

1C394D78 462EF239 C659F715 B98C0A59 5BBB5CBD 0CFEBEA3 700A8BF7 D8F256EE

4AA4E80D DB6FD1C9 60B1FD18 FFC69C96 6FA68957 A2617DE7 104FDC5F EA2956AC

7390A3EB 2B5436AD C847A2C5 DAB553EB 69A9A535 58E9F3E3 C0BD23CF 58BD7188

68E69491 20F320E7 948E71D7 AE3BCC84 F10684C7 4BC8E00F 539BA42B 42C68BB7

C7479096 B4CB2D62 EA2F505D C7B062A4 6811D95B E8250FC4 5D5D5FB8 8F27D191

C55F0D76 61F9A4CD 3D992327 A8BB03BD 4E6D7069 7CBADF8B DF5F4368 95135E44

DFC7C6CF 04DD7FD1 02030100 01A34230 40300E06 03551D0F 0101FF04 04030201

06300F06 03551D13 0101FF04 05300301 01FF301D 0603551D 0E041604 1449DC85

4B3D31E5 1B3E6A17 606AF333 3D3B4C73 E8300D06 092A8648 86F70D01 010B0500

03820101 00507F24 D3932A66 86025D9F E838AE5C 6D4DF6B0 49631C78 240DA905

604EDCDE FF4FED2B 77FC460E CD636FDB DD44681E 3A5673AB 9093D3B1 6C9E3D8B

D98987BF E40CBD9E 1AECA0C2 2189BB5C 8FA85686 CD98B646 5575B146 8DFC66A8

467A3DF4 4D565700 6ADF0F0D CF835015 3C04FF7C 21E878AC 11BA9CD2 55A9232C

7CA7B7E6 C1AF74F6 152E99B7 B1FCF9BB E973DE7F 5BDDEB86 C71E3B49 1765308B

5FB0DA06 B92AFE7F 494E8A9E 07B85737 F3A58BE1 1A48A229 C37C1E69 39F08678

80DDCD16 D6BACECA EEBC7CF9 8428787B 35202CDC 60E4616A B623CDBD 230E3AFB

418616A9 4093E049 4D10AB75 27E86F73 932E35B5 8862FDAE 0275156F 719BB2F0

D697DF7F 28

quit

crypto pki certificate pool

cabundle nvram:ios_core.p7b

no license feature hseck9

license udi pid C1111-8PWB sn

license boot level securityk9

memory free low-watermark processor 66007

diagnostic bootup level minimal

spanning-tree extend system-id

enable secret 9

username admin privilege 15 secret 9

redundancy

mode none

vlan internal allocation policy ascending

class-map type inspect match-any INSIDE-TO-OUTSIDE_cmap_app

match protocol http

match protocol https

match protocol icmp

match protocol tcp

match protocol udp

class-map type inspect match-all INSIDE-TO-OUTSIDE_cmap

match access-group name INSIDE-TO-OUTSIDE_acl

match class-map INSIDE-TO-OUTSIDE_cmap_app

policy-map type inspect INSIDE-TO-OUTSIDE_policy

class type inspect INSIDE-TO-OUTSIDE_cmap

inspect

class class-default

drop log

zone security INSIDE

description Zone for inside interfaces

zone security OUTSIDE

description Zone for outside interfaces

zone-pair security INSIDE-TO-OUTSIDE source INSIDE destination OUTSIDE

service-policy type inspect INSIDE-TO-OUTSIDE_policy

interface GigabitEthernet0/0/0

description WAN 1

ip address xxx.xxx.xxx.xxx 255.255.255.252

ip nat outside

zone-member security OUTSIDE

negotiation auto

interface GigabitEthernet0/0/1

no ip address

zone-member security OUTSIDE

media-type rj45

negotiation auto

interface GigabitEthernet0/1/0

description To Core Switch

switchport access vlan 250

zone-member security INSIDE

interface GigabitEthernet0/1/1

zone-member security INSIDE

interface GigabitEthernet0/1/2

zone-member security INSIDE

interface GigabitEthernet0/1/3

zone-member security INSIDE

interface GigabitEthernet0/1/4

zone-member security INSIDE

interface GigabitEthernet0/1/5

zone-member security INSIDE

interface GigabitEthernet0/1/6

zone-member security INSIDE

interface GigabitEthernet0/1/7

zone-member security INSIDE

interface Wlan-GigabitEthernet0/1/8

zone-member security INSIDE

interface Vlan1

description Default

ip address 192.168.1.1 255.255.255.0

zone-member security INSIDE

interface Vlan250

description WAN

ip address 192.168.250.10 255.255.255.0

ip nat inside

zone-member security INSIDE

ip http server

ip http authentication local

ip http secure-server

ip forward-protocol nd

ip nat inside source list NAT_acl interface GigabitEthernet0/0/0 overload

ip nat inside source route-map track-primary-if interface GigabitEthernet0/0/0 overload

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/0 71.37.144.146

ip route 192.168.10.0 255.255.255.0 192.168.250.1

ip route 192.168.40.0 255.255.254.0 192.168.250.1

ip route 192.168.50.0 255.255.255.0 192.168.250.1

ip route 192.168.60.0 255.255.255.0 192.168.250.1

ip route 192.168.70.0 255.255.255.0 192.168.250.1

ip route 192.168.80.0 255.255.255.0 192.168.250.1

ip route 192.168.100.0 255.255.255.0 192.168.250.1

ip access-list extended INSIDE-TO-OUTSIDE_acl

1 permit ip 192.168.1.0 0.0.0.255 any

10 permit ip 192.168.10.0 0.0.0.255 any

40 permit ip 192.168.40.0 0.0.1.255 any

50 permit ip 192.168.50.0 0.0.0.255 any

60 permit ip 192.168.60.0 0.0.0.255 any

70 permit ip 192.168.70.0 0.0.0.255 any

80 permit ip 192.168.80.0 0.0.0.255 any

100 permit ip 192.168.100.0 0.0.0.255 any

250 permit ip 192.168.250.0 0.0.0.255 any

ip access-list extended NAT_acl

1 permit ip 192.168.1.0 0.0.0.255 any

10 permit ip 192.168.10.0 0.0.0.255 any

40 permit ip 192.168.40.0 0.0.1.255 any

50 permit ip 192.168.50.0 0.0.0.255 any

60 permit ip 192.168.60.0 0.0.0.255 any

70 permit ip 192.168.70.0 0.0.0.255 any

80 permit ip 192.168.80.0 0.0.0.255 any

100 permit ip 192.168.100.0 0.0.0.255 any

250 permit ip 192.168.250.0 0.0.0.255 any

route-map track-primary-if permit 1

match ip address 197

set interface GigabitEthernet0/0/0

control-plane

banner login ^CLewis Home Edge Router^C

line con 0

transport input none

stopbits 1

line vty 0 4

length 0

transport input ssh

line vty 5 14

transport input ssh

call-home

! If contact email address in call-home is configured as sch-smart-licensing@cisco.com

! the email address configured in Cisco Smart License Portal will be used as contact email address to send SCH notifications.

contact-email-addr sch-smart-licensing@cisco.com

profile "CiscoTAC-1"

active

destination transport-method http

ntp server 0.ciscome.pool.ntp.org

ntp server 1.ciscome.pool.ntp.org

ntp server 2.ciscome.pool.ntp.org

end

Re: Blocking outside access to router

MHM Cisco World — Sun, 31 Dec 2023 09:11:43 GMT

to be honest I was think that the OUT-IN Zone pair cover also zone-pair OUT-Self
but in such case and I have time I lab it to check

Case 1
the OUT-IN using class match protocol OUT-IN action is drop
and you can see I can telnet to R1

Case2
Zone Pair OUT-Self with class match telnet and action is drop
you can see the port is closs and I cant access R1 anymore
so use class match protocol then use policy action drop
NOTE:- this make you can not access Router via telnet or SSH from OUT anymore

MHM

Re: Blocking outside access to router

Rob Ingram — Sun, 31 Dec 2023 15:53:56 GMT

@jeremy0463 if you wish to restrict access "to" the router itself using ZBFW then you need to use the "self" zone. Create a zone-pair from source OUTSIDE to destination self (referening the service policy obviously). Using a zone-pair from OUTSIDE to INSIDE affects only traffic going "through" the firewall, not "to" the firewall itself.

EDIT - @MHM Cisco World I notice you have now corrected your initial response, FYI here is more information on the self zone https://community.cisco.com/t5/security-knowledge-base/zbfw-self-zone-integration/ta-p/3154572

Re: Blocking outside access to router

MHM Cisco World — Sun, 31 Dec 2023 16:03:14 GMT

Thanks

Let us stop work and enjoy with our family this night.

Have a nice new year eve

See you next year lol..

MHM

Re: Blocking outside access to router

jeremy0463 — Sun, 31 Dec 2023 21:38:45 GMT

So here is what I am planning on implementing. It should leave room to add vpn later. Does this work?

—————————————————————————————————————————

SELF AND INSIDE

—————————————————————————————————————————

ip access-list extended Self_and_Inside

permit ip any any

class-map type inspect Inside_Self

match access-group name Self_and_Inside

policy-map type inspect Inside_Self

class Inside_Self

inspect

Policy-map type inspect Self_Inside

class Inside_Self

inspect

zone-pair security Self_to_Inside source self destination INSIDE

service-policy type inspect Self_Inside

zone-pair security Inside_to_Self source INSIDE destination self

service-policy type inspect Inside_Self

—————————————————————————————————————————

SELF AND OUTSIDE

—————————————————————————————————————————

ip access-list extended OUTSIDE_to_self_acl

deny ip any any

ip access-list extended self_to_OUTSIDE_acl

permit ip any any

class-map type inspect match-any OUTSIDE_to_self_app

match protocol ipsec

class-map type inspect match-any self_to_OUTSIDE_app

match protocol any

class-map type inspect match-all OUTSIDE-to-self_cmap

match class-map OUTSIDE_to_self_app

match access-group name OUTSIDE_to_self_acl

class-map type inspect match-all self-to-OUTSIDE_cmap

match class-map self-to-OUTSIDE_app

match access-group name self-to-OUTSIDE_acl

policy-map type inspect self-TO-OUTSIDE_policy

class type inspect OUTSIDE-TO-self_cmap

inspect

class class-default

drop log

policy-map type inspect OUTSIDE-TO-self_policy

class type inspect self-TO-OUTSIDE_cmap

inspect

class class-default

drop log

zone-pair security Out-To-Self source OUTSIDE destination self

service-policy type inspect Out_Self

zone-pair security Self-To-Out source self destination OUTSIDE

service-policy type inspect Self_Out

Re: Blocking outside access to router

Rob Ingram — Sun, 31 Dec 2023 22:08:00 GMT

@jeremy0463 Why are you matching all on the same class map? Traffic will have to match both.

class-map type inspect match-all OUTSIDE-to-self_cmap
 match class-map OUTSIDE_to_self_app
 match access-group name OUTSIDE_to_self_acl

Regardless, you would "pass" the IPSec traffic (udp/500, esp and udp/4500 if nat-t) rather than match on ipsec for traffic to the router. https://www.cisco.com/c/en/us/support/docs/routers/3800-series-integrated-services-routers/112051-zbf-vpn-access-config.html

So create an ACL to match the IPsec traffic, match on that ACL in the class-map and reference in the policy-map. Then deny all other traffic to self from outside using the class-default and drop. Example:

ip access-list extended ISAKMP-IPSEC
 permit udp any any eq isakmp
 permit esp any any
 permit udp any any eq non500-isakmp

class-map type inspect match-all CM-IPSEC
 match access-group name ISAKMP-IPSEC

policy-map type inspect PM-OUTSIDE->self
 class type inspect CM-IPSEC
 pass
class class-default
 drop

zone-pair security OUTSIDE->self source OUTSIDE destination self
 service-policy type inspect PM-OUTSIDE->self

Re: Blocking outside access to router

jeremy0463 — Sun, 31 Dec 2023 23:10:44 GMT

The vpn was just a provision for the future just in case, I can leave that alone for now and make that another step. Basically I had a match all so that the acl would be matched and the class map would also be matched. I left the deny all in place to block it completely for now, but was later going to permit specific iPs and then I could do the pass con portion. I don’t know, still learning here. My primary goal is to block outside access to the router itself. I jumped the gun on vpn. Let’s stick with blocking services. So as far as an overall “self-zone” to block services from outside to self but allow self to outside, inside to self, and self to inside, would this accomplish:

—————————————————————————————————————————

SELF AND INSIDE

—————————————————————————————————————————

ip access-list extended Self_and_Inside

permit ip any any

class-map type inspect Inside_Self

match access-group name Self_and_Inside

policy-map type inspect Inside_Self

class Inside_Self

inspect

Policy-map type inspect Self_Inside

class Inside_Self

inspect

zone-pair security Self_to_Inside source self destination INSIDE

service-policy type inspect Self_Inside

zone-pair security Inside_to_Self source INSIDE destination self

service-policy type inspect Inside_Self

—————————————————————————————————————————

SELF AND OUTSIDE

—————————————————————————————————————————

ip access-list extended OUTSIDE_to_self_acl

deny ip any any

class-map type inspect OUTSIDE_to_self_cmap

match access-group name OUTSIDE_to_self_acl

policy-map type inspect OUTSIDE-TO-self_policy

class type inspect OUTSIDE-TO-self_cmap

inspect

class class-default

drop log

ip access-list extended self_to_OUTSIDE_acl

permit ip any any

class-map type inspect self_to_OUTSIDE_cmap

match access-group name self_to_OUTSIDE_acl

policy-map type inspect self-TO-OUTSIDE_policy

class type inspect self-TO-OUTSIDE_cmap

inspect

class class-default

drop log

zone-pair security OUTSIDE-TO-self source OUTSIDE destination self

service-policy type inspect OUTSIDE-TO-self_policy

zone-pair security self-TO-OUTSIDE source self destination OUTSIDE

service-policy type inspect self-TO-OUTSIDE_policy

Re: Blocking outside access to router

jeremy0463 — Sun, 31 Dec 2023 23:12:34 GMT

I feel like I’m confused now

Re: Blocking outside access to router

MHM Cisco World — Sun, 31 Dec 2023 23:17:01 GMT

Dont confused' in late night of Monday I will send you some note.

Dont worry

Happy new year friend

MHM

Re: Blocking outside access to router

Rob Ingram — Sun, 31 Dec 2023 23:46:06 GMT

@jeremy0463 for outside to self policy map just reference the class-default class which will drop the traffic from outside to self, as per your requirements.

Re: Blocking outside access to router

MHM Cisco World — Mon, 01 Jan 2024 16:21:34 GMT

it long time from last year LOL...
NOW let start
classify the Zone
there is
1-default Zone which all interface member of it unless you make interface member of other Zone (this use for though the box)
2-Zone, simple way config zone with name IN and OUT or LAN and WAN ...etc.
3-Self Zone this include the all interface in this device (use for to-box traffic)

Zone Pair
1-to-Self-from-Out
traffic like
1- icmp
2-telnet
3-SSH
4-VPN IPSec UDP 500/4500
5-http

use class match-any let called it Class Port

traffic toward specific IP
use acl
use class match all let called it Class IP

finally we config class let called it Class to-self match all under it we match class Class Port and Class IP

for policy we use Class to-self and action is
1- Pass if we dont use other zone pair from-Self
2- Inspect if we use other zone pair from-self

1-from-Self-to-Out
this zone if you want to ping from router to other and telnet from it to other.
traffic like
1- icmp
2-telnet
3-SSH
4-VPN IPSec UDP ports 500/4500
5-http

use class match-any let called it Class Port

note:- you can optional specific IP that router can ping or make it open

finally we config class let called it Class from-self match all under it we match class Class Port

for policy we use Class from-self and action is
Inspect since we use to-self with inspect

that all what you need

you are free to ask if you have Q

MHM

Re: Blocking outside access to router

Sarahtaylor69 — Mon, 01 Jan 2024 16:27:29 GMT

agreed

Re: Blocking outside access to router

jeremy0463 — Mon, 01 Jan 2024 17:02:25 GMT

lol! Yes it has been a long time…haha

ok, let me get to working on this and I will report back. I’m going to do some more reading and start the firewall configuration over completely. I feel like there is a gap in my understanding of how zone based firewalls work. I will report back soon

Re: Blocking outside access to router

jeremy0463 — Mon, 01 Jan 2024 22:15:11 GMT

Ok, just got finished reading the ZBFW design doc all over again. Here is what I think I have come up with. Let’s just start over here:

——————————————————————————————————————————

Firewall requirements:

Allow all traffic from inside to outside
Deny all traffic outside to inside for now
Allow all traffic from self to outside
Deny all traffic from outside to self except VPN

***Configuration below uses Cisco default firewall configuration as a base***

——————————————————————————————————————————

1-2:

zone security INSIDE

description Zone for inside interfaces

zone security OUTSIDE

description Zone for outside interfaces

zone security default

ip access-list extended Web_acl

permit ip any any

class-map type inspect match-any Web_app

match protocol tcp

match protocol udp

match protocol ftp

match protocol icmp

class-map type inspect match-all Web

match class-map Web_app

match access-group name Web_acl

policy-map type inspect INSIDE-OUTSIDE-POLICY

class type inspect Web

inspect

class class-default

drop log

zone-pair security INSIDE-OUTSIDE source INSIDE destination OUTSIDE

service-policy type inspect INSIDE-OUTSIDE-POLICY

interface gigabitEthernet 0/1/0

zone-member security INSIDE

interface Vlan1

zone-member security INSIDE

interface Vlan250

zone-member security INSIDE

interface gigabitEthernet 0/1/0

zone-member security OUTSIDE

Comments - This configuration defines three zones, which by default are deny according to the ZBFW rules. A class map “Web” has been defined to inspect and match all traffic in the Web_acl and the Web_app class map. Inside each of those is a match any. So as I understand it, what happens is, any traffic from inside to out must match anything in the acl and any traffic in the class map in order to be permitted. This seems to allow restricting/permitting particular clients or networks and more generally, particular protocols. So if I wanted to allow https but not http, I would do that in the class map. If I wanted to restrict internal subnets from getting through, I would specify only the ones I wanted to get through in the acl. The policy map INSIDE-OUTSIDE-POLICY then performs the action. It inspects based on the web class map and permits but inspects that traffic. Then everything else is dropped and logged based on the class class-default. In this case, all traffic is inspected but permitted from inside to out. Since the zone outside and inside are defined, but no policy is in place for outside to inside, all traffic is denied by default. This seems to accomplish the first two objectives in the requirements. If I wanted to allow som out-in traffic at some point, I would need to do the same configuration as above for the out-in policy, limit to particular ip addresses in the acl, and limit to particular protocols in the class map with a new class map that was match all. Then I would inspect that traffic and then drop and log all other traffic based on class-default. Although, I’m not sure why I need the drop portion of the policy if the default is deny. Wouldn’t the policy allow what has been defined and drop everything else? Or is that only implicit when a policy does not exist?

Now on to the self zone.

According to the documentation, the self-zone a system defined zone is the only exception to the default deny all policy. All traffic to any router interface is allowed until traffic is explicitly denied. Therefore, it would seem that in this case, I can similarly configure the self-out policy to permit all traffic as above. However, I can’t leave out-self without a policy because it will implicitly permit all traffic. Therefore, I think this needs to be my self zone configuration:

ip access-list extended self_Web_acl

permit ip any any

class-map type inspect match-any self_Web_app

match protocol tcp

match protocol udp

match protocol ftp

match protocol icmp

class-map type inspect match-all self_Web

match class-map self_Web_app

match access-group name self_Web_acl

policy-map type inspect self-OUTSIDE-POLICY

class type inspect self_Web

inspect

class class-default

drop log

zone-pair security self-OUTSIDE source self destination OUTSIDE

service-policy type inspect self-OUTSIDE-POLICY

4: (This one is the one I am not sure about)

ip access-list extended Web_self_acl remark: in place to permit future vpn ip addresses

deny ip any any

class-map type inspect match-any Web_self_app remark: left empty to add vpn protocols

class-map type inspect match-all Web_self

match class-map Web_self_app

match access-group name Web_self_acl

policy-map type inspect OUTSIDE-self-POLICY

class type inspect self_Web

pass remark: because layer 7 can’t be inspected?

class class-default

drop log

zone-pair security OUTSIDE-self source OUTSIDE destination self

service-policy type inspect OUTSIDE-self-POLICY

Comments: now I know I could simplify #4 to policy-map type inspect OUTSIDE-self-POLICY

class class-default

drop log

But I want to leave room for vpn from specific addresses. And I may even permit all in the acl in order to use the client to site vpn so I could connect from anywhere. But this is where I am. Does this seem right and like I understand everything correctly? This is after reading this article again (https://www.cisco.com/c/en/us/support/docs/security/ios-firewall/98628-zone-design-guide.pdf) and the articles you guys posted.

Re: Blocking outside access to router

MHM Cisco World — Mon, 01 Jan 2024 22:57:37 GMT

all is correct, and I also check your point 4,
I check if by default the traffic between the OUT and Self is permit or not
and I get result it permit by default
I run IPSec VPN and the tunnel is UP and traffic is pass between two routers (after allow traffic from IN/OUT to OUT/IN)
so your steps to deny the traffic is override the default and deny any VPN

MHM

Re: Blocking outside access to router

Rob Ingram — Mon, 01 Jan 2024 23:16:14 GMT

@jeremy0463 For your "Web_app" class map you should reorder you match protocols. FTP should be above TCP, otherwise the
FTP connection is going to match on TCP and not treated as an FTP connection, this would probably cause problems with FTP.

On "self_Web_app" you cannot match on L7 protocol "ftp" and inspect on a self zone.

Using a "deny ip any any" on "Web_self_acl" means traffic will not match class-map "Web_self" and will subsequently be dropped by class-default - not sure that was your intention?

Re: Blocking outside access to router

jeremy0463 — Mon, 01 Jan 2024 23:20:15 GMT

Awesome, I feel like I’m understanding the concept now. On 4, yes, I intended to deny all for now until I get around to setting up the vpn. For now, the policy should deny all traffic from outside to self.

Re: Blocking outside access to router

MHM Cisco World — Mon, 01 Jan 2024 23:28:00 GMT

Yes I see and it more secure.
for IN-OUT you match any protocol and action is inspect this will allow traffic from IN to OUT match protocol + prefix
and since you use inspect NOT pass the return traffic can permit from OUT-IN
that different between inspect and pass
have a nice day and happy new year
MHM

Re: Blocking outside access to router

jeremy0463 — Mon, 01 Jan 2024 23:29:41 GMT

Oh yeah, I remember reading that somewhere about order for ftp. Noted. I will reorder those.

On the layer 7 inspection part, would this work:

ip access-list extended self_Web_acl

permit ip any any

class-map type inspect match-any self_Web_app

match protocol tcp

match protocol udp

match protocol ftp

match protocol icmp

class-map type inspect match-all self_Web

match class-map self_Web_app

match access-group name self_Web_acl

policy-map type inspect self-OUTSIDE-POLICY

class type inspect self_Web

pass

class class-default

drop log

zone-pair security self-OUTSIDE source self destination OUTSIDE

service-policy type inspect self-OUTSIDE-POLICY

And on the last part, yes I intended to drop all traffics grout outside to self for now until I can get around to setting up vpn. I’ll start another post for that eventually.

Re: Blocking outside access to router

jeremy0463 — Mon, 01 Jan 2024 23:33:38 GMT

Plus swapping the protocol order, forgot to do that before posting