by lpsz on 2/12/16, 2:44 AM with 139 comments
by sugarfactory on 2/12/16, 8:20 AM
by sergiotapia on 2/12/16, 4:00 AM
A situation we can all imagine ourselves in: You need to check the google analytics for your website/company site. You can't because it's blocked at Host level.
What solution would there be for this use case?
by stblack on 2/12/16, 1:43 PM
I'm always looking for ways to improve things so I'm open to all suggestions.
EDIT: A couple of clarifications.
1) This isn't just for adblock. Your hosts file is useful for thwarting all sorts of malware. If a bot or trojan phones home with a domain, a vigilant hosts file will block it. A if a bot or trojan phones home with an IP, then the hosts file can't help you but, then again, an IP can be physically located fairly quickly.
2) The key to a good hosts file is keeping it current. This hosts file amalgamates several well-curated sources. So your hosts file is only as good as your ability to keep it current. This repo helps with this.
by baptistem on 2/12/16, 8:06 AM
using 127.0.0.1, I have a httpd responding to every request by a 200. this avoid some anti-ad-block check. (such as "watch this ad before your video")
you can also configure your server to reply with a cat gif. but who would like to see a such Internet?
by bloaf on 2/12/16, 4:46 AM
http://www.abelhadigital.com/hostsman
Lets you chose which lists to use, and automatically update those lists. Also makes it easy to temporarily disable your rules if you need something that's blocked. Has a button for flushing the DNS cache.
by stephendicato on 2/12/16, 4:35 PM
Blocking via your hosts file has some great benefits; it works regardless of network and is relatively easy to update. Unfortunately, it doesn't scale easily to many systems or give you any insight into whether or not you are trying to connect to blocked domains.
Blocking via DNS is a good alternative and is suggested multiple times in this thread. You can easily protect a whole network by setting your recursive resolvers and it works across any system.
If you are interested in this and don't want to operate and maintain your own DNS (as well as pulling down various domain lists) check out https://strongarm.io. We manage DNS, aggregating lists of bad domains, and (most uniquely) will alert you if you try and talk to a blocked domain.
It's free for personal use. We are a growing startup and love feedback from HN. Feel free to contact me directly as well! stephen[at]strongarm.io
by vbezhenar on 2/12/16, 7:49 AM
by laumars on 2/12/16, 7:35 AM
I'm not going to argue that localhost is better than 0, but that specific argument they've raised is incorrect. You don't have to wait for a timeout on localhost either. It will either fail instantly due to no listening processes on that IP and port, or it will connect to whatever process you have open on that address (eg a local instance of a http daemon).
by jedisct1 on 2/12/16, 1:32 PM
by buro9 on 2/12/16, 3:42 PM
The reasons:
* Block adverts in native mobile apps
* Block adverts in mobile web browsing
* Create a single connection for the mobile (reduce exposure to latency of new connections to different servers)
* VPN connection keep-alive means I seldom reconnect
* Side effect of mitigating risk of my telco screwing with my traffic or excessively logging metadata
It works really, really well.
I'm sure someone will say "battery!" but the cost of mobile adverts on batteries far outweighs the cost of connecting to a VPN.
This is effectively adblock for mobile that works for all apps and websites.
by RKearney on 2/12/16, 4:01 AM
On second thought, you shouldn't be using the hosts file for this at all.
by SixSigma on 2/12/16, 8:52 AM
by Stamy on 2/12/16, 8:13 AM
by riobard on 2/12/16, 8:13 AM
by finishingmove on 2/13/16, 12:34 AM
by jcoffland on 2/12/16, 6:20 AM
Edit: AdAway uses an /etc/hosts file.
by aapje on 2/12/16, 9:31 AM
Anyone exprerienced doing this?
by sosuke on 2/12/16, 4:52 AM
by jakeogh on 2/12/16, 4:12 AM
by jdoss on 2/12/16, 5:59 AM
https://github.com/jdoss/dockerhole
It was inspired by https://pi-hole.net/ and I am glad to see there are others making similar things to block Ads.
by stirner on 2/13/16, 12:02 AM
There's a bit of an impedance mismatch since filter lists support some fairly advanced pattern matching while hosts file entries are obviously limited to specific domains, but it gets most domains.
by jsingleton on 2/12/16, 11:11 AM
You can also block the BBC Breaking News banner this way by adding polling.bbc.co.uk. Or if you want to play a prank use 192.30.252.153 as the IP. GitHub pages don't check if you own the domain.
https://unop.uk/dev/breaking-the-news-blocking-the-bbc-news-...
by Borating on 2/12/16, 1:58 PM
A pi-hole clone notrack [2]
[1] https://gaenserich.github.io/hostsblock/ | [2] https://github.com/quidsup/notrack
by derFunk on 2/12/16, 8:22 AM
by dbalan on 2/12/16, 12:41 PM
This is for people who cannot edit /etc/hosts, but can change DNS server.
by dbg31415 on 2/12/16, 2:07 PM
Ads slow us down.
by cdnsteve on 2/12/16, 1:12 PM
by kamaal on 2/12/16, 5:58 PM
Would love to see some project like that.
by kup0 on 2/12/16, 3:13 AM
Ad-blocking via hosts files can often lead to a noticeable performance hit.
by IgorPartola on 2/12/16, 1:56 PM
by LoSboccacc on 2/12/16, 10:05 AM
Has window 10 got better with that?
by simoncion on 2/12/16, 5:38 AM
Although figuring out how to propagate RPZ changes to them isn't exactly straightforward (more on this below), if you're using BIND, you can set up views that match certain clients and provide one mix of RPZs to one set, and another to another set.
On updating RPZs in a view (warning: BIND 9-specific instructions follow) :
So, BIND has this nifty option for a zone called "in-view". This lets you say "The data for this particular zone lives in this other view, so when requests come in for this zone, in this view, use the data in this other view.". It might sound complicated, but it's really just a pointer to a pre-existing zone definition. This lets you define your master zones in one big "zone definition" view, and have client-specific views refer back to those definitions.
However, you can't use in-view with RPZs. Why? Who knows? [2] But, what you can do is this:
* Create one unique RNDC key per view
* Add an allow-notify and match-clients entry in each view with that view's key
* In the appropriate views, add a slave zone definition for each relevant RPZ, with localhost as the master, and whatever is your usual domain xfer key as the key [3]
* Back up in your "zone definition" view, add to your also-notify list for each master RPZ definition an entry for localhost and each view key. [4] Having an ACL just for these RPZ slaves cleans up the RPZ definitions.
Now you have dynamically updatable host blocking that can be deployed on a per-host basis, if you like. It's initially a bit more work than managing a local hosts file, but you can easily apply host blocking lists to any set of machines on your LAN, and you can programmatically update the RPZ lists with tools like nsupdate.
[0] http://jpmens.net/2011/04/26/how-to-configure-your-bind-reso...
[1] http://www.zytrax.com/books/dns/ch7/rpz.html
[2] RPZs are handled just like regular zones in every other way except for this one. It's a bit frustrating.
[3] This is actually less burdensome than it sounds, as you can write these slave zone definitions once and include the files containing the definitions in whatever view needs them.
[4] That is, if you had three views, your also-notify list would have something like the following new entries: 127.0.0.1 key "view1-key"; 127.0.0.1 key "view2-key"; 127.0.0.1 key "view3-key"; You can have entries for just the views that use a given RPZ, but it doesn't hurt to have one ACL that notifies all views when any RPZ data changes.
by bitsoda on 2/12/16, 1:34 PM
by pette on 2/12/16, 10:28 AM
by DyslexicAtheist on 2/12/16, 4:12 PM
by pauly on 2/12/16, 10:04 AM
by Xophmeister on 2/12/16, 10:24 AM