Hot!Yes, another Zones question

Author
bmduncan34
Bronze Member
  • Total Posts : 25
  • Scores: 0
  • Reward points: 0
  • Joined: 2017/07/05 10:33:11
  • Status: offline
2019/12/05 08:50:39 (permalink)
0

Yes, another Zones question

I have 52 interface pairs in my IPv4 policies and it's unwieldy.  I'm drafting a plan to build zones to make it more manageable.  I've seen where some admins recommend three zones; Inside, Outside and DMZ; and I've seen just two zones - Inside and Outside, where the DMZ interface was included in the Inside zone.  Following this logic couldn't I just build a single zone and put all interfaces in there?  Then all policies would roll up into the one Zone to Zone pair.  One answer I may guess would be "yes, you can do that but a little more structure will make it more intuitive".  Any comments, or best-practice recommendations or considerations?
 
BTW, I do know I'll have to delete all policies that reference any interface before I can move that interface into a zone.  So this isn't a trivial amount of work...
 
Thanks in advance.
#1

5 Replies Related Threads

    Kenundrum
    Gold Member
    • Total Posts : 155
    • Scores: 19
    • Reward points: 0
    • Joined: 2008/05/15 10:25:50
    • Location: Rhode Island, US
    • Status: online
    Re: Yes, another Zones question 2019/12/05 10:35:38 (permalink)
    0
    Fortigate Zones can be used for two purposes (for the most part). You can use them to simplify management of multiple interfaces with EXACTLY the same security requirements, or you can use them to abstract away the physical interfaces and make the configuration more portable and future-proof. I use them exclusively for the second purpose. You assign policies to zones that have meaningful names in order to be able to change the underlying physical ports without breaking all the configuration.
    In order to use them to simplify a significant ruleset- the interfaces inside the zones need to have the exact same security requirements as any policy you create will apply to all the interfaces. If port1 and port2 both need to access a system on port3, you can simplify that with a zone and turn the 2 rules into 1. The problem is that as soon as you have something attached to port1 that needs to access port3, but something on port2 must not access that same destination- you are stuck.
     
    I believe you are conflating Zones in the fortigate world with generic security zones when you refer to inside/outside/dmz. The answer there is it really depends on your needs. However, i would strongly caution against putting an "inside" interface in the same zone as a "dmz" interface. The nature of a typical DMZ is to segregate the devices receiving connections from the outside world and then specify which internal devices those DMZ systems are further allowed to talk to. You lose that ability by putting them into the same FGT Zone.
     
    If you have 50 interface pairs, and a significant number of them actually are identical in all ways, you may have some simplification from using zones to group interfaces. The long term best plan is to classify systems based on the data they contain and the other systems they communicate with. Define the guidelines for those and then use what the fortigate provides to enact that policy.
    For example, if you have users, web servers, database servers, and the internet. You may want the internet and users to be able to access web servers. Web Servers should be able to access database servers. Users and the internet should not access database servers directly. Users should be able to go out to the internet. Web servers and database servers should not be able to access the internet (except for maybe updates). If you then see that you have 5 physical interfaces that have only web servers connected to them- you can consolidate that to a zone. If you dont- you may be better off reorganizing some of the equipment to better align to that overall security plan and eventually you will see simplification.
     
    PS- that is just a simplified example- it's probably not the best idea to actually have internet users directly connecting to the same web servers internal users are connecting to unless the web servers are hardened to be able to sit on the internet.
    post edited by Kenundrum - 2019/12/05 10:39:40

    NSE4
    Some FGT500Es, 500Ds, 60Ds at work
    FWF60E, FWF80CM at home
    #2
    emnoc
    Expert Member
    • Total Posts : 5462
    • Scores: 355
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: online
    Re: Yes, another Zones question 2019/12/05 16:07:30 (permalink)
    0

    The problem is that as soon as you have something attached to port1 that needs to access port3, but something on port2 must not access that same destination- you are stuck.

     
     
    That's a 110% incorrect statement, we've been through this in quite a few other posts on this site , but just having 1 2 3 4 5 6 7 or even 10000 interfaces in a zone does not automatically mean it has access to all on the dst-zone.
     
    FWPOLICy are still src/dst zone AND src/dst subnets. So if you write the rule loosely than you would be correct, but if you write rule correct, then this is NOT an issue.
     
    e.g
     
    config system zone
    edit EXTERNAL
    set interface WAN1
    end
    config system zone
    edit INTERNAL
    set interface PORT1 PORT2
    end
     
     
    config sys int 
        edit PORT1
              set ip 10.1.1.1/24
        next 
        edit PORT2
              set ip 10.1.2.1/24
    end
     
     
    config firewall address
          edit PORT1_LAN
                 set subnet 10.1.1.0/24
          next 
          edit . PORT2_LAN
                 set subnet 10.1.2.0/24
          next
     
     
    config firewall policy 
        edit 10
           set src-zone INTERNAL
           set dst-zone EXTERNAL
           set srcaddr PORT1_LAN
           set dstaddr ALL
     
    etc....
     
    Ken Felix
     
    again most people do not understand zones or doing it wrong.
     
    Ken Felix
     
     
     

    PCNSE 
    NSE 
    StrongSwan  
    #3
    bmduncan34
    Bronze Member
    • Total Posts : 25
    • Scores: 0
    • Reward points: 0
    • Joined: 2017/07/05 10:33:11
    • Status: offline
    Re: Yes, another Zones question 2019/12/06 11:52:50 (permalink)
    0
    Thanks Ken.  That's what I was asking after - kinda best practices.  You don't need to include interfaces that only have exactly the same security requirements in a zone.  I could easily have only two zones - an Outside zone with WAN interfaces etc, and an Inside zone that also includes my DMZ zone.  To manage traffic between my LAN segment and my DMZ I would just say both source and destination interfaces were Inside, but then apply the correct addresses for source and destination and I'd be fine.  Technically you could create only one zone, with one interface pair (Zone to Zone), and be still very secure, with the correct addressing/services combinations.  You would have one single flat list of policies, which might not be as easy to manage as breaking things up to different interface pairs like Inside-Outside, Outside-Inside, etc.  Does all that sound valid?
     
    Thanks very much!
    #4
    boneyard
    Gold Member
    • Total Posts : 191
    • Scores: 8
    • Reward points: 0
    • Joined: 2014/07/30 11:15:18
    • Status: online
    Re: Yes, another Zones question 2019/12/07 03:11:08 (permalink)
    0
    it is a balance thing. like Kenundrum i always use zones with a one on one mapping to an interface for flexibility. then combine interfaces in one zone mainly on doing pretty much the same thing, i.e. two wan interfaces (although sd-wan interface is messing with that now), multiple client networks, add a second VPN tunnel.
     
    to combine almost all interface in one zone feels like a quick solution but not a real pretty one, you loose some of the logic zones bring and loose a good overview of your rule based in my opinion. you also have to be much more careful with rules blocking part of the traffic.
    #5
    emnoc
    Expert Member
    • Total Posts : 5462
    • Scores: 355
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: online
    Re: Yes, another Zones question 2019/12/07 06:28:54 (permalink)
    0
    Zones have to be thought out and src/dst address in the policy still controls the traffic flow. The only issue with zones, once you go zone you can NOT uses in the policy if it is in a zone. CHKP and Forcepoint bends this restriction.
     
    FWIW, I've seen very good zone deployments and very bad ones also.Most are deploying bad design and or deploying zones with made forethought but that's my opinion.
     
    I've use zones maybe 30% of the time, unless it's a PANW/JNPR migrations and in these 2 platforms it's 100% "zone" with no exceptions.
     
     
    Ken Felix
     
     

    PCNSE 
    NSE 
    StrongSwan  
    #6
    Jump to:
    © 2020 APG vNext Commercial Version 5.5