Fortigate Securing for remote access ( untrust networks )

If you remember the use of  SSLVPN for remote management  in this blog;

http://socpuppet.blogspot.com/2015/03/sslvpn-sslroot-management-access.html

And running ssh management on a not-so-well known port;

http://socpuppet.blogspot.com/2014/12/hardening-your-unix-ssh-server-access.html

Will the final wrap, is for clients that need to allow pings access. Within fortiOS you allow ssh ping http https etc... via the set allowaccess command.

 Than allow the "admin" accounts access via the trusthost for ipv4 or ipv6

e.g  ( allow access)

So if you need to allow ping access, how do we do this securely. Simple, if you need to deploy the wildcards "any", you can define a user with  no access and then apply that user with a trusthost set for 0.0.0.0/0

e.g ( NOACCES user on my fgt & accprofile )

In the above we have an account profile named "NOACCESS"    for the users. A combination of two-factor authentication and with the token sent to a null email-account will ensure that NOBODY could brute-force the account via the admin account that has a trusthost of ANY for ipv4 or ipv6 networks.


And if he/she could access the unit ( the hacker ) , the account profile will ensure they have ZERO access.

e.g ( webgui and ssh.....both are blank with no permissions )

You still need to analyze any risk,  and if you need ssh/webgui open. And if yes to who, but restricting access via admin and accounts can easily be controlled and by deploying 2-factor authentication, you can almost with 120%  surety ensure that the account would not be hacked.

two-factor authentication should still deploy a strong based password, I like to use a 20+ character password and a not-common "administrator" name.



With the sslvpn management, you can stack various authentication requirements to ensure strong  security protocols for accessing the firewalls from remote networks that are deemed un-trusted.

Running https and ssh services on not-to-well-known ports, will eliminate like 99% of the script kiddies which is typically of obnoxious  & persistent group.

Ensuring stroing cipher support for ssh/https and eliminating "SSLv3" from WebGUI managements will ensure you can go to sleep without any worries.



Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
       o 
      /  \