Skip to main content
horinius
horinius
New Member
February 28, 2013
Solved

Bug or documentation ambiguity concerning Trusted Hosts

  • February 28, 2013
  • 12 replies
  • 25606 views
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.
    Best answer by Jay_Libove
    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.

    12 replies

    Show previous replies
    emnoc
    emnoc
    New Member
    October 19, 2013
    In reality their' s a lot of drama over nothing. 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. I don' t personally think it' s a bad design, except that person are using it in the wrong fashion & expecting a different outcome. So what if you need to create a few junk accounts as so-called. This is a security appliance & should be thought of just that " security" appliance :)
    AlexFeren
    AlexFeren
    New Member
    October 21, 2015

    ... 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
    emnoc
    New Member
    October 21, 2015

    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

     

    Jay_Libove
    Jay_Libove
    New Member
    October 21, 2013
    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
    Jay_Libove
    New Member
    October 21, 2013
    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
    rwpatterson
    New Member
    October 21, 2013
    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.
    Terms & ConditionsAccessibility statement