3

tl;dr: In order to prevent a potential use of our computers to mine crytpocurrencies, I and a few other people were advised to append this: https://github.com/hoshsadiq/adblock-nocoin-list/blob/master/hosts.txt to our hosts file. I notice that this list blocks cryptocurrency domains by binding them to 0.0.0.0, while the standard practice, as I remember it, was to block undesireable domains by binding them to 127.0.0.1. Is there any reason to do this that way and what is the result of sending a packet to 0.0.0.0? Is it safe to amend the hosts file in this way at all?

Whole story: Me and a few other people reported on Wikipedia that editing long articles with Firefox is insufferably slow and results in FIrefox using up unreasonably high percentages of CPU. In response, a volunteer said that our browsers are likely to be the problem and that someone may be using our computers to dig cryptocurrencies. I find this not very probable since (1) The problem happens when we edit long articles and not when we browse other websites, it doesn't seem likely that a cryptocurrency digging malware would fire up whenever it detects a Wikipedia article is being edited and (2) Our CPU is being used and not GPU, and I reason that if our browsers were infected they would likely use GPU to dig cryptocurrencies, but... Since I was told to "modify hosts and report back if the problem persists", I reckon I have no more arguments in this discussion until I modify hosts and see if the problem persists... But before I put anything to hosts I want to be certain what am I doing and if this is safe.

Note: Not sure if I should ask this here or on superuser. I choose this site since the list in question attempts to block a specific malicious activity, however, if I was wrong, please move my question to a more appropriate site.

gaazkam
  • 5,607
  • 11
  • 24
  • 37

1 Answers1

1

0.0.0.0 can be equally dangerous, as it acts like 127.0.0.1 on some operating system such as Linux.

In order to block domain names, you'd better use a DNS proxy such as dnscrypt-proxy. In addition to being way faster than hosts files with large datasets, DNS proxies can block suffixes, prefixes and regular expressions.

Instead of returning an actual IP address, these proxies return responses with the REFUSED error code, which is the standard way in the DNS protocol to refuse queries.

Frank Denis
  • 273
  • 1
  • 4
  • `0.0.0.0` does not act like `127.0.0.1` on Linux. I'm not sure where you got that from. – forest Mar 09 '18 at 02:30
  • 1
    Really? `telnet 0.0.0.0 22` connects to the local SSH server on Linux. This is not the case on BSD and macOS. – Frank Denis Mar 09 '18 at 08:41
  • That is because specifying address `0.0.0.0` tells the kernel to listen on all available addresses (e.g. `127.0.0.1`), just like binding to port 0 tells the kernel to open any available port. It just acts like a flag, meaning something other than an actual address (specifically, it acts as the flag `INADDR_ANY`). It still isn't routable, so it's re-purposed. In fact, it's specified by the IPv4 standard to be unroutable and instead used as a "meta address", with an implementation-defined and context-dependent meaning. – forest Mar 09 '18 at 08:46
  • 1
    I believe this answer is incorrect as "null routing" is a common technique where a hostname is bound to `0.0.0.0`, which is an illegal and non-routable address _in that context_. In the context of things like telnet, the behavior may be different. **Telling the system to _bind_ to `0.0.0.0` means "listen to everything". Telling the system to _route_ to `0.0.0.0` means "drop the traffic".** Note that this is different from `0.0.0.0/0` which is a netmask that means "every address that exists". – forest Mar 09 '18 at 08:54