Home page logo

basics logo Security Basics mailing list archives

Re: Removing ping/icmp from a network
From: Ansgar -59cobalt- Wiechers <bugtraq () planetcobalt net>
Date: Fri, 4 Apr 2008 14:28:18 +0200

Re-sending, because the first mail doesn't seem to have made it to the

On 2008-03-31 Jason wrote:
What do you mean by "many vendors configure firewalls"? Any admin who
doesn't tailor his firewall configuration to the particular needs of his
network has already lost.

Vendors have firewalls too. But what I mean is really many customers /
vendors / admins / whatever.

Ah, I thought you meant "firewall vendors". Misunderstanding on my part,

I call bullshit.

a) A ping sweep isn't the only way to do network exploration. I'll refer
   you to the man-page of nmap for more details.
b) You can't hide computers on the Internet. IP simply doesn't work that
   way. Not responding to echo requests does *not* mean "host isn't
c) ICMP doesn't care about ports. Like, at all. Thus a ping sweep is
   entirely unsuitable to "find that server running on port whatever".

Never said it was (??)

Then what does "finding a server on port whetever" have to do with a

If the host is supposed to be accessible: why whould you care about
someone discovering it?

If the host is not supposed to be accessible: why is it accessible in
the first place?

You can't hide them, but you can make them more difficult to discover
by those who may wish to cause damage. And I said IF an attacker ping
sweeps, I didnt say at all that it was the only way. Any attacker
worth their salt will USUALLY find the hosts, but the idea is to
reduce the possibility, not remove it.

That's just obscurity, which won't gain you any security. At all. Not
worth the time or effort you put into it.

ICMP is a protocol, not a service. And why would I care about "those
with malicious intent" finding a server that is supposed to be
accessible? Rather than wasting my time and effort on security by
obscurity (and not responding to echo requests is just that) I'd put it
into hardening the systems and exposing only those systems and services
that are supposed to be accessible.

Security by design is always best, but hiding the presence of a device
may sometimes be desired.

Again: that's just obscurity, which won't gain you any security. At all.
Not worth the time or effort you put into it.

And hardening those systems is a process that RARELY happens
unfortunately. If you harden the systems, good for you. But you'd be
surprised how many do not.

Obscurity is NOT a replacement for due diligence. Which includes
hardening Internet-facing systems.

Would you agree that opening ports that aren't necessary is a bad

Yes, because they increase the code base without serving a purpose, thus
increasing your potential risk of being exploited.

Umm increases your code base? I could nitpick but I wont.


By running additional services you increase the code base that's exposed
to other networks.

Then why open ICMP which also serves no real purpose for web

ICMP is still a protocol, not a service. And unlike unnecessary
services it has a purpose.

I am not saying it doesn't again, its just not necessary.

As a matter of fact you *did* say it wouldn't. You even quoted the
respective part (underlined above).

And could you please explain why your infrastructure is exposed to
the outside in the first place?

Layout of the infrastructure for secure internet access. If you want
to nitpick, technically your external firewall(s) is/are part of the

External firewalls are exposed anyway (by definition). As are Internet-
facing servers. Your point being? You can't hide *and* expose a system
at the same time. Not to mention that IP simply doesn't have the option
to hide a system that's supposed to be accessible.

Well MS hasn't been able to be pinged for x years, they seem to be
getting along just fine.


Yeah. Except for everyone else who's trying to troubleshoot connection
problems to their servers. Bad practice doesn't magically become good
practice just because Microsoft does it.

LOL a lot more sites than MS do it.

Repeating myself: bad practice doesn't magically become good practice
just because other people do it too.

And when I, and I am sure many other technical people, can't ping a
web site and response to it is very slow they don't throw their
hands up in the air and say their servers are unreliable and they
are breaking the Internet, they say that it is likely being blocked
like most sites do, and try to use other means of determining the
problem. Like using tcpdump or other monitoring and troubleshooting

You did not just suggest to use tcpdump instead of ping, did you?

There are many ways to troubleshoot issues, tcpdump (yes, packet
capturing) is one.

There are many ways to put a nail into a wall. Yet I'd still prefer a
hammer over an oscilloscope to achieve that.

And you can ping a TCP port too you know.

Ummm... no, as a matter of fact you can't. You can try to establish a
connection to a TCP port, but that's completely different from ping.

If ping is unavailable to test latency, there are other ways. I am
suggesting options. And ping is not a must for all troubleshooting.
I'm sorry but if an admin relies solely on ping to do trouble-

That's entirely besides the point. Of course I'll use other means when
one becomes unavailable. That is, however, no reason AT ALL to disable
(or unduly restrict) a valid and appropriate protocol for detecting and
troubleshooting network issues.

Take a survey of security professionals and even the more seasoned
network admins and ask how many of them depend on ICMP to determine
if a web site, or ANYTHING, is up or not. I guarantee the answer you
will get is: "I use it, but if it doesn't respond I use other
methods because most vendors block ping to their web servers

Ummm... yeah. So? That makes it a good idea how?

And while you're taking your survey, ask the network admins if they'd
prefer ICMP enabled or disabled, and how they handle ICMP in their
own networks. I have a strong suspicion you'll get answers similar to

I didn't ask what network admins 'prefer'. If a security professional
just does what the net admins prefer, attackers would have a much
easier life :)

Any "seasoned network admins" worth their money are also (network)
security professionals. You don't run a network without security
considerations. Not successfully, that is.

Again, its not the end of the Internet if its disabled. And it doesn't
confuse most admins when it is.

Which - of course - is not a valid reason to disable it.

ICMP does not increase your exposure. That's plain and utter
nonsense. Either your hosts are epxosed or they're not. ICMP doesn't
change the least about this. Security by obscurity will not help and
is not a replacement for actual security. What is so hard to
understand about that?

It's not a replacement, I never said it was. You have to understand
that security by design is sometimes not the way things are done, and
I am being generous.

Well, I am not.

And before you say how wrong that is, yes, you're right it is wrong.
But its life. The idea is to minimize the exposure of a host and not
affect required services or protocols.


Again: either a host IS exposed, or it's NOT exposed. ICMP doesn't
change anything AT ALL about that. It's merely adding some obscurity,
which you don't need if you have security in the first place. And if you
don't have security, then *that's* what you want to fix instead of
applying snake-oil.

ICMP is not a required protocol for a web server, sorry. Convenient,
yes. Required, no. If you believe it is then thats okay. That's the
beauty of the Internet, everyone has an opinion.

So basically you're justifying obscurity instead of security, because
there are so many stup^Wintellectually challenged admins out there? What
kind of argument do you think that is? You do realize that this list is
about security, don't you?

Ansgar Wiechers
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]