Local traffic - ICMP workaround

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]

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 

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.

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.

@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.

 

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

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..

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.

Just tried it out. As in FortiOS v5.2.3, local-in policies cannot have an IPS sensor, actually no UTM at all.

Okie Dokie

I was just checkin since I never seen IPS sensors being applied to  a local-in|out-policy. I figured  FTNT didn't deployed this as new feature either, so I want to be 100% sure or corrected.

If the  OP is worried about brute-force attacks against the fortigate unit directly his only options are  the TH or local-in policies.Typically imho the "TH" meets 90-100% of the security concerns and by adjustment of the failed login attempts  you can steer away 99% of the bad logins.

the following with a 3600sec lockout is very good for securing the ship;

FGTEQXNYC4010839467  (global) # show | grep admin     set admin-console-timeout 300     set admin-lockout-duration 3600     set admin-lockout-threshold 5     set admin-port 1443     set admin-scp enable     set admin-ssh-port 7822     set admintimeout 15  

ymmv