Local traffic - ICMP workaround

[sandeep_fgt]

Hi Guys,

There was a weird situation where I applied a workaround to fix for now. Just wanted to know if there is any other good solution I can deploy in my environment.

Issue: Users were unable to ping the default gateway (setup on Fortigate) though the interface had PING enabled. After analyzing the logs, I found that the FG was dropping off the packet considering it to be high threat. The issue seems to be the admin profile I had setup on the device. There were only 2 subnets which were defined as protected subnet. I guess the issue was the Fortigate considering only the management traffic trusted only from the defined protected subnet and rest all as untrusted, so it was dropping packets for untrsuted network even when they were connected directly to the Fortigate. 

Workaround: I created a test profile with no access and applied it on a test user profile. After this, the FG interface started responding.

So, just wanted to know if there is any CLI command where I can defined PING to be allowed from any network for the PING enabled interface?

Thanks!

Sandeep Jha

[ede_pfau]

hi,

this is known behavior. If you protect admin access with "Trusted Hosts" ping from arbitrary networks will be blocked.

The fix is easy.

"Trusted Hosts" will create a local-in policy. This kind of policy controls traffic to the FGT itself. Local-in policies are only visible in the CLI ("config firewall local-in").

If you check the local-in policy you could add "ping" to the allowed services.

The other workaround with a dummy admin is very valid as well.

Please read the most recent post on this subject here: [link]https://forum.fortinet.com/tm.aspx?m=126290[/link]

[sandeep_fgt]

Thanks for the response. Good to know from you..

I can see the local-in firewall policy and even after removing the dummy profile I created, it remains same allowing ICMP_ANY service. I have a query- does Fortigate check for threshold count before considering the source untrusted and then modify the local-in FW policy?

Regards,

Sandeep Jha 

[Toshi_Esumi]

I never heard of FG modifies something configured statically, like policies, based on traffic. If it does in controllable fashion that would be great. Does it?

[ede_pfau]

I don't know the inner workings and dependencies between GUI "Trusted Hosts" and the local-in policies. But fortunately I don't have to. The local-in policies are effective - traffic traverses top-down. If not matched at the end traffic reaches the management.

[ede_pfau]

I think you got me wrong. Sometimes settings in the GUI "look" different or are spread over several distinct settings in the CLI but still they need to be changed manually. For example, checking the option "Use dedicated management port" in the HA setup GUI sets up 3 options in the CLI, "config system ha".

I would always expect that both representations are in sync at all times. Removing the dummy admin should then change the local-in policy as well. If not, I'd consider this a bug.

[ede_pfau]

@sandeep:

Now I got you wrong, sorry.

The "Trusted Hosts" are trusted because you declare them to be. It's a whitelist of IP addresses for admin access.

If you want to further protect the admin access (without TH) then you may add an IPS rate filter to a local-in policy. Rate filters looks for certain events (traffic patterns) which are detected by an IPS signature, count and time them and trigger an action if the event occurs more often per time unit than specified. The client IP address is then either blocked permanently or suspended for some time period.

The goal is to prevent brute forcing a password protected access.

In the past, I've posted such an IPS rate filter here, searching should find it. In v5.2, IPS rate filters can be created in the GUI. The difficult part probably is how to detect an invalid login attempt, by scanning either client traffic or the server's response messages.

[emnoc]

If you want to further protect the admin access (without TH) then you may add an IPS rate filter to a local-in policy

Are we 100% sure about this? I do not believe a IPS security profile can be added to either local-in-policy or local-out-policy. Unless this is a new v5.2.4 feature.

I always like to look at "TH" as  security for  a layer3  network+system-admin while  local-in-policy is a layer3 ACL for the firewall.

Ken

[sandeep_fgt]

If you mean that the issue was caused due to IPS action, I would agree with you to great extent. The Local-in-policy had the ICMP allowed and again the issue was encountered today. So, my solution with a profile with no access defined with protected subnet allowed accessible any was the right solution and working now..

[ede_pfau]

Ken,

no, we both are only assuming that local-in policies can take an IPS sensor. It would just be beautiful to assume that a similar construct would allow similar options. I didn't have the resources on Sunday to test this but may do so in the next days.