Skip to main content
Kempniu
Kempniu
New Member
January 31, 2014
Question

Filtering by interfaces in policy

  • January 31, 2014
  • 20 replies
  • 16381 views
Greetings, I' d like to correctly understand how traffic filtering functions on a Fortigate 60C firewall. The specific matter I' d like to discuss is how filtering by source/destination interfaces in firewall policy influences security. Consider the following example: I have a unit with 4 tunnel interfaces - A, B, C, D - connecting it to remote networks. Each interface has a static route assigned to it: 10.0.1.0/24 via interface A 10.0.2.0/24 via interface B 192.168.1.0/24 via interface C 192.168.2.0/24 via interface D Let' s assume tunneling and routing already works properly. Now, I want all IPv4 traffic from A and B to C and D to be allowed. Please consider two alternate scenarios: SCENARIO 1. Each network has a firewall object created with the relevant interface assigned: NET_A: 10.0.1.0/24 (interface A) NET_B: 10.0.2.0/24 (interface B) NET_C: 192.168.1.0/24 (interface C) NET_D: 192.168.2.0/24 (interface D) Because objects belonging to different interfaces cannot be grouped into a firewall address group, four separate allow policies have to be created: a) source interface: A source address: NET_A destination interface: C destination address: NET_C b) source interface: A source address: NET_A destination interface: D destination address: NET_D c) source interface: B source address: NET_B destination interface: C destination address: NET_C d) source interface: B source address: NET_B destination interface: D destination address: NET_D SCENARIO 2. Each network has a firewall object created without assigning it to a specific interface: NET_A: 10.0.1.0/24 (interface any) NET_B: 10.0.2.0/24 (interface any) NET_C: 192.168.1.0/24 (interface any) NET_D: 192.168.2.0/24 (interface any) Because these objects aren' t assigned to a specific interface, two firewall address groups can be created to group networks together: NET_AB: NET_A, NET_B NET_CD: NET_C, NET_D With these firewall address groups, I can enforce the same traffic filtering rules as in scenario 1 with only one policy: source interface: any source address: NET_AB destination interface: any destination address: NET_CD The question. Is scenario 2 any less secure than scenario 1? As far as I understand, the firewall will perform reverse path checks for every packet traversing it, so even though we don' t specify source/destination interfaces in scenario 2, any invalid packets (e.g. packet with source address 10.0.2.1 received on interface A) will still be dropped as they will fail the reverse path check.

    20 replies

    g3rman
    g3rman
    New Member
    February 12, 2014
    Hi Kempniu, welcome to the forums. Go with option 2. As you already figured out it' s exactly the same as option 1. Assigning objects to interfaces does not provide anti-spoofing a la Checkpoint. Reverse path check works off of the routing table.
    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    February 12, 2014
    I suggest you look into the ' zone' firewall object to group interfaces together. That would simplify your policy table a lot. Simple setup = secure setup. Zones are not only groups of (interface) names but for what you are planning this picture fits. Binding an address object to an interface helps in configuring - you cannot populate an policy address field with an address that will never show up on the connected interface. But that' s about all you gain. With less than 20 policies you wouldn' t really need this. The drawback of binding is that you cannot re-use an address object when the corresponding host moves. You will have to delete and recreate the address. So I tend to avoid binding. One good advice: avoid the ' any' interface. It literally means ' from any source' so that it is very easy to loose sight which way your data is flowing through the policy table.
    Kempniu
    KempniuAuthor
    New Member
    February 12, 2014
    Thank you both for your input, it' s very helpful. ede_pfau, after reading your post, this is the picture I get: 1. Assigning interfaces to firewall address objects doesn' t increase security, it' s only helpful when there' s a lot of addresses and/or interfaces configured on the firewall. 2. I should consider segregating interfaces into zones and using them instead of the any interface. Please correct me if I got anything wrong. Following up on point 2: what if I' m defining policies for a hub in a star network (one hub, multiple spokes connected via VPN) and I want certain traffic (say, HTTP) to be allowed between all spokes (assume all traffic between spokes is flowing through the hub)? Should I define a zone consisting of all the VPN interfaces (but not the default gateway interface) and use it instead of the any interface? Is this the way of thinking you' re suggesting? The problem is that a single interface cannot be used in multiple zones - but I suppose a reasonable workaround is to define multiple zones as source/destination interfaces in policy definition when needed.
    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    February 12, 2014
    1. yes. It helps while creating or changing policies. No impact on data flow control. 2. You are combining interfaces in a zone. 3. For the hub-and-spoke scenario, to allow intra-zone traffic with policy control you create a policy from ' myZone' to ' myZone' and specify the service and other constraints. This gives you full control over the traffic between zone members. 4. An interface that is member of a zone cannot be used as just an interface in an other policy. (at least that is what I think, I might be wrong here. Seems to depend on the FortiOS version as well, especially v5 has more restrictions.)
    Kempniu
    KempniuAuthor
    New Member
    February 12, 2014
    4. Indeed - any interface which is part of a zone is unavailable on its own in policy definition. But it gets worse - if I define two zones, each containing several tunnel interfaces, I cannot use both these zones in a single policy (CLI returns " Cannot use tunnel interface in multiple interfaces." ). So if I wanted to use this technique for a scenario involving tunnel interfaces, I' d have to define multiple similar policies (one for each source/destination zone pair) instead of just one with any specified as source, right? Because this is specifically what I wanted to avoid. As you said, simple policy is good policy, as long as it' s secure of course. Oh, and about that: apart from policy readability, does using the any interface introduce any security risks? Won' t the reverse path check filter out unwanted traffic anyway?
    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    February 12, 2014
    Maybe I don' t understand quite right what you tried when you got the error message. Anyway, you cannot put the same interface into multiple zones. And you cannot use the interface by itself in a policy if it is part of a zone. But in your case... say you have 5 VPN tunnels, all in Interface mode: Rome, Vienna, Prague, London, Paris. On your gateway you have these policies: zone: ' VPNs' , members: Rome, Vienna, Prague, London, Paris src IF: internal src addr: HQ_LAN dst IF: VPNs dst addr: all service: ANY NAT: disable This allows traffic from HQ into the remote offices. Use a similar policy if you want to allow traffic from the offices into HQ. Now for traffic between offices: src IF: VPNs src addr: all dst IF: VPNs dst addr: all service: HTTP NAT: disable That should work. But no policies from HQ to e.g. Rome or vice versa. Zones are more or less the only practical way of handling a hub-and-spoke design with more than 4-5 tunnels.
    Kempniu
    KempniuAuthor
    New Member
    February 12, 2014
    Maybe I don' t understand quite right what you tried when you got the error message.
    What I was trying to do is the following: a) define zone ZONE_WX consisting of tunnel interfaces W and X, b) define zone ZONE_YZ consisting of tunnel interfaces Y and Z, c) define a single policy with source interface specified as ZONE_WX or ZONE_YZ (set srcintf " ZONE_WX" " ZONE_YZ" ). Such a configuration is not possible. That last step (followed by next or end) executed on the CLI produces the error message I' ve quoted. I understand the examples you' ve given, thank you for providing them. However, I still haven' t heard a response to the last question from my previous post:
    (...) apart from policy readability, does using the any interface introduce any security risks? Won' t the reverse path check filter out unwanted traffic anyway?
    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    February 12, 2014
    RPF check will still work as expected. Only the flow of data through the policies can be contrary to what you expect if using the ' any' interface. That' s why I recommend not using it. Putting multiple zones into the ' Interface' entry is possible in FOS v5. Which version do you use?
    Kempniu
    KempniuAuthor
    New Member
    February 12, 2014
    Yes, it is possible, as long as all the zones you use consist of only physical interfaces. The problem reveals itself once you satisfy both of the following conditions: 1. use more than one zone for input interface or output interface, 2. at least one of the zones from the ones you' ve selected contains a tunnel interface. I' ve just tested it on FortiOS 5.0.6 running on a Fortigate 60C.
    Kempniu
    KempniuAuthor
    New Member
    February 12, 2014
    I' ve also given a little bit more thought to what you wrote about data flowing contrary to what one might expect when using the any interface. I can' t think of such a situation for non-overlapping address pools defined as source and destination addresses. If I define a policy like this: src IF: any src addr: 10.0.0.0/24 dst IF: any dst addr: 192.168.0.0/16 service: HTTP NAT: disable where 10.0.0.0/24 is only available via interface A and 192.168.0.0/16 is only available via interface B, how can this policy match any other traffic than HTTP sessions initiated from A to B? I understand that when the address pools specified as source and destination overlap, that' s where things start to get confusing, e.g.: src IF: any src addr: 10.0.0.0/16 dst IF: any dst addr: 10.0.0.0/8 service: HTTP NAT: disable where 10.0.3.0/24 is only available via interface C and 10.0.4.0/24 is only available via interface D, then such a policy will allow both HTTP sessions initiated from C to D and vice versa. But I' m aware of that. Is there something I am missing here? If so, could you please come up with an example?
    Show more replies
    Terms & ConditionsAccessibility statement