public IP wget/curl dumps html into shell

[DailytheNoob]

get_public_ip=$(wget -4qO- "http://whatismyip.akamai.com/" || curl -4Ls "http://whatismyip.akamai.com/")
https://github.com/Nyr/openvpn-install/blob/master/openvpn-install.sh#L233

This dumps 503 unavailable HTML into the shell: https://asciinema.org/a/288522

[Nyr]

Is it still happening right now? What is your server's ISP?

[DailytheNoob]

yes, happening right now. ISP is super specific and only serves the one small city, so I'm not willing to divulge that this openly.

FQDN is daviddaily.dev

[DailytheNoob]

the following all return the correct public IP:

$ curl ifconfig.me
$ curl icanhazip.com
$ curl ipecho.net/plain
$ curl ident.me
$ curl bot.whatismyipaddress.com
$ curl https://diagnostic.opendns.com/myip
$ curl http://checkip.amazonaws.com

[Nyr]

Well, with that FQDN you did reveal the specific ISP, I guess. The AS has 6400 originated IPv4 so you probably shouldn't worry too much, but it's irrelevant, I only wanted to know if it was a big ISP.

Okay, about your issue:

• Please provide the output of the following command: curl -Iv http://whatismyip.akamai.com/. That way we can see if your ISP is intercepting the request or the problem lies with Akamai.
• Try accessing https://www.akamai.com/ from your web browser, does it work?
• Replace the Akamai URL in the script with other service like for example: http://icanhazip.com/. That will resolve your issue immediately.

[DailytheNoob]

Yeah, it did, but there's a bit more effort involved there than just reading it here.

result of curl -Iv http://whatismyip.akamai.com/:

* About to connect() to whatismyip.akamai.com port 80 (#0)
*   Trying 0.0.0.0...
* Connected to whatismyip.akamai.com (0.0.0.0) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: whatismyip.akamai.com
> Accept: */*
>
< HTTP/1.1 503 Service Temporarily Unavailable
HTTP/1.1 503 Service Temporarily Unavailable
< Server: nginx/1.13.1
Server: nginx/1.13.1
< Date: Mon, 16 Dec 2019 16:45:44 GMT
Date: Mon, 16 Dec 2019 16:45:44 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 213
Content-Length: 213
< Connection: keep-alive
Connection: keep-alive

<
* Connection #0 to host whatismyip.akamai.com left intact

Accessing https://www.akamai.com/ from elinks worked

Replacing it did solve the issue. Just thought you might want to be aware that it doesn't always work.
although I don't know why

[Nyr]

Yeah, your ISP is probably intercepting that request, 0.0.0.0 is of course not served by Akamai.

So I'll not change the service, but thanks for the report anyway.

[DailytheNoob]

sounds good, have a great day!

[sindastra]

Hello, I have the same issue. In my case, it dumps the HTML of localhost (local running Apache2 web server, default web page is shown) in the shell. I can confirm because if I stop Apache2, no HTML will be dumped.

I guess it tries to connect to my public IP/hostname or something with curl and thus dumps the HTML of my web server? I verified that there was no dumping when using the script from commit 1c79a96 (last known version that does not dump contents). So, some change between then and now causes dumping.

Additional info: My hostname is in /etc/hosts and points to 127.0.0.1.

Thanks.

[Nyr]

@sindastra please provide the output of the following command (run it from your server):
curl -Iv http://whatismyip.akamai.com/

If possible, please also let me know which internet provider is that server connected to. This is very likely an issue with the server network.

[sindastra]

Hello, I investigated this now and found that you were right that it is indeed a network issue!

I run my own DNS servers which incorporate filter lists. In one of them (https://hosts-file.net/ad_servers.txt) whatismyip.akamai.com was a false-positive, which resulted in a resolution of the domain to the IP 0.0.0.0. This list is not maintained anymore and I have pulled it. The script works now that it can resolve the address.

On a side-note hosts-file.net often has false-positives and should not be used by anyone. Seems like they stopped existing now anyway. One problem though might have been that it's also a default in Pi-hole block lists, and unless manually removed the filter list will remain in the cache with all its false positives. So, it's good you moved to AWS, thanks!

[Nyr]

First of all, thanks for the detailed report. Considering this is the default behavior in a popular piece of software, it was a good idea to drop the Akamai service.

I however didn't consider a new issue yesterday which I inadvertently introduced: working over HTTPS, the new checkip service will not work in systems where the ca-certificates package is unavailable. This was common years ago, not sure about the current situation, but we don't necessarily require SSL for this request and preferably wouldn't want to use SSL.

It is a simple issue, but our requirements for a checkip service are not that easy:

• Not blocked in any major network or piece of software
• Stable and fast around the world. Amazon is not as fast as Akamai, but is was ok
• Doesn't trust Client-IP or X-Forwarded-For HTTP headers (not an issue over HTTPS, but Amazon and many others have this issue over plain HTTP)

I'll see this afternoon if I can reach a middle ground, probably a different service can be used over HTTP.

[sindastra]

🔐 About using HTTPS: I agree that it's not needed since it just returns the IP, which is already "public information" as the request happens. The only argument could be to avoid manipulation or redirects (for example a HTTP proxy in between).

🤔 While I do believe CentOS, Debian and Ubuntu should have ca-certificates, chances are that Debian and CentOS minimal do not. However, I do not know. But you could probably check if it's included in default installations.

↪️ About using another service: If you don't mind doing a bit of parsing, have you seen http://checkip.dyndns.com/?

📜 The official documentation is here https://help.dyn.com/remote-access-api/checkip-tool/

👎 I never liked that their response is wrapped in HTML. It's madness in my opinion. 😆

[Nyr]

🔐 About using HTTPS: I agree that it's not needed since it just returns the IP, which is already "public information" as the request happens. The only argument could be to avoid manipulation or redirects (for example a HTTP proxy in between).

Yes, because chances of a proxy are smaller compared to my other worries, like certificate validation failing.

🤔 While I do believe CentOS, Debian and Ubuntu should have ca-certificates, chances are that Debian and CentOS minimal do not. However, I do not know. But you could probably check if it's included in default installations.

Doesn't matter, there are other situations like OpenVZ templates and custom images from cloud providers. The package is just not there anyway.

↪️ About using another service: If you don't mind doing a bit of parsing, have you seen http://checkip.dyndns.com/?

$ curl http://checkip.dyndns.com/ -H "X-Forwarded-For: 1.2.3.4"
<html><head><title>Current IP Check</title></head><body>Current IP Address: 1.2.3.4</body></html>`

See? They will trust whatever gets passed to them instead of printing the real remote address. This is commonplace in many services and maybe I should stop caring about it, but it is not right and the administrators of those very popular services seem to be unwilling to fix their load balancers which are causing this issue.

[sindastra]

✅ OK, I found one that does not use HTML and does not care about the X-Forwarded-For header: http://ip1.dynupdate.no-ip.com/

📜 Documentation: https://www.noip.com/integrate/ip-detection

[Nyr]

That is an excellent find which satisfies all of our requirements.

Thank you!