Local-in policy for system admin user

[AlexFerenX]

Hi!

There seems to be a severe limitation with 'firewall local-in-policy' as scalable substitute for 'system admin' limit of 10 trusthosts.

Since (a) 'firewall local-in-policy' cannot reference 'system admin user' as allowed source; nor (b) 'system admin user' can specify a 'firewall local-in-policy' that may enforce access we seem to be stuck with trusthosts.

For example, a simplest security requirement is: two ('system admin' with 'wildcard' and 'remote-group') administrator users A & B, where A are only allowed from login from host X, and B are only allowed to login from host Y, how can this implemented using local-in-policy (or any other way except 'system admin' trusthosts)?

Feren

[mpandya]

https://community.fortinet.com/t5/FortiGate/Technical-Tip-The-difference-between-Local-in-policy-and...

[xsilver_FTNT]

Hi AlexFerenX,

first of all I'm not quite sure about WHY would you like to workaround trusted hosts?
As those are designed exactly to do what you seems me are trying to achieve.

Which is to limit specific admin to specific IP/NETs from which he can log into FortiGate's management interface.
Every single admin has his list of 10 trusted hosts.
And kindly note that those are not just "single host" IPs but actually subnets!
https://docs.fortinet.com/document/fortigate/7.4.4/administration-guide/014906/administrator-account... 

The local-in policies are on the other hand designed to generally block any traffic targeting FortiGate directly. So not a forwarded / pass-through traffic which is handled by regular firewall policies.
But traffic where some of FortiGate's interface IPs is actual destination address of the packets.

Those local-in policies and trusted hosts are two different tools.
However, they can work together as extended fortification for your FortiGate unit.

If you are worried about bad guys accessing your FortiGate from public side. And so you'd like to limit the access to management from outer world. Then how about to block it completely from outside and use one of Fortinet's VPN solutions to actually get "inside" the network. And then access FortiGate's management from internal / private side. And there you would have also firewall policies for VPN to further harden your perimeter.

[AlexFerenX]

Hi @xsilver_FTNT

thanks for replying...

> first of all I'm not quite sure about WHY would you like to workaround trusted hosts?

I think I answered this in very first sentence - "... as scalable substitute for 'system admin' limit of 10 trusthosts.". Perhaps unclear, but 10 isn't enough!! If FortiOS only allowed 10 "firewall local-in-policy" entries - would that be enough?

In our case, those 10 trusthosts are meant to cover a dozen Network and security appliances monitoring the Fortigate, in addition to multiple jumpservers used by administrators spread across multiple regions. [And.. no, this isn't about a single user, this is a 'system admin user' with 'wildcard' enabled - many different users authenticated/authorised using a single 'remote-group']

So... back to question:
> For example, a simplest security requirement is ... how can this be implemented using local-in-policy (or any other way except 'system admin' trusthosts)?

Is the answer... it cannot?

Feren.

[xsilver_FTNT]

Hi,

"dozen Network and security appliances monitoring the Fortigate" and wildcard user.

Well, admin accounts are usually for humans.
If you have that big network, then are you monitoring everything via SSH or HTTPS to FGT?
How about API access, or SNMP which has separate access rules?
I understand that if you have hundreds of jumphosts and would like to define every single of them as single IP/32 in trusted hosts that then you do not have enough of them. But aren't your jumphosts and management appliances actually in some management (OOB) subnets? Or how about VPN workaround limiting access.

As you found out, local-in-policy in let's say srcaddr accepts just firewall address objects, not a local users, admins or user groups. As it is NOT designed to trigger any authentication, but limit L2/L3 access to FGT's interfaces. Then it is not suitable to anyhow filter admins themselves, only their source IPs/Subnets where they can come from.
As I said, as complementary hardening, or replacement, for/to trusted hosts.

[vbandha]

Hi @AlexFerenX 
In addition to the recommendation mentioned above, you can also look into providing GUI access via Loopback interface. You can do port forwarding from Wan interface to a loopback interface and enable the HTTPS access on the loopback interface.

This will give you a lot more options over controlling this access compared to local in policy. You will need to create a firewall policy to allow this traffic and you can put restrictions on this policy as per requirement. You will not have limit of 10 trusted hosts here.

Regards,

Varun

[AlexFerenX]

Hi @vbandha 

thanks for replying...

Our administrative access isn't from Internet - it's either to 'system ha' 'direct-ha' interface IP address; or, via Intranet-facing VDOM to root VDOM's IP address connected to that VDOM using vdom-link or npuX-vlinkY inter-VDOM interfaces.

Your idea is interesting - perhaps you can formalize it by presenting associated CLI configurations - I'm sure surprisingly many would be very interested?

Feren.

[vbandha]

Hi @AlexFerenX 

As per your request, I will create an article going over the steps and post it here once it is published.

Regards,

Varun

[vbandha]

Hi @AlexFerenX 

Here's the article for using loopback interface to secure GUI access: 

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Use-Loopback-interface-to-secure-GUI...

[AlexFerenX]

Hi @vbandha 

I must be missing something... How does your KB facilitate this:

.. a simplest security requirement is: two ('system admin' with 'wildcard' and 'remote-group') administrator users A & B, where A are only allowed from login from host X, and B are only allowed to login from host Y, how can this implemented using local-in-policy (or any other way except 'system admin' trusthosts)?

I'm still dependent on trusthosts, to control access by different administrators - no?

BTW, something I don't understand - modern Fortinet KBs involve so many screenshots and explanations of the screenshots - why not just paste CLI configurations - KBs will be less ambiguous, more concise and easier to adapt? That KB can be 1/3 of the volume it is now - is there some incentive to pad out KBs?