In case of DDoS: accessing sites through IP / decentralized networks?

#1

Hi all,

After the huge DDoS on Friday, I had a quick question about accessing sites through IP. All of the sites which the attack blocked access to - Twitter, GitHub, Reddit, etc. - weren't actually down themselves, just the DNS server that pointed to them.

So am I right in saying that directly visting the IP rather than typing the URL would have given access to the site as normal, or is it more complicated than that? (For example, I think there was a point when Twitter access came back online, but the t.co links weren't resolving).

Also, given that we'll most likely see many more similar attacks - especially now the Mirai code is in the open - I wondered if anyone has thoughts on whether decentralized / P2P social networks are something which will be more important for journalists in future?

#2

So am I right in saying that directly visting the IP rather than typing
the URL would have given access to the site as normal, or is it more
complicated than that?

Yes, this is basically correct, with the caveat that if you visit a site that redirects to TLS, your browser will give you a security warning, but you will still be able to connect to the site if you click through the warning. Github is at 192.30.253.112, for example. You can try it out and see what I mean. The browser TLS security warning will come up because the "requested domain name does not match the server's certificate," which is of course true, since you didn't request a domain name, but connected directly by specifying the site's IP address. Depending on how the site is configured, you may run into other issues, as well, but basically, yes this will work.

To discover the IP address of a website on Linux or a Unix-like operating system:

ping website.com

returns:

PING website.com (IP ADDRESS HERE) 56(84) bytes of data.

Of course, ping will not work either, if your ISP's DNS server is unreachable. However, if your intent is to build a list of static IP addresses that map to sites you commonly use, in order to keep that list around should your ISP's DNS server get knocked offline, then you can use ping to build that list.

Another thing to keep in mind is that http sites typically have dynamically assigned IPs, so their DNS records will change frequently. TLS (https) sites have statically assigned IPs, so their records will more or less remain the same, which would be relevant if you want to keep a backup cache and become a DNS prepper :wink:, since any http-only IPs you save may turn out to be worthless if you try to use them during a DNS DDoS.

Additionally, in the event of a similar DNS DDoS, you may be able to use Tor to connect to the site you would like to visit. This works because your Tor exit node will resolve your hostname (website) request for you. Since the client resolver (in this case, your exit node) is directed to a DNS server by its ISP (which typically runs this DNS server), this means that your request will be directed to a DNS server near your Tor exit node. If this DNS server is not being attacked, unlike your local ISP's DNS server, then your request will be successful.

#3

TL;DR using the IP address is worth a try in an emergency, but expect problems.

First of all, with cheaper hosting providers it's common for several sites to share an IP address. The browser tells the server which site it wants, based on the URL. If you type the IP address rather than the hostname, the browser doesn't know which site you want, so it can't tell the server.

You can try it with any wordpress.com blog, for example. My DNS server says the IP address of retroshareteam.wordpress.com is 192.0.78.12 (actually the IP address changes each time I look it up, because wordpress.com is load-balanced across multiple IP addresses - but that's not important right now). But visiting http://192.0.78.12 in the browser doesn't work - I just get a generic wordpress.com error page, because my browser didn't tell the server which site I wanted.

A second problem is that if you try to visit the HTTPS version of a site, the browser will complain that the connection is insecure, because the name on the site's certificate (for example twitter.com) doesn't match what you typed into the browser (for example 104.244.42.65, which is one of the IP addresses for twitter.com). So if you try to visit https://104.244.42.65, your browser will warn you not to continue.

A third problem is that many web pages try to load parts of the page, such as images and scripts, using URLs that are based on the hostname you typed into the browser. If you type the IP address rather than the hostname, you may be able to fetch the main body of the page but other parts won't load, or it may not even be possible to view the main body of the page. It depends on how the site's put together.

You can see this in action by visiting http://170.149.161.130, which is one of the IP addresses for nytimes.com. The masthead loads, but none of the articles appear.

A final problem is links. A link in a web page can either be relative or absolute. If it's relative, the URL that the link points to is based on your current URL. If you're using the IP address instead of the hostname, relative links will mostly work. But if the link is absolute, the URL that it points to is unrelated to your current URL. So if you want to follow the link, you'll need to copy and paste it into the address bar and replace the hostname with the IP address... which gets boring pretty quickly.

Again, you can see this by visiting http://170.149.161.130 - the link to the World section points to http://www.nytimes.com/pages/world/index.html, not to http://170.149.161.130/pages/world/index.html, so it's an absolute link.

#4

I will note that for sites that can be accessed via a CDN - like twitter and the like - if you can find a VPN endpoint outside of the affected region being targeted then you'll have far fewer problems accessing things.

As it happens, I just spent the past several days building an automatic-failover setup for just that type of occasion :wink:

It's a fairly sticky and complicated kind of setup to put together, though; most folks will probably want to go through some commercial VPN service where you can pick your endpoint to do this themselves, and turn on the appropriate one when they need it.

#5

From Bruce Schneier's "Cryptogram" blog earlier today:

"An additional market failure illustrated by the Dyn attack is that neither the seller nor the buyer of those devices cares about fixing the vulnerability. The owners of those devices don't care. They wanted a webcam -- or thermostat, or refrigerator -- with nice features at a good price. Even after they were recruited into this botnet, they still work fine -- you can't even tell they were used in the attack. The sellers of those devices don't care: They've already moved on to selling newer and better models. There is no market solution because the insecurity primarily affects other people. It's a form of invisible pollution.

And, like pollution, the only solution is to regulate. The government could impose minimum security standards on IoT manufacturers, forcing them to make their devices secure even though their customers don't care. They could impose liabilities on manufacturers, allowing companies like Dyn to sue them if their devices are used in DDoS attacks. The details would need to be carefully scoped, but either of these options would raise the cost of insecurity and give companies incentives to spend money making their devices secure."

Not too encouraging, is it?