Correct security policy for multiple intranet zones

Options
zyxelUser2021
zyxelUser2021 Posts: 9
First Anniversary First Comment
edited April 2021 in Security
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.

All Replies

  • PeterUK
    PeterUK Posts: 2,709  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    edited April 2021
    Options
    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.                                              
  • zyxelUser2021
    zyxelUser2021 Posts: 9
    First Anniversary First Comment
    Options
    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

  • zyxelUser2021
    zyxelUser2021 Posts: 9
    First Anniversary First Comment
    Options
    Tried myself: does not work.
  • PeterUK
    PeterUK Posts: 2,709  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    edited April 2021
    Options
    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.1
  • Zyxel_Can
    Zyxel_Can Posts: 342  Zyxel Employee
    Friend Collector First Answer First Comment
    Options

    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.

Categories

Security Highlight


Read more

Security Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）