Bug or documentation ambiguity concerning Trusted Hosts

[horinius]

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.

[Jay_Libove · Accepted solution]

</VENT ON> 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... </VENT OFF>

[Jay_Libove · Accepted solution]

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(91.232.208.38) action=login status=failed reason=" name_invalid" msg=" Administrator root login failed from ssh(91.232.208.38) 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.

[AlexFeren]

... 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':

FGT60D-1 (border) # execute log display 1 logs found. 1 logs returned. 1: date=2015-10-21 time=17:58:04 logid=0001000014 type=traffic subtype=local level=notice vd=border srcip=10.161.1.46 srcintf="wan1" dstip=140.159.XX.YY dstintf=14 sessionid=149735 status=deny policyid=0 dstcountry="Australia" srccountry="Reserved" trandisp=noop service=8/0/icmp proto=1 app=8/0/icmp duration=0 sentbyte=0 rcvdbyte=0 and FGT60D-1 (border) # diag debug flow trace start 10 id=13 trace_id=130 func=resolve_ip_tuple_fast line=4299 msg="vd-border received a packet(proto=1, 10.161.1.46:1->140.159.XX.YY:8) from wan1." id=13 trace_id=130 func=init_ip_session_common line=4430 msg="allocate a new session-000248e7

No clue to explain deny, except policyid=0 which, at best, is unhelpful.

[emnoc]

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.

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

The bad or negative to  this approach;

    1: if the sslvpnd daemon dies;  you could be locked out

    2: if you mistakenly mess up your sslvpn settings ; you could be locked out

    3: if you delete or a fwpolicy or ; you could be locked out

YMMV may vary over this. Lately I've been using the fortitoken approach for both ssh and https management for external access. It's has proven to be 100% reliable.

Ken

[AlexFeren]

Hi Ken,

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

R's, Alex

[emnoc]

Hi Ken, > 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? R's, Alex

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.root is 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)

Ken

[Jay_Libove]

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.

Hi Emnoc, 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.

[Jay_Libove]

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.

[rwpatterson]

What some (most?) of us here do is turn SSH off on the public interface and manage via the SSL VPN login. Alternatively, you could just change the SSH admin port to some high port.