I'm a linux noob, and while looking for a simple OS-level website blocking technique, I came upon the solution of using the linux hosts file like so: websiteiwanttoblock.com anotherone.com

This is nice and simple - perfect for my purposes, but here's my question: If I often use for web development purposes, is this dangerous?

It seems that, at the very least it could mess up the web dev project I'm currently working on? For example, if Chrome/Firefox makes a request to websiteiwanttoblock.com/api/blah, then would that make a request and potentially mess with my project's api?

If this is dangerous in that regard, is there a safer "null" ip address that I could redirect blocked sites to? I know it's probably not good practice to use the hosts file like this, but I just love the simplicity of editing a text file rather than downloading a package or whatever.

Edit: Oh, and I often use port 3000 for dev stuff, but let's assume that I sometimes use 80, or any other available port number.

  • Not really! I use \WINDOWS\system32\drivers\etc\hosts to block Reddit, Facebook, YouTube and a bunch of others! Everyone should! In order to perform a XSS attack, someone would have to hack a public site they know you do visit, create a link to a site they know you block, and exploit a vulnerability in your development software. They would have to access your system in the first place to know the last two bits of info. The odds are so astronomical it would be easier to hack your OS directly. I never worry because my dev software is always secure :).
    – Chloe
    Commented Nov 26, 2017 at 18:12
  • 4
    Use instead of, bind to eth0:1 (or enp4s0:1 or whatever your adapter is called), and configure your webserver not to listen on That'll provide you with a "safer" IP to redirect to which doesn't need iptables. To expand on this, use distinct 10.x.y.z addresses for each host, have your webserver listen on all of them, and log the request including IP so you get an idea which of the blocked sites got which request, and when. Commented Nov 26, 2017 at 20:16
  • 4
    Whether or not secure, it's a dirty hack. etc/hosts is not for blocking outbound traffic. That's what a firewall (ipf or iptables) is for. Commented Nov 26, 2017 at 21:58
  • @GuntramBlohm Why not use instead?
    – jamesdlin
    Commented Nov 27, 2017 at 11:28
  • @jamesdlin: because you want an address that's known to be served by exactly one distinct device (that will reject the connection). Try ssh, then call netstat, you'll see a connection from to It's kind of hard to tell your webserver to serve requests from localhost, but refuse these requests. Commented Nov 27, 2017 at 11:38

5 Answers 5


Short Answer

Is it safe to use the /etc/hosts file as a website blocking "null" address?

I would argue the answer should be: No.

If for no other reason than the requests are not actually "nulled". They are still active requests. And as the OP indicates, since the requests are for legitimate Internet hosts, this sort of short cut method of redirecting requests to localhost may interfere with testing networking code in a development environment.

Perhaps a better method of blocking traffic to and from certain Internet hosts, is to utilize iptables which is the interface to the Linux kernel's firewall. iptables is the default networking rule table for most GNU/Linux systems. Some distros use ufw as a front-end to iptables.

If you want to use iptables, here's a simple script which will DROP all incoming and outgoing packets for a list of IP addresses or hostnames with one address or hostname per line contained in a plain text file called ~/blocking.txt

## Block every IP address in ~/blocking.txt
## DROP incoming packets to avoid information leak about your hosts firewall
## (HT to Conor Mancone) REJECT outgoing packets to avoid browser wait
for i in $(cat ~/blocking.txt); do
    echo "Blocking all traffic to and from $i"    
    /sbin/iptables -I INPUT -s $i -j DROP
    /sbin/iptables -I OUTPUT -d $i -j REJECT

Sample ~/blocking.txt


Do not place your localhost IP addresses in this file.

Longer Answer

While reassigning Internet hosts to localhost in the /etc/hosts file is a common short cut technique to block unwanted Internet hosts, this method has some serious security drawbacks.

Incoming requests

Incoming requests which were not purposefully initiated via a specific user request. The most common example is ads on webpages. Let's follow the incoming packets...

First, I start up wireshark. Then I place the biggest Internet ad company in my /etc/hosts file with this line:   google.com

And then disable all ad blockers in my browser, navigate to youtube and play any random video.

If I filter my packets, broadly including Google's IP address space:


I am still receiving packets from Google.

What does this mean?

It means that there is a possibility of a malicious server inserting malware which may be able to attack my computing platform via packets that are still arriving and sent to localhost. The use of /etc/hosts rather than dropping or rejecting the packets via the firewall rules, is a poor security measure. It does not block incoming packets from possible malicious hosts, nor does it provide effective feedback for trouble shooting purposes.

Outgoing requests

Outgoing requests which are sent to localhost rather than being rejected or dropped by the firwall rules are still being processed by the kernel. There are a few undesirable actions that occur when /etc/hosts is used rather than the firewall:

  • Extra processing is occurring when the outgoing packet hits localhost. For example, if a webserver is running on the host, the packet sent to localhost may be processed by the webserver.

  • The feedback from outgoing requests may become confusing if the /etc/hosts is populated with certain domains.

iptables can handle lots of rules

According to some:

ServerFault: How many rules can iptables support

A possible theoretical limit on a 32-bit machine is 38 million rules. However, as noted in the referenced post, as the iptables rule list expands so does the needed kernel memory.

  • 16
    It is better to use REJECT rather than DROP. DROP simply ignores it, which causes the system that made the request to continue to wait for a response. REJECT both ignores the request and sends a notice to the person who requested it telling them that the request was blocked. The practical difference is that if you accidentally load up a website in your browser with DROP, your browser will show a loading screen forever. For REJECT, you will immediately get an error in your browser. The latter is much more convenient, IMO. Commented Nov 26, 2017 at 14:35
  • 2
    Is iptables really suitable for 100k+ hosts? I figured as a traffic routing (and not just DNS) service it'd destroy performance off any traffic what so ever if it goes badly, not just the initial resolution.
    – Allison
    Commented Nov 26, 2017 at 17:01
  • 3
    Useless use of backticks. Commented Nov 26, 2017 at 20:43
  • 1
    If I may suggest a bit of improvement here, for i in $(cat ~/blocking.txt); do is kinda poor style in shell scripts. One, that's useless use of cat and two, it won't output lines properly with leading tabs/spaces. De-facto standard is via while IFS= read -r line; do...done < input.txt or better while IFS='' read -r l || [ -n "$l" ];do...done<input.txt to handle files without newline at the end of file. See also this. Or this if you want to use for loops. Commented Nov 27, 2017 at 8:21
  • 2
    Actually there are good reasons to use DROP rather than REJECT in firewall rules. DROP looks to an attacker like there is no computer present. REJECT confirms there is a working system listening at that IP address and it may be worth trying different attack vectors. For that reason it's common on servers to DROP ping and other identity confirming messages to minimise the server's visibility to script kiddies.
    – matt
    Commented Nov 27, 2017 at 10:56

[...] while looking for a simple OS-level website blocking technique, I came upon the solution of using the linux hosts file [...]

To clarify, /etc/hosts just maps hostnames to IP addresses. An entry with doesn't block your access to the server, it just makes your computer locally resolve that particular name to You and the server could still be exchanging packets without restrictions.

If I often use for web development purposes, is this dangerous? It seems that, at the very least it could mess up the web dev project I'm currently working on?

No, resolving to doesn't put you in additional danger. That's because a website can have their name be resolved to any IP anyway, including (unless the DNS server blocks that). So if evilpage.example wanted to resolve to, they could just specify a respective DNS A record and wouldn't have to rely on your /etc/hosts. (Also see: Is it safe to have a DNS record pointing to

Note that running something on may make you vulnerable to DNS rebinding attacks.


Unless your webserver is running on port 80 or 443 on your local machine (, then that shouldn't affect your web project. If it is though, then it could be an annoyance. If you sent a request to http://example.com/api/, then it would end up sending a request to If you have a resource called /api/, then it would end up receiving the request and thus interfering with your app. But the biggest point that I would like to stress that @Arminus mentioned was that the /etc/hosts/ file is for mapping IP addresses to hostnames. If you want to block a particular host, I would suggest installing a firewall such as UFW or using the default Linux firewall, iptables. Here are some links to help you get started:

UFW: https://www.linux.com/learn/introduction-uncomplicated-firewall-ufw

iptables: https://www.howtogeek.com/177621/the-beginners-guide-to-iptables-the-linux-firewall/


If you want to use an IP address that should not go anywhere, you can use the official documentation IP addresses:


It's still possible that they go somewhere, but they SHOULD be added to non-routable address spaces. As others have noted, that potentially will only route your traffic to those IP addresses - there are better solutions mentioned in the other answers, but these at least won't go to your local machine.


The entire address range is localhost so you can block outgoing traffic for one address in this range for example

Then use the hosts file to redirect unwanted traffic to this address so unwanted tracking requests won't hammer your webserver running on localhost.

You must log in to answer this question.