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.

[rwpatterson]

Wow, is that OLD or what? Version 2.80?

[horinius]

ORIGINAL: TopJimmy I don' t see it as a bug …

LOL So what?? You don' t see it as a bug doesn' t mean you are correct. It only means your logic has flaw. It' s written " The IP address and netmask of trusted hosts from which the administrator can log in" for Trusted Hosts field. Ping is not associated with log in. So either the sentence or the implementation is incorrect. QED! Mind you that I have found the " workaround" to make it work before I made the post, but that doesn' t mean I agree with it.

ORIGINAL: TopJimmy … and documentation exits on it. Just search the KB..I did. http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=10876&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=43714791&stateId=0%200%2043716303

That, you called it " documentation" ? Come on! I would call it " disordered, odds and ends, slacky patchworks to remedy the shortcoming in the official documentation" . What I mean by " documentation" are those published as PDF. Moreover, the very existence of this article proves further that the corresponding part in the official documentation is not clear. The other day when I came across this " problem" , I had called a Fortinet-agreed company for technical assistance and they were unable to figure this out! LMAO

[ede_pfau]

The ' trusted hosts' setting governs the administrative access, further subdivided with the settings on each interface. Administrative access is not limited to login but includes ping as well. That' s the way it' s meant. If you feel this is documented in a misleading way then please report to techdoc@fortinet.com and ask for a clarified description to be included in future doc versions. To make things easier, suggest a paragraph of your wording instead of the current one. They are always very responsive and helpful and usually suggestions like these will make it to the docs in a couple of weeks (it' s not a big trashbin...). I' ve done that a couple of times now, with very good results.

[horinius]

ORIGINAL: ede_pfau (snipped) ... That' s the way it' s meant. If you feel this is documented in a misleading way then please report to techdoc@fortinet.com and ask for a clarified description to be included in future doc versions. To make things easier, suggest a paragraph of your wording instead of the current one. (snipped)...

OK, thank you. I will do.

[FredInd]

To share you my own experience, the fact that there' s a link between ' Thrusted hosts' and allowing ping is a bit confusing. We' ve 3 admin accounts on our Fortigate cluster, and one had no ' thrusted hosts' referenced. In order to correct this security lack, i' ve add ' thrusted hosts' on this account and restrict those ' thrusted hosts' to network range in which administrative access for remote managment was needed. A few days after, I' ve discovered that I was unable to ping some gateways and I had no idea why ... I spend 2 days looking for a reason, and finally add those network range as ' thrusted hosts' in one of those 3 accounts .... grrrrr .... Fred

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

[emnoc]

Will it' s been that way for afew years and a few releases now. To add to ede_pfau clarifications; it effects just more than admin access, but pings and even snmp. So be aware.

[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.

[nothingel · Accepted solution]

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.

[emnoc]

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 :)