I do! I do! I got one with over 9000 entried to protect me at a global level. Helps loads.
Page 1 / 1
I don't use a HOSTS file for the simple reason many domains become outdated in a short space of time. It is a time-consuming job to keep such HOSTS files updated.
I know there are programs and lists already created by others, and some might find them useful in keeping a HOSTS file up to date if they wish to use them.
I know there are programs and lists already created by others, and some might find them useful in keeping a HOSTS file up to date if they wish to use them.
I got a batch file one that you can download and run to update for you.
I don't, for several reasons in fact...
TonyW has already brought up one of the reasons: Keeping it up to date. Not gonna happen. The advanced threats that really need to be worried about aren't going to use consistent hosts.
The next bit of fun is the impact on general network use, especially if the hosts file is used to block ads. It's not pretty, and even better, all those broken images and page load delays as the computer tries to pummel itself for information that it won't give or get.
The final impact is more sinister though. Security. Worse, it's in multiple parts...
Advanced threats aren't going to touch your hosts file at all because they won't use the Windows DNS resolution system. They'll toss their request out to a name server directly and the hosts file won't have an impact on them at all.
On top of that, there are threats that will happily install a micro web server locally and all of those hosts redirects to keep them away from bad stuff suddenly become not only worse than the other bad stuff, but also a treasure trove of information for the threat to look at.
And finally, many network security systems like to use reverse DNS to help protect. For example, they know that evil.com is a bad location. In many cases they can see DNS or HTTP Header information requesting evil.com stuff, so they can cut it off directly. But a hard-coded request to 66.66.66.66 across TLS will foil that. So they toss the IP into a reverse DNS request and see that it comes out as evil.com, thus block it. But wait! Now the DNS system thinks that evil.com is 127.0.0.1. So not only is the possibility of triggering false positives for all connections to 127.0.0.1 out there, but to avoid that all of the domains in the hosts file can no longer be reliably reversed to, so the protection again direct, encrypted IP contact with them is compromised or eliminated.
In the end, hosts file-based blocking gives a false sense of security despite the fact that it can actually reduce that security. It's literally like trying to get rid of a field of gophers by putting a fake gopher at every gopher hole out there so the real gophers can't get into the holes. The downside is that the moment a new hole pops up and has no fake gopher at it, it's impossible to reliably spot the real gopher amongst all the fakes. It's tremendously better than nothing, if no other options exist for the user at all, but almost anything else is better than it.
TonyW has already brought up one of the reasons: Keeping it up to date. Not gonna happen. The advanced threats that really need to be worried about aren't going to use consistent hosts.
The next bit of fun is the impact on general network use, especially if the hosts file is used to block ads. It's not pretty, and even better, all those broken images and page load delays as the computer tries to pummel itself for information that it won't give or get.
The final impact is more sinister though. Security. Worse, it's in multiple parts...
Advanced threats aren't going to touch your hosts file at all because they won't use the Windows DNS resolution system. They'll toss their request out to a name server directly and the hosts file won't have an impact on them at all.
On top of that, there are threats that will happily install a micro web server locally and all of those hosts redirects to keep them away from bad stuff suddenly become not only worse than the other bad stuff, but also a treasure trove of information for the threat to look at.
And finally, many network security systems like to use reverse DNS to help protect. For example, they know that evil.com is a bad location. In many cases they can see DNS or HTTP Header information requesting evil.com stuff, so they can cut it off directly. But a hard-coded request to 66.66.66.66 across TLS will foil that. So they toss the IP into a reverse DNS request and see that it comes out as evil.com, thus block it. But wait! Now the DNS system thinks that evil.com is 127.0.0.1. So not only is the possibility of triggering false positives for all connections to 127.0.0.1 out there, but to avoid that all of the domains in the hosts file can no longer be reliably reversed to, so the protection again direct, encrypted IP contact with them is compromised or eliminated.
In the end, hosts file-based blocking gives a false sense of security despite the fact that it can actually reduce that security. It's literally like trying to get rid of a field of gophers by putting a fake gopher at every gopher hole out there so the real gophers can't get into the holes. The downside is that the moment a new hole pops up and has no fake gopher at it, it's impossible to reliably spot the real gopher amongst all the fakes. It's tremendously better than nothing, if no other options exist for the user at all, but almost anything else is better than it.
I do agree, however It does help alittle. I never say to anyone that it's the best solution.
I use Ad Muncher, have done for over six years.
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.