Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Security.nl vraagt script op van sseal.ru

24-08-2021, 19:55 door nicolaasjan, 52 reacties
Laatst bijgewerkt: 24-08-2021, 20:00
Dit script wordt geblokkeerd door uMatrix.
Screenshot:
https://dl.dropboxusercontent.com/s/7nl9wd3ahzan8ob/screenshot_sseal.png

Debian 10 Virtual Machine; Firefox ESR.
Maar ook in Linux Mint 19.3; Pale Moon.
Verschijnt echter niet in Firefox met DNS over HTTPS ingeschakeld (provider Quad9; blokkeert kwaadaardige domeinen).

Wat moet ik hier van denken?
Reacties (52)
24-08-2021, 20:50 door [Account Verwijderd]
Door nicolaasjan: Dit script wordt geblokkeerd door uMatrix.
Screenshot:
https://dl.dropboxusercontent.com/s/7nl9wd3ahzan8ob/screenshot_sseal.png

Debian 10 Virtual Machine; Firefox ESR.
Maar ook in Linux Mint 19.3; Pale Moon.
Verschijnt echter niet in Firefox met DNS over HTTPS ingeschakeld (provider Quad9; blokkeert kwaadaardige domeinen).

Wat moet ik hier van denken?

Aaaiii. Dat lijkt goed mis! Dat domein staat op immortal malware domains lijst: http://mirrors.usu.edu/malwaredomains/immortal_domains.txt (zoek in die pagina).
24-08-2021, 20:56 door Anoniem
Door nicolaasjan: Dit script wordt geblokkeerd door uMatrix.
Screenshot:
https://dl.dropboxusercontent.com/s/7nl9wd3ahzan8ob/screenshot_sseal.png

Dat lijkt veel op een mislukte (?) poging van een MITM aanval, door middel van SSL stripper.

Debian 10 Virtual Machine; Firefox ESR.
Maar ook in Linux Mint 19.3; Pale Moon.

De schaduw van Vladimir is hier niet zichtbaar, met uBlock in Tor Browser onder Tails OS 4.21

Wat moet ik hier van denken?

uMatrix en Quad9 voorkomen verbrande vingers. Pas op op wiens lange tenen je gaat staan.
24-08-2021, 21:18 door nicolaasjan
Door Toje Fos:
Aaaiii. Dat lijkt goed mis! Dat domein staat op immortal malware domains lijst: http://mirrors.usu.edu/malwaredomains/immortal_domains.txt (zoek in die pagina).
Ja, had ik ook gezien.
Ping geeft niets, omdat het ook in mijn hosts bestand staat:

ping sseal.ru
PING sseal.ru (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.031 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.068 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.054 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.072 ms
64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.059 ms
64 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0.077 ms
64 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0.088 ms
64 bytes from localhost (127.0.0.1): icmp_seq=8 ttl=64 time=0.070 ms

--- sseal.ru ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7167ms
rtt min/avg/max/mdev = 0.031/0.064/0.088/0.019 ms

Ik kan mij niet voorstellen dat zowel mijn systeem als die virtual machine met malware zijn geïnfecteerd.
Kan het zijn dat Security.nl is gecompromitteerd?

Ik zie zo gauw ook niets verdachts in de bron van Security.nl, waarbij ik moet toegeven dat mijn kennis van JavaScript nul is.
24-08-2021, 21:54 door Anoniem
Door nicolaasjan:
Ping geeft niets, omdat het ook in mijn hosts bestand staat:

Ik denk dat je daar de root-cause te pakken hebt. Deze site laadt geen rare dingen bij mij (tested in multiple vms). Ik gok dat je een weirde interactie te pakken hebt tussen umatrix en je hosts file. Maybe slim om voor de zekerheid toch even lokaal goed te kijken voor malware op je eigen pc?
25-08-2021, 07:21 door Anoniem
Door Anoniem: Dat lijkt veel op een mislukte (?) poging van een MITM aanval, door middel van SSL stripper

https://www.debian.org/security/2021/dsa-4963

CVE-2021-3711 openssl An attacker able to present SM2 content for decryption to an application can take advantage of this flaw to change application behaviour or cause the application to crash (denial of service).
25-08-2021, 08:59 door Anoniem
Aan de deskundigen;
Ik volg als niet iT geschoolde gebruiker deze site.
Nu zie ik dat t's min of meer gered lijkt te zijn door een scriptblokker umatriks.
Ik ben nal van meerdere berichten omtrent het nut van een scriptblokker begonnen met mijzelf te verdiepen in noscript.
Daar vielen de adressen die met een site meekomen natuurlijk op.
Nu vroeg ik mijzelf al af, hoe verifieer ik die adressen veilig op hun functie en/of reputatie?
Tot nu toe kan ik alleen Google gebruiken, maar hoe doen jullie die verificatie?
Jullie zullen er zeker vak-sites voor hebben.
Maar wat kan ik als leek veilig gebruiken om te zien of ik " gered ben" door noscript?
Dus hoe kan ik veilig nagaan waarmee ik te maken krijg?
Alvast bedankt.
25-08-2021, 09:52 door Anoniem
Door Anoniem: Nu vroeg ik mijzelf al af, hoe verifieer ik die adressen veilig op hun functie en/of reputatie?

Klik daarvoor de icoon van NoScript in de werkbalk aan, waardoor het menu met de verborgen URLs verschijnt. Laat de muiscursor in het NoScript venster over de getoonde domeinen van de third party's en trackers van de bezochte website zweven. De cursor neemt dan de vorm van een vraagteken aan. Als je de daaronder getoonde URL dan aanklikt, dan verschijnt de bijbehorende 'Security and Privacy Info' pagina van noscript.net, waarop je je oordeel mede kunt baseren.

Verificatie gaat op basis van reputatie van de gevonden trackers en / of met behulp van JavaScript malware scanners.
25-08-2021, 09:52 door Anoniem
Verhaaltje van "one bitten twice shy". Van zo'n incident leert men. En u bent zo iemand. Vertrouw geen onbekend script van 3rd party sites. Voorbeeldhttps://thehackerblog.com/the-noscript-misnomer-why-should-i-trust-vjs-zendcdn-net/
De Russische site is kwaadaardig (o.a. via Magento webshop hacks). Verwacht kwaadaardig script - is dagelijkse geautomatiseerde kost ;).
luntrus
25-08-2021, 09:57 door nicolaasjan
Door Anoniem @21:54:
Door nicolaasjan:
Ping geeft niets, omdat het ook in mijn hosts bestand staat:

Ik denk dat je daar de root-cause te pakken hebt. Deze site laadt geen rare dingen bij mij (tested in multiple vms). Ik gok dat je een weirde interactie te pakken hebt tussen umatrix en je hosts file. Maybe slim om voor de zekerheid toch even lokaal goed te kijken voor malware op je eigen pc?
Ja, als ik het hosts bestand terugzet naar default, zie ik dat domein niet verschijnen...

Ik zou echter niet weten waar ik in dit geval moet kijken naar eventueel aanwezige malware.
25-08-2021, 10:04 door nicolaasjan
Door Anoniem:
Door Anoniem: Dat lijkt veel op een mislukte (?) poging van een MITM aanval, door middel van SSL stripper

https://www.debian.org/security/2021/dsa-4963

CVE-2021-3711 openssl An attacker able to present SM2 content for decryption to an application can take advantage of this flaw to change application behaviour or cause the application to crash (denial of service).
OpenSSL is hier gister bijgewerkt:
openssl (1.1.1-1ubuntu2.1~18.04.13) bionic-security; urgency=medium
25-08-2021, 10:10 door nicolaasjan
Door Anoniem @20:56:
De schaduw van Vladimir is hier niet zichtbaar, met uBlock in Tor Browser onder Tails OS 4.21
In mijn Tor browser onder Mint 19.3 zie ik hem ook niet.
25-08-2021, 10:13 door nicolaasjan
Door Anoniem @8:59: Aan de deskundigen;
Ik volg als niet iT geschoolde gebruiker deze site.
Nu zie ik dat t's min of meer gered lijkt te zijn door een scriptblokker umatriks.
Ik ben nal van meerdere berichten omtrent het nut van een scriptblokker begonnen met mijzelf te verdiepen in noscript.
Daar vielen de adressen die met een site meekomen natuurlijk op.
Nu vroeg ik mijzelf al af, hoe verifieer ik die adressen veilig op hun functie en/of reputatie?
Tot nu toe kan ik alleen Google gebruiken, maar hoe doen jullie die verificatie?
Jullie zullen er zeker vak-sites voor hebben.
Maar wat kan ik als leek veilig gebruiken om te zien of ik " gered ben" door noscript?
Dus hoe kan ik veilig nagaan waarmee ik te maken krijg?
Alvast bedankt.
Ik denk dat je beter een nieuw topic kunt maken met deze vraag.
25-08-2021, 10:21 door nicolaasjan - Bijgewerkt: 25-08-2021, 10:49
Vreemd...
Als ik die entry 'sseal.ru' uit mijn hosts bestand verwijder, verschijnt 'ssh.mi61l.cn'
En als ik die weg haal, krijg ik 'ssiapawz.com'.

Deze domeinen zijn opeenvolgend in het hosts bestand...

[Edit]
En als ik er nog een paar weg haal verschijnt de aloude 'ssl.google-analytics.com'...
25-08-2021, 10:44 door Anoniem
Door nicolaasjan: Vreemd...
Als ik die entry 'sseal.ru' uit mijn hosts bestand verwijder, verschijnt 'ssh.mi61l.cn'
En als ik die weg haal, krijg ik 'ssiapawz.com'.

Deze domeinen zijn opeenvolgend in het hosts bestand...

ok gewoon een bug dus.
wellicht doet er ergens iets een reverse-lookup van 127.0.0.1 ?
het is ook niet handig om 127.0.0.1 te gebruiken als adres in een hostsfile die je wilt gebruiken om bepaalde domeinen
te "blokkeren". Neem dan iets anders bijv 127.1.1.1 ofzo.
25-08-2021, 11:04 door Erik van Straten
Door nicolaasjan: Vreemd...
Als ik die entry 'sseal.ru' uit mijn hosts bestand verwijder, verschijnt 'ssh.mi61l.cn'
En als ik die weg haal, krijg ik 'ssiapawz.com'.

Deze domeinen zijn opeenvolgend in het hosts bestand...

[Edit]
En als ik er nog een paar weg haal verschijnt de aloude 'ssl.google-analytics.com'...
Het lijkt er dus op dat:
- ssl.google-analytics.com JavaScript probeert op te halen van 127.0.0.1 (voor de mensen die dit niet weten, dat is altijd de computer zelf, dus niet iets op internet);
- je, bovenaan jouw hosts file, geen entries (zowel IPv4 als IPv6) hebt staan voor localhost;
- umatrix reverse lookups doet (IP-adres -> domeinnaam) en daar (al dan niet via het OS) de hosts file voor gebruikt.

De vraag blijft wel waarom Google dat doet (evt. onder welke omstandigheden).
25-08-2021, 11:42 door Anoniem
Aan 1e anoniem 09.52 en de 2e (luntrus)
Bedankt voor jullie reactie!
Dit begrijp ik en kan er tenminste weer iets meer mee.
Vooral ook bedankt voor de duidelijke waarschuwing luntrus.
Ik ken mijn plaats in deze. :-)
Groetjes.
25-08-2021, 12:06 door nicolaasjan
Door Anoniem @10:44:

ok gewoon een bug dus.
wellicht doet er ergens iets een reverse-lookup van 127.0.0.1 ?
het is ook niet handig om 127.0.0.1 te gebruiken als adres in een hostsfile die je wilt gebruiken om bepaalde domeinen
te "blokkeren". Neem dan iets anders bijv 127.1.1.1 ofzo.
Ik gebruik
0.0.0.0
25-08-2021, 12:10 door nicolaasjan - Bijgewerkt: 25-08-2021, 12:17
Door Erik van Straten:
Het lijkt er dus op dat:
- ssl.google-analytics.com JavaScript probeert op te halen van 127.0.0.1 (voor de mensen die dit niet weten, dat is altijd de computer zelf, dus niet iets op internet);
- je, bovenaan jouw hosts file, geen entries (zowel IPv4 als IPv6) hebt staan voor localhost;
- umatrix reverse lookups doet (IP-adres -> domeinnaam) en daar (al dan niet via het OS) de hosts file voor gebruikt.

De vraag blijft wel waarom Google dat doet (evt. onder welke omstandigheden).
Header van mijn hosts bestand:

127.0.0.1 localhost
127.0.1.1 nico-desktop
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

[Edit]
Als ik uMatrix uitschakel, krijg ik geen entry voor 'sseal.ru' in uBlock Origin's logger.
Ook niets in Developer tools.
25-08-2021, 12:14 door Anoniem
Door nicolaasjan:
Door Anoniem @10:44:

ok gewoon een bug dus.
wellicht doet er ergens iets een reverse-lookup van 127.0.0.1 ?
het is ook niet handig om 127.0.0.1 te gebruiken als adres in een hostsfile die je wilt gebruiken om bepaalde domeinen
te "blokkeren". Neem dan iets anders bijv 127.1.1.1 ofzo.
Ik gebruik
0.0.0.0

Deze uitspraak is in tegenspraak met wat je eerder plaatste:

ping sseal.ru
PING sseal.ru (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.031 ms
25-08-2021, 12:28 door Anoniem
Door Anoniem: Bedankt voor jullie reactie!

Een tip.

Laat je webbrowser onder Windows in een container of sandbox draaien. Dat maakt het gebruik van het web veiliger:

https://en.wikipedia.org/wiki/Sandboxie


Eigenaren van een Linux systeem gebruiken een AppArmor profiel of een Firejail, waarin ze de browser opsluiten.
25-08-2021, 13:15 door Anoniem
Door nicolaasjan: Dit script wordt geblokkeerd door uMatrix.
Screenshot:
https://dl.dropboxusercontent.com/s/7nl9wd3ahzan8ob/screenshot_sseal.png

Debian 10 Virtual Machine; Firefox ESR.
Maar ook in Linux Mint 19.3; Pale Moon.
Verschijnt echter niet in Firefox met DNS over HTTPS ingeschakeld (provider Quad9; blokkeert kwaadaardige domeinen).

Wat moet ik hier van denken?

Waar maakt u zich druk om?
Ik maak gebruik van een centrale server waar Pi-Hole op staat.
Als je alle query's bekijkt van bv de afgelopen 15 minuten gaan je nekharen overeind staan.
De meest vreemde sites worden aangeroepen als je browst over het internet.
25-08-2021, 14:00 door nicolaasjan
Door Anoniem @12:14:

Deze uitspraak is in tegenspraak met wat je eerder plaatste:

ping sseal.ru
PING sseal.ru (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.031 ms
Toch is het zo. ;)
Misschien "vertaalt" ping het niet bestaande adres '0.0.0.0' naar localhost?

Probeer het zelf maar eens met een test hosts bestandje.
25-08-2021, 14:35 door Erik van Straten
Door nicolaasjan: Misschien "vertaalt" ping het niet bestaande adres '0.0.0.0' naar localhost?
Weer een puzzelstukje ;-)

Volgens https://news.ycombinator.com/item?id=20397473 en https://unix.stackexchange.com/questions/99336/how-does-ping-zero-works geldt dat voor Linux (alle versies?).

Daar pas ik mijn analyse (op basis van erg weinig gegevens) op aan, het lijkt er dus op dat:
- ssl.google-analytics.com JavaScript probeert op te halen van 0.0.0.0 (of toch van 127.*.*.* en Firefox, een plug-in of Linux dat vertaalt naar 0.0.0.0);
- umatrix reverse lookups doet (IP-adres -> domeinnaam) en daar (al dan niet via het OS) de hosts file voor gebruikt, waarbij kennelijk de eerst gevonden domeinnaam gekoppeld aan 0.0.0.0 wordt geretourneerd.

De vraag blijft wel waarom Google dat doet (evt. onder welke omstandigheden). Of komt dit uit umatrix zelf? Maar waarom dan niet bij DoH?
25-08-2021, 15:37 door nicolaasjan
Door Erik van Straten:
Weer een puzzelstukje ;-)

Volgens https://news.ycombinator.com/item?id=20397473 en https://unix.stackexchange.com/questions/99336/how-does-ping-zero-works geldt dat voor Linux (alle versies?).

Daar pas ik mijn analyse (op basis van erg weinig gegevens) op aan, het lijkt er dus op dat:
- ssl.google-analytics.com JavaScript probeert op te halen van 0.0.0.0 (of toch van 127.*.*.* en Firefox, een plug-in of Linux dat vertaalt naar 0.0.0.0);
- umatrix reverse lookups doet (IP-adres -> domeinnaam) en daar (al dan niet via het OS) de hosts file voor gebruikt, waarbij kennelijk de eerst gevonden domeinnaam gekoppeld aan 0.0.0.0 wordt geretourneerd.

De vraag blijft wel waarom Google dat doet (evt. onder welke omstandigheden). Of komt dit uit umatrix zelf? Maar waarom dan niet bij DoH?

Als test heb ik even de optie in uMatrix om CNAME's te onthullen uitgezet.
Resultaat: geen 'sseal.ru' meer!

De oorzaak van deze "bug" is denk ik: in 1 regel in het hosts bestand staan 9 entries (dat kan).
Betreffende regel:

0.0.0.0 sseal.ru ssh.mi61l.cn ssiapawz.com sskill.b0ne.com ssl.bezpieczne-platnosci.pl ssl.clickbank.net ssl.full-secure-payments.online ssl.google-analytics.com ssl.siteimprove.com
25-08-2021, 16:18 door Erik van Straten
Door nicolaasjan:
0.0.0.0 sseal.ru [knip] ssl.google-analytics.com [knip]
Helder, zo lijkt sseal.ru een CNAME van ssl.google-analytics.com.

Wat me opviel (en verbaasde) in jouw screenshot was dat het "script" vakje van ssl.google-analytics.com groen was/is en "1" bevat. Daardoor ging ik er vanuit dat JavaScript vanaf ssl.google-analytics.com werd gedownload en uitgevoerd (wat niet gebeurt omdat jouw hosts file dat verhindert, maar dat weet umatrix niet).

Als je [*.]google-analytics.com in umatrix had geblokkeerd, was je niet op het verkeerde been gezet - maar dan had ook ik hier niets van geleerd ;-)
25-08-2021, 17:04 door nicolaasjan - Bijgewerkt: 25-08-2021, 17:34
Door Erik van Straten:
Door nicolaasjan:
0.0.0.0 sseal.ru [knip] ssl.google-analytics.com [knip]
Helder, zo lijkt sseal.ru een CNAME van ssl.google-analytics.com.

Wat me opviel (en verbaasde) in jouw screenshot was dat het "script" vakje van ssl.google-analytics.com groen was/is en "1" bevat. Daardoor ging ik er vanuit dat JavaScript vanaf ssl.google-analytics.com werd gedownload en uitgevoerd (wat niet gebeurt omdat jouw hosts file dat verhindert, maar dat weet umatrix niet).

Als je [*.]google-analytics.com in umatrix had geblokkeerd, was je niet op het verkeerde been gezet - maar dan had ook ik hier niets van geleerd ;-)
Ja, ik had het een keer groen gezet, omdat uBlock Origin het toch omleid naar een dummy script. ;)

https://github.com/gorhill/uBlock/blob/a94df7f3b27080ae2dcb3b914ace39c0c294d2f6/src/web_accessible_resources/google-analytics_ga.js

Misschien moet ik [*.]google-analytics.com maar uit het hosts bestand verwijderen.
Het schijnt dat er sites zijn die niet (helemaal) goed werken als het streng wordt geblokkeerd.
Daar helpt dan dat dummy script voor, schijnt het.

[Edit]
Of ondervangen uMatrix en uBlock Origin die netwerk aanvragen eerst?

[Edit2]
Ja dus.
Zie:
https://old.reddit.com/r/uBlockOrigin/comments/khkysa/is_using_a_hosts_file_block_list_in_windows_on/gglm0gg/
25-08-2021, 17:10 door Anoniem
Door Erik van Straten: Helder, zo lijkt sseal.ru een CNAME van ssl.google-analytics.com.

https://en.wikipedia.org/wiki/CNAME_record

A Canonical Name record (abbreviated as CNAME record) is a type of resource record in the Domain Name System (DNS) that maps one domain name (an alias) to another (the canonical name)
25-08-2021, 17:42 door nicolaasjan
Mijn kwestie is hierbij opgelost.

Met dank aan allen en vooral Erik van Straten voor het meedenken!
25-08-2021, 17:54 door Anoniem
je nu hoe instructief dit soort draadjes zijn. Zonder de OP en Erik van Straten was dit niet over het voetlicht gekomen. Toont ook wederom aan hoe Google van allerlei obfuscerende aliassen gebruik maakt, die hun allomtegenwoordige tracking tracht te verdoezelen. Malscript fighters hebben het daardoor niet gemakkelijk en ook degenen die precies willen analyseren wat er op de stack gebeurt.
luntrus
25-08-2021, 18:06 door nicolaasjan
25-08-2021, 18:45 door Erik van Straten
Door nicolaasjan:
Door Erik van Straten: Maar waarom dan niet bij DoH?

Gerelateerd:
https://bugzilla.mozilla.org/show_bug.cgi?id=1544233

https://bugzilla.mozilla.org/show_bug.cgi?id=1616252
Uit die bugzilla threads maak ik op dat de issue resolved zou zijn, waarmee -neem ik aan- bedoeld wordt dat Firefox, met DoH ingeschakeld, éérst de hosts file checkt (en bij een match geen DoH request doet).

Als je in je hosts file tijdelijk opneemt:
127.0.0.1 www.security.nl
en, met DoH aan, https://www.security.nl/ opent, wat gebeurt er dan?

Voor de zekerheid zou ik testen met die regel aan het begin van de hosts file, maar ook met die regel (uitsluitend) aan het einde van een lange hosts file.

Als, met DoH aan, deze site opent (zou niet moeten zoals zonder DoH), kan het zijn dat er iets (wellicht Firefox) herstart moet worden om de hosts file (na wijziging) opnieuw in te lezen. Ook kan het zijn dat Firefox wel werkt zoals verwacht, maar dat één of meer van jouw plugins het DNS gedrag veranderen als DoH aan staat.
25-08-2021, 19:59 door nicolaasjan - Bijgewerkt: 25-08-2021, 20:21
Door Erik van Straten:
Uit die bugzilla threads maak ik op dat de issue resolved zou zijn, waarmee -neem ik aan- bedoeld wordt dat Firefox, met DoH ingeschakeld, éérst de hosts file checkt (en bij een match geen DoH request doet).

Als je in je hosts file tijdelijk opneemt:
127.0.0.1 www.security.nl
en, met DoH aan, https://www.security.nl/ opent, wat gebeurt er dan?

Voor de zekerheid zou ik testen met die regel aan het begin van de hosts file, maar ook met die regel (uitsluitend) aan het einde van een lange hosts file.

Als, met DoH aan, deze site opent (zou niet moeten zoals zonder DoH), kan het zijn dat er iets (wellicht Firefox) herstart moet worden om de hosts file (na wijziging) opnieuw in te lezen. Ook kan het zijn dat Firefox wel werkt zoals verwacht, maar dat één of meer van jouw plugins het DNS gedrag veranderen als DoH aan staat.
Nou breekt mijn klomp!
Met www.security.nl in mijn hosts bestand laad de site wel (na herstart browser)!
Dat zou toch niet moeten neem ik aan.

[Edit]
Ook in een schoon nieuw profiel zonder add-ons.

[Edit2]
En ook in een andere browser zonder DoH...

Het hosts bestand wordt niet meer gelezen lijkt het...
(ook niet na herstart van de PC)
25-08-2021, 20:40 door nicolaasjan
Ik zie nu hoe dat kon:
In mijn hosts bestand stond ook:
82.94.191.109 www.security.nl
haha.

Weggehaald en nu wordt het hosts bestand wel gelezen door de andere browser en laadt de site niet.
Echter nog wel in Firefox met DoH...
25-08-2021, 20:57 door Erik van Straten - Bijgewerkt: 25-08-2021, 20:59
Door nicolaasjan: Met www.security.nl in mijn hosts bestand laad de site wel (na herstart browser)!
Dat zou toch niet moeten neem ik aan.
Dat lijkt controversieel als ik die bugzilla threads lees. Deze spreekt boekdelen, uit https://bugzilla.mozilla.org/show_bug.cgi?id=1544233#a34643193_1689:
Daniel Veditz [:dveditz]
Updated • 1 year ago (2020-05-18 12:19 PDT)
Type: defect -> enhancement

Voordat DoH in Firefox werd geïntroduceerd, raadpleegde Firefox gewoon het OS om domeinnamen naar IP-adressen te resolven (elk OS met een "TCP/IP stack" biedt die functionaliteit). Daarbij zorgt het OS voor het parsen van de hosts file (de meeste OS'en zullen er wel een in-memory cache voor hebben).

Voor zover ik weet bestaat er geen OS'en waaraan je kunt vragen een DNS-lookup in uitsluitend de hosts file te doen. Als Mozilla Firefox van DoH gebruik wil laten maken (buiten het OS om) zullen zij zelf die hosts file moeten parsen, en dat is duidelijk iets waar een deel van de Firefox ontwikkelaars geen zin in had (of heeft). Hoe ga je bijv. om met fouten daarin?

Nu zag ik dat je de ESR versie van Firefox gebruikt - ik gok, maar het zou kunnen dat de fix (of de "enhancement") wel in de main stream versie van Firefox, maar (nog) niet in ESR verwerkt is.

Dank voor het testen in elk geval: goed om te weten dat genomen beveiligingsmaatregelen in in de hosts file simpelweg genegeerd kunnen worden. Ik was al geen fan van DoH, maar deze kennis maakt het er niet beter op...

Ik checkte nog even in een nieuwe tab of je wellicht aanvullingen had gedaan, ja dus (ik laat de tekst hierboven maar voor wat het is).
Door nicolaasjan:
[Edit]
Ook in een schoon nieuw profiel zonder add-ons.

[Edit2]
En ook in een andere browser zonder DoH...

Het hosts bestand wordt niet meer gelezen lijkt het...
(ook niet na herstart van de PC)
Ik denk dat je het beste een paar bakken sterke koffie kunt nemen en dan een wandeling maken (neem een plu mee). En morgen dubbelchecken dat je geen tikfouten in de hosts file hebt gemaakt, en daarna uitzoeken wanneer die hosts file wel en wanneer niet wordt geraadpleegd :-)

Aanvulling: we raken out of sync 8-/
25-08-2021, 21:07 door nicolaasjan
Door Erik van Straten:
Ik denk dat je het beste een paar bakken sterke koffie kunt nemen en dan een wandeling maken (neem een plu mee). En morgen dubbelchecken dat je geen tikfouten in de hosts file hebt gemaakt, en daarna uitzoeken wanneer die hosts file wel en wanneer niet wordt geraadpleegd :-)

Aanvulling: we raken out of sync 8-/
Je had die latere post (20:40) nog niet gelezen denk ik. ;)

En nee, ik maak zelden tikfouten (beetje autistisch). ;)
Nu zag ik dat je de ESR versie van Firefox gebruikt - ik gok, maar het zou kunnen dat de fix (of de "enhancement") wel in de main stream versie van Firefox, maar (nog) niet in ESR verwerkt is.
Nee, ESR was in die Debian VM.
Firefox hier is 91.0.2.
25-08-2021, 22:19 door Anoniem
Juist inrichten van een host file is belangrijk. Name server switch, waarbij DNS niet voor files kan komen. In dat laatste geval wordt etc/host namelijk eerst bevraagd. Gebruik host commando om te testen. Voor Erik is dat natuurlijk gesneden koek. Maar toch nog dit even ten overvloede.
luntrus
26-08-2021, 10:35 door Erik van Straten
Door Anoniem: Gebruik host commando om te testen. Voor Erik is dat natuurlijk gesneden koek.
Nou nee, ook ik word voortdurend verrast (en niet alleen m.b.t. DNS). Als Firefox zelf DoH gebruikt en daarbij de hosts file links laat liggen, heb je -helaas- niks aan met je OS meegeleverde tools om te checken of DNS werkt zoals verwacht.

@Nicolaasjan: ik heb gisteravond verder gezocht, maar geen uitsluitsel gevonden of c.q. met welke instellingen, Firefox-met-DoH toch de hosts file evalueert.

In een antwoord in https://superuser.com/questions/1433325/does-firefox-ignore-the-hosts-file-how-to-make-firefox-honor-the-hosts-file wordt gesuggereerd dat het op false zetten van network.dns.offline-local (via about:config) Firefox-met-DoH de hosts file zou laten parsen, maar iemand anders meldt dat dit pas werkte in een vers profiel.
Bovendien lijkt dit een ongedocumenteerde instelling (placebo?) - want ik kan er verder weinig over vinden en false suggereert het tegenovergestelde (de key network.dns.offline-localhost bestaat overigens wel). Ik kan het niet pinpointen maar er zou ook nog een verschil kunnen bestaan tussen Firefox versies waarbij DoH de default is, en waarbij je DoH zelf hebt aangezet.

[rant] Firefox verliest onnodig gebruikers doordat stijfkoppige Mozilla ontwikkelaars onvoldoende aan verwachtingsmanagement doen. Ook al zouden er uitstekende redenen zijn om, bij gebruik van DoH, de hosts file niet meer te parsen: als je, als gebruiker, die redenen niet kent (d.w.z. ze je niet onder je neus zijn gedrukt) is dit totaal onlogisch, en m.i. -onder bepaalde omstandigheden- zelfs een security issue. Temeer daar veel Firefox-gebruikers een weloverwogen browserkeuze hebben gemaakt en dus vaak aanvullende beveiligingsmaatregelen zullen hebben genomen. Zo erger ik me er ook aan dat bij de gewone Firefox voor Android je about:config niet kunt openen (wel in de Nightly versie). [/rant]

Back on topic, ook hier geldt weer: it's always DNS (https://www.cscdbs.com/blog/wp-content/uploads/2021/05/Its-always-DNS-06-SSBroski.jpg. En neem toch die bak koffie, maar dan uit deze beker: https://i.etsystatic.com/7781014/c/740/588/149/255/il/8713bf/1663355705/il_340x270.1663355705_sepe.jpg :-)
26-08-2021, 11:13 door Anoniem
@ Erik van Straten,
Samen met jou een bakkie doen met onderwijl een uitwisseling van gedachten hierover lijkt me een prima idee.
Inlezen, inlezen en selectief inlezen. Die zich juist weet in te lezen en info weet te vergaren is soms beter af als de l33t h@cker.
De bronnen zijn online te vinden. Die zoekt, die vindt.
Groetjes,
luntrus
26-08-2021, 11:22 door Anoniem
26-08-2021, 11:36 door Anoniem
Een oplossing? https://live.paoaltonetworks.com/t5/custom-signatures/custom-app-id-for-dns-over-https/td-p/229784[/URluntrus
26-08-2021, 16:21 door nicolaasjan
Door Erik van Straten:
In een antwoord in https://superuser.com/questions/1433325/does-firefox-ignore-the-hosts-file-how-to-make-firefox-honor-the-hosts-file wordt gesuggereerd dat het op false zetten van network.dns.offline-local (via about:config) Firefox-met-DoH de hosts file zou laten parsen, maar iemand anders meldt dat dit pas werkte in een vers profiel.
Bovendien lijkt dit een ongedocumenteerde instelling (placebo?) - want ik kan er verder weinig over vinden en false suggereert het tegenovergestelde (de key network.dns.offline-localhost bestaat overigens wel). Ik kan het niet pinpointen maar er zou ook nog een verschil kunnen bestaan tussen Firefox versies waarbij DoH de default is, en waarbij je DoH zelf hebt aangezet.
Beide config opties doen helaas niets hier.
Ook niet in een vers profiel...
26-08-2021, 17:57 door Erik van Straten
Door nicolaasjan: Beide config opties doen helaas niets hier.
Ook niet in een vers profiel...
Dat verwachtte ik al...

Jaaaaren geleden heb ik kort met Unbound [1] gespeeld (nog onder XP) omdat het misbruiken van de hosts file als blocklist een slechte oplossing is: je kunt immers alleen volledige domeinnamen blokkeren (niet met 1 regel alle potentiële sub-, sub-sub- domeinen etc. onder example.com), noch TLD's blokkeren; met Unbound kan dat (beide als ik me goed herinner) wel.

[1] https://www.nlnetlabs.nl/projects/unbound/about/

Heb je al eens nagedacht over het lokaal draaien van een DNS resolver, of een PiHole gebruiken? Naar verluidt ondersteunt PiHole ook upstream DoH [2] en Unbound ondersteunt zelfs downstream DoH [3]. Nb. met de PiHole heb ik zelf geen ervaring en mijn kennis van Unbound is grotendeels weggezakt (en sowieso niet up-to-date).

[2] https://docs.pi-hole.net/guides/dns/cloudflared/
[3] https://blog.nlnetlabs.nl/dns-over-https-in-unbound/
26-08-2021, 18:03 door Anoniem
Zijn de nameserver lines goed ingegeven?
luntrus
26-08-2021, 18:21 door nicolaasjan
Door Erik van Straten: Jaaaaren geleden heb ik kort met Unbound [1] gespeeld (nog onder XP) omdat het misbruiken van de hosts file als blocklist een slechte oplossing is: je kunt immers alleen volledige domeinnamen blokkeren (niet met 1 regel alle potentiële sub-, sub-sub- domeinen etc. onder example.com), noch TLD's blokkeren; met Unbound kan dat (beide als ik me goed herinner) wel.

[1] https://www.nlnetlabs.nl/projects/unbound/about/

Heb je al eens nagedacht over het lokaal draaien van een DNS resolver, of een PiHole gebruiken? Naar verluidt ondersteunt PiHole ook upstream DoH [2] en Unbound ondersteunt zelfs downstream DoH [3]. Nb. met de PiHole heb ik zelf geen ervaring en mijn kennis van Unbound is grotendeels weggezakt (en sowieso niet up-to-date).

[2] https://docs.pi-hole.net/guides/dns/cloudflared/
[3] https://blog.nlnetlabs.nl/dns-over-https-in-unbound/
Hmm...
Ik denk dat dit toch een beetje te ingewikkeld wordt voor mij... Haha.

Ondertussen heb ik de kwestie maar even naar voren gebracht op de Firefox subreddit:
https://old.reddit.com/r/firefox/comments/pc1dic/with_doh_enabled_firefox_doesnt_read_hosts_file/

Mocht daar niets uit komen, dan kan ik wellicht een issue openen op Bugzilla?
26-08-2021, 20:22 door Anoniem
Door nicolaasjan:
Hmm...
Ik denk dat dit toch een beetje te ingewikkeld wordt voor mij... Haha.

Ondertussen heb ik de kwestie maar even naar voren gebracht op de Firefox subreddit:
https://old.reddit.com/r/firefox/comments/pc1dic/with_doh_enabled_firefox_doesnt_read_hosts_file/

Mocht daar niets uit komen, dan kan ik wellicht een issue openen op Bugzilla?

Misschien heb je hier wat aan:
".... you could use the "network.trr.excluded-domains" preference in about:config to exclude particular domain names from resolution through the doh-provider which - i would guess - falls back to the system settings including the hosts-file."
https://support.mozilla.org/en-US/questions/1266680

(heb het zelf niet uitgeprobeerd)
27-08-2021, 09:54 door nicolaasjan
Door Anoniem @20:22:

Misschien heb je hier wat aan:
".... you could use the "network.trr.excluded-domains" preference in about:config to exclude particular domain names from resolution through the doh-provider which - i would guess - falls back to the system settings including the hosts-file."
https://support.mozilla.org/en-US/questions/1266680

(heb het zelf niet uitgeprobeerd)
Weet ik, maar er staan ruim 42000 domeinen in mijn hosts bestand, dus dat is helaas geen optie.
27-08-2021, 10:12 door Anoniem
Het kan een probleem met stabilieit zijn, dat veroorzaakt wordt door de systeem instellingen. Bij Windows zijn dat vaak registerproblemen en/of maximale file grootte. Google Chrome wil de grootte van blokkeringsfiles ook mettertijd gaan beperken. De redenen hiervoor kan een ieder wel bedenken. Ze geven niet voor niets geld aan Mozilla Firefox.
luntrus
27-08-2021, 13:34 door nicolaasjan
Door Anoniem @10:12: Het kan een probleem met stabilieit zijn, dat veroorzaakt wordt door de systeem instellingen. Bij Windows zijn dat vaak registerproblemen en/of maximale file grootte. Google Chrome wil de grootte van blokkeringsfiles ook mettertijd gaan beperken. De redenen hiervoor kan een ieder wel bedenken. Ze geven niet voor niets geld aan Mozilla Firefox.
luntrus
Daarom heb ik het even getest met een hosts bestand met slechts 1 entry:
'0.0.0.0 www.google.com'
Dan wordt het geblokkeerd, maar het duurt even voordat de foutmelding wordt weergegeven.

Ik vind dit duidelijk een bug, omdat het volgens:
https://bugzilla.mozilla.org/show_bug.cgi?id=1616252
zou zijn opgelost.

Heb maar even een comment geplaatst daar:
https://bugzilla.mozilla.org/show_bug.cgi?id=1616252#c7
Of ze er wat mee doen is maar de vraag...
27-08-2021, 13:43 door Anoniem
@nicolaasjan,
In ieder geval heb jij je verantwoordelijkheid genomen en het hier en daar gemeld aan de community. Wat meer kun je doen? Deed een ieder dat, leefden we met z'n allen in een veel veiliger wereld. Mij boeit het wel. Ik heb weer heel wat doorgenomen en het nodige ervan opgestoken. Alle ervaring onderwijst de mens, althans zo zou het moeten zijn. Ga zo door zou ik zeggen en een gemeende groet van mij,
luntrus
29-08-2021, 17:53 door Anoniem
Door Anoniem: Verhaaltje van "one bitten twice shy". Van zo'n incident leert men. En u bent zo iemand. Vertrouw geen onbekend script van 3rd party sites. Voorbeeldhttps://thehackerblog.com/the-noscript-misnomer-why-should-i-trust-vjs-zendcdn-net/
De Russische site is kwaadaardig (o.a. via Magento webshop hacks). Verwacht kwaadaardig script - is dagelijkse geautomatiseerde kost ;).
luntrus

Ja Rusland is wel heel kwaadaardig misschien net zo erg zoniet erger dan diegenen die vreemde SIDs in execuables achterlaten , zo vond ik een bekende hash S-1-5-21-708247480-2834978148-2381576337-1001 die ik eerst maar niet kon verklaren. De md5sum van een bestand klopte niet. Kwam ik achter toen ik de exe proberen te draaien en een DLL vreemd ging doen.

Zouden de Russische malware boeren (vermoedelijk hebben ze gewoon bedrijven in Nederland die net nog geen kinderen in kantoorhuizen opsluit tot de malware klaar is want het de phishing mail was heel netjes in het Nederlands) deze code hebben gestolen en gebruikt in de malware?

Hoe leer ik hier meer over? Ik wil weten wie zijn de threatactoren bijvoorbeeld in het Westen de NSA CIA enzovoortz in het Oosten de CCP, Rusland, Iraan, Turkije enzovoortz.

Kan iemand laten zien in een overzichtje wie wat doet onder water / in de oceaan van het internet zowel offline als online?

BVD (Bij voorbaat dank!)
30-08-2021, 10:02 door Anoniem
Het oude Sovjet systeem kun je van alles aanwrijven, maar hun technische opleidingen waren puik te noemen, vaak nog met surplus. Net als onze opleidingen van voor de Mammoetwet.
Tegenwoordig speelt criminaliteit een rol overal en de interesse van de grote investeringsmaatschappijen kent letterlijk geen grenzen.
Russian Business Netwerk zit ook in Groot Mokum, maar ook bij de kleine hostertjes in het donkere zuidendes lands (achter Eindhoven) Via zit in Frankfurt, Krakau, Belgrado etc. Interpol bij alle AV binnen en Google overal op elk netwerk. Zoek het nu maar uit.
#sockpuppet
30-08-2021, 11:14 door nicolaasjan
Door Anoniem @27-08-2021, 13:43: @nicolaasjan,
In ieder geval heb jij je verantwoordelijkheid genomen en het hier en daar gemeld aan de community. Wat meer kun je doen? Deed een ieder dat, leefden we met z'n allen in een veel veiliger wereld. Mij boeit het wel. Ik heb weer heel wat doorgenomen en het nodige ervan opgestoken. Alle ervaring onderwijst de mens, althans zo zou het moeten zijn. Ga zo door zou ik zeggen en een gemeende groet van mij,
luntrus
Dank je!
Heb maar een nieuw bug report geplaatst:
https://bugzilla.mozilla.org/show_bug.cgi?id=1728073

Ik hoop dat het geen domme fout van mij is, die dit probleem veroorzaakt, haha.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.