Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #405154 > unrolled thread

Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus.

Back to article view | Back to ger.ct

Contents

  Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. "Dr. Joachim Neudert" <neudert@5sl.org> - 2019-07-06 12:22 +0200
    Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2019-07-06 13:02 +0200
      Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. "Dr. Joachim Neudert" <neudert@5sl.org> - 2019-07-06 13:25 +0200
        Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Ulrich Heidenreich <from!not-for-mail@tremornet.de> - 2019-07-06 13:30 +0200
          Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. "Dr. Joachim Neudert" <neudert@5sl.org> - 2019-07-06 13:36 +0200
            Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Ulrich Heidenreich <from!not-for-mail@tremornet.de> - 2019-07-06 15:06 +0200
              Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dr. Joachim Neudert <neudert@5sl.org> - 2019-07-06 15:30 +0000
                Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Ruediger Lahl <ruediger.lahl@gmx.de> - 2019-07-06 18:30 +0200
        Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dietz Proepper <dietz-news@rotfl.franken.de> - 2019-07-06 13:52 +0200
        Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2019-07-06 22:06 +0200
        Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2019-07-06 22:14 +0200
          Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dr. Joachim Neudert <neudert@5sl.org> - 2019-07-07 05:53 +0000
            Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. "Dr. Joachim Neudert" <neudert@5sl.org> - 2019-07-07 09:36 +0200
              Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Ulrich Heidenreich <from!not-for-mail@tremornet.de> - 2019-07-07 09:56 +0200
                Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. "Dr. Joachim Neudert" <neudert@5sl.org> - 2019-07-07 10:09 +0200
                  Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Ulrich Heidenreich <from!not-for-mail@tremornet.de> - 2019-07-07 10:18 +0200
                    Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. "Dr. Joachim Neudert" <neudert@5sl.org> - 2019-07-07 10:22 +0200
              Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dietz Proepper <dietz-news@rotfl.franken.de> - 2019-07-07 12:04 +0200
                Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dennis Preiser <d__p@d--p.de> - 2019-07-07 11:34 +0000
                  Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dietz Proepper <dietz-news@rotfl.franken.de> - 2019-07-07 13:52 +0200
                    Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dennis Preiser <d__p@d--p.de> - 2019-07-07 12:14 +0000
                      Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dietz Proepper <dietz-news@rotfl.franken.de> - 2019-07-07 14:36 +0200
                        Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dennis Preiser <d__p@d--p.de> - 2019-07-07 14:05 +0000
                          Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dr. Joachim Neudert <neudert@5sl.org> - 2019-07-07 14:17 +0000
                            Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dennis Preiser <d__p@d--p.de> - 2019-07-07 14:58 +0000
                              Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. "Dr. Joachim Neudert" <neudert@5sl.org> - 2019-07-07 17:10 +0200
                                Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dietz Proepper <dietz-news@rotfl.franken.de> - 2019-07-07 17:21 +0200
                                  Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. "Dr. Joachim Neudert" <neudert@5sl.org> - 2019-07-07 17:40 +0200
                                    Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dennis Preiser <d__p@d--p.de> - 2019-07-07 16:24 +0000
                      Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. "Dr. Joachim Neudert" <neudert@5sl.org> - 2019-07-07 14:55 +0200
                        Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. "Dr. Joachim Neudert" <neudert@5sl.org> - 2019-07-07 15:15 +0200
            Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2019-07-07 09:51 +0200
      Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dietz Proepper <dietz-news@rotfl.franken.de> - 2019-07-06 13:31 +0200
    Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dietz Proepper <dietz-news@rotfl.franken.de> - 2019-07-06 13:03 +0200
      Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. "Dr. Joachim Neudert" <neudert@5sl.org> - 2019-07-06 13:31 +0200
        Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Dietz Proepper <dietz-news@rotfl.franken.de> - 2019-07-06 14:07 +0200
    Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Carlo XYZ <carloxyz@invalid.invalid> - 2019-07-06 14:47 +0200
    Re: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus. Gerald Eіscher <Spamer@fahr-zur-Hoelle.org> - 2019-07-07 00:45 +0200
    GoT (was: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus.) Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2019-07-08 17:00 +0200

Page 2 of 2 — ← Prev page 1 [2]

#405222

Dietz Proepper <dietz-news@rotfl.franken.de> wrote:
> Dennis Preiser wrote:
>> Versuch ein 'www' davor. Zur Illustration mal folgende Zeilen in der
>> /etc/hosts:
>> 
>> 127.0.0.1       heise.de
>> 127.0.0.1       www.heise.de
>> ::1             heise.de
>> ::1             www.heise.de
>> 
>> Damit wird in Safari der Aufruf von 'heise.de' erfolgreich
>> unterbunden.
> 
> Ok, dann ist ja alles gut. Was mich aber ohnehin ein wenig wundert - in 
> Joachims Originalpost standen jeweils nur Domainnamen, keine Hostnamen. 
> Das kann so eigentlich nie funktioniert haben. Bzw. nur, wenn die 
> entsprechenden Entitäten eben über foo.com und nicht über www.foo.com 
> angesprochen werden. In beiden Fällen sollte aber die obige 
> Doppelnennung nicht nötig sein.

Zumindest das später aufgeführte covertcomputerhelp.fun reagiert auch
auf www.covertcomputerhelp.fun.

>> Mit tcpdump kann man sich ansehen, was genau nach außen geht. Da
>> braucht man nicht rumraten.

> Und tcpdump hilft Dir bei der Frage, wann und wie die /etc/hosts 
> ausgewertet wird auch nicht so richtig weiter.

Diese Frage hätte ich mir erst gestellt, wenn exakt das, was ich da
eingetragen habe, trotzdem nach außen geht.

Dennis

[toc] | [prev] | [next] | [standalone]

#405223

Dennis Preiser wrote:

> Dietz Proepper <dietz-news@rotfl.franken.de> wrote:
>> Dennis Preiser wrote:
>>> Versuch ein 'www' davor. Zur Illustration mal folgende Zeilen in der
>>> /etc/hosts:
>>> 
>>> 127.0.0.1       heise.de
>>> 127.0.0.1       www.heise.de
>>> ::1             heise.de
>>> ::1             www.heise.de
>>> 
>>> Damit wird in Safari der Aufruf von 'heise.de' erfolgreich
>>> unterbunden.
>> 
>> Ok, dann ist ja alles gut. Was mich aber ohnehin ein wenig wundert -
>> in Joachims Originalpost standen jeweils nur Domainnamen, keine
>> Hostnamen. Das kann so eigentlich nie funktioniert haben. Bzw. nur,
>> wenn die entsprechenden Entitäten eben über foo.com und nicht über
>> www.foo.com angesprochen werden. In beiden Fällen sollte aber die
>> obige Doppelnennung nicht nötig sein.
> 
> Zumindest das später aufgeführte covertcomputerhelp.fun reagiert auch
> auf www.covertcomputerhelp.fun.

Den finde ich in Joachims Originalpost nicht. Und bezweifle nachwievor, 
dass ein hosts-Eintrag der Form

1.2.3.4	covertcomputerhelp.fun

eine Auflösung für www.covertcomputerhelp.fun ergibt.

Bzw. eine glibc macht das offenbar nicht. Und das eine bsd $hier 
ebenfalls nicht.

>>> Mit tcpdump kann man sich ansehen, was genau nach außen geht. Da
>>> braucht man nicht rumraten.
> 
>> Und tcpdump hilft Dir bei der Frage, wann und wie die /etc/hosts
>> ausgewertet wird auch nicht so richtig weiter.
> 
> Diese Frage hätte ich mir erst gestellt, wenn exakt das, was ich da
> eingetragen habe, trotzdem nach außen geht.

Naja, lokales Cacheing etc. macht das ggf. ein wenig unzuverlässig. Aber 
klar, so herum geht's natürlich auch.

-- 
CASE NIGHTMARE GREEN

[toc] | [prev] | [next] | [standalone]

#405232

Dietz Proepper <dietz-news@rotfl.franken.de> wrote:
> Den finde ich in Joachims Originalpost nicht. Und bezweifle nachwievor, 
> dass ein hosts-Eintrag der Form
> 
> 1.2.3.4 covertcomputerhelp.fun
> 
> eine Auflösung für www.covertcomputerhelp.fun ergibt.
> 
> Bzw. eine glibc macht das offenbar nicht. Und das eine bsd $hier 
> ebenfalls nicht.

Ich gehe davon aus, dass das eine Funktion in Safari ist. Ohne Einträge
in der /etc/hosts geht beim Aufruf von heise.de in Safari ein Get an
heise.de (Port 80) raus. Hab ich folgendes in /etc/hosts:

127.0.0.1       heise.de
::1             heise.de

dann geht beim Aufruf von heise.de ein get an www.heise.de (Port 80)
raus. In beiden Fällen schickt heise ein 301 auf https://www.heise.de
zurück. Mit

127.0.0.1       heise.de
127.0.0.1       www.heise.de
::1             heise.de
::1             www.heise.de

in /etc/hosts geht nix mehr raus und Safari informiert, dass er sich
nicht mit dem Server verbinden kann.

Dennis

[toc] | [prev] | [next] | [standalone]

#405233

Dennis Preiser <d__p@d--p.de> wrote:
> Dietz Proepper <dietz-news@rotfl.franken.de> wrote:
>> Den finde ich in Joachims Originalpost nicht. Und bezweifle nachwievor, 
>> dass ein hosts-Eintrag der Form
>> 
>> 1.2.3.4 covertcomputerhelp.fun
>> 
>> eine Auflösung für www.covertcomputerhelp.fun ergibt.
>> 
>> Bzw. eine glibc macht das offenbar nicht. Und das eine bsd $hier 
>> ebenfalls nicht.
> 
> Ich gehe davon aus, dass das eine Funktion in Safari ist. Ohne Einträge
> in der /etc/hosts geht beim Aufruf von heise.de in Safari ein Get an
> heise.de (Port 80) raus. Hab ich folgendes in /etc/hosts:
> 
> 127.0.0.1       heise.de
>> :1             heise.de
> 
> dann geht beim Aufruf von heise.de ein get an www.heise.de (Port 80)
> raus. In beiden Fällen schickt heise ein 301 auf https://www.heise.de
> zurück. Mit
> 
> 127.0.0.1       heise.de
> 127.0.0.1       www.heise.de
>> :1             heise.de
>> :1             www.heise.de
> 
> in /etc/hosts geht nix mehr raus und Safari informiert, dass er sich
> nicht mit dem Server verbinden kann.
> 
> Dennis
> 

Und das Verhalten, das ich in meiner Antwort dargelegt habe, wie erklärt
sich das?
Geblockt in /etc/hosts mit IP 127.0.0.1 sind domain.com und www.domain.com


Beim ersten Aufruf von domain.com ergänzt Safari das www versuchsweise
selbst, zeigt eine Seite an mit dem nackten apache default einer doch
irgendwie  gefundenen IP für www.domain.com, beim Reload (Reload-Icon in
der Adresszeile) der Seite dann erklärt er korrekt das explizit geblockte
www.domain.com (das Safari ja selbst ergänzt hat auf Verdacht) sei nicht
erreichbar? 

Soll das so sein?

Gruß 

Joachim

-- 
please forgive my iPhone typos -sent via Newstap

[toc] | [prev] | [next] | [standalone]

#405235

Dr. Joachim Neudert <neudert@5sl.org> wrote:
> Und das Verhalten, das ich in meiner Antwort dargelegt habe, wie erklärt
> sich das?

Woher soll ich das wissen?

> Geblockt in /etc/hosts mit IP 127.0.0.1 sind domain.com und www.domain.com
> 
> Beim ersten Aufruf von domain.com ergänzt Safari das www versuchsweise
> selbst, zeigt eine Seite an mit dem nackten apache default einer doch
> irgendwie  gefundenen IP für www.domain.com,

Das ist Deine Interpretation. Die Seite könnte auch aus einem Cache
kommen.

>                                              beim Reload (Reload-Icon in
> der Adresszeile) der Seite dann erklärt er korrekt das explizit geblockte
> www.domain.com (das Safari ja selbst ergänzt hat auf Verdacht) sei nicht
> erreichbar? 
> 
> Soll das so sein?

Offensichtlich nicht, sonst würdest Du ja nicht nachfragen.

Mein heißer Tipp: die Seite kommt vor dem Reload aus dem Safari Cache.
Wenn dem so ist, dürfte das Verhalten nicht auftreten, wenn Du Safari im
Privat Mode betreibst:

<https://support.apple.com/de-de/guide/safari/ibrw1069/mac>

Dennis

[toc] | [prev] | [next] | [standalone]

#405236

Am 07.07.19 um 16:58 schrieb Dennis Preiser:
> Mein heißer Tipp: die Seite kommt vor dem Reload aus dem Safari Cache.
> Wenn dem so ist, dürfte das Verhalten nicht auftreten, wenn Du Safari im
> Privat Mode betreibst:

Wahrscheinlich.

Eben getestet: Im private Mode kommen bei beiden Schreibweisen von
vornherein keine Daten mehr:


covertcomputerhelp.fun
www.covertcomputerhelp.fun


Sollte er sich doch eigentlich auch im Cache merken ab dem zweiten
Versuch, daß die Seite nicht mehr unter dieser Adresse existiert, und
keine veralteten Daten immer wieder ausgeben.

Gruß

Joachim

[toc] | [prev] | [next] | [standalone]

#405237

Dr. Joachim Neudert wrote:

> Am 07.07.19 um 16:58 schrieb Dennis Preiser:
>> Mein heißer Tipp: die Seite kommt vor dem Reload aus dem Safari
>> Cache. Wenn dem so ist, dürfte das Verhalten nicht auftreten, wenn Du
>> Safari im Privat Mode betreibst:
> 
> Wahrscheinlich.
> 
> Eben getestet: Im private Mode kommen bei beiden Schreibweisen von
> vornherein keine Daten mehr:
> 
> 
> covertcomputerhelp.fun
> www.covertcomputerhelp.fun
> 
> 
> Sollte er sich doch eigentlich auch im Cache merken ab dem zweiten
> Versuch, daß die Seite nicht mehr unter dieser Adresse existiert, und
> keine veralteten Daten immer wieder ausgeben.

Caches sind komplexe Gebilde. Und ibs. das Speichern eines Fehlversuchs 
kann in dem Szenario unbeabsichtigte Folgen haben.

-- 
CASE NIGHTMARE GREEN

[toc] | [prev] | [next] | [standalone]

#405238

Am 07.07.19 um 17:21 schrieb Dietz Proepper:
> Dr. Joachim Neudert wrote:
> 
>> Am 07.07.19 um 16:58 schrieb Dennis Preiser:
>>> Mein heißer Tipp: die Seite kommt vor dem Reload aus dem Safari
>>> Cache. Wenn dem so ist, dürfte das Verhalten nicht auftreten, wenn Du
>>> Safari im Privat Mode betreibst:
>>
>> Wahrscheinlich.
>>
>> Eben getestet: Im private Mode kommen bei beiden Schreibweisen von
>> vornherein keine Daten mehr:
>>
>>
>> covertcomputerhelp.fun
>> www.covertcomputerhelp.fun
>>
>>
>> Sollte er sich doch eigentlich auch im Cache merken ab dem zweiten
>> Versuch, daß die Seite nicht mehr unter dieser Adresse existiert, und
>> keine veralteten Daten immer wieder ausgeben.
> 
> Caches sind komplexe Gebilde. Und ibs. das Speichern eines Fehlversuchs 
> kann in dem Szenario unbeabsichtigte Folgen haben.
> 

Oh-kay.

Ich konstatiere: Meine Blockversuche mit der /etc/hosts sind überwiegend
doch weiter erfolgreich, aber Safari unterläuft einige davon  mit einem
www vor der geblockten Domain, was dann wirksam ist wenn ein Nameserver
tatsächlich eine IP ausgibt zu www.boesebubens.de, und was man durch
ergänzendes Blocken auch von

127.0.0.1	www.boesebubens.de

ganz gut stoppen kann.

Google Chrome arbeitet hingegen immer wie erwartet, wie ping und anders
als nslookup.

Und die Blockliste von Google (die Apples Safari von "Google  Safe
Browsing" übernimmt) und vor allem von UBlock Origin blockiert auch
schon recht gut.


Und: Egal was Apple unternimmt, Pop-Ups und Öffnen von neuen Seiten
verdeckt im Hintergrund ist mit eingeschaltetem Javascript leider immer
wieder neu möglich.

https://support.apple.com/de-de/HT203987

Die boesenbubens finden leider immer neue Wege. Wie Hase und Igel.

Gruß

Joachim

[toc] | [prev] | [next] | [standalone]

#405239

Dr. Joachim Neudert <neudert@5sl.org> wrote:
> Ich konstatiere: Meine Blockversuche mit der /etc/hosts sind überwiegend
> doch weiter erfolgreich, aber Safari unterläuft einige davon  mit einem
> www vor der geblockten Domain, was dann wirksam ist wenn ein Nameserver
> tatsächlich eine IP ausgibt zu www.boesebubens.de, und was man durch
> ergänzendes Blocken auch von
> 
> 127.0.0.1       www.boesebubens.de
> 
> ganz gut stoppen kann.

Noch zwei Anmerkungen von mir.

Ich nutze Safari immer im Private Mode und sehe keinen Grund, das für
das tägliche Browsen nicht zu verwenden. Sehr selten gibt es Seiten, die
dann Probleme machen. Ironischerweise ist eine davon
developer.apple.com. Irgendetwas ging da im Private Mode nicht.

Deine Blockiererei funktioniert, ich hatte das am Beispiel von heise.de
verdeutlicht, nur mit ipv4. Wenn Deine bösen Buben ipv6 aktivieren,
greifen Deine 172.0.0.1er Einträge nicht.

Dennis

[toc] | [prev] | [next] | [standalone]

#405224

Am 07.07.19 um 14:14 schrieb Dennis Preiser:
> Dietz Proepper <dietz-news@rotfl.franken.de> wrote:
>> Dennis Preiser wrote:
>>> Versuch ein 'www' davor. Zur Illustration mal folgende Zeilen in der
>>> /etc/hosts:
>>>
>>> 127.0.0.1       heise.de
>>> 127.0.0.1       www.heise.de
>>> ::1             heise.de
>>> ::1             www.heise.de
>>>
>>> Damit wird in Safari der Aufruf von 'heise.de' erfolgreich
>>> unterbunden.
>>
>> Ok, dann ist ja alles gut. Was mich aber ohnehin ein wenig wundert - in 
>> Joachims Originalpost standen jeweils nur Domainnamen, keine Hostnamen. 
>> Das kann so eigentlich nie funktioniert haben. Bzw. nur, wenn die 
>> entsprechenden Entitäten eben über foo.com und nicht über www.foo.com 
>> angesprochen werden. In beiden Fällen sollte aber die obige 
>> Doppelnennung nicht nötig sein.
> 
> Zumindest das später aufgeführte covertcomputerhelp.fun reagiert auch
> auf www.covertcomputerhelp.fun.
> 
>>> Mit tcpdump kann man sich ansehen, was genau nach außen geht. Da
>>> braucht man nicht rumraten.
> 
>> Und tcpdump hilft Dir bei der Frage, wann und wie die /etc/hosts 
>> ausgewertet wird auch nicht so richtig weiter.
> 
> Diese Frage hätte ich mir erst gestellt, wenn exakt das, was ich da
> eingetragen habe, trotzdem nach außen geht.
> 
> Dennis
> 


Nice.
Ich hab jetzt auch die spezifische Zeile

127.0.0.1	www.covercomputerhelp.fun

ergänzt in /etc/hosts.
Dann den DNS-Cache geflusht.

sudo dscacheutil -flushcache

Dann Safari beendet und neu gestartet.

Wenn ich in der Adresszeile eingebe
covertcomputerhelp.fun

öffnet er erfolgreich die bekannte Apache-Seite, und schreibt in die
Adresszeile selbständig  oben rein

http://www.covertcomputerhelp.fun

Wenn ich jetzt den  Reload starte  in Safari (mit dem  Reload-Icon)-

dann zeigt er an
"Safari kann keine Verbindung zum Server aufbauen".

(Offenbar hat Safari noch einen eigenen DNS-Cache?)


Safari ausschalten, neu starten. In die Adresszeile direkt eingeben:

www.covertcomputerhelp.fun

Da wird auch wieder der Apache der Seite geladen.
Nochmal "Reload"- jetzt wird er geblockt...

Und wenn ich den Apache stoppe, neu starte und
http://www.covertcomputerhelp.fun
eingebe- dann wird er  beim ersten mal auch geladen, und beim "Reload"
geblockt.


Auch ein

sudo killall -HUP mDNSResponder;say DNS cache has been flushed

ändert nichts, beim ersten Versuch lädt der obige Apache-Server noch,
beim Reload nicht mehr.

Das Verhalten von Chrome gefällt mir jedenfalls  besser, da berechenbar.
In Chrome ist die Seite immer geblockt.

Ich hab bisher immer die Stamm-Domain geblockt, nicht  noch spezifische
Subdomains oder www-Präfix-Server. Die meisten Malware-Quellen die mir
unterkamen liefen auch nicht mit einem wwww-Präfix, ihre Adressen
entnahm ich aus der Safari-Adresszeile. Das Blocken hat bis vor einem
halben Jahr auf die Weise recht gut funktioniert, Fenster wurden zwar
weiter geöffnet (erstaunlich wie die Programmierer immer neue Methoden
finden ein unerwünschtes Pop-up Fenster zu öffnen) aber dann kam die
Meldung "Server reagiert nicht"

[toc] | [prev] | [next] | [standalone]

#405226

Am 07.07.19 um 14:55 schrieb Dr. Joachim Neudert:
> Ich hab bisher immer die Stamm-Domain geblockt, nicht  noch spezifische
> Subdomains oder www-Präfix-Server. 

Und funktioniert auch weiter so. Kommt offenbar sehr darauf an, ob es im
Zonefile für die Domain auch einen eigenen Nameserver-Record  gibt für
www.boesebubens.com , den Safari dann ungefragt zu öffnen versucht.

https://boesebubens.com/Malwareverzeichnis wird so jedenfalls weiter
erfolgreich geblockt. Eben getestet mit einem alten geblockten
Domaineintrag:

"Safari kann keine Verbindung zum Server aufbauen".


("boesebubens" ist natürlich nur ein Platzhalter)

[toc] | [prev] | [next] | [standalone]

#405213

Dr.  Joachim Neudert meinte:

> Mit ping getestet funktioniert es jetzt schon, siehe meine Antwort an
> Dietz. Da pingt er für den eingetragenen malwareserver.com die 127.0.0.1
> an, so wie sie in /etc/hosts eingetragen ist. Safari, der Browser,
> ignoriert es aber.

Safari ist kaputt ...

Mach einen Bugreport bei Apple auf.
-- 
 pgp-Key (RSA) 1024/09B8C0BD 
 fingerprint = 2C 49 FF B2 C4 66 2D 93  6F A1 FF 10 16 59 96 F3 
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#405171

Diedrich Ehlerding wrote:

> Dr. Joachim Neudert meinte:
> 
>> Er fragt also neuerdings erst das Telekom Speedport Modem, und erst
>> dann die lokale /etc/hosts ab. Regelwidrig, ja.
> 
> Kommt drauf an, wie du dein system eingestellt hast. (Ja, ich weiß, du
> hast es nicht selber eingestellt, sondern vvertraust auf Apple. aber
> Vertrauen ist gut, Kontrolle ist besser.)  Also:
> 
> Was ergibt
> 
>  grep "hosts:" /etc/nsswitch.conf
> 
> auf deinem System

Verwendet MacOS die ebenfalls? Tante Gurgel meint nach 15s "eher nicht".

-- 
CASE NIGHTMARE GREEN

[toc] | [prev] | [next] | [standalone]

#405161

Dr. Joachim Neudert wrote:

> Seit gut 4 Jahren verwende ich die /etc/hosts, um Sites zu blockieren,
> die nur Malware ausliefern wollen.

Kompliziert.

[...]
> Und weg war trustedmacleaner.com, wenn eine Site da darauf verlinken
> wollte und im Hintergrund ein Fenster öffnen.
> 
> Jetzt: funktioniert nicht mehr. Neue Site eingetragen, DNS-Cache
> gelöscht, testweise aufgerufen- Mist, sie wird immer noch aufgerufen.
> Nslookup gibt auch gleich brav die originale IP aus, nicht mehr
> 127.0.0.1

Nun, *ns*lookup sollte *immer* den Nameserver verwenden. Um den 
(libc-)Resolver zu testen ist z.B. ping empfehlenswerter.

> Ich hab schon etwas gesucht, bin auf das hier gestoßen:
> 
> der Befehl
> 
> scutil --dns gibt die Reihenfolge der Resolver an:
> 
> scutil --dns
> DNS configuration
[...]
> Er fragt also neuerdings erst das Telekom Speedport Modem, und erst
> dann die lokale /etc/hosts ab. Regelwidrig, ja. So kann das Blockieren
> von Sites natürlich nicht mehr gehen.

Bist Du Dir sicher? Ich kann mit dem Output von scutil wenig anfangen, 
die Dokumentation schweigt (natürlich) über die Details.

Und regelwidrig ist das erst mal nicht. Unter etwas linuxoidem ist das 
in /etc/nsswitch.conf fest gelegt und nirgendwo steht, dass /etc/hosts 
als erstes gefragt werden muss.

> Seit wann machen die das? Und wie kriegt man wieder den Vorrang der
> lokalen /etc/hosts zurück?

Unter Windoze und Linux könnte ich's Dir sagen. Mäkkes? BRRR.

Achja, ich hatte mir nochmal ein iPad (Pro,11") bestellt. Nix für ungut, 
es hat etwas über 30min gedauert, bis ich's wieder verpackt habe. Das 
war kurz nach dem Zeitpunkt, wo mich das Drecksteil mit 
"Sicherheitsfragen" nervte. Die Hardware ist ja wirklich nicht 
unschnuckelig (und wäre 2/3 des geforderten Preises sicherlich wert), 
aber das, was bei Apple als "Usability" durch geht ist nichtmal mehr ein 
schlechter Witz.

> Bin übrigens schon seit einer Woche wieder da, hab fleissig
> mitgelesen, aber wenig Grund gesehen mitzudiskutieren.

Ging mir nach dem Urlaub ähnlich.

> Seid doch mal wieder ein
> bisserl freundlicher zueinander, wenn jeder jedem überwiegend nur 
> noch Beleidigungen an den Kopf wirft, war's das mit dem Usenet und
> ger.ct.

Seufz. Ich gebe noch fünf Jahre.

> Mein Filter ist auch schon adjustiert, ihr erratet sicher für
> welchen Anonymous nach dieser Woche.

Well ...

-- 
CASE NIGHTMARE GREEN

[toc] | [prev] | [next] | [standalone]

#405168

Am 06.07.19 um 13:03 schrieb Dietz Proepper:
> Dr. Joachim Neudert wrote:
> 
>> Seit gut 4 Jahren verwende ich die /etc/hosts, um Sites zu blockieren,
>> die nur Malware ausliefern wollen.
> Kompliziert.
> 
> [...]
>> Und weg war trustedmacleaner.com, wenn eine Site da darauf verlinken
>> wollte und im Hintergrund ein Fenster öffnen.
>>
>> Jetzt: funktioniert nicht mehr. Neue Site eingetragen, DNS-Cache
>> gelöscht, testweise aufgerufen- Mist, sie wird immer noch aufgerufen.
>> Nslookup gibt auch gleich brav die originale IP aus, nicht mehr
>> 127.0.0.1
> Nun, *ns*lookup sollte *immer* den Nameserver verwenden. Um den 
> (libc-)Resolver zu testen ist z.B. ping empfehlenswerter.
> 


Interessant, Du hast recht:

joachims-imac-2014:etc neudert$ ping electosake.com
PING electosake.com (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.030 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.103 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.150 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.114 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.050 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.137 ms



Da nimmt er also das was in /etc/hosts steht, und pingt den localhost an.

joachims-imac-2014:etc neudert$ nslookup
> electosake.com
Server:		192.168.2.1
Address:	192.168.2.1#53

Non-authoritative answer:
Name:	electosake.com
Address: 104.26.2.179
Name:	electosake.com
Address: 104.26.3.179
>


Da zeigt er also leider die IP von Boesebuben.com weiter an, und das
steuert dann auch Safari an. Früher war auch für Safari dann Schluß beim
Localhost, das blocken hat so jahrelang gut funktioniert.

[toc] | [prev] | [next] | [standalone]

#405175

Dr. Joachim Neudert wrote:

> Am 06.07.19 um 13:03 schrieb Dietz Proepper:
>> Dr. Joachim Neudert wrote:
>> 
>>> Seit gut 4 Jahren verwende ich die /etc/hosts, um Sites zu
>>> blockieren, die nur Malware ausliefern wollen.
>> Kompliziert.
>> 
>> [...]
>>> Und weg war trustedmacleaner.com, wenn eine Site da darauf verlinken
>>> wollte und im Hintergrund ein Fenster öffnen.
>>>
>>> Jetzt: funktioniert nicht mehr. Neue Site eingetragen, DNS-Cache
>>> gelöscht, testweise aufgerufen- Mist, sie wird immer noch
>>> aufgerufen. Nslookup gibt auch gleich brav die originale IP aus,
>>> nicht mehr 127.0.0.1
>> Nun, *ns*lookup sollte *immer* den Nameserver verwenden. Um den
>> (libc-)Resolver zu testen ist z.B. ping empfehlenswerter.
> 
> Interessant, Du hast recht:

A professionals profession ;-).

> joachims-imac-2014:etc neudert$ ping electosake.com
> PING electosake.com (127.0.0.1): 56 data bytes
> 
> Da nimmt er also das was in /etc/hosts steht, und pingt den localhost
> an.
> 
> joachims-imac-2014:etc neudert$ nslookup
>> electosake.com
> Server:		192.168.2.1
> Address:	192.168.2.1#53
> 
> Non-authoritative answer:
> Name:	electosake.com
> Address: 104.26.2.179

Das ist so beabsichtigt! nslookup und dig etc. sind Tools, um einen 
Nameserver zu befragen! Die schauen nicht mal in die /etc/hosts (bzw. 
nicht für die eigentliche Namensauflösung). Mir ist btw. auch kein Tool 
bekannt, das "einfach" einen lookup über die entsprechende libc-Funktion 
macht. Soviel zu professional ;-).

> Da zeigt er also leider die IP von Boesebuben.com weiter an, und das
> steuert dann auch Safari an. Früher war auch für Safari dann Schluß
> beim Localhost, das blocken hat so jahrelang gut funktioniert.

Hmm. Schon mal mit einer "frischen" Safari.Instanz (ohne Deine 
Enstellungen, Plugins, $sonstwas) probiert?

Abgesehen davon, *Safari* war ein nützlicher Hinweis. Schau' z.B. mal 
nach

https://apple.stackexchange.com/questions/92710/why-is-safari-ignoring-my-etc-hosts-file

Das, was dort steht sieht erst mal nicht ganz unplausibel aus. Ibs. 
Eintrag #6 könnte man mal ausprobieren.

-- 
CASE NIGHTMARE GREEN

[toc] | [prev] | [next] | [standalone]

#405177

Am 06.07.19 um 12:22 schrieb Dr. Joachim Neudert:
> Seit gut 4 Jahren verwende ich die /etc/hosts, um Sites zu blockieren,
> die nur Malware ausliefern wollen.

> Er fragt also neuerdings erst das Telekom Speedport Modem, und erst dann
> die lokale /etc/hosts ab. Regelwidrig, ja. So kann das Blockieren von
> Sites natürlich nicht mehr gehen.
> 
> Seit wann machen die das? Und wie kriegt man wieder den Vorrang der
> lokalen /etc/hosts zurück?

Geht das nicht mit der gleichen utility?

(scutil --prefs und dann help, da gibt's Kommandos,
die interessant aussehen, zumindest unter meinem 10.13)

[toc] | [prev] | [next] | [standalone]

#405204

Am 06.07.19 um 12:22 schrieb Dr. Joachim Neudert:
> 
> Jetzt: funktioniert nicht mehr. Neue Site eingetragen, DNS-Cache
> gelöscht, testweise aufgerufen- Mist, sie wird immer noch aufgerufen.
> Nslookup gibt auch gleich brav die originale IP aus, nicht mehr 127.0.0.1
> 
> Ich hab schon etwas gesucht, bin auf das hier gestoßen:
> 
> der Befehl
> 
> scutil --dns gibt die Reihenfolge der Resolver an:
> 
> scutil --dns
> DNS configuration
> 
> resolver #1
>   search domain[0] : Speedport_W_921V_1_45_000
>   nameserver[0] : fe80::1%en0
>   nameserver[1] : 192.168.2.1
>   if_index : 5 (en0)
>   flags    : Request A records, Request AAAA records
>   reach    : 0x00020002 (Reachable,Directly Reachable Address)
> 
> resolver #2
>   domain   : local
>   options  : mdns
>   timeout  : 5
>   flags    : Request A records, Request AAAA records
>   reach    : 0x00000000 (Not Reachable)
>   order    : 300000
> 
> 
> 
> Er fragt also neuerdings erst das Telekom Speedport Modem, und erst dann
> die lokale /etc/hosts ab.

resolver #2 sieht *sehr* nach Bonjour (ZeroConf) aus und nicht nach
/etc/hosts.
Was dein Speedport als search domain per DHCP mitteilt, ist ziemlich
schräg, da sollte der domain name des lokalen Netzwerkes drin stehen.

> Regelwidrig, ja. So kann das Blockieren von
> Sites natürlich nicht mehr gehen.
> 
> Seit wann machen die das?

Die Ausgabe von 'scutil --dns' unter Schneeleopard sieht nicht
wesentlich anders wie deine obige aus.


-- 
Gerald

[toc] | [prev] | [next] | [standalone]

#405287 — GoT (was: Mac OSX 10.14.5 Mojave: Resolver wertet /etc/hosts erst an 2. Stelle aus.)

Salve allerseits,

Dr. Joachim Neudert schrieb:

> Bin übrigens schon seit einer Woche wieder da, hab fleissig mitgelesen,
> aber wenig Grund gesehen mitzudiskutieren

Und? Die Erklärung für das Ende von Game of Thrones inzwischen gesehen?
Wir sind übrigens mit Staffel 7 auch längst durch und kann dein Verdikt
nicht nachvollziehen! Die Geschichte wird konsequent weitererzählt und
ganz und gar auf das Ende fokussiert! Dass Staffel 7 so viel kürzer
und mit deutlich weniger Nebenhandlungen als sonst üblich dürfte
schlicht daran liegen, dass /The Winds of Winter/ noch gar
nicht erschienen ist und /A Dream of Spring/ bis dato
nur als Konzept existiert...

	M.f.G.

-- 
Diese E-Mail-Adresse wird nur aus nostalgischen Gründen verwendet. Sie
wird praktisch nie gelesen.  Das MausNet ist nicht tot – es riecht nur
etwas komisch... ;-)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | ger.ct

csiph-web