Multi-Vdom can open you up to more risk on a fortigate ( configurations access or lack of )

Okay,  this will be my last blog post for  the year 2014. If you remember the following two earlier  posts ;

http://socpuppet.blogspot.com/2014/08/your-fortigate-is-not-as-secured-as-you.html

and

http://socpuppet.blogspot.com/2014/09/a-stacked-vdom-concept-with-fortigate.html

I will demonstrate how one firewall administrator  & in a non-Management vdom,  can actually grab the configuration for all other vdoms. This means the following;

•   limited user of non-root-vdom can gather all other vdom cfg even regardless of your profile type

•   users of a non-Management vdom can gather ALL other  cfgs including root-vdom or the   defined management vdom

Now keep in mind that all critical  users accounts details, radius secrets , local users details,  vpn PSKs , and other passwords are hashed for security reasoons. But any other firewall administrator in a muti-tenant vdom setup,  could actually gain access to ALL of the configurations details of his own vdom and any other vdoms that's present on the security appliance.

To expanded  on this, if the user is assigned a RO account, he/she can still gather all other configurations details.

1st let's look at my  user  "custA", he's assigned into custA-vdom  & as a firewall administrator. His profile is a RO profile.

So now we will  ssh into the  firewall or even use https access, all we really need ; " is to get to the cli console to execute our commands  cli  fnsysctl  commands "






A copy of the full  saved and running configuration is stored in local directory /data2/config. Yes, it's that obvious,  and the  unprotected firewall configuration file is present with a time/date stamp to show you the most up todate configuration file.

note: My RO user assigned to  vdom-custA can see the config cfg that has permissions set for anybody to read.

So what this means from a muti-tenant  use firewall ; " you place your other tenant configurations details out in open , and at risk of being  reviewed  by another user ( administrator ) who happen to  have cli access & via a simple cli command ( fnsysctl ) "

Okay the best way to prevent this type of access;

1:  assign the firewall as a FIPS mode (  fnsysctl command accces is eliminated in FIPS-compliant mode  of operations )
http://socpuppet.blogspot.com/2014/09/hardening-your-fortigate-firewall-by.html

2:  disallow ssh/telnet access for not root-Management vdoms interfaces ( taken away the console access via these management access methods )

and

3:  remove the jsconsole widget-type from non-Management vdom firewall administrators account
 ( taken away the console access widget )

e.g

config global
    config sys admin
         edit <username>
           config dashboard
          delete 3
end



What I thought was funny, Fortinet took  the time effort to protect you from deleting or copying the file to another directory or a usb mount point, but you still have full read-access view of the configuration file on the security appliance by using cat or more  with the cli command fnsysctl

If you do try to move or copy the file, you will be challenged with the "Admin" passwords for a valid administrator  within the management-vdom

Just keep in mind  to  control what the "actual firewall administrator has access to " and the cli command  fnsysctl,  can be quite dangerous. It's a cli  tool that can expose everything from  ssh/ssk keys and configurations details. The FIPS mode of operations can protect you.

note: I just one to point out, that in a cisco ASA running multi-contexts, this risk is pretty much eliminated. A  user can't access the system configurations files without  changing to the system context and most important he/she will the priv-level for enable.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^
=(  @  @ )=
         o 
        /  \