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.

[Dave_Hall]

Are you able to ping the server from the Fortigate? I would be more incline to think the server is blocking incoming icmp packets. Are you able to ping the Fortigate from any other device on the DMZ?

[horinius]

Yes, I was able to ping the server from the Fortigate (without having server' s IP address in Trusted Hosts field). No, ping from any other device in the DMZ gave the same result. That' s why I was confused and didn' t understand what happened at the beginning. About the possibility that icmp packets being blocked, I don' t think so, but how to check?

[abc987]

The docs sometimes have not all details. The relationship is between the " trusted hosts" and " administrative access" configured at the interface settings.

[horinius]

ORIGINAL: abc987 The docs sometimes have not all details. The relationship is between the " trusted hosts" and " administrative access" configured at the interface settings.

Yes, that' s also my conclusion. However, it' s not only a matter of " details" , it' s totally misleading. They need to rectify their documentation.

[Maik]

firmware you are mentioning is 4 MR2. see a ping to a fortigate as an administrative task. so only " admins" are allowed to do that.

[horinius]

ORIGINAL: Maik firmware you are mentioning is 4 MR2.

Yes, my fortigate firmware is v4.0,build0346,120606 (MR2 Patch 12) Are you implying that this problem is solved in a newer version?

ORIGINAL: Maik see a ping to a fortigate as an administrative task. so only " admins" are allowed to do that.

Well, maybe, but it' s a matter of viewpoint and interpretation, and therefore it' s not objective enough. And there' s a flaw in this reasoning of yours: the ping works with whatever admin (because you only need to put IP address in any trusted hosts of any admin account). But there' s no login associated to a ping, how can you be sure that only admins are allowed to do that?

[abc987]

But there' s no login associated to a ping, how can you be sure that only admins are allowed to do that?

It' s only dependent to the trusted hosts. If you have 0.0.0.0/0 in there (default) and have admin access boxes checked everyone can " connect" via http, https, ssh, ping... Login as a admin is after connecting. So ping works for everyone. Be shure which admin accesses you check on WAN-Interface If you need remote-access at WAN be shure no admin has 0.0.0.0/0 (restrict all admins to remote IP or privat IP)

[horinius]

ORIGINAL: abc987

But there' s no login associated to a ping, how can you be sure that only admins are allowed to do that?

It' s only dependent to the trusted hosts. If you have 0.0.0.0/0 in there (default) and have admin access boxes checked everyone can " connect" via http, https, ssh, ping... Login as a admin is after connecting. So ping works for everyone. Be shure which admin accesses you check on WAN-Interface If you need remote-access at WAN be shure no admin has 0.0.0.0/0 (restrict all admins to remote IP or privat IP)

Of course I understood all the implications (and complications) once I found out the workaround. My time is limited so I' m not going to comment on this. So I' ll let you think about it and see by yourself how this setting is bad and useless.

[TopJimmy]

I don' t see it as a bug 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