Skip to main content
AlexFerenX
AlexFerenX
New Member
September 6, 2024
Question

Local-in policy for system admin user

  • September 6, 2024
  • 7 replies
  • 4772 views

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

 

7 replies

xsilver_FTNT
Staff
xsilver_FTNT
Staff
September 6, 2024

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-options#Restrict 

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
    AlexFerenXAuthor
    New Member
    September 6, 2024

    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
    Staff
    xsilver_FTNT
    Staff
    September 6, 2024

    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
      Staff
      vbandha
      Staff
      September 6, 2024

      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
        AlexFerenXAuthor
        New Member
        September 8, 2024

        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
        Staff
        vbandha
        Staff
        September 8, 2024

        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
          Staff
          vbandha
          Staff
          September 9, 2024

          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-admin/ta-p/339782

           

            AlexFerenX
            AlexFerenXAuthor
            New Member
            September 10, 2024

            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?

            Toshi_Esumi
            SuperUser
            Toshi_Esumi
            SuperUser
            September 10, 2024

            If you have to limit the allowed sources per admin user, only way to set the different restrictions is by trusthosts, because they're configured at each user, or per user.
            All other methods, regarless local-in-policies or regular (inter-interface) policies, can limit IP addresses and/or services/ports. Those policies can't look into the content of HTTP or SSH SYN packets ("username") to take different actions.

             

            Toshi

            vbandha
            Staff
            vbandha
            Staff
            September 10, 2024

            Hi @AlexFerenX 

            Well you have to be careful. It will not do it directly. You need to make sure that GUI access is not allowed on any other interface.

            The way you would do it is through the firewall policy mentioned in the article. You would mention both user group and IP under source in separate policies.
            So first policy would have user group with admin A and IP configured as X and second firewall policy would have user group with admin B and IP configured as Y.
            This way the traffic is passed to loopback interface only if both group and IP match.

            I have not tested this so you may need to test this to confirm. 

             

            Can you tell what is your larger concern here? 

            Is it that the admin may login with another admin's credential?

             

            You could also use Multi Factor Authentication for that. 

            Regards,

            Varun

              AlexFerenX
              AlexFerenXAuthor
              New Member
              September 10, 2024

              Hi @vbandha ,

              > Can you tell what is your larger concern here? 

              As I've answered before:

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

               

              > I have not tested this so you may need to test this to confirm. 

              the requirement is simple (again, for clarity keyword is: "scalable"). I understand you (personally) may not be obliged to provide a KB to cover it, but, Fortinet should... if it is possible.

               

              Thanks, Feren

              Terms & ConditionsAccessibility statement