I was looking at the domain information of a website (poaulpos.net) on who.is that Chrome connects to whenever I visit a specific an old Tech Times article about Thunderstrike 2, a Mac firmware attack ("Thunderstrike 2 Is The Latest Nightmare Of Mac Owners"). I have Little Snitch, an application based firewall, so I blocked it the first time Chrome attempted to connect to it.

My question is very basic: clicking on the diagnostics tab of any who.is entry automatically runs a ping and a traceroute on the website. Is that more or less like visiting the website by typing the hostname into your browser and letting it load?

The website in question was only registered yesterday and contact information is Whoisguard protected. I'm pretty paranoid. I'm suspicious of the website and am worried if somehow, I could've just allowed something malicious onto my laptop by attempting to reach the website via the who.is diagnostics tab.

  • 61
    If you could get infected by just checking a website through who.is, society would be in great trouble.
    – Azami
    Commented Jul 7, 2016 at 12:20
  • 5
    As a bonus, pinging a website won't even get logged anywhere. Many server farms have a firewall block on ICMP ports Commented Jul 7, 2016 at 15:10
  • 6
    @usr-local-ΕΨΗΕΛΩΝ but... ICMP doesn't have the concept of ports.
    – Dmiters
    Commented Jul 7, 2016 at 16:41
  • 25
    and there's no such thing as "pinging a website" Commented Jul 7, 2016 at 16:42
  • 5
    It would be clearer to add the context to the question title, like asking "Does pinging a website carry any of the security risk of visiting a website in the browser?" There are many ways to interpret the title (like availaiblity checking, firewall penetration, etc.). Commented Jul 8, 2016 at 18:23

6 Answers 6


They are not the same at all.

A ping request is an ICMP packet which just by default sends null data to check if the host is up (You can change around the parameters being sent (read more here).)

When you visit a website in the browser you are using the HTTP protocol which requests data and so you have a CLIENT/SERVER setup here (data is served to the client from server upon a request that is sent in the HTTP protocol).

Either way, if you are not the one sending the request but rather the service (poaulpos.net) you are using sends it, there is no traceback to you and therefore no security risk for you.

  • 6
    ...to check if host is up... But it doesn't tell you if host is down. Commented Jul 8, 2016 at 6:20
  • 3
    @user2338816 Actually it does, by context. When you want to check if the server is down you're probably looking forward to use some service that will do more than just receive a null request and return an empty response. When you ping a server that can't even do that, the server is certainly not reachable for anything. Commented Jul 8, 2016 at 14:58
  • 18
    @ViniciusPires Not true. It's perfectly possible - and indeed relatively common - to have hosts set up to respond to some services, but not ICMP.
    – reirab
    Commented Jul 8, 2016 at 15:09
  • 4
    @reirab And that's why ping is not the ONLY tool used to see if a server is down :) Commented Jul 8, 2016 at 16:07
  • 2
    @ViniciusPires Agreed. I was just disagreeing with your assertion that a server is certainly not reachable for anything if it doesn't respond to ICMP echo requests. That's probably true if you set the server up yourself and you know it's set up to respond to ICMP echo requests, but not for the case of pinging someone else's webserver, as in this question.
    – reirab
    Commented Jul 8, 2016 at 16:10

Is that more or less like visiting the website by typing the hostname into your browser and letting it load?

Short answer, no ... it's not even close.

When you run whois you are doing a lookup of an IP or Domain's publicly registered information. In many cases the whois request will not even communicate with the target server. Rather whois databases are mainly run by registrars and registries. ICANN’s IANA department runs the central registry for all kinds of Internet resources, pointing to the whois server of the responsible (sub)-registry as well as the contact details of this registry.

The program you are running is also running a ping against the server. In most cases the standard ping command makes use of ICMP or The Internet Control Message Protocol. This however is not always the case for programs that are checking the status of a server. The tool you are using might instead be doing a port scan to check the availability of ports 80 and 443. NMAP is an example of another tool that has this functionality.

Now, to the heart of your question ... how are all of the things listed above different from visiting the website itself? The answer is that all of the tools above are pretty simplistic, they send a message and get a message but do very little processing. They are all more or less dumb challenge/response type systems in comparison to opening up a TLS socket for communication via HTTPS.

When you open your browser and navigate to https://google.com, the following things happen:

  • Your browser does a DNS lookup of google.com in an attempt to get an IP address to which it should connect.
  • Once an IP address has been obtained, a TLS socket will be negotiated: TLS Negotiation
  • After a secure socket connection has been established, the browser makes a HTTP:GET request for google.com's / (usually a file called index.html but can also be index.php, index.asp, etc depending on the server).
  • Once the HTML content of / is received by the browser, it attempts to load its content for you to see ... however while the HTML can have images (base64 uri encoded) and scripts in its content ... it usually contains references to other files that need to be downloaded as well. In many cases loading a page can result in a great number of secondary requests ... for example loading google.com caused 12 different HTTP requests.
  • Once the page is loaded, any JavaScript is then interpreted and client side code is executed within your browser ... this JavaScript code or flash / java-applet code is usually the root cause of the malicious activities you are afraid of.

It is possible to load a page without JavaScript by using something like NoScript however, this could also prevent the web page from functioning ... for example you wouldn't be able to log into stackexchange without letting some of the JavaScript content be executed.

So to answer the heart of your question, no ... it is very unlikely if not totally impossible to infect your computer by running a whois or ping against evil-website-of-doom.com ... however, if you ping it ... they will get your IP address which may or may not be an issue ... but that is a different question completely.

  • Well, you can read Stack Exchange happily enough without allowing JavaScript. But unfortunately, it does refuse to let you log in without JS and/or cookies (I forget which I had to allow...) Commented Jul 7, 2016 at 14:52
  • 1
    @TobySpeight JS or Cookie, but you need JS to authenticate and get the cookie. Six in one Half a Dozen in the other Commented Jul 7, 2016 at 14:58
  • 1
    You forgot index.aspx, index.cgi, index.htm, default.htm, default.html, etc etc :D Commented Jul 7, 2016 at 16:41
  • 1
    @LightnessRacesinOrbit Added etc Commented Jul 7, 2016 at 16:44

Pinging a website and viewing it in a browser are two absolutely different processes which involve different protocols altogether. Ping sends an ICMP request (response won't be malicious) while viewing a webpage sends a request to get the index page (possibly malicious) of the website.

In your case, you have nothing to worry about. Firstly, it was a request to the machine that hosts the website and not the website itself. Secondly, the connection was made by who.is to the website and not from your laptop to the website. The website had no way of knowing your IP address.

  • 4
    "response won't be malicious" any chance there's a web server that responds to pings with port scans instead of the protocol-defined ping response? Commented Jul 8, 2016 at 3:49
  • 2
    @JanDvorak I could be wrong, but I think ping is operating way below the application layer; the web server (software) won't respond maliciously. Pinging does give away to the target that you exist, though, yes. The ping response itself shouldn't be able to be malicious, but whoever/whatever saw the ping could begin to do something afterward. Commented Jul 9, 2016 at 0:10

You can't ping a web site. You can ping a network interface; this sends ICMP ECHO request packets to that interface (and summarizes the replies received).

A web site (in this context) is a server answering HTTP and/or HTTPS requests on one or more TCP ports on the interface (normally port 80 for HTTP and port 443 for HTTPS).

A given interface may or may not reply to ICMP ECHO packets (but it ought to). The same interface may or may not have one or more web sites bound to its TCP ports. But the two are totally independent of each other.

To answer the security question: ping cannot carry a malicious payload; the server is required to return exactly the payload you send, but even if it doesn't, you never interpret it in any way. Your ping program may check that the received data match what was sent, but must not do anything else with the content (and in most cases, you'll be sending an empty payload anyway).

You are giving away a small amount of information (the fact that one interface is interested in the reachability/status of another) but very little beyond that.

  • 3
    I feel "ought to" should be "ought not, in most situations". Ping is useful for troubleshooting a connection to a service. If an interface is not providing any externally accessible services, there's no reason to have ping. Even if there is a service, permitting ping increases your attack profile: see security.stackexchange.com/questions/4440/security-risk-of-ping Commented Jul 7, 2016 at 19:07
  • 2
    @Dew - opinions differ, as evident in the question you linked. I don't quite agree with you (ping can be useful against interfaces that are only ever initiators), but in the end, it's a judgement to make based on information - and the more the better, so thanks! Commented Jul 8, 2016 at 8:13
  • "ping cannot carry a malicious payload" - but: Ping of Death. (Though I guess there is no such thing as a ping-reply of death ...9 Commented Jul 9, 2016 at 16:12
  • @Hagen - good point, but ping-of-death normally means malformed packets - not, strictly speaking, the payload. If you have a system vulnerable to such attacks, you really don't want to put it on the public Internet... Commented Jul 11, 2016 at 10:21
  • If we're going to nitpick about website vs interface terminology... :-) "You can ping a network interface" An ICMP packet does not address an interface, it addresses an IP address. I don't know which specific interface I reach when I ping because of the anycast routing. Where you end up depends on routing decisions, not which interface you specified, because you can't specify an interface (at most, you can specify an outgoing interface with IPv6's ::1%lo notation).
    – Luc
    Commented Aug 13, 2019 at 10:01

No. I would say running ping or traceroute on a domain is not a security risk. Furthermore, the ping is done by who.is and not by your computer.


Ping is nothing like loading the website, as has been said its a completley separate protocol, that might even be blocked. I'd use something that does a dummy HTTP request or the good old Telnet:80

these will give you more information about the web server than a ping.

  • this doesn't really answer the question
    – schroeder
    Commented Jul 11, 2016 at 15:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .