A client of mine, had a specific security requirement for allowing remote management of a fortigate via SSLvpn remote access.
E.g of the network topology top view. Each remote nets are objects in the untrusted cloud space
Now the government agency they are working with wanted the following;
1: no direct ssh access
2: no direct telnet access ( that should be obvious but .....just in case )
3: no direct HTTP or HTTPs access ( the former protocol should be obvious to a security engineer as weak )
4: no ipsec vpn
5: A person must go thru a vpn to access the fortigate & by using ssl encryption
Now items #1,2,3 was simple we did not allowaccess ssh http https or telnet on our outside untrusted interface, but item #5 caused a wake of numerous round table discussions.
And knowing the gov, they wanted to install a 30K solution with yet another appliance for vpn access & controls just for gaining access to a dozen or so fortigate appliances.
BTW, they needed SSL access vrs IPSEC, due to a lot of foreign networks have a high degree of not allowing ipsec traffic to flow.
So I crafted a POC & that I'm proud to say they bought after careful review.
Here's what I did;
1: I built a vpn group and assigned it a unique ipv4 pool that we also set into our trusthost
2: we assigned a ipv4 address to the ssl.root interface ( yeap it's a interface like any other interface , in fact it's a tunnel interface hence the /32 mask )
3: Next we allowed the approved access management ( ssh ) over this sslvpn
Now I want to point out the following;
> This method is a little overkill for security , since we have ssh encryption encrypted into another encryption type ( SSL )
> Also if any sec-engineer screws up any sslvpn settings, they could disable the access
> Also in our case the remote vpn was authenticated via radius, so the user needs to have 1> a radius access account 2> and the local system administration account
Once again .......overkill, but than the average government wants overkill!
Now with strong crypto ciphers in the webvpn portal, you can now protect a weaker access that might be vulnerable ( SSH )
Do you recall the past debian OpenSSH keys issues ?
Here's the ssl.root cfg
And just create a ssl vpns setting and a portal that has tunnel-mode and assign the group.
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix -----a----t---- socpuppets ---dot---com
=( * * )=