Filtering by interfaces in policy

[Kempniu]

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.

[Kempniu]

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?

[ede_pfau]

No, you are correct. But think of a rogue host brought into your LAN, e.g. with an address 10.0.0.x. This policy will allow it to communicate with hosts in the 192.168.0.0 subnet without you ever knowing it. Same (to some extent) with the ' all' address. If used within an ' any' policy...you wouldn' t need a firewall at all.

[Kempniu]

In order for that rogue host to communicate with 192.168.0.0/16, it would have to be connected to the network through the one and only interface that the firewall uses to send traffic to 10.0.0.0/8 (interface A). Otherwise, RPF will block the traffic generated by the rogue host. If it' s connected to the right interface, I' m explicitly allowing it anyway. Could you please explain where the danger is (or what am I missing here)?

[g3rman]

I think it' s also important to note that when you create and address object and select " any" in the interface this doesn' t mean that your policy is necessarily using the " any" interface. When you create an address object and select an interface in the drop-down list this simply means that you can only use it in policies that reference the specified interface. For example you create a host called host-123 and select " port1" as the interface. Now you will only be able to use it in policies that are Source Interface: Port1 Destination Interface: Some other interface Some of the above discussion is also centered around creating policies using Source Interface: Any Destination Interface: Any This is different from what I believe your initial question was about.

[Kempniu]

I think it' s also important to note that when you create and address object and select " any" in the interface this doesn' t mean that your policy is necessarily using the " any" interface. (...)

Yes, all you' ve written is perfectly clear to me.

Some of the above discussion is also centered around creating policies using Source Interface: Any Destination Interface: Any This is different from what I believe your initial question was about.

Actually, this is exactly what my initial question was about. Yes, we drifted away a bit along the way, but the main issue for me here is to determine if there are any security drawbacks stemming from the use of the any interface in policies. Your answer was that there are none, but then ede_pfau suggested it might cause undesired traffic to be passed through the firewall. So far the picture I get is that using the any interface only increases the chance of human error while defining policies, but otherwise, if the policies are defined correctly, using specific interfaces/zones in policies does not increase the security of the setup because RPF is still in place. The only way I can be convinced that any is evil ;) would be to present me with a specific example of how can a firewall configured with policies using any be tricked into allowing traffic that wouldn' t be allowed by a corresponding configuration using specific source/destination interfaces/zones in its policies.

[g3rman]

Gotcha. I read your initial question as simply assigning interfaces to address objects. The " any" interface is not evil in and of itself, but rather, as has been pointed out, can make policies harder to read. Also, if you use 1 or more policies that have the " any" interface as source or destination you lose the " section view" in the GUI and can only use " global view" .

[Kempniu]

Your answer hits the spot - it is exactly what I needed to know, thanks! Though, ede_pfau, if you' d like to follow up on your rogue host example (or any other, for that matter), I' ll be happy to discuss it further.

[ede_pfau]

I think you can configure both designs in a secure way. The question is: which one is more intuitive and less prone to error? If i think of a policy with destination ' any' then I would have a hard time guessing which way my traffic flows, just from a look at the policy table. Of course, if you put in restricted address ranges you still can make it tight. The other aspect g3rman mentioned is worth noting: in ' global view' you see all policies laid out flat. No fun if the count exceeds a screenful. Back to the rogue example: what if - your LAN has a default address range (192.168.[0-2].x/24) as with so many real LANs out there - and someone brings along a small NAS or WLAN AP, loaded with a DHCP server, unsecured, with immediate full access to both your LAN and the internet. Does that sound dangerous enough?

[Kempniu]

These are all good points, thank you. I' m aware of the dangers you' ve mentioned. I' m still not following you with the rogue device example, though. Naturally, I understand the danger of users plugging in their own network devices into the infrastructure, but I can' t relate that to the issue of using/not using the any interface in policies, which is what we were discussing in this thread.

[ede_pfau]

OK. Still my first 2 points hold; IMHO the ' any' interface opens up the possibility to error unnecessarily. Fortigates are policy-based, and policies connect specific interfaces. When I am designing a policy I know which interfaces are in play. If I don' t know there' s something wrong with my design. Just my opinion.