Why are you worrying about your servers showing up on simple scans like this?
>> Sometimes we give guest access for some users that work on temp basis. We do not want them to use Fing and get idea out all the servers. Because one of them is entry to production though it is secured via ssh auth. But still why to take chances.
BTW, this is what the security chairman of our company wants us to implement.
Either you've misunderstood what exactly your security chairman wants you to implement, or he's incompetent.
Blocking ping scans is pointless, it's security through obscurity. It is not going to offer the security protection you need, it's just going to make network connectivity troubleshooting more difficult.
Hiding the servers from ping scans does not prevent communication with them via other protocols, and thus nor does it hide them from being discovered via scanning with these other protocols. For example, you say that the servers are running ssh for authentication, so what if I were to scan port 22 (ssh) across your network's entire IP range? I've just discovered all your servers (all those running ssh that is)! You can even do this yourself with fing, albeit only on one host at a time - press the cog icon top right to access the tools menu, under host tools select 'scan TCP services', and enter an IP address. fing also let's you configure the TCP services it scans for (tools > configuration > edit TCP services), the version I have here has a default list of 1027 services.
Fing of course isn't the only such scanning tool, what if one of your temp contractors were to connect their laptop to your network and run some other scanning tool that allows them to scan TCP services across a range of IP address, unlike fing allowing just one at a time. So what are you going to do about preventing the discovery of the servers via these other protocols?
Your attempt to enhance security by attempting to block discovery via blacklisting communication with pings is extremely weak and ineffective.
What you should be doing is segmenting your network (VLANS, which you've already got) and then implementing access controls, which is what your attempting, but you're going about completely wrong.
Here's how I would summarise your options, in terms of implementing layer3 access lists on your networking equipment (assuming you have equipment with such capabilities):
Quick definition of what I mean below by destination/source:
At destination = Access controls on the network equipment, at the point where the servers connect.
At source = Access controls on network equipment, at the point where clients connection to the network, or at the point where traffic is exiting the client's VLAN.
- Blocking (blacklisting) pings at destination : WRONG - does not block other types of scanning or communication.
- Blocking (blacklisting) pings at source : WRONG - does not block other types of scanning or communication.
- Blocking (blacklisting) pings and other protocols/destination-ports like ssh at destination : WRONG - cuts off all communication making servers useless.
- Blocking (blacklisting) pings and other protocols/destination-ports at destination, for traffic with source address in specific IP range : BETTER - though a whitelist is better than a blacklist, and it's imperfect because a malicious host could spoof the source IP address to get malicious packets through. Thus they could still DOS the server, or potentially exploit vulnerabilities where the malicious host being able to receive responses doesn't matter (e.g. a vulnerability in a server's database package that may allow random modification/corruption/deletion of data - the attacker may be satisfied with just screwing up the database as best as possible!).
- Blocking (blacklisting) at source, pings and other protocols/destination-ports, destined for specific addresses/ranges : MUCH BETTER - now you're starting to properly cut off access to the servers from hosts you don't want to allow communication from.
- Blocking at source, pings and other protocols/destination-ports, destined for specific addresses/ranges, by using a whitelist of stuff communications that are allowed : BEST - whitelists are generally preferable to blacklists.