Bug or documentation ambiguity concerning Trusted Hosts
Few days ago during a diagnostic, I was annoyed to find that I got no ping reply from my FortiGate 80c DMZ interface (ping sent from a server situated in the DMZ). But " PING" option in DMZ interface properties page has already been checked. After some fiddlings, I figured out that I also had to put source IP address in " Trusted Host" field of *any* administrator.
Now, there' s a problem (or two problems):
* The description of PING in the PDF documentation (fortigate-admin-40-mr2.pdf) says that
Interface responds to pings. Use this settings to verify your installation and for testing.
* The description of " Trusted Hosts" says that
The IP address and netmask of trusted hosts from which the administrator can log in.
But ping has nothing to do with " log in" , so in first reading, it was hard to imagine there' s a relationship between " trusted hosts" and " ping" .
It' s either a bug or a documentation ambiguity.
FortiOS 5.0.4, just ran into this same %#$%#%#$% bug, mis-feature, crappy documentation, whatever you want to call it.
There should be NO relationship between Administrators, Trusted Hosts, and the configuration for whether an interface will respond to PINGs!
I don' t give a rat' s *** WHY FortiNet ended up doing it this way. It' s wrong. It' s not " documented" , it' s a non-obvious (I found posts REFERRING to the KB entry, but my searches had turned up the KB entry itself), kluge. It makes no sense **IN TERMS OF HOW A REASONABLE ADMINISTRATOR EXPECTS A PRODUCT TO REASONABLY WORK**.
FortiNet, what were you smoking when you came up with this?
I have far too many other important headaches to suffer these kinds of insults...
Further, being forced to enable broad access so that PINGs would be possible also results, even though harmlessly in terms of real security threat, in the whole world being able to bounce off of the SSH front door, thus:
The following critical firewall event was detected: Critical Event.
date=2013-10-18 time=16:51:09 devname=FG100D3G13807731 devid=FG100D3G13807731 logid=0100032002 type=event subtype=system level=alert user=" root" ui=ssh(184.108.40.206) action=login status=failed reason=" name_invalid" msg=" Administrator root login failed from ssh(220.127.116.11) because of invalid user name"
In fact, because the only administrator which could log in is the totally unprivileged one, this couldn' t produce harm ... but it will produce a lot of junk log messages.
It really doesn' t matter that this incredibly poor design has been that way for a few years - it still deserves to be fixed.
I agree -- it' s crazy to add a junk user with no IP restrictions just for PINGs. That said, I do know other admins who prefer to completely ignore PING and thus the existing behavior is probably desired.
If anything, perhaps Fortinet could devise a way so that there' s an easy way to exempt PINGs from the IP restrictions without needing a totally separate username.
... run into same bug, on 5.0.7, wasting a day trying to figure out why pings were failing even though interface's allowaccess included 'ping'. [ping came about because needed to test routeability from FortiManager to Fortigate.]
The worst thing is that Fortigate provides no visibility for execution of this 'feature':
Show use the trusthost setting but like bob said a common practice for external access that's very tight is to allow forticlient and ssl.root management access. This will require your admin has ssh access or https over the ssl.root and the forticlient.
> ssl.root management access
we have a dedicated-to-VPN Gateway, ASA 5525 and I trust Cisco's AnyConnect.
In your opinion, Forticlient is a seriously reliable alternative?
In your website:
> And just create a ssl vpns setting and a portal that has tunnel-mode and assign the group.
Why not include the configuration and make the example complete?
I'll address both items.
#1 if you have a management gateway device than great, trust and filter that "trusthost" but that add more $$$$.$$ and complexity and a avg SMB/ENT probably will not buy a ASA or anotherdevice just for this purpose. I've have seen org do this and buy a dedicate sslvpn gateway like irepass , cyberroam or even plain jain OPENVPN, but all of that add one more tier and support which might be overkill for a smaller organization.
The vpnclient ( FTNT ) SSLVPN will allow a admin to access a device very securely, but ALL of the earlier risks mention above could be a showstop. Also one more risk; " if you have local-authentication or if your using remote-authentication, any changes or errors in these will become a "show stopper" for that admin account "
#2, i guess I could have built a full tunnel-mode example but that was not my intention. Plenty of example exist in either a fortinet kb, youtube-video, or cookbook.
The goal of that blog post was just to show and demo that the ssl.rootis a "interface" and has the same management functions as real or virtual-interface. So allowaccess with allowances for ping ssh, https, snmp , etc... does exist your trusthost will work also.
We've done some weird things in the past using this method to include trusthost of the sslvpn_pool member and statically assignment of address to a "particular" user. All of this was due to the government agencies had problem and issues with pure "ssh access" and the debian_ssh-keys issues in the pass. So double encrypting it in a secured and strong SSL_VPN just makes it all much better and limits your brute-force for ssh or weak ssh-keys.
Bottom line, just build a regular tunnel-mode sslvpn and allow the ssl.root allowaccess if you want the security of ssl/tls with or without client_side-certificate requirements.
You have a host of methods for gaining and restrict access from the outside untrusted networks with a fortigate that pretty much other security-appliance don't offer. If you don't want , or don't like to use the trusthost for the user profile. Research what you want, and means that you are attempting and go at it ;)
if you need to open up trusthost for pings but restrict ssh access ;
1: move the ssh port to something NONE tcp/22
2: deploy fortitoken via email/sms
or the best ( imho )
3: allow ssh / https for management after a successful sslvpn connection and still deploy the trust_host for the ssl_vpn SRC(s)
You should be controlling pings from the external untrusted or internal(s) via the set allowaccess command imho and further via the trusthost if you have it enabled.
That IS how I' m TRYING to control PING access. But the trusthost settings OVERRIDE the " set allowaccess ping" seting.
If ANY administrator has a trusthost setting (which of course all should), then NO host which does not appear in at least one administrator' s list of trusted hosts will be able to PING the interface. So at least one junk administrator with wide open " trusted hosts" will be required in order to allow PINGs. (And, we' ll start getting harmless but distracting notices about failed SSH logins, because the trusthost configuration of that same ' administrator' who is allowed to PING also makes it possible for any of those ' trusted' many-or-all Internet IP addresses to hit the SSH Server port, even though the SSH protocol is NOT selected in the " set allowaccess ..." configuration for the interface.)
It' s a bad design.
Sigh, and it may not even work as " cleanly" as all that. I turned off the trusthost entries for my unprivileged-administrator account a few hours ago (to stop getting the warning emails about failed SSH logins), and just now I got two more.
Most likely, it' s just a bug where the reconfiguration takes too long to fully take effect, or doesn' t take effect fully until a reboot, but I wanted to mention it here in case anyone knows something about it.
To re-state, the understanding I' ve developed is that, if ANY administrator has trusted hosts configured, then NO administrative access (no matter what is configured for each interface in set allowaccess) will actually be permitted from any IP address which does not appear in at least one administrator' s list of trusted hosts.
A few hours ago, I deleted the trusthosts settings for my one administrator who had had broad openness, so that I could PING randomly during testing, but just now I still got a couple of SSH login fail warnings through an external interface.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.