Discussion:
Why doesn't NetBSD recognize my entries in /etc/hosts?
(too old to reply)
Johnny Billquist
2015-09-16 19:36:14 UTC
Permalink
RE: http://mail-index.netbsd.org/netbsd-users/2014/04/27/msg014543.html
I put domains that I want to block in /etc/hosts preceded by 0.0.0.0
but I can still ping them.
I rebooted, but I can still ping them.
Then I have mass-changed all entries from 0.0.0.0 to 127.0.0.1 and I
can still ping them.
Rebooted, same thing.
Why can I do this effortlessly with Windows and Linux but not with NetBSD?
First of all, using /etc/hosts as a way of block domains is extremely
unreliable and not really a meaningful way of actually block anything.
Why? It works on other platforms?
Depends on what you mean by "works". Changing things in /etc/hosts does
not prevent me from reaching any of those places. It just prevents me
from using those specific names for reaching them. What are you trying
to do? Just prevent local users from using the domain names? Because
that is all you can hope to accomplish. And it also depends on whatever
application we're talking about also not trying to do DNS lookups on its
own, totally circumventing any reference to the local /etc/hosts file.
Second, I guess you haven't heard of /etc/nsswitch.conf. It also exists in
Linux. It tells which methods are used, and in which order. It might be that
you have dns before files.
I've checked my nsswitch.conf, it's files before hosts
Changing a destination to 127.0.0.1, and then pinging it, why would you
expect it to not work. 127.0.0.1 will most likely respond to pings.
Pinging 0.0.0.0 will also give some result. Most probably your default
gateway machine.
Yes, I didn't express myself correctly. I meant that I ping the
original host, not 127.0.0.1.
BTW, rebooting TWICE produced the intended result. I wonder why I had
to reboot twice.
That sounds extremely strange.
Maybe you should try and learn about /etc/hosts.deny as well as ipfilters?
But again, why?
If I have a list of 300 domains to block, this would not be practicable.
The question is - what do you actually want to do. And how it entering
them all in /etc/hosts any more practicable than using /etc/hosts.deny?
But it do achieve different goeals. /etc/hosts.deny will stop any
connections *from* those places, but will not prevent local users from
contacting those places.
But, like I said, /etc/hosts do not stop you from accessing anything.
It, at most, will prevent your usage of certain domain names.

Johnny


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ottavio Caruso
2015-09-16 19:56:56 UTC
Permalink
Maybe you should try and learn about /etc/hosts.deny as well as ipfilters?
But again, why?
If I have a list of 300 domains to block, this would not be practicable.
The question is - what do you actually want to do. And how it entering them
all in /etc/hosts any more practicable than using /etc/hosts.deny?
There are third party lists of domains that are either malware or
nasty tracing cookies, this is one of them:
http://winhelp2002.mvps.org/hosts.txt

This is what I want to do. This is my machine and I am happy with
blocking all these domains. It might not be the most elegant thing to
do but it works for me.

Hosts.deny blocks those domains accessing services on my computer but
not my computer accessing their servers.

Running ipfilter is a bit overkill.
--
Ottavio

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Martin Husemann
2015-09-17 05:54:16 UTC
Permalink
Post by Ottavio Caruso
There are third party lists of domains that are either malware or
http://winhelp2002.mvps.org/hosts.txt
ping mfr.a2dfp.net
PING mfr.a2dfp.net (0.0.0.0): 56 data bytes
64 bytes from 192.168.111.42: icmp_seq=0 ttl=255 time=0.366921 ms
64 bytes from 192.168.111.42: icmp_seq=1 ttl=255 time=0.328004 ms
...

This is my gateway answering (as expected).

I have

lookup file bind

in /etc/resolv.conf and default /etc/nsswitch.conf.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Eric Haszlakiewicz
2015-09-16 22:19:58 UTC
Permalink
http://mail-index.netbsd.org/netbsd-users/2014/04/27/msg014543.html
I put domains that I want to block in /etc/hosts preceded by 0.0.0.0
but I can still ping them.
I rebooted, but I can still ping them.
Then I have mass-changed all entries from 0.0.0.0 to 127.0.0.1 and I
can still ping them.
Rebooted, same thing.
Why can I do this effortlessly with Windows and Linux but not with
NetBSD?
First of all, using /etc/hosts as a way of block domains is extremely
unreliable and not really a meaningful way of actually block
anything.
Why? It works on other platforms?
Second, I guess you haven't heard of /etc/nsswitch.conf. It also
exists in
Linux. It tells which methods are used, and in which order. It might
be that
you have dns before files.
I've checked my nsswitch.conf, it's files before hosts
Changing a destination to 127.0.0.1, and then pinging it, why would
you
expect it to not work. 127.0.0.1 will most likely respond to pings.
Pinging 0.0.0.0 will also give some result. Most probably your
default
gateway machine.
Yes, I didn't express myself correctly. I meant that I ping the
original host, not 127.0.0.1.
BTW, rebooting TWICE produced the intended result. I wonder why I had
to reboot twice.
Fwiw, using /etc/hosts sounds entirely reasonable for what you're trying to do (and hosts.deny, though having a similar name, is pointless to look at).

Do additional changes require a reboot? If so, something is really odd. Changes to /etc/hosts should take effect immediately. Maybe use ktrace/kdump to see if it's actually being read?

Eric



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ottavio Caruso
2015-09-17 17:32:26 UTC
Permalink
Show us a sample hosts entry and the full output of your ping, please.
Ok, this is not necessary now.

For some reasons, I have redone the whole process today and the
entries were correctly redirected to 0.0.0.0 as expected.

There must have been a file corruption when downloading the file from:
http://winhelp2002.mvps.org/hosts.txt

The first time I just downloaded it with wget.

Now I have selected all text and copied it into leafpad, then moved it
to /etc/hosts.

There might have been some extra line feed that could have prevented
the file from being parsed correctly.

It's my bad. This has nothing to do with NetBSD.

Thank you all for your contribution.


Ottavio

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Eric Haszlakiewicz
2015-09-18 02:29:01 UTC
Permalink
Post by Ottavio Caruso
Show us a sample hosts entry and the full output of your ping, please.
Ok, this is not necessary now.
For some reasons, I have redone the whole process today and the
entries were correctly redirected to 0.0.0.0 as expected.
http://winhelp2002.mvps.org/hosts.txt
The first time I just downloaded it with wget.
Now I have selected all text and copied it into leafpad, then moved it
to /etc/hosts.
There might have been some extra line feed that could have prevented
the file from being parsed correctly.
Yep, there definitely are carriage returns (not line feeds), but it's
not file corruption, it's just a MS Windows style text file.
If you open it in vi you'll clearly see all the "^M"'s at the end of
each line.

Assuming you'll want to fetch an updated copy of that file in the
future, you can automatically trim those off with something like this:
ftp -o - http://winhelp2002.mvps.org/hosts.txt | tr -d '\r' > hosts.txt

(wget should work too, but NetBSD's ftp does what you need without any
extra packages)

Eric

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Johnny Billquist
2015-09-18 21:22:43 UTC
Permalink
Post by Eric Haszlakiewicz
Post by Ottavio Caruso
Show us a sample hosts entry and the full output of your ping, please.
Ok, this is not necessary now.
For some reasons, I have redone the whole process today and the
entries were correctly redirected to 0.0.0.0 as expected.
http://winhelp2002.mvps.org/hosts.txt
The first time I just downloaded it with wget.
Now I have selected all text and copied it into leafpad, then moved it
to /etc/hosts.
There might have been some extra line feed that could have prevented
the file from being parsed correctly.
Yep, there definitely are carriage returns (not line feeds), but it's
not file corruption, it's just a MS Windows style text file.
If you open it in vi you'll clearly see all the "^M"'s at the end of
each line.
Assuming you'll want to fetch an updated copy of that file in the
ftp -o - http://winhelp2002.mvps.org/hosts.txt | tr -d '\r' > hosts.txt
(wget should work too, but NetBSD's ftp does what you need without any
extra packages)
Hum. That's what *text* mode in ftp is there for... :-)
The various conventions on how text files indicate newlines in different
operating systems should not carry across. Someone running ftp in binary
mode when they shouldn't? :-)

Johnny


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Eric Haszlakiewicz
2015-09-18 22:48:18 UTC
Permalink
Post by Johnny Billquist
Hum. That's what *text* mode in ftp is there for... :-)
The various conventions on how text files indicate newlines in
different
operating systems should not carry across. Someone running ftp in binary
mode when they shouldn't? :-)
Which, afaik, doesn't apply to things fetched over http. Don't get stuck on the fact that the tool mentioned happens to be called "ftp", which historically had features that are questionable for current usages.
While perhaps convenient occasionally, in my experience having a file transfer tool "adjust" your file, especially by default and silently, has led to more problems than it solves.

Eric


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...