Explorer III

Question

External Connectors in Local In Policy and IPv4 DoS policy

Forum|Forum|3 years ago
January 26, 2023
6 replies
5543 views

Hello
How can I use the "IP Address Threat Feed" previously created in External Connectors as "srcaddr" in the "Local In Policy" and "IPv4 DoS Policy" rules?
Attempts to add in the CLI end with an error message. When building a DoS Policy rule in the GUI, in Source Address it is not possible to select the previously created "IP Address Threat Feed" because it is not visible there.
Any hints?

FortiGate

fredery

Staff

Hello wotik,

"Local In Policy" and "IPv4 DoS Policy" are optimized mechanisms which haven't been developed with the full NGFW features like those available in "Firewall Policy". Dynamic objects, including from Threat feed are not supported. While I am not aware they are planned to be added, they may be in the future if this needed by the market. You can always ask your Fortinet account team and explain this is a feature you need to help steer the product development in this direction.

wotikAuthor

Explorer III

Hi

Thanks for the answer. Well, it's a pity...

In my opinion, this should be one of the basic functionalities. You will admit that adding entries to "Address" and later using them in policies is quite cumbersome in the case of a large number of records... :(

How can I submit a request to Fortinet to add this functionality?

fredery

Staff

Hello wotik,

I totally understand the need and the pain, let's just say the paradigm of having everything statically configured for management access is being modified quite bit in the last decade with the Cloud and all related technologies. You have to reach to your Fortinet account team to ask for this functionality.

Yurisk

SuperUser

I am trying to see how it would be useful and ... can't.

Local-in Policy - the idea for this management access policy is to white-list IPs, i.e. allow few and block anything else. Using dynamic external lists makes sense only to block with them, so then you are supposed to allow everything else? Bad idea.

DDoS Policy - is meant to compliment, not replace the Security Rules, which already have external feeds as source address with an action of Block. Why would duplicate the functionality? Additionally, DDoS control is meant to measure dynamically the session parameters from any host and block even the "good" hosts if they start behaving "badly". Limiting DDoS to source IPs in any form would reduce their functionality to ACLs, which btw Fortigate already has - hardware-implemented ACLs.

Regards

yurisk.info - all things Fortinet blog, no ads

wotikAuthor

Explorer III

Hey Yurisk,

Thanks for the answer. It has raised some doubts in my reasoning about security policies...

No, I'm not going to allow all network traffic in "Local In Policy" and block only selected addresses. What do I want to use it for? Some of the materials available on the Internet show that additional rules created in "Local In Policy" to block network traffic prevent further "processing" of this traffic by FortiGate. This reduces the CPU or RAM usage. It simply "rejects" the given move and does not analyze it. So I would like to use my "external connectors" to "reject" such traffic from specific IP addresses that I will specify. Alternatively, for complete blocking of traffic from specific countries by geolocation, as shown here This is an example of blocking traffic from a specific country in "Local In Policy". So is it blocking something that is already blocked by default (assuming I don't use any services in that country) and it makes no sense to you?

Yes, I am aware that the DoS policy only supplements my "Firewall Policy". And I don't plan to replace it with them. In another thread I asked about "Life of a Packet" in FortiGate. According to what @pminarik presented - https://community.fortinet.com/t5/Support-Forum/Priority-of-Local-In-Policy-and-IPv4-DoS-Policy/m-p/243936/highlight/true#M206096 - the DoS module is one of the first through which the packet passes. My intention is therefore, as in the case of "Local In Policy", to "kill" the unwanted packet much earlier before it possibly reaches the core firewall module and thus consumes FortiGate resources. "Killing" it also based on geolocation or a list of your own IP addresses.
What do you think about this course of action?

Yurisk

SuperUser

Hi Wojtek,

I've never heard about Local-in policies being less intensive to the Fortigate in processing, so cannot confirm nor deny it. Regarding usage pattern, yes, I still think it would add complexity and unneeded processing to those rules. BAsically, you want to allow specific IPs to access specific management ports, then deny any any. In newer versions, 7.2.x, indeed you have GeoIP option as source address, but the only use case I can think of is to restrict access to SSL VPN portal by Geo. But again, for that you can use Geo objects directly in the VPN SSL Settings, this will do the same job and will be more visible in configuration.

Reagrding the 2nd, yes, DDoS is processed before the security rules, but to use it as ACL you have to "full" the Fortigate by using very small -> 0 tresholds for DDoS protections, while using ACLs, which are also processed before security rules, you can block as expected and have it offloaded to the hardware as well.

There is no black or white here of course - every case should be assessed individually.

Regards.

yurisk.info - all things Fortinet blog, no ads

Sign up

Login with SSO

Login to the community

Login with SSO