Correct security policy for multiple intranet zones
zyxelUser2021
Posts: 9
I'd like to know, is there a correct (secure) way to control several zones in one policy in USG devices (USG20, for example).
Consider we have the following internal networks, grouped into three intra zones and one WAN zone:
Network Zone Purpose
192.168.0.1/24 SERVICE Intranet servers (our server)
192.168.1.1/24 SERVICE Storage devices
192.168.2.1/24 OFFICE Office computers
192.168.3.1/24 GUEST Guest network
x.x.x.x WAN Wan (all traffic via NAT)
We want to allow all intra hosts (i.e. all hosts in SERVICE, OFFICE or GUEST zones) to access a server 192.168.0.100 in SERVICE zone, but make sure no unwanted traffic from WAN gets there.
Because a network cannot belong to several zones, we would need to have several zone-based rules:
Allow from OFFICE to SERVICE destination 192.168.0.100
Allow from GUEST to SERVICE destination 192.168.0.100
Allow from SERVICE to SERVICE destination 192.168.0.100
This can be problematic to maintain if there are large amount of internal networks, zones and individual services to control.
Networks can be grouped, and we could do a similar setup with network-based rule:
INTRANETS_GROUP = 192.168.0.1/24, 192.168.1.1/24, 192.168.2.1/24, 192.168.3.1/24
Allow from ANY source INTRANETS_GROUP to SERVICE destination 192.168.0.100
This contains a doubt: is this safe? Because we would allow "192.168.x.x from ANY zone", we could unintentionally allow packets originating e.g. 192.168.3.1 also from WAN zone.
There are many ways to prevent this, but what would be the safe setup? We want to be absolutely sure that no unwanted packets enter the intranet zones and separate rules for each zone is not an option.
Assume the WAN side is public internet with no private RFC1918 networks to intentionally communicate with. Rogue packets could have any addresses, even those 192.168.x.x, 10.x.x.x., multicasts etc. Nat is in use.
Consider we have the following internal networks, grouped into three intra zones and one WAN zone:
Network Zone Purpose
192.168.0.1/24 SERVICE Intranet servers (our server)
192.168.1.1/24 SERVICE Storage devices
192.168.2.1/24 OFFICE Office computers
192.168.3.1/24 GUEST Guest network
x.x.x.x WAN Wan (all traffic via NAT)
We want to allow all intra hosts (i.e. all hosts in SERVICE, OFFICE or GUEST zones) to access a server 192.168.0.100 in SERVICE zone, but make sure no unwanted traffic from WAN gets there.
Because a network cannot belong to several zones, we would need to have several zone-based rules:
Allow from OFFICE to SERVICE destination 192.168.0.100
Allow from GUEST to SERVICE destination 192.168.0.100
Allow from SERVICE to SERVICE destination 192.168.0.100
This can be problematic to maintain if there are large amount of internal networks, zones and individual services to control.
Networks can be grouped, and we could do a similar setup with network-based rule:
INTRANETS_GROUP = 192.168.0.1/24, 192.168.1.1/24, 192.168.2.1/24, 192.168.3.1/24
Allow from ANY source INTRANETS_GROUP to SERVICE destination 192.168.0.100
This contains a doubt: is this safe? Because we would allow "192.168.x.x from ANY zone", we could unintentionally allow packets originating e.g. 192.168.3.1 also from WAN zone.
There are many ways to prevent this, but what would be the safe setup? We want to be absolutely sure that no unwanted packets enter the intranet zones and separate rules for each zone is not an option.
Assume the WAN side is public internet with no private RFC1918 networks to intentionally communicate with. Rogue packets could have any addresses, even those 192.168.x.x, 10.x.x.x., multicasts etc. Nat is in use.
0
All Replies
-
Its safe as OFFICE, GUEST and SERVICE subnets from any zone can only go to 192.168.0.100
The only thing I be worried about is you used SERVICE for both 192.168.0.1/24 and 192.168.1.1/24
The USG20 has fixed zones on untagged interfaces so your LAN1 for a given port can not be changed but you can do VLANs based on that port for a given zone name.0 -
Thanks for the reply!The SERVICE zone assigned for two networks is intentional exception: it's just an example that classifies two networks in one cagegory (to be able to do policies inside the SERVICE zone).But what happens to a rogue packet that arrives from WAN, with source address e.g. 192.168.2.100 and targeting 192.168.1.100? (Normally this shouldn't happen, but let's assume there is a hacking attempt going on). Even if the SERVICE zone server's response would not be able to reach the sender on WAN, the incoming packet could still do harm.About the LAN1 zone:Do the LAN1 and LAN2 zones include the mentioned (vlan-based) traffic? That would be the optimal solution.I mean this scenario:LAN1 being the untagged port for:
- vlan1 (zone SERVICE)
- vlan2 (zone SERVICE)
- vlan3 (zone OFFICE)
- vlan4 (zone GUEST)
Could this do the trick:Allow from LAN1 to SERVICE destination 192.168.0.100
0 -
Tried myself: does not work.
0 -
The rogue traffic would likely be dropped I would think as the targeting IP 192.168.0.100 is not to the WAN IP.
But if you did a NAT rule to forward a port to 192.168.0.100 then if on the WAN you have from source address 192.168.2.100 to WAN IP then the rule
Allow from ANY source INTRANETS_GROUP to SERVICE destination 192.168.0.100
might be allowed?
What I have done is put a switch upstream to block rfc1918 only allowing 10. for DHCP and 192.168.100.10 -
Thank you @PeterUK.
Hi @zyxelUser2021,
Apart from PeterUK’s recommendation you can create multiple Security policy rules for each zone.
The safest way for this setup would be creating Security Policy rules one by one as you mentioned before.
0
Guru Member
Zyxel Employee
Categories
- All Categories
- 415 Beta Program
- 2.5K Nebula
- 152 Nebula Ideas
- 101 Nebula Status and Incidents
- 5.8K Security
- 296 USG FLEX H Series
- 281 Security Ideas
- 1.5K Switch
- 77 Switch Ideas
- 1.1K Wireless
- 42 Wireless Ideas
- 6.5K Consumer Product
- 254 Service & License
- 396 News and Release
- 85 Security Advisories
- 29 Education Center
- 10 [Campaign] Zyxel Network Detective
- 3.6K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 87 About Community
- 76 Security Highlight
