New Member

Solved

Bug or documentation ambiguity concerning Trusted Hosts

Forum|Forum|13 years ago
February 28, 2013
26 replies
25673 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.

Dave_Hall

New Member

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?

horiniusAuthor

New Member

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

New Member

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

horiniusAuthor

New Member

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

New Member

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.

horiniusAuthor

New Member

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

New Member

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)

TopJimmy

New Member

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

rwpatterson

New Member

Wow, is that OLD or what? Version 2.80?

ede_pfau

SuperUser

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.

horiniusAuthor

New Member

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

New Member

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

New Member

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

New Member

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_LiboveAnswer

New Member

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

New Member

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.

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO