[Pi-Hole] Ervaringen & discussie

[jpgview]

nero355 schreef op vrijdag 14 juni 2019 @ 15:52:

Wat een overkill handleiding zeg...

Heel veel dingen heb je niet eens nodig en RaspBian en Pi-Hole heb je binnen 15 minuten opgezet op voorwaarde dat je een snel kaartje gebruikt die zo door apt-get update en apt-get dist-upgrade heen knalt!

Ik heb die handleiding gemaakt, aangepast door de jaren heen. De bedoeling is een manageable en secure pihole te maken waar door de gebruiker dingen kunnen worden aan toegevoegd, zonder dat er allerlei neven effecten ontstaan.
Wanneer meer mensen de handleiding zouden volgen, zou waarschijnlijk de helft van het gezeur op discourse verdwijnen.

De setup is ook een opstap voor het toevoegen van allerlei uitbreidingen, zoals:
- unbound, knot-resolver, unfiltered DNS, nmap, munin, wireguard, … , alles te vinden op discourse.

Voor mensen met de NEXT / NEXT / NEXT mentaliteit is dit uiteraard geen goede handleiding, ze lopen dan het risico ook nog iets bij te leren.

[ Voor 2% gewijzigd door jpgview op 15-06-2019 09:56 . Reden: link naar handleiding ]

[jpgview]

sanghoku schreef op donderdag 27 juni 2019 @ 09:13:
Hey,
Blijkbaar gaat dan de lighttpd in de mist omdat ie gaat zoeken naar de logs die er niet meer zijn.

Ik zet zowel de lighttpd, als de pihole logs op TMPFS, zonder problemen, geen startup scripts nodig.

Lighttpd hier uitgelegd, Pihole logs hier uitgelegd (lees ook de correctie, entry na de originele how to).

Het enige waar je een beetje rekening moet mee houden, is de size van de TMPFS mounts, dat is sterk afhankelijk van hoe intens pihole gebruikt word

Dit alles is mogelijk door de correcte, volledige syntax voor TMPFS te gebruiken, e.g.

entry voor lighttpd:
$ a tmpfs /var/log/lighttpd tmpfs nodev,nosuid,gid=www-data,uid=www-data,mode=0750,size=16M 0 0
entry voor pihole logs:
$ a tmpfs /var/log/pihole tmpfs nodev,nosuid,gid=pihole,uid=pihole,mode=0755,size=16M 0 0

door het gebruik van gid, uid en mode zorg je ervoor dat de tmpfs dezelfde group, owner en permissions heeft als het origineel, laat dit na en je krijgt permissions 1777 (sticky bit set)

[ Voor 25% gewijzigd door jpgview op 27-06-2019 20:31 . Reden: verklaring tmpfs settings ]

[jpgview]

sanghoku schreef op vrijdag 28 juni 2019 @ 10:07:
ik mount de hele /var/log in tmpfs zonder onderscheid in aparte dingen

Natuurlijk doet iedereen wat hij/zij wil, persoonlijk vind ik dit geen goed idee, omdat er logs zijn waar je toch wel wat historiek wil van terug vinden, ook na een reboot. Wat ik wel doe, is het aantal logs dat word bijgehouden na logrotation aanpassen. Voor lighttpd staat dit bevoorbeeld op 12 (Raspbian strectch). Voor een publieke webserver kan dit interessant zijn, voor een pihole? Ik zet het aantal dan ook op 1, dus alleen "previous day". voor pihole staat dit op 5, wat mij betreft ook ver erover, ik ga nooit vijf dagen terug, maar weerom, persoonlijke voorkeur...

sanghoku schreef op vrijdag 28 juni 2019 @ 10:07:
verder had ik begrepen dat de tmpfs entries zonder size bepaling, de ruimte van tmpfs delen, en dat het totaal dan niet groter kon zijn dan de helft van de ram.

Ik ben geen Linux specialist, verre van, duckduckgo is mijn beste vriend. Wat ik er van begrijp is dat je wel dedelijk percentages, of helemaal niets kan specifieren, MAAR dat geld voor de individuele entries, voor iedere entry in fstab. Het lijkt mij onmogelijk om te specifieren dat alle tmpfs samen maximum 50% van het ram gebruiken. CORRECT ME IF I'M WRONG PLEASE, with reference, if you please

[jpgview]

sanghoku schreef op vrijdag 28 juni 2019 @ 11:57:
"the default, when neither size nor nr_blocks is specified, is size=50%"

ik wil niet moeilijk doen, wel opheldering, nog eens, geen Linux expert.

hier zegt men:
tmpfs is great and makes "ramdisks" simple, but one thing to be aware of is that tmpfs does not have a global size limit but a size limit per mounted instance.

Dat bevestigd mijn idee over hoe het werkt, en de url waar je naar verwijst (waarvoor dank) spreekt helemaal niet over meerdere tmpfs mounts, maar over één.

Natturlijk is het ook weer mogelijk dat de url waar ik naar verwijs ook gemaakt is door iemand die geen Linux expert is en ook alleen maar duckduckgo gebruikt…

Hopelijk leest een Linux expert dit, en geeft ons uitsluitsel.

[jpgview]

Hier een handleiding om maltrail op je pi te installeren. Ik vind het een nuttige toevoeging, omdat, aan de hand van lijsten, die dagelijks (instelbaar) gedownload worden, verdachte requests weergeeft. Je moet dan wel zelf het initiatief nemen om het domain aan de blacklist toe te voegen.

getest op raspberry pi 3B met Raspbian stretch en buster.

Install (/home/pi/install_maltrail.sh, uitvoeren met sudo):
- een van de sed commando's bevat het IPv4 address van je pihole, aan te passen om de web interface te kunnen benaderen.

#!/bin/bash

sudo apt-get -y install screen
sudo apt-get -y install schedtool

# install sensor
sudo apt-get -y install git
sudo apt-get -y install python-pcapy
git clone https://github.com/stamparm/maltrail.git

# install server
[[ -d maltrail ]] || git clone https://github.com/stamparm/maltrail.git

file=/home/pi/maltrail/maltrail.conf
# configure server to listen on primary IP address
sudo sed -i '/^HTTP_ADDRESS/ s/0.0.0.0/192.168.2.57/' $file
# configure sensor for malicious DNS trails
sudo sed -i '/^CHECK_HOST_DOMAINS/ s/false/true/' $file

Startup script (/home/pi/maltrail.sh):
- het startup script bevat het IPv4 address, aan te passen om server.py correct te starten
- de syntax van screen is gewijzigd in Raspbian buster, indien je nog Raspbian stretch gebruikt moet je de optie `-Logfile` verwijderen (twee keer), de bestandsnaam moet blijven staan.

#!/bin/bash

until (/sbin/ip addr | /bin/grep "192.168.2.57" >/dev/null 2>&1); do
/bin/sleep 5
done

result=$(pgrep -fl sensor.py)
if [ $? -eq 1 ]; then
sudo screen -S sensor -L -Logfile /var/log/maltrail/sensor.txt -dm bash -c "cd /home/pi/maltrail; sudo python sensor.py"
fi
result=$(pgrep -fl server.py)
if [ $? -eq 1 ]; then
sudo screen -S server -L -Logfile /var/log/maltrail/server.txt -dm bash -c "cd /home/pi/maltrail; sudo python server.py"
fi

cron job, om sensor en server te starten bij reboot (/etc/cron.d/maltrail):
- uiteraard moet de naam van het startup script gebruikt worden.

@reboot root PATH="$PATH:/home/pi/" /home/pi/maltrail.sh

Als alles goed gaat, eindig je met twee extra screens (putty), die je kan oproepen met:
`sudo screen -r server` voor de server
`sudo screen -r sensor` voor de sensor
Om te detatchen van het screen (application blijft draaien), druk je <CTRL>ad
Om de application te stoppen, selecteer het correcte screen en druk <CTRL>c, de application stopt en het screen verdwijnt

Opgelet, om dat screen met sudo is gestart krijg je geen lijst van screens met het commando `screen -r`, dit zijn de screens van de pi user. Om de screens van de root user te bekijken moet je `sudo screen -r` gebruiken

De web interface is bereikbaar op http://<ip_van_de_pihole>:8338

Enjoy...

'edit'
Ik heb de default 'CAPTURE_FILTER' setting in maltrail.conf gewijzigd in 'CAPTURE_FILTER port 53' (alleen DNS monitoren dus). Dat is natuurlijk een persoonlijke keuze, maltrail draait naast pihole, ik gebruik de raspberry pi uitsluitend voor DNS gerelateerde zaken.
Omdat het reeds waardevolle informatie heeft opgeleverd, heb ik de installatie ervan ook opgenomen in mijn pihole handleiding. In de handleiding ook de waarschuwing dat maltrail niet werkt (kan werken) bij gebruik van DoH of DoT.
'/edit'

[ Voor 21% gewijzigd door jpgview op 09-07-2019 13:35 ]

[jpgview]

Mschamp schreef op zaterdag 29 juni 2019 @ 09:18:
[...]
Als je het toch wil, kan je een extra router er tussen plaatsen

Een eigen router/firewall plaatsen is het beste idee, echter, met de hardware die TheCeet beschreven word (niet echt duidelijk welk model/type). is het alleen maar een goed idee wanneer je de modem/router omruild voor een "cable modem only", omdat je blijkbaar de standard modem/router niet in "bridge mode" kan plaatsen, en daardoor alles door twee firewalls zou sturen (je eigen firewall en de telenet firewall)

Blijkbaar is omruilen mogelijk, lees hier, zelf nooit moeten doen, omdat ik vanaf dag één een "cable modem only" gebruik.

beschrijving van een cable modem only (IPv6 capable):
Type
Motorola / CV6181E (DOCSIS)
Technologie
EURODOCSIS 3.0

Opgelet:
- voor je omruild moet je eerst een fatsoenlijke eigen operationele route/firewall hebben.
- een cable modem only heeft geen WIFI, moet je dus ook zelf voor zorgen

[ Voor 4% gewijzigd door jpgview op 29-06-2019 11:26 . Reden: WIFI warning ]

[jpgview]

nero355 schreef op zaterdag 29 juni 2019 @ 17:53:
[...]

Allemaal leuk en zo, maar wat is het en waar gaat het over

Linkje naar de homepage van het geheel ?

Staat in de source van het install script als comment, maar goed, hier nog eens: https://github.com/stamparm/maltrail
Is ook de eerste hit als je duckduckgo "maltrail" zoekt

[jpgview]

ninjazx9r98 schreef op maandag 1 juli 2019 @ 23:01:
@NeutraleTeun
Default user is pi en default password is raspbian.

@NeutraleTeun
According to RaspberryPi.org, the default username on Raspbian is pi and the default password is raspberry.

reference here.

[jpgview]

In deze software update (matomo) stel ik de vraag hoe analytics werkt, nadat iemand aangeeft dat het onontbeerlijk is voor het beheer van zijn website.

Als antwoord krijg ik (aannemelijk) dat er een snipet op de pagina word gezet, die het tellen voor zich neemt, waarna ik aangeef dat zowat elke poging om ´ssl.google-analytics.com´ te contacteren word afgeblocked. ((niet zeker dat dit de teller is, bevestiging a.u.b).

Naast de eventuele bevestiging van bovenstaande hypothese, de vraag of iemand weet of matomo en piwik (zelfde product, andere naam, maar waarschijnlijk bestaan beide DNS entries nog wel) op dezelfde manier werken en of iemand de DNS namen kent, dit om ook hen in de toekomst stokken in de wielen te steken.

Motivatie: We kennen ondertussen allemaal de anonieme data collectie die alle websites doen, maar er wel toe leiden dat ze je maat van schoenen en kleur van je onderbroek kennen.

<edit>
de reactie van Timo002 tussen de replies vind ik ronduit schokkend, GDPR en privacy zijn gewoon dood. Een gelijkaardige reactie van een developer / moderator op het pihole forum hier (they can frankly kiss my butt).
</edit>

[ Voor 14% gewijzigd door jpgview op 02-07-2019 19:45 . Reden: edit ]

[jpgview]

Er is een nieuw type malware gespot, misbruikt DoH (DNS over HTTPS), lees hier. Een nieuw 'feature request' (reeds geweigerd) dat zou kunnen verdedigen tegen deze nieuwe bedreiging werd op discourse aangevraagd, lees hier. Een 'feature request', dat gaat over het blokkeren van de IP addressen, vermeld op de GitHub pagina, vind je hier (pihole-FTL: block IP's from lists). Stem (vote) voor het 'feature request', als je wil dat pihole je kan beschermen tegen gekende, verdachte IP addressen, en je network dus beter beschermd word.

Relevante lijsten met verdachte IP addressen hier (talos) en hier (Firehole).

Diegenen die reeds DoH gebruiken, zou ik aanbevelen na te denken over de implicaties van de malware en de unbound oplossing als alternatief te overwegen…

`edit`
Bedankt @Freee!! voor " the vote of confidence, nu nog een vote voor het feature request, en dan zetten we opnieuw een gigantische stap richting ideale wereld.
`/edit`

`edit2`
firefox users! de firefox setting `network.trr.uri` wijst naar `https://mozilla.cloudflare-dns.com/dns-query` (about:settings). Het domain `mozilla.cloudflare-dns.com` levert (nslookup) IP addressen die in de DoH lijst voorkomen op GitHub. Het is misschien verstandig om het domain te blokken (blacklist), zodat firefox het niet kan oplossen, hopelijk met als resultaat dat firefox DoH niet kan gebruiken, en zo de malware buiten je network blijft.
`/edit2`

`edit3`
Heb nu enkele dagen de IP's uit de GitHub lijst toegevoegd aan de firewall en de de DNS lijst (raw format) toegevoegd als blocklist aan pihole + `mozilla.cloudflare-dns.com` in de blacklist. Na zeer intensief gebruik van internet, met als doel het oplossen van een probleem met `watchdog` (zie het resultaat in de pihole handleiding), heb ik geen enkel probleem ervaren met de toevoegingen.

Ik lees op verschillende plaatsen de opmerking over het gebruik van unbound, dat alles unencrypted is. Ik beschouw dit als een security voordeel, omdat, in het originele artikel staat:
`quote`
The DoH (DNS) request is encrypted and invisible to third-party observers, including cyber-security software that relies on passive DNS monitoring to block requests to known malicious domains.
`/quote`
Zelf gebruik ik suricata op pfsense, maar er zijn een heleboel security producten (o.a. ook snort en andere, enterprise gerichte security oplossingen). In de suricata logs vind ik regelmatig entries i.v.m DNS packets die gedropt zijn, omdat ze de regels die ik in suricata heb aangezet activeren. Deze DNS packets zouden waarschijnlijk niet opgemerkt zijn bij gebruik van DoH.
Ook maltrail, hier uitgelegd op het forum, kan rustig zijn ding doen en domains identificeren, die je eventueel wil blacklisten.
`/edit3`

[ Voor 52% gewijzigd door jpgview op 07-07-2019 10:35 . Reden: please vote ]

[jpgview]

nieuw systeem met Raspbian buster image (june 2019) geeft problemen met 'sudo apt-get update && sudo apt-get upgrade.

blijkbaar eenvoudig, oplossing hieronder

'edit'
nog eenvoudiger, een nieuw Raspbian image is gereleased (july 2019), download hier
'/edit'

[ Voor 68% gewijzigd door jpgview op 12-07-2019 23:25 ]

[jpgview]

Een nieuwe source voor blocklists?

Artikel dat er naar verwijst op reddit, de Energized Protection pagina hier, de GitHub pagina met de lijsten hier.

Een andere reddit post geeft aan dat een van de default pihole lijsten, zeustracker.abuse.ch, er mee gestopt is (discontinued), dit is in de post ook bevestigt door een developer. Je verwijderd deze lijst dus best, als je dat niet doet zal de cached list steeds opnieuw gebruikt worden, maar die is dus niet langer up to date

[ Voor 36% gewijzigd door jpgview op 22-08-2019 09:13 . Reden: zeustracker.abuse.ch ]

[jpgview]

Om ervoor te zorgen dat firefox pihole niet negeert (DOH ingebouwd in firefox), voeg het volgende toe aan /etc/dnsmasq.d/01-pihole.conf:

server=/use-application-dns.net/

en herstart pihole-FTL (sudo service pihole-FTL restart)

referenties:
pihole support forum en mozilla.

Deze setting zou in een volgende release van pihole standaard opgenomen zijn in de dnsmasq settings (GitHub).

<edit>
In pihole v4.3.2 (released 15/09/2019) werd deze setting nog NIET toegevoegd. Je moet ze dus ook in deze release nog steeds manueel toevoegen.
</edit>

[ Voor 10% gewijzigd door jpgview op 16-09-2019 10:42 . Reden: pihole v4.3.2 ]

[jpgview]

Nog een nieuwe source voor blocklists?

Op deze pagina vind je (linker zijde / about the list / download) een tar file die een heleboel blocklists bevat.

De eenvoudigste manier, die ik gevonden heb, om na te kijken of er iets in zit dat voor jou toegevoegde waarde heeft:

1. maak een nieuw script in /home/pi , bv. /home/pi/shallalist.sh, inhoud:

#!/bin/bash
file=shallalist.tar.gz
wget http://www.shallalist.de/Downloads/$file -O $file
wget http://www.shallalist.de/Downloads/$file.md5 -O $file.md5
md5sum --check ./$file.md5 | grep "shallalist.tar.gz: OK" &> /dev/null
if [ $? == 0 ]; then
echo "download OK (MD5 checksum)"
else
echo "download failed (MD5 checksum)"
exit
fi
tar xzf $file

2. Je kan nu met WinSCP op je pi naar de inhoud van de folder /home/pi/BL kijken. elke subfolder (categorie) bevat twee files, voor pihole lijsten gebruik je steeds het bestand met de naam domains.

3. Om te testen of een lijst voor jou toegevoegde waarde heeft, maak je gebruik van het script dat hier beschreven is en hier gedownload kan worden. Het script (checklist.sh) werkt op pihole v4.3.1 (laatste versie), Let op het zal niet meer werken op pihole v5 (momenteel in ontwikkeling) omdat in pihole v5 de meeste gegevens in de database worden opgeslagen, nu zijn het losse bestanden.
voorbeeld: om de lijst uit de folder tracker te testen geef je het volgende commando:
sudo ./checklist.sh file:///home/pi/BL/tracker/domains

Zoals je ziet, is het ook moglijk lijsten van het filesystem (de SD kaart van de pi) te gebruiken. De syntax om een lijst aan de adlists.list toe te voegen is: file:///home/pi/BL/tracker/domains (file: gevolgd door drie (3) forward slashes).

Opgelet. het resultaat van checklist.sh is verschillend op ieder system. er wordt gekeken naar het verschil tussen de gravity entries op het system en de eventuele toegevoegde entries. een voorbeel van het resultaat op mijn systeem:
Result: file:///home/pi/BL/tracker/domains contains 535 new host entries.
Nogmaals, resultaat is verschillend op jouw systeem. Indien je besluit de lijst toe te voegen kan je dus de UNC syntax (file:///) gebruike om de lijst aan pihole toe te voegen. Daarna een cron job maken om het eerste script (shallalist.sh) wekelijks uit te voeren, bij voorkeur op zaterdag avond, omdat pihole de gravity lijsten automatisch update op zondag morgen.

Enjoy...

[ Voor 0% gewijzigd door jpgview op 14-09-2019 18:51 . Reden: typo ]

[jpgview]

Wie windows 10 en Edge gebruikt, heeft waarschijnlijk ook al gemerkt dat er DNS lookups naar www.bing.com tevoorschijn komen, ondanks het feit dat je b.v. duckduckgo als search engine hebt ingesteld.

Waarom dit gebeurt, dat is de vraag, iemand een antwoord?

Bij wijze van test heb ik een configuratie file (/etc/dnsmasq.d/08-bing.conf) toegevoegd, inhoud:

host-record=duckduckgo.com,176.34.155.23
cname=www.bing.com,duckduckgo.com

Uiteraard moet je daarna pihole-FTL herstarten (sudo service pihole-FTL restart)

Daarna zie je nog wel www.bing.com in het query log tevoorschijn komen, de eerste keer als CNAME, daarna als cached, maar als je op je pc een nslookup uitvoerd, krijg je volgend resultaat:

nslookup www.bing.com
Server: raspberrypi.localdomain
Address: 192.168.2.57

Name: duckduckgo.com
Address: 176.34.155.23
Aliases: www.bing.com

het address is het address dat in de dnsmasq config is opgegeven, niet meer bing dus…

<edit>
De reden waarom ik dit onderzoek?
Na de update naar 1903 kreeg ik een melding dat ik mijn pc gebruik tussen uur x en uur y; met de vraag of ik mijn windows update restart wenste aan te passen buiten die uren. Dit wil zeggen dat MS je in de gaten houd, wat ik om privacy redenen niet echt wil. Gebruiken ze edge om dit te detecteren?
</edit>

Iemand enige bemerkingen bij deze strategie om bing buitenspel te zetten?
Het gebruik van een andere browser is een voor de hand liggende oplossing en hoeft dus niet gemeld te worden...

[ Voor 17% gewijzigd door jpgview op 17-09-2019 10:58 ]

[jpgview]

Black Piet schreef op woensdag 18 september 2019 @ 11:58:
Ik heb de volgende adressen geïdentificeerd die voor overlays of reclame zorgen op mijn tablet en telefoon.

code:

*.googlevideo.com Poort 443 (UDP IPv4/IPv6)
*.manifest.googlevideo.com (UDP IPv4/UDP IPv6)
*.redirector.googlevideo.com (UDP IPv4/UDP IPv6 + TCP IPv4/UDP IPv6)
*.www.gstatic.com (UDP IPv4/UDP IPv6 + TCP IPv4/UDP IPv6) (Let op het volledige adres)
*i.ytimg.com (UDP IPv4/UDP IPv6)
Yt3.ggpht.com (UDP IPv4/UDP IPv6) (Let op het volledige adres)
Lh5.googleusercontent.com (UDP IPv4/UDP IPv6 + TCP IPv4/UDP IPv6)
Lh6.googleusercontent.com (UDP IPv4/UDP IPv6 + TCP IPv4/UDP IPv6)

Vragen

• Is mijn idee in PiHole mogelijk?
• Hoe kan ik dit in PiHole programmeren?
• Welke config file moet ik hiervoor aanpassen?

In PFSense heb ik het werkend gekregen.

@Black Piet: Om je vragen te kunnen beantwoorden lijkt het mij nodig (en leerzaam) om de pfsense rules die je hebt gebruikt te kunnen bestuderen, graag ook met vermelding van het extra package dat je hebt toegevoegd (indien dit het geval is). Als je de rules oplijst, zullen heel veel tweakers / pihole users dit verder kunnen onderzoeken...

[jpgview]

GieltjE schreef op woensdag 16 oktober 2019 @ 10:28:
Kan ook erg aanraden om redis aan unbound te hangen, de minimale config hiervoor is in unbound:

@GieltjE ,@ViNOK16Bit , @nero355 @ninjazx9r98

Het spijtige van dit forum is dat dit onderwerp uit de aandacht verdwijnt, wanneer plots weer een andere discussie de overhand krijgt.
Heb de hele dag dit onderwerp (Redis backend) onderzocht en hier een topic gemaakt, in de hoop toch nog een zinvolle pro / con discussie uit te lokken.

Topic, met alle nodige installatie en configuratie files, plus een web interface om naar de inhoud van de Redis data te kijken.

[jpgview]

ninjazx9r98 schreef op vrijdag 18 oktober 2019 @ 07:17:
Zit alleen nog te twijfelen of ik jouw methode ga volgen of het Raspbian source package zelf pak en daarmee een nieuw package maak met afwijkend versienummer wat ik daarna via de package manager kan installeren.

Voor mij geniet compileren van source de voorkeur. Je kan dan heel snel actie nemen, wanneer er iets wijzigt aan unbound. Zo was 1.9.4 het resultaat van een security audit by unbound. Deze keer heeft de maintainer van het Raspbian package snel gereageerd, in het verleden echter liep de Raspbian versie hopeloos achter op de latest stable release, ze draaiden v1.6.x, unbound zat toen al op 1.9.x.
Bijkomend voordeel van mijn instructies om unbound te compileren: unbound draait met chroot, wat de veiligheid ten goede komt, het is en blijft een van de weinige packages die met de buitenwereld communiceert.

[jpgview]

Remco Tr schreef op vrijdag 18 oktober 2019 @ 12:23:
Wil graag naar de nieuwste versie maar geen ervaring met compileren. Is er ergens een tutorial?

op GitHub staat alles wat je nodig hebt.

Als je een paar comments wil lezen, kan je dit oude topic lezen.

Let op, als je de Raspbian versie van unbound al hebt draaien moet je die eerst VOLLEDIG verwijderen, anders zijn er conflicten en werkt het niet. De beste aanpak is om te starten met de laatste versie van het Raspbian OS (september 2019) en van scratch alles opnieuw te instaleren.

[jpgview]

nero355 schreef op vrijdag 18 oktober 2019 @ 16:26:
@GieltjE :
Ik heb het idee dat de winst dan erg klein is en je alleen maar alweer een stukje software hebt dat Writes op het microSDXC kaartje van je Pi veroorzaakt ?!

Om de writes te elimineren volgende commando's (op Raspbian):

sudo sed -i '/save 900 1/s/^/#/g' /etc/redis/redis.conf
sudo sed -i '/save 300 10/s/^/#/g' /etc/redis/redis.conf
sudo sed -i '/save 60 10000/s/^/#/g' /etc/redis/redis.conf
sudo service redis stop
sudo rm /var/lib/redis/dump.rdb
sudo service redis start

Natuurlijk is de cached data dan weg als je Redis herstart en / of je system reboot

Het voordeel van het gebruik van Redis is, mijns inziens, het elimineren van DNS requests die je in het verleden hebt gedaan. Zolang een en ander gecached is, zelfs als de TTL verlopen is, gaat er geen nieuwe request naar de buitenwereld.. DNS analyse door gelijk wie dit ook mag doen (ISP, …) toont dan aan dat je een site hebt bezocht, maar nooit hoe dikwijls. Privacy enhancement? Voor discussie vatbaar, maar tot het tegendeel wordt aangetoond ben ik een believer.

Een nadeel, mag ook gezegd worden, is het bezoeken van sites die van een DDNS gebruik maken. Als het IP wijzigt, en dus het DDNS record, zal je de site niet meer kunnen benaderen, tenzij je de cache leegmaakt. Vraag is of je hetzelfde problem niet zou ervaren door de cache van unbound en / of pihole-FTL.
Of dit vandaag de dag nog frequent voorkomt is een andere vraag. Heb zelf een DDNS record aangemaakt voor gebruik met Wireguard, mijn IP is al jaren niet meer gewijzigd (Laatste keer toen ik een nieuwe IPv6 kabel modem kreeg van mijn ISP).

[ Voor 41% gewijzigd door jpgview op 19-10-2019 10:55 ]

[jpgview]

GieltjE schreef op zaterdag 19 oktober 2019 @ 18:47:
in mijn test gaan er wel degelijk nieuwe requests uit als de TTL verlopen is, anders zou je namelijk links en rechts nogal wat eens wat internet breken.

Hier ben ik nog niet helemaal uit. Ik begrijp jouw argument (internet breken), door Redis records steeds opnieuw te gebruiken, zul je waarschijnlijk vroeg of laat foute IP resultaten krijgen. Anderzijds kan ik me niet voorstellen dat het IP address van b.v. tweakers.net om de haverklap wijzigt (gebeurt mogelijkerwijs wanneer ze van hosting company wisselen, of een grote backend change doorvoeren, maar anders???) Ook zie ik, m.b.v. de phpRedisAdmin web interface dat alle keys een TTL 'does not expire' hebben, helaas geen referentie wanneer de key is aangemaakt (of gewijzigd). Verder groeit het aantal Redis keys alleen maar, er verdwijnen nooit keys.

Over jouw (terechte) argumentatie (internet breken) had ik ook al nagedacht, en heb volgende recovery methode ingebouwd (toegevoegd).

1. Script, /etc/unbound/clearRedisDB.sh,met content:

#!/bin/bash
redis-cli FLUSHALL

2. Lijntje toegevoegd aan /lib/systemd/system/unbound.service, content:

ExecStartPre=/etc/unbound/clearRedisDB.sh

Het resultaat is, zoals je waarschijnlijk begrijpt, dat, wanneer unbound herstart, de Redis cache wordt leegemaakt. Op die manier kan ik snel ingrijpen (unbound restart) of gebeurd het automatisch bij reboot.

Mijn system, met de laatste wijzigingen (geen DB save), is nog niet lang genoeg up and running om een definitief oordeel te vellen, maar alle argumenten pro/con/… blijven welkom.

[jpgview]

Dit script, en de bijbehorende verklaring, gaat over je pihole, niet over je router...
Hier is een scriptje dat het voor jou doet.

#!/bin/bash

# get current IPv6 address
CURRENT_IPV6_ADDRESS=$(ip -6 a | grep '2a02' | awk -F " " '{gsub("/[0-9]*",""); print $2}')

# read configured IPv6 address from /etc/pihole/setupVars.conf
file=/etc/pihole/setupVars.conf
OLD_IPV6_ADDRESS=$(grep 'IPV6_ADDRESS=' "$file" |sed 's/^IPV6_ADDRESS=//')

# read/compare previous IPv6 address from file
if ! grep -q "$CURRENT_IPV6_ADDRESS" $file; then
sed -i.bak "s/$OLD_IPV6_ADDRESS\b/$CURRENT_IPV6_ADDRESS/g" "$file"
/usr/local/bin/pihole updateGravity
fi

Ik run dit dagelijks met cron, om te voorkomen dat een address change niet door de pi zou worden opgepikt. Mijn IPv6 address wijzigt soms als mijn modem een reset krijgt (door mij of door de provider). Mijn IPv4 address is al Jaren niet meer gewijzigd.

IPv6, volgens een pihole developer, is aanbevolen omdat er meer en meer sites opduiken met uitsluitend IPv6. De IPv4 pool is in sommige regios en bij sommige providers gewoon op. Zonder IPv6 kan je die sites gewoon niet bereiken (ik heb GEEN voorbeeld hiervan).

updateGravity run ik omdat /etc/local.list hierdoor ook word aangepast (niet door mijn script).

Let wel, het script werkt alleen als /etc/pihole/SetupVars.conf ook al een IPv6 setting bevat EN jouw IPv6 address begint met 2a02. Script dus eventueel aan te passen met jouw range e.g. 2a02 -> eerste vier digits van jouw IPv6 address (dit zal nooit wijzigen - toegekend aan regio / provider).

Ik draai al twee jaar met IPv6, zonder problemen, let wel (voordeel / nadeel?):
Windows 10 met IPv6 heeft blijkbaar de mogelijkheid om een alternatieve DNS server te zoeken en te gebruiken als de system configured dns setting (jouw pihole address) niet bereikbaar is. Het duurt effe, maar als de pi down is (onbereikbaar) gaat windows 10 op zoek naar een IPv6 DNS server en begint die te gebruiken.

Ik gebruik unbound als recursive resolver. pihole-FTL (dnsmasq + customization voor pihole) heeft een feature dat alle geconfigureerde resolvers regelmatig test (de snelste?) mijn pihole gebruikt overwegend de IPv6 resolver, wat wil zeggen dat het ook gewoon sneller is.
dus, in /etc/dnmasq.d/01-pihole.conf staat:

server=127.10.10.2#5552
server=fdaa:bbcc:ddee:2::5552#5552

dit zijn de addressen en ports waar unbound op luistert (sudo netstat -pln | grep 'LISTEN' | grep '5552')
pihole prefereert de IPv6 resolver (snelste)

Telenet router info: Afhankelijk van het type router dat je hebt, kan je pihole op sommige telenet routers niet gebruiken, tenzij je het ding in bridge mode plaatst (gelezen op het telenet users forum). De meeste mensen kiezen dan voor de oplossing om de router door een modem only te vervangen. Uiteraard wil dit zeggen dat je dan eerst zelf een router / firewall moet kopen en configureren, die je achter de modem only hangt.

[ Voor 21% gewijzigd door jpgview op 25-01-2020 09:50 . Reden: dnsmasq speed test ]

[jpgview]

Ik neem deel aan de pihole beta5 trial, die sinds een week loopt. Op discourse vind je een heleboel topics met tag beta5, het word langzaam teveel om door het bos de bomen nog te zien.

Alle resultaten van mijn tests en ervaringen heb ik gebundeld in een updated manual (pihole5). Wie zin heeft kan de draft gebruiken om een en ander te testen, als een en ander niet correct is hoor ik dat graag.

De pihole v4 manual vind je hier, de pihole v5 (draft) vind je hier.

Opgelet, je kan beta5 niet van scratch instaleren, zoals in de manual vermeld (dat is toekomst muziek voor de final version). volg de instructies uit de announcement.

[ Voor 10% gewijzigd door jpgview op 26-01-2020 13:18 ]

[jpgview]

Alle lijsten die je vroeger met sudo nano OF de web interface OF iets als WinSCP beheerde, bestaan niet meer. Alle pihole data, met uitzondering van de CONF files zitten in een sqlite3 database (/etc/pihole/gravity.db).

Group Management: het is nu mogelijk om the whitelisten of blacklisten voor specifieke clients, e.g. bijvoorbeeld google.com bereikbaar voor client X maar niet voor client Y

CNAME blocking, een techniek die door adverteerders wordt gehanteerd om pihole (en andere add blockers) te bypassen (toch advertentie zichtbaar) wordt nu ook gededecteerd en geblocked.
Meer weten? lees de announcement...

Test dit bij voorkeur op een aparte pi, in productie zou je nog wel eens tegen bugs kunnen aanlopen, t'is dan ook een beta - trial. Regelmatig pihole -up is aanbevolen, de wijzigingen volgen elkaar snel op.

Opgelet, ik las ergens (unconfirmed) dat een upgrade van beta5 naar v5 final niet zal werken. Wanneer je beta5 op je produktie system test, zal je pihole van scratch moeten installeren waaneer v5 final word gereleased.

[ Voor 14% gewijzigd door jpgview op 26-01-2020 13:55 ]

[jpgview]

Dit soort problemen (mijn vrouw wil ads in haar zoekresultaten) is net de reden waarom Group Management toegevoegd werd. Je moet nog steeds de correcte whitelist entries zoeken en toevoegen, maar je kan er nu voor zorgen dat die whitelist entries alleen gelden voor specifieke clients. Vroeger was het iedereen of niemand, nu kan je uitzonderingen maken voor bepaalde toestellen. In mijn manual v5 beschrijf ik (hopelijk werkt het ook op die manier - een paar testen wijzen uit van wel, maar je weet nooit) hoe je dit moet verwezlijken.

[jpgview]

Een adblocker, zoals ublock origin is nog steeds een noodzakelijk kwaad, zelfs met pihole 5, om bepaalde reklames en trackers te verwijderen.

Als je niet de reklame wil (sponsored links) maar wel de pest hebt aan het feit dat de eerste links nooit werken, gebruik dan DuckDuckgo i.p.v. google. Gebruik beide al jaren met volle tevredenheid. In het extreme geval dat je iets niet vind met DuckDuckgo, kan je nog steeds de google search engine gebruiken (openen in web pagina) om alsnog de search uit te voeren, met google resultaten inbegrepen

[jpgview]

Nope, gebruik daarvoor een adblocker, zoals ublock origin.

Reclames op youtube en waarschijnlijk ook twitch (geen ervaring mee) zullen nooit door pihole geblocked kunnen worden, omdat het domain waar het youtube fimpje en de advertentie staan, hetzelfde is. Pihole is een domain blocker, in het geval van youtube, block de advertentie, dan block je ook het filmpje

Hier vind je het topic over CNAME blocking.
Hier vind je het artikel waardoor het hele CNAME probleem aandacht kreeg van de adblockers, en pihole. Het artikel verklaard hoe third party blocking in web browsers zo goed als ongedaan is gemaakt, door deze techniek.
Basically komt het erop neer dat ze een CNAME record aanmaken in het eigen domain (niet geblocked in een adlist), dat naar een ander domain (third party) verwijst, om zo de third party blocking te omzeilen.
Pihole 5 is hier nu tegen gewapend.

[ Voor 12% gewijzigd door jpgview op 26-01-2020 19:20 ]

[jpgview]

grote_oever schreef op zondag 26 januari 2020 @ 16:55:
voor mijn beeldvorming:

Om te omzeilen moet tweakers een CNAME aanmaken naar een ad-site. b.v s1d5.tweakers.net. Adblockers, waaronder pihole, kunnen dan niet de site vinden die daarachter geredirect wordt. Tweakers.net blocken is niet handig, waardoor je op subdomain moet blocken. Nieuwe subdomain aanmaken is paar minuten werk of kan zelfs geautomatiseerd. Pihole5 heeft nu mogelijkheid tot CNAME resolution, waardoor pihole er toch achter komt waar de subdomain naar verwijst.

Klopt, zie ook Wikipedia artikel over CNAME...

[ Voor 103% gewijzigd door jpgview op 26-01-2020 18:57 ]

[jpgview]

Toet3r schreef op zondag 2 februari 2020 @ 17:30:
[...]

Wireguard wordt gezien als een potentiële opvolger van OpenVPN, het zit echter nog zo vroeg in ontwikkelingsfase dat het nog niet echt wordt aangeraden om het te gebruiken.
Profielen importeren is wel veel makkelijker dan bij OpenVPN, namelijk doormiddel van scannen van een QR code met de wireguard app op je mobiel.

reddit: Wireguard VPN merged into Linux kernel (v5.6) -- PLEASE stop saying it's "untested" or unproven. It is OUTSTANDING.
arstechnica: Linus Torvalds pulled WireGuard VPN into the 5.6 kernel source tree
The last likely hurdle to inclusion in the Linux kernel itself is cleared.

We say it's unaudited, and that's still true.

[jpgview]

JB schreef op maandag 3 februari 2020 @ 09:32:
Kan die Pi Hole ook hostnames laten zien in de web interface? Nu moet ik kijken in de DHCP leases van mijn router om IP te kunnen herleiden.

Sinds drie weken ben ik volop bezig om mijn manual te updaten voor v5 van pihole, zodat die onmiddelijk beschikbaar is, wanneer de final release er is.

Mijn pihole v4.3.2 manual vind je hier.
Mijn pihole v5 (draft) vind je hier.

In de pihole v5 manual, een nieuw hoofdstuk (chapter 9 - Adding a local LAN list). Hier beschrijf ik hoe je, ofwel de pihole feature (Custom DNS) kan gebruiken, ofwel een custom oplossing kan implementeren, die je later ook kan gebruiken om clients te importeren in de database, voor gebruik met de nieuwe group management feature.

Als er fouten of onvolkomenheden staan in de draft, hoor ik dat graag.

[jpgview]

sweetdude schreef op woensdag 12 februari 2020 @ 16:16:
Izo zijn er gisteren tussen 20:40 en 20:49 60.000 requests geweest naar zomerweer.com.#mijn domein#

Heeft iemand een idee waar dit vandaan kan komen of hoe ik kan onderzoeken waar dit vandaan komt?

Geen idee of dit voor jou een hulp is, in mijn (windows) omgeving had ik ook het problem dat er steeds weer queries naar bv. something.something.localdomain te voorschijn kwamen, die uiteraard geen resultaat opleverden. Na onderzoek volgende oplossing:
1. Mijn dhcp server is pfsense. Op de pfsense ben je verplicht een domain naam in te vullen. Mag onder geen beding local zijn, dus localdomain gekozen.
2. de dhcp server (pfsense) gebruikt die info, om de clients een domain entry te geven, op de windows, enter ipconfig /all en kijk naar Connection-specific DNS Suffix. dat is het domain dat je van de dhcp server krijgt. Als dat domain overeen komt met het domain waar je steeds weer queries van ziet, next step.
3. Properties van je network opvragen, rechts klik op network icon in system tray, select Open Network and Internet settings, select change adapter options, rechts klik op je network adapter en kies properties, select internet protocol version 4 en opnieuw properties. Select advanced button, selecteer de tab dns. Zorg dat alles leeg is, alles unchecked en selecteer append these dns suffixes (in order). klik op add, geef een punt (period) in, en add. Sluit alle dialogen met ok.

Er zullen nu geen automatische (onverklaarbare) localdomain queries gedaan worden, tenzij je ze zelf initieerd (dig something.localdomain)
Opgelet, Connection-specific DNS Suffix (ipconfig /all) wijzigt hierdoor niet, er zullen alleen geen automatische queries naar het domain gedaan worden (append suffix). Er wordt door het system een punt (period) toegevoegd, maar dat is OK, de correcte sysntax voor een domain is b.v. www.google.com. (trailing period), maar alle systemen (OS en tools, zoals dig) zijn er op voorzien dat je dit niet hoeft te typen.

[ Voor 10% gewijzigd door jpgview op 13-02-2020 10:15 ]

[jpgview]

ronjansen87 schreef op vrijdag 14 februari 2020 @ 13:27:
Daarnaast 1 harde blacklist:
[Afbeelding]

je doet er goed aan het aantal regular expressions tot een minimum te beperken, beter is dus:

^(.+\.)??(facebook|.*fb.+)\.(com|net)$

bron: reddit

een zeer efficiente lijst met regular expressions vind je hier.

in dit pihole (discourse) topic geef ik een aantal links naar sites waar je regular expressions kan evalueren, handig om te kijken of je regex wel het gewenste effect zal hebben (eerste link) en, om inzicht te krijgen over de structuur van je regex (tweede link). Ook nog een linkje naar de tutorial.

in pihole version 5 (beta!!!) zal het een stuk eenvoudiger zijn om de regular expression te identificeren, die het blocken van een web site veroorzaakt. Screenshots hier.

[ Voor 52% gewijzigd door jpgview op 14-02-2020 22:41 ]

[jpgview]

Spinozo schreef op vrijdag 6 maart 2020 @ 01:16:
Potentiële nieuwe blocklist voor Pihole.

Na een comment op discourse het script gewijzigd. Het is niet haalbaar alle domains van de csv file te gebruiken als block list. Er zijn teveel geldige domains (‘google.com’, ‘youtube.com’, ‘twitter.com’, ‘snapchat.com’, …) die geblocked zouden worden.

Heb het script aangepast, zodat alleen domains van bepaalde categorieen (columns) worden gebruikt, voor de aanmaak van de lijst. Als voorbeeld 'Ad Fraude' en 'Malware'. Het is aan de gebruiker om de columns te kiezen die hij wenst te blocken, door de code toe te voegen (duplicate) voor de gewenste column.

GitHub csv file hier.

@gitaarwerk aangepast script...

[ Voor 120% gewijzigd door jpgview op 06-03-2020 14:53 ]

[jpgview]

Church of Noise schreef op maandag 9 maart 2020 @ 22:50:
Draait iemand beta 5 al op een Pi Zero (W)?
Gezien de aangegeven hogere load bij gebruik van de deep CNAME functionaliteit wil ik graag andere ervaringen horen.

Zelf al meer dan een maand op beta5 op een 3B. Er zijn verschillende topics geweest over performance problemen, ook op een ZERO, die zijn ondertussen allemaal opgelost. De toegevoegde functionaliteit (deep CNAME inspection, regex whitelist, group management, identificatie van reden blocking, …) werkt allemaal perfect. Wat over blijft zijn cosmetic (web UI) en bijkomende feature requests, maar draagt niets bij tot de werking van pihole beta5.

Ergens (op discourse) heb ik gelezen dat de upgrade van beta5 naar v5 mogelijk zal zijn, maar dit is niet bevestigd (en dus geen zekerheid).

Omdat ik er vrij intens mee bezig ben, kom ik, op mijn systeem, tot de conclusie dat het CNAME probleem eigelijk veel minder aanwezig is dan in de media word aangegeven, blocked wegens CNAME detectie komt in mijn query log zelden te voorschijn, zelfs de regex blacklist blocks (voor CNAMEs) zijn verwaarloosbaar (NEXTDNS domains)

Mijn draft pihole5 manual bevat info over beta5, ook een script om de NEXTDNS CNAME entries toe te voegen (sectie 'Deep CNAME inspection). Opmerkingen altijd welkom

[jpgview]

Dit is GEEN pro/con DoH (DNS over HTTPS) post. Iedereen moet voor zichzelf uitmaken of DoH een optie is.

Persoonlijk ga ik voor unbound, omdat bij gebruik van DoH al je DNS requests door één provider gezien worden, met unbound ziet niemand het geheel.

In mijn (draft) pihole v5 manual, heb ik een sectie over DoH toegevoegd. Doel is het beschikbaar maken van een geconsolideerde lijst van DoH servers, die je op de firewall (NIET op pihole) kan blocken. Deze lijsten (DOHipv4.txt en DOHipv6.txt) worden dagelijks (automatisch) geupdate van volgende bronnen:

https://raw.githubusercon...-doh/master/doh-hosts.txt
https://raw.githubusercon...l/master/TheGreatWall.txt
https://raw.githubusercon...ohservers/master/list.txt
https://raw.githubusercon...-Servers/master/README.md
https://raw.githubusercontent.com/tjay/DoH-List/master/hosts
https://raw.githubusercon...h-list/master/domains.txt
https://raw.githubusercon...rl/curl/DNS-over-HTTPS.md
https://download.dnscrypt...son/public-resolvers.json (proto DoH only)

De bedoeling is om een URL Table Alias (pfsense terminologie) te maken, en een firewall rule die de alias gebruikt om port 443 te blocken. Block NIET alle ports, de lijst bevat ook IPs van servers die op port 443 EN port 53 reageren, alle poorten blocken kan voor pihole problemen zorgen

Dit zal niet op alle firewalls mogelijk zijn. Raadpleeg je firewall documentatie, om na te gaan of het kan...

Als je andere DoH server lijsten kent, kan je die altijd melden, als issue op de github pagina.

[jpgview]

Videopac schreef op zaterdag 21 maart 2020 @ 14:01:
Welke externe DNS server kun je dan het beste gebruiken? Ik gebruik nu Cloudflare maar als ik je lijst met DoH adressen, waar Cloudflare op staat: is mijn externe DNS server dan nog bereikbaar?

Als je de spelregels volgt, die ik heb aangegeven (alleen port 443 blocken) kan het alleen een probleem vormen, indien je ook deze setup gebruikt. Je zal dan de cloudflare servers ( 1.1.1.1, 1.0.0.1, 2606:4700:4700::1001, 2606:4700:4700::1111) uit de lijsten moeten verwijderen.
Indien je gewoon de cloudflare servers gebruikt als upstream (dus niet de DoH oplossing) moet je niets doen, je gebruikt voor reguliere DNS requests (ook naar cloudflare) immers port 53.
Indien je clouflared (DoH setup) niet gebruikt als upstream resolver voor pi-hole, kan ik alleen maar aanbevelen de unbound oplossing te gebruiken (persoonlijke keuze, niemand heeft het volledige beeld van je DNS requests).

[jpgview]

Er is een interessante wending aangaande youtube ads. Je kan er alles over lezen in dit discourse topic.
Je kan het script hier downloaden.

Het zou uitermate nuttig zijn om dit te testen met zoveel mogelijk gebruikers, gelieve eventuele problemen te melden op discourse, niet hier (de auteur is, bij mijn weten, niet actief op dit forum).

Er word nog hard gewerkt aan verbeteringen, het is dus aan te raden de GitLab pagina in de gaten te houden voor eventuele updates.

Hoe werkt het? (je kan dit ook lezen in de comment - begin van het script).
- download het script

code:

sudo wget https://gitlab.com/grublets/youtube-updater-for-pi-hole/-/raw/master/youtube.update.sh -O /home/pi/youtube.update.sh

- maak het script executable (sudo chmod +x /home/pi/youtube.update.sh)
- je moet het script aanpassen, vervang 123.456.789.999 (dummy) door een IP address uit je pihole log, dat address is een googlevideo address in jouw regio (something like r6---sn-ni5f-tfbl.googlevideo.com - lees ook de comment in het script)
- run het script één maal met sudo (sudo /home/pi/youtube.update.sh)
- controleer of het bestand /etc/dnsmasq.d/99-youtube.grublets.conf bestaat.
- controleer of het bestand /etc/hosts.youtube bestaat.
- herstart pihole-FTL (sudo service pihole-FTL restart)
- maak een cron job aan, maak een bestand /etc/cron.d/youtubeupdate, inhoud:

code:

* * * * * root  PATH="$PATH:/home/pi/" /home/pi/youtube.update.sh 2>&1

vanaf nu zal de cron job elke minuut draaien, en eventuele nieuwe domain names toevoegen aan /etc/hosts.youtube, er word, door pihole-FTL dan altijd verwezen naar het IP address dat jezelf hebt gekozen uit je pihole log, wat het aantal ads drastisch zal (zou - het blijft een test, maar de eerste resultaten zijn gunstig) doen dalen.

Er zijn voorlopig nog geen entries voor IPv6 (word aan gewerkt)
Het script maakt intensief gebruik van je SD kaart (voor pi gebruikers). Er is een voorstel gedaan om dit te wijzigen naar TMPFS (memory).

[ Voor 6% gewijzigd door jpgview op 11-05-2020 14:38 ]

[jpgview]

Freee!! schreef op dinsdag 5 mei 2020 @ 22:28:
Ik zou voor die tweede kiezen.
Ik heb het script even bekeken en in plaats van iedereen dat script te laten editen, was het waarschijnlijk beter geweest om dat IP-adres als parameter door te laten geven. Stuk eenvoudiger voor de meeste gebruikers en een stuk flexibeler als er in eerste instantie een fout IP-adres wordt meegegeven.

Je hebt er totaal geen idee van welk googlevideo ad domain de gebruiker reeds bezocht heeft, moeilijk om een nslookup of dig te doen naar een niet bekende domain naam.
Je kan ook niet zomaar een googlevideo.com domain uit de logs plukken, zoals MisteRMeesteR al aangaf, zou je per ongeluk het address van redirector.googlevideo.com kunnen gebruiken, dan loopt het helemaal mis.
Het is zelfs niet zeker dat er al een googlevideo.com domain in de logs te vinden is. Geen perfecte oplossing mogelijk, vandaar de noodzakelijke manuele aanpassing.
Het is ook wenselijk (noodzakelijk?) een lokaal (regio) IP address te gebruiken. Omdat pihole all over the world gebruikt wordt, kan je niet zomaar een routine bedenken die dat allemaal opvangt.

Als je een geweldig idee hebt, dat absoluut waterdicht is voor alle pihole flavours (pi, Raspbian, dietpi, vm, docker, ...), suggesties zijn welkom…

Als je wijzigingen aanbrengt aan het script, die ten goede kunnen komen aan alle gebruikers, meld ze dan eventueel op discourse. Er word nog hard gewerkt aan het script (IPv6, TMPFS, sqlite3 queries i.p.v. log parsing, …)

[ Voor 18% gewijzigd door jpgview op 05-05-2020 22:56 ]

[jpgview]

Sinus_rhythm schreef op maandag 11 mei 2020 @ 16:15:
Het maken van groepen en toewijzen van bepaalde block/whitelists is echt een fijne toevoeging!

Alleen heb ik nu het idee dat nieuwe clients niet automatisch worden toegevoegd aan een groep en dus buiten de blocklist vallen, klopt dat?

Fout. Alle clients, ook nieuwe, zijn per definitie onderhevig aan de regels van the default group, zelfs al heb je geen clients aangemaakt in group management. Pas wanneer je group management begint te gebruiken (maak een groep, een client en wijs die client toe aan die group) kan je zinvolle regels beginnen te maken. Ik geef een uitgewerkt voorbeeld in mijn manual, sectie 18 (group management, a whitelist example).

[ Voor 38% gewijzigd door jpgview op 11-05-2020 20:30 ]

[jpgview]

SmiGueL schreef op dinsdag 12 mei 2020 @ 11:46:
[...]

Ik vraag mij alleen af;
Omdat YouTube steeds andere URL's gebruikt, eg: r5---sn-ni5f-tfbl.googlevideo.com
Is het niet zo dat bij elke nieuwe URL de advertentie de 1e keer gewoon geladen wordt?

Er zijn inmiddels reacties waarbij sommigen er inmiddels honderden unieke URL's hebben 'verzameld'.
Bij zo vaak van server wijzigen is er dan toch geen houden aan?

- Ik ben niet de auteur van dat script, ik heb het alleen hier op het forum gemeld, omdat niet iedereen constant discourse, reddit, GitLab en GitHub in de gaten houd.
- Tot op heden heb ik alleen maar een vermoeden, waarom het werkt, ik heb ook geen idee of het zal blijven werken (omdat de lijst alleen maar groter wordt)

Zoals ik ook al in het pihole v5 topic schreef, mijn analyse van het pihole log:
- je start een google video -> loading
- op die moment zie je de DNS request voor de video URL in het log komen.
- de video begint af te spelen, maar...
- terwijl de video speelt, zie je nieuwe DNS requests, waarschijnlijk de requests voor een advertentie.
- wanneer de video is afgelopen word (waarschijnlijk) het IP van de vorige stap gebruikt om de ad te laden.

Het is dus nodig om de nieuwe entries (die van de requests, terwijl de video aan het spelen is) zo snel mogelijk toe te voegen aan de youtube hosts file. Niet snel genoeg -> ad, vandaar cron elke minuut.

Nogmaals, ik ben niet de auteur van het script, ik heb alleen maar een vermoeden wat de logica is.Wil je meer weten, of vragen stellen aan de auteur, doe het op GitLab

@MijnKijk heeft hierboven (hoop dat de link correct is) een versie gebupliceerd, die SD card friendly is (alleen SD writes als er een nieuw domain gevonden is). Ben deze versie op dit moment aan het bekijken. Mijn eerste indruk is positief, alleen zou ik het logger commando verwijderen, dit is een extra SD card write, die niets bijdraagt aan de werking.

[jpgview]

rvk schreef op dinsdag 12 mei 2020 @ 12:35:
[...]
Of zie ik iets over het hoofd?

Je ziet iets over het hoofd. Een regex blacklist zorgt er voor dat het antwoord op de query 0.0.0.0 is. Dat is niet wat het script doet, Het script doet een redirect, e.g. echt IP address wordt vervangen door het IP address dat je de eerste keer in het script hebt toegevoegd.

[jpgview]

SmiGueL schreef op dinsdag 12 mei 2020 @ 12:47:
[...]

Begrijp ik dan goed dat deze methode werkt omdat het opgegeven IP adres, waarnaar in feite alles wordt geredirect, wél alle video's kan serveren, maar niet elke advertentie op deze server heeft staan?

Nee, tenmiste daar ga ik vanuit.
Wanneer een video laad, zie je in het pihole log een request naar de CNAME (v.b.r7---sn-uxaxoxu-cg0r.googlevideo.com - drie streepjes). Pihole-FTL doet zijn ding en geeft het address van het A record als antwoord. Het A record wijst naar het domain r7.sn-uxaxoxu-cg0r.googlevideo.com (geen streepjes maar een punt), dat is de domain entry die aan de lijst word toegevoegd.

Wanneer je allebei (CNAME en A record) aan de lijst toevoegd, is de pret binnen de paar minute over (error loading …)

Zoals al gezegd, het is mij ook niet duidelijk waarom en hoelang het werkt. Ik had ook graag een verklaring, maar heb deze, ondanks vele uren onderzoek, ook nog niet gevonden.

[jpgview]

Zjemm schreef op woensdag 13 mei 2020 @ 19:00:
ik had tot voor kort een zelfde soort lijst met googlevideo domeinen, maar die blokkeerde ik dan gewoon en dat zorgde ook voor minder advertenties.
dat was deze lijst: https://raw.githubusercon...ist/master/domainlist.txt

Ik onderzoek dit, m.b.v. pihole log tracing en wireshark als sinds de eerste dag dat het script gepublished is op discourse (pihole forum). Ik heb nog steeds geen sluitende verklaring gevonden waarom het werkt. Het valt mij wel op dat ik nergens lees dat het niet (meer) werkt...

edit
toch een melding van een probleem
/edit

Wel ben ik er redelijk van overtuigd, dat de lijst, die jij vermeld problemen veroorzaakt (error loading video)
Het originele script voegt uitsluitend entries met de structuur rx.sn- toe. Ik heb geexperimenteerd met het toevoegen van entries met de structuur rx---sn-. Het duurde minder dan een uur om een load video error te krijgen.
dus:
- toevoegen (example): r1.sn-25ge7n76.googlevideo.com
- NIET toevoegen (example): r1---sn-25ge7n76.googlevideo.com

blocken, met b.v. de lijst die jij vermeld, werkt dus volgens mij niet (bevat beide type entries - rx.sn- en rx---sn-). Zelfs in pihole v4.4 ( en dus ook in pihole v5.0) zou ik twijfelen om deze blocklist te gebruiken, je kan immers alle entries in die lijst afblokken met één regular expression (regex blacklist).
Verder is er een fundamenteel verschil tussen blocken en het script gebruiken.
- blocken: reply = 0.0.0.0
- script: reply = het address dat je geconfigureerd hebt in het script.

[ Voor 3% gewijzigd door jpgview op 13-05-2020 22:12 ]

[jpgview]

INF3RN040 schreef op woensdag 13 mei 2020 @ 15:44:
[En hoe kan je het wijzigen naar TMPFS ?

@MijnKijk heeft een script op het forum gezet, dat het gebruik van TMPFS overbodig maakt (een paar entries voor jouw vraag). hier (als mijn link correct is)

[jpgview]

drvo schreef op donderdag 14 mei 2020 @ 10:40:
[...]


Wat de maker van het script hier schrijft is:

"What seems to be happening is the name lookup that appears immediately before an ad returns a new IP that seems primed to fire the ad as soon as the client hits it. I've gone over network dumps until my eyes were near bleeding and observed it first hand with YouTube streaming as I watched live traffic from an AppleTV. An in-video ad has always been preceded by one of these lookups."

Het adres dat je terugkrijgt is elke keer anders (en zoals ook opgemerkt door anderen waarschijnlijk gebonden aan de regio waarin je zit), maar het aantal mogelijkheden is waarschijnlijk beperkt, aangezien Google regelmatig dezelfe URLs terugstuurt. Achter het IP-adres van de URL die je computer terugkrijgt staat waarschijnlijk een ad klaar om afgevuurd te worden op jou als gebruiker.

Wat ik vermoed is dat die ad alleen op die server klaar staat voor je. Als je dat dus afvangt (een eerste keer is via deze methode niet mogelijk aangezien die URL nog niet in je logs staat) en die URL laat verwijzen naar een ander IP-adres van een googlevideo-server die eerder aan je gestuurd is (dat verwijzen gebeurt via de /etc/hosts.youtube file), is de kans klein dat daar een ad voor je klaar staat. Tenminste dat is mijn theorie, gebaseerd op wat ik kan halen uit de verschillende reacties en door het lezen van het script.

Bij mij lijkt het erop dat ie na een tijdje soms toch weer reclames laat zien. Als ik dan de foreceIPv4 variabele update naar een nieuw adres (gewoon weer een nslookup doen op een recente URL), en dit adres ook doorvoer in de hosts.youtube-file, lijkt het wel weer goed te gaan. Het kan natuurlijk ook toeval zijn dat het hard gecodeerde ip-adres van de server in de hostfile voor mij op dat moment ads staat te serveren. Dat is me niet helemaal duidelijk.

Wat me ook opvalt is dat de opbouw van de URL telkens hetzelfde is:

code:

r[1-8].sn-<semi-willekeurige reeks alfanumerieke tekens>.googlevideo.com

De <semi-willekeurige reeks tekens> lijkt echter beperkt qua mogelijkheden en komt telkens terug per r1, r2, r3 etc. Als je dus een nieuwe reeks tegenkomt voor bijv. r1, kan je die (als de theorie klopt) ook gelijk toepassen voor r[2-8]. Dat kan je automatiseren en vangt dan de eerste keer potentieel 7 keer zoveel ads af dan wanneer je wacht tot een r2, r3 etc. met diezelfde reeks terugkomt.

Mogelijke verbeteringen aan het script die ik nog zie zijn:

• Automatisch parsen van forceIPv4 uit je logs, als er een googlevideo.com domain in je logs staat
• Slim mechanisme bedenken voor het dynamisch updaten van forceIPv4 (als mijn theorie klopt)
• Automatisch parsen van de reeks semi-willekeurige tekens en ook meteen 7 entries toevoegen voor de overige 'r' hosts.

edit: Ik lees net hier dat iemand die problemen had omdat er geen ads werden afgevangen, na het wijzigen van zijn upstream DNS-server in pi-hole van Google naar OpenDNS geen problemen meer had.

Feel free to shoot, ik zie het graag als iemand betere inzichten heeft.

Prachtig verhaal, ik wou dat ik het kon bevestigen of ontkennen. Zoals al eerder gezegd, ik zit al een hele tijd te zoeken naar een verklaring waarom dit werkt, helaas…

Wat het hele verhaal voor mij nog onduidelijker maakt:
- het script voegt entries zoals r3.sn-5hnekn7d.googlevideo.com toe aan /etc/hosts.youtube en doet een pihole restartdns reload, wat volgende entries in het pihole log doet verschijnen:

May 14 11:43:33 dnsmasq[29244]: read /etc/hosts - 15 addresses
May 14 11:43:33 dnsmasq[29244]: read /etc/hosts.youtube - 66 addresses
May 14 11:43:33 dnsmasq[29244]: read /etc/pihole/custom.list - 0 addresses
May 14 11:43:33 dnsmasq[29244]: read /etc/pihole/local.list - 4 addresses

- als ik echter daarna volgend commando uitvoer:

cat /var/log/pihole.log | grep /etc/hosts.youtube

zie ik uitsluitend entries zoals:

May 14 11:05:27 dnsmasq[29244]: read /etc/hosts.youtube - 54 addresses
May 14 11:18:25 dnsmasq[29244]: read /etc/hosts.youtube - 58 addresses
May 14 11:29:26 dnsmasq[29244]: read /etc/hosts.youtube - 62 addresses

- wanneer ik echter vanop een workstation het commando

nslookup r3.sn-5hnekn7d.googlevideo.com

uitvoer, en daarna opnieuw het commando

cat /var/log/pihole.log | grep /etc/hosts.youtube

krijg ik het volgende resultaat:

May 14 11:05:27 dnsmasq[29244]: read /etc/hosts.youtube - 54 addresses
May 14 11:18:25 dnsmasq[29244]: read /etc/hosts.youtube - 58 addresses
May 14 11:29:26 dnsmasq[29244]: read /etc/hosts.youtube - 62 addresses
May 14 11:40:19 dnsmasq[29244]: /etc/hosts.youtube r3.sn-5hnekn7d.googlevideo.com is 208.117.238.19
May 14 11:40:19 dnsmasq[29244]: /etc/hosts.youtube r3.sn-5hnekn7d.googlevideo.com is 2620:11a:a036::13

e.g. nslookup query r3.sn-5hnekn7d.googlevideo.com geeft als resultaat het IPv4 en IPv6 address uit /etc/hosts.youtube.

er staat hier, op een andere computer constant een video serie af te spelen (ene na de andere guild wars2 video), uren aan een stuk. Ik zie in het log nooit entries te voorschijn komen, waarbij het address voor een of andere googlevideo (of ad) uit /etc/hosts.youtube komt (tenzij ik een nslookup doe)

Kan iemand, die het script heeft draaien, en regelmatig youtube video's afspeelt ook eens het commando:

cat /var/log/pihole.log | grep /etc/hosts.youtube

uitvoeren, en melden of de pc (browser) wel requests doet, die vanuit /etc/hosts.unbound worden opgelost?

[jpgview]

Zjemm schreef op donderdag 14 mei 2020 @ 12:14:
heb even gekeken in mijn oude Bind server logs en in een unbound server en een bihole.
maar in allemaal zie ik alleen maar entries als deze:

code:

May 13 15:39:13 unbound[3044:0] info: 192.168.1.153 redirector.googlevideo.com. A IN NOERROR 0.020356 0 60
May 13 15:39:13 unbound[3044:0] info: 192.168.1.153 r3---sn-5hnekn7z.googlevideo.com. A IN NOERROR 0.035892 0 95
May 13 15:40:01 unbound[3044:0] info: 192.168.1.153 r4---sn-5hnekn7d.googlevideo.com. A IN NOERROR 0.043597 0 95
May 13 15:40:02 unbound[3044:0] info: 192.168.1.153 r1---sn-n4v7sn7l.googlevideo.com. A IN NOERROR 0.036605 0 95
May 13 15:40:28 unbound[3044:0] info: 192.168.1.153 r3---sn-5hne6nsd.googlevideo.com. A IN NOERROR 0.035378 0 95

dus allemaal met 3 streepjes, nooit iets in een ander formaat
het script kijkt naar entries met 1 streepje zo het lijkt

de logica begint me totaal te ontgaan

je zit in unbound logs te kijken, het script werkt uitsluitend met de pihole logs. pihole log entries (wanneer een video laad) zien er zo uit:

May 14 11:42:53 dnsmasq[29244]: query[A] r5---sn-5hne6nsk.googlevideo.com from 192.168.2.179
May 14 11:42:53 dnsmasq[29244]: forwarded r5---sn-5hne6nsk.googlevideo.com to fdaa:bbcc:ddee:2::5552
May 14 11:42:53 dnsmasq[29244]: query[A] r5---sn-5hne6nsk.googlevideo.com from 192.168.2.179
May 14 11:42:53 dnsmasq[29244]: forwarded r5---sn-5hne6nsk.googlevideo.com to 127.10.10.2
May 14 11:42:53 dnsmasq[29244]: forwarded r5---sn-5hne6nsk.googlevideo.com to fdaa:bbcc:ddee:2::5552
May 14 11:42:53 dnsmasq[29244]: reply r5---sn-5hne6nsk.googlevideo.com is <CNAME>
May 14 11:42:53 dnsmasq[29244]: reply r5.sn-5hne6nsk.googlevideo.com is 172.217.132.42

er is een reply regel met een IP address als antwoord, die regel wordt door het originele script gebruikt.

ben er al een tijdje mee gestopt het originele script te gebruiken (en dus altijd de logs te parsen)

requirements:
- telnet (sudo apt-get -y install telnet)
- screen (sudo apt-get -y install screen)
gebruik:
- run het originele script éénmaal (sudo <scriptname>.sh
- vul de IP's in het script hieronder
- run sudo screen (een nieuw screen gaat open)
- start het nieuwe script (zie hieronder)
- je kan nu volgen wat er gebeurd.
- om terug een console te krijgen (het script draait gewoon verder), druk <CTRL>AD
- om terug naar het screen te gaan , enter sudo screen -r
we gebruiken sudo, omdat het script de nodige permissions moet hebben...
script:

#!/bin/bash

FTLdb=/etc/pihole/pihole-FTL.db
ytHosts="/etc/hosts.youtube"

IPv4=
IPv6=

starttime() {
start="$(date "+%y%m%d %R" -d "$1")"
begintm=$(TZ=CET date --date="$start" +"%s")
echo $begintm
}

while :;do
# we retrieve all records, no older than 2 minutes
starttm=$(starttime "2 minutes ago")
# we are using telnet to retrieve the domains from memory (pihole-FTL)
mapfile -t domains < <(( echo ">getallqueries-time ${starttm}"; echo ">quit"; sleep 1; ) \
| telnet 127.0.0.1 4711 \
| cut --delimiter " " --fields 3 \
| grep -e .*---sn-.*googlevideo.com \
| sed 's/---/./g' )

lenArray=${#domains[@]}

# stop processing if the result is empty
if [ $lenArray != 0 ]; then
# count number of entries of current hosts file
ytEntries=$(wc -l $ytHosts)

for (( i=0; i<$lenArray; i++ )); do
if [ $(grep -c "${domains[$i]}" $ytHosts) == 0 ]; then
# Add line to ytHosts
echo " added ${domains[$i]}"
echo "${IPv4} ${domains[$i]}" >> $ytHosts
if [ ! -z "$IPv6" ]; then
echo "$IPv6 ${domains[$i]}" >> $ytHosts
fi
fi
done

# check if there are new entries, restart reload if necessary.
if [ "$ytEntries" != "$(wc -l $ytHosts)" ]; then
/usr/local/bin/pihole restartdns reload
fi
fi

sleep 59
done

Als je dit wil proberen, vergeet dan niet de cron job (originele script methode) te verwijderen, het is het een OF het ander!!!

[jpgview]

Zjemm schreef op donderdag 14 mei 2020 @ 13:23:
[...]


dat klopt, ik gebruik nu even de unbound logs (vind ik overzichtelijker) als voorbeeld voor welke query's er allemaal langs komen voor googlevideo.
die query's zijn niet anders dan die van pihole natuurlijk.

en het script gooit naar mijn idee alle gevonden googlevideo urls in de lijst die iets in zich hebben met bijvoorbeeld: r3---sn-

daarom is het ook vreemd, want zo creëer je een lijst met alle googlevideo urls waar die r3---sn-achtige vorm in voor komt, en die ga je vervolgens redirecten naar een en het zelfde google IP

zoals ik hierboven al gezegd heb:

Het originele script voegt uitsluitend entries met de structuur rx.sn- toe. Ik heb geexperimenteerd met het toevoegen van entries met de structuur rx---sn-. Het duurde minder dan een uur om een load video error te krijgen.
dus:
- toevoegen (example): r1.sn-25ge7n76.googlevideo.com
- NIET toevoegen (example): r1---sn-25ge7n76.googlevideo.com

[jpgview]

theduke1989 schreef op donderdag 14 mei 2020 @ 13:32:
beste alle,

hoe kan je Unbound managen, beheren? 1x installatie doorvoeren kan iedereen.
Maar daarna het beheer, de updatebeleid etc is dit via GUI te beheren of moet je daar meer kennis voor hebben?

zoals het in de pihole documentatie staat:

Important: Download the current root hints file (the list of primary root servers which are serving the domain "." - the root domain). Update it roughly every six months. Note that this file changes infrequently.

wget -O root.hints https://www.internic.net/domain/named.root
sudo mv root.hints /var/lib/unbound/

target aanpassen naar waar je root.hints file staat. na installatie zijn er in veel gevallen twee bestanden root.hints op het system te vinden, de system default versie en de versie, gebruikt door unbound. ik update ze alle twee wekelijks.

[jpgview]

Zjemm schreef op donderdag 14 mei 2020 @ 13:23:

en het script gooit naar mijn idee alle gevonden googlevideo urls in de lijst die iets in zich hebben met bijvoorbeeld: r3---sn-

daarom is het ook vreemd, want zo creëer je een lijst met alle googlevideo urls waar die r3---sn-achtige vorm in voor komt, en die ga je vervolgens redirecten naar een en het zelfde google IP

ik kan weer effe niet meer volgen. r3---sn- (drie streepjes)?

hier het originele script.

het relevante commando uit het script (heb de variable vervangen door de value):

zgrep -e "reply.*-.*\.googlevideo.*\..*\..*\..*" /var/log/pihole.log | awk -v fIP=208.117.238.19 '{ print fIP, $6 }'

resultaat:

208.117.238.19 r1.sn-uxaxoxu-cg0k.googlevideo.com
208.117.238.19 r8.sn-uxaxoxu-cg0r.googlevideo.com
208.117.238.19 r8.sn-uxaxoxu-cg0r.googlevideo.com
208.117.238.19 r2.sn-5hne6ns6.googlevideo.com
208.117.238.19 r7.sn-uxaxoxu-cg0k.googlevideo.com
208.117.238.19 r6.sn-uxaxoxu-cg0k.googlevideo.com

waar plots die resultaten met format rx---sn- (CNAME) vandaan komen, zoals jij aangeeft, weet ik niet. het originele script maakt entries met het format rx.sn- (A record).

het is zo, dat gedurende het laden van een video er een request komt van de browser (de CNAME - drie streepjes), de reply van pihole-FTL is het het A record + IP address (één streepje).

nogmaals, derde keer, bij mij (uitvoerig getest) leid het redirecten van de CNAME (drie streepjes) naar een vooraf gedefineerd IP (forceIP uit het script) binnen de korste keren tot een video load error, dus:
- toevoegen (example): r1.sn-25ge7n76.googlevideo.com
- NIET toevoegen (example): r1---sn-25ge7n76.googlevideo.com

ik blijf dan ook met de vraag zitten of iemand, die het originele script gebruikt, na het uitvoeren van volgend commando:

cat /var/log/pihole.log | grep /etc/hosts.youtube

meer ziet dan

May 14 11:05:27 dnsmasq[29244]: read /etc/hosts.youtube - 54 addresses
May 14 11:18:25 dnsmasq[29244]: read /etc/hosts.youtube - 58 addresses
May 14 11:29:26 dnsmasq[29244]: read /etc/hosts.youtube - 62 addresses

ik blijf hopen op

May 14 11:40:19 dnsmasq[29244]: /etc/hosts.youtube r3.sn-5hnekn7d.googlevideo.com is 208.117.238.19
May 14 11:40:19 dnsmasq[29244]: /etc/hosts.youtube r3.sn-5hnekn7d.googlevideo.com is 2620:11a:a036::13

maar zelf zie ik het nooit (tenzij ik een nslookup doe - na talloze youtube video series af te spelen op een andere computer).

[jpgview]

Zjemm schreef op vrijdag 15 mei 2020 @ 09:25:
[...]


Ah Helder, alles met drie streepjes is CNAME voor hetzelfde domein zonder streepjes achter r1

dig: 'r1---sn-32o-guhe.googlevideo.com' is not a legal IDNA2008 name (string contains forbidden two hyphens pattern), use +noidnout

leuk is dus dat dit tegen de standaard in is als ik DIG mag geloven.
Waarom zou google dit doen? wat voegt het CNAME toe aan een response wat pratisch hetzelfde domein is

dig +short +noidnin +noidnout r1---sn-32o-guhe.googlevideo.com

geeft je alle info die je nodig hebt, result:

r1.sn-32o-guhe.googlevideo.com.
195.121.71.44

Ik ga er vanuit dat google dit doet als onderdeel van de strategie om het blocken van ads te bemoeilijken.

Een vergelijkbare techniek wordt door sommige ad company's gebruikt om de 'third party' block, die eigelijk bijna op alle browsers default aan staat, te omzeilen. Door gebruik te maken van een CNAME, lijkt het alsof de ad van de 'first party' afkomstig is. Je kan daarover hier meer lezen. andere bronnen over dit fenomeen gewenst -> duckduckgo search term 'CNAME cloaking'.

Pihole v5.0 is hiertegen gewapend (deep cname inspection). Je kan hierover meer lezen in mijn manual, sectie 15. Je vind er ook een script om de domains, die 'third party' ads pushen, toe te voegen als regex blacklist. Die domains worden ook gebruikt door nextDNS (het script gebruikt de nextDNS lijst). Let wel, pihole v5.0 deep cname inspection werkt uitsluitend voor blocking (reply 0.0.0.0). Het kan dus niet gebruikt worden om een redirect te doen (het youtube script doet een redirect)..

[jpgview]

quote]Zjemm schreef op vrijdag 15 mei 2020 @ 11:43:

is dat trouwens DE manier waarop Pihole cname inspection doet? op basis van die lijst? of doet pihole meer?

[/quote]

er zijn ook blocklist(s) met relevante entries. Als zo'n entry in een lijst voorkomt, en dus in de gravity database, zal dat ook gedetecteerd worden. Het is dus NIET zo, dat, als je geen specifiek entry's (b.v. van de nextDNS lijst) toevoegd, deep cname inspection niets doet. het is afhankelijk van de lijsten die je toevoegd.

eentje die bij mij b.v. regelmatig te voorschijn komt:



de browser zoekt fonts.gstatic.com (CNAME - niet aanwezig in een blocklist) maar omdat gstaticadssl.l.google.com (A record) wel op een blocklist staat, vind en blocked pihole de query

[jpgview]

ivootjuh schreef op zondag 17 mei 2020 @ 09:59:

Ik zal zeker iets over het hoofd zien, maar ik zie het zelf gewoon niet. Ligt het aan mij, of is het niet heel erg intuïtief?

In mijn manual, section 18, a whitelist example. Dit voorbeeld legt uit hoe een (regex) whitelist entry uitsluitend voor bepaalde devices toe te passen. getest…

edit
ik hoor regelmatig dat users.telenet.be blocked is door sommige lijsten. Manual lezen? > whitelist…
/edit

[ Voor 11% gewijzigd door jpgview op 17-05-2020 10:30 ]

[jpgview]

ivootjuh schreef op zondag 17 mei 2020 @ 10:34:

Wat voor verschil zit er tussen de Regex en de Exact Whitelist dan? zal het daar dan fout gaan?

Ik heb nu dus een Exact Whitelist aangemaakt en naar de group verwezen waar mijn vrouw in zit.
Ik zit niet in die group, maar ik kan nu ook gewoon Google ads openen!

een regex dekt meerdere domains (alt1-mtalk, alt2-mtalk, …). Er is geen enkel probleem met het gebruik van een exact whitelist, je dekt dan alleen dat specifieke domain af.

Nadat je een groupmanagement configuratie hebt gemaakt, moet je:
- dit best nog eens bekend maken aan pihole-FTL (pihole restartdns reload-lists)
- de DNS cache van je eigen pc leegmaken (op windows: ipconfig /flushdns)

als dit niet werkt heb je ergens een fout gemaakt, eenvoudigste methode is dan alles weggooien, en stap voor stap opnieuw aanmaken (troubleshooting can be a bitch...)

ivootjuh schreef op zondag 17 mei 2020 @ 10:34:
Ik heb even screenshots toegevoegd!
Kan ik trouwens ergens controleren of clients standaard onder de Default group komen? Ik heb deze group namelijk wel een keer gewijzigd aan het begin, misschien gaat het daar fout?

- Default word elke client, ook diegene die niet in groupmanagement / clients zijn gedefineerd, toegewezen aan the default group
- Iets waarmee je altijd rekening moet mee houden: whitelist always wins.
- Het is heel moeilijk om aan de hand van je screenshots een mogelijke fout aan te geven. Iets wat me niet bevalt is dat je client slechts aan een groep is toegewezen (er van uit gaande, dat dit een client is, waarvoor je de selectieve whitelist entries wil toepassen)

In het voorbeeld wil ik de whitelist alleen toepassen voor android devices. De client entry (S9) ziet er dan zo uit:

[ Voor 40% gewijzigd door jpgview op 17-05-2020 11:02 ]

[jpgview]

ivootjuh schreef op zondag 17 mei 2020 @ 10:59:
Het lijkt erop alsof hij clients niet standaard onder de Default group zet. Zodra ik mezelf in de Default group zet, dan werkt het gelijk en wordt alles geblockt. Gooi ik mezelf echter uit de group, dan werken de advertenties weer (wat ik dus niet wil) Iedereen moet standaard onder de Default komen, waar ads geblockt worden.

vorige post aangepast (screenshot).
er vanuitgaande dat je slechts twee groepen hebt (the default groep en the google groep)
- het device van je vrouw moet erutzien zoals S9
- je eigen device zoals wiiu

nogmaals de screenshot

[jpgview]

ivootjuh schreef op zondag 17 mei 2020 @ 11:13:
Het gaat echter niet alleen om mijn apparaat. Ik wil alle apparaten en nieuwe apparaten (van familie en vrienden e.d.) standaard onder de default hebben. Op deze manier moet ik handmatig iedereen aan een groep toewijzen iedere keer.

De regels van the default group zijn altijd automatisch van toepassing op nieuwe clients, ook voor clients die NIET in group management / clients zijn gedefineerd.

Alleen als je voor een nieuw apparat ook de google uitzondering wil toepassen, moet je:
- de client aan maken in group management
- de client toevoegen aan de google group.
- er op toezien dat de client de client all selected weergeeft in group management / clients

remember whitelist always wins!

[ Voor 7% gewijzigd door jpgview op 17-05-2020 11:26 ]

[jpgview]

ivootjuh schreef op zondag 17 mei 2020 @ 11:32:
Maar haal ik mezelf uit de group management, dan werken de advertenties nog steeds (ook na flush dns).

dit is hoe je whitelist entries er moeten uitzien (exact whitelist, alleen toegewezen aan de google group). Ik kan jouw problem alleen maar verklaren als de whitelist entries aan beide groepen zijn toegewezen. Let wel, het kan een bug zijn, maar er zijn tot op heden geen meldingen van...

[jpgview]

ivootjuh schreef op zondag 17 mei 2020 @ 11:56:
[...]


Ja ik vindt het ook raar hoor, want alle Adlists werken wel gewoon als ik ik geen enkele groep zit. En even voor de duidelijkheid. Ik heb die whitelists alleen toegewezen aan de Google group en niet aan de default group.

Er gaat dus echt iets niet goed met de whitelists.

Ik heb je scenario net getest.
- test pc google ads -> ad links blocked
- test pc toegevoegd aan google ads group -> ad links werken
- client entry (de test pc) verwijderd, de google ad links werken na het verwijderen van de test pc NIET (meer). Logisch want er is geen client toegewezen aan de group.

Ik ga er dus vanuit dat je ergens een fout hebt gemaakt (geen bug)

advies: gooi alles weg, zorg ervoor dat alle clients aan the default group zijn toegewezen, volg de instructies uit mijn handleiding om alles terug op te bouwen.

[jpgview]

ivootjuh schreef op zondag 17 mei 2020 @ 12:39:
hoe kan ik zien of een gebruiker standaard ik de default group zit? Dat is me namelijk niet duidelijk. Ik kan nergens terug vinden of een apparaat standaard in die group zit!

[jpgview]

ivootjuh schreef op zondag 17 mei 2020 @ 15:55:
Ik snap er echt helemaal niks van, ben toch best wel bekend met groep management op mijn server en nas, maar krijg dit gewoon niet werkend.

Omdat ik vermoed dat er wel meer mensen geintereseerd zijn in deze oplossing, heb ik een document (handleiding) gemaakt, specifief voor dit scenario. je vind het hier.

Er zit een script bij (GitHub link) dat het meeste werk voor jou doet. Je hoeft daarna alleen nog maar een client aan te maken en aan de groep toe te voegen (ook beschreven in het document)

Ik heb het getest, het werkt (hardware is raspberry pi 3B, OS Raspbian, laatste versie)

Opgelet, je bent beta tester (maar bij mij liep alles goed). issues op GitHub a.u.b.

- users.telenet.be in sommige block lists -> lezen = whitelisten.
- zorg ervoor dat je eerst alle oude troep verwijderd, ook whitelist entries die je in het verleden voor je wag hebt aangemaakt (zijn van toepassing op alle devices).
- lees de comments in het script, voor je het uitvoert!

downloaden:

code:

sudo wget https://raw.githubusercontent.com/jpgpi250/piholemanual/master/googleads.sh -O /home/pi/googleads.sh
chmod +x /home/pi/googleads.sh

execute:

code:

sudo /home/pi/googleads.sh

Graag hoor ik commentaar op de whitelist entries, daar ben ik niet 100% van overtuigd (teveel?)

Laat maar iets weten, bij mij werkt het in elk geval (scripted implementation).

[jpgview]

ivootjuh schreef op zondag 17 mei 2020 @ 22:18:

Weet jij toevallig een goede blocklijst ook om trackers e.d. te blokkeren? Ik kom veelal de lijst tegen van Wally3k https://firebog.net/
Mocht ik deze willen gebruiken, moet ik dan al die links die daarin staan één voor één in de Adlist onder Group management toevoegen, of is daar nu ook al een makkelijkere manier voor (is alweer even geleden).

En opnieuw verwijs ik naar mijn manual, sectie 16

An interesting set of lists, can be found here. This page will let you choose from 3 sets of lists, I’ve been using the non-crossed lists. This page will display a set of URLs that can be added. Using sqlite3, it is possible to add these list with a script. You can add these lists by running /home/pi/firebog.sh:

voor de links en het script verwijs ik naar de manual... (remember users.telenet.be misschien geblocked. lezen = whitelisten)

[jpgview]

Jazco2nd schreef op maandag 18 mei 2020 @ 15:54:
Ik zou dan eerder naar Unbound DNS schakelen, wil altijd recursive DNS gebruiken. Ik zoek nog wel uit wat de mogelijkheden zijn.

https://discourse.pi-hole...-for-pihole-disable/20246

[jpgview]

Jazco2nd schreef op maandag 18 mei 2020 @ 16:46:
[...]


Vaag, als je Unbound reeds gebruikt icm Pihole heb je zijn hele verhaal niet nodig. Volgens mij zegt hij dat ook in het begin. Ik kan me niet voorstellen waarom je deze oplossing zou volgen..

Als je Pihole disabled, disable je alleen adblocking. DNS queries worden nog steeds resolved door PiHole via Unbound.

ligatus .com zit in een of andere block list
- eerste nslookup -> default DNS (pihole), result 0.0.0.0
- tweede nslookup -> secondary IP (redirected to unbound), result 104.115.80.64



de oplossing werkt, ik gebruik ze al sinds ik het topic heb gemaakt op discourse

Jazco2nd schreef op maandag 18 mei 2020 @ 16:46:
Voordeel daarvan is dat je nog steeds DNS caching van Pihole gebruikt. Unbound heeft die functie niet.

unbound heeft wel degelijk caching (veel info over de cache in how to optimize), meer nog, ik zet de cache van dnsmasq (=pihole-FTL) op nul (cache-size=0), draai dit al maanden op die manier, geen delays...

Je moet meer lezen dan de eerste zin, daarin zeg ik allen waar het idee vandaan komt, al de rest gaat over de methode, gebruikt om pihole te bypassen en de queries om te leiden naar unbound

[ Voor 3% gewijzigd door jpgview op 18-05-2020 17:23 ]

[jpgview]

Videopac schreef op maandag 18 mei 2020 @ 21:28:
Kan iemand me uitleggen wat unbound is en hoe dat werkt en waarom je dan geen DNS server meer hoeft in te vullen. Er wordt hier aangenomen dat dat algemene kennis is, maar dat is het voor mij (nog) niet.

lees eerst deze handleiding van de pihole developers. het is de eenvoudigste manier om met unbound aan de slag te gaan.

[jpgview]

rvk schreef op dinsdag 19 mei 2020 @ 23:22:
Ik ben het hele script werkend maar zit toch met een probleem.

Zoals al eerder aangegeven, ik heb nog steeds geen idee hoe het komt dat het youtube script werkt.

Een verklaring voor jouw probleem zou kunnen zijn (zie hieronder waarom ik dit denk).
- je doet een restartdns, de dnsmasq (=pihole-FTL) cache is nu dus leeg.
- je doet een ping, omdat de cache leeg is, forward dnsmasq de query (r5---sn-5hne6nlr.googlevideo.com zit NIET in de cache).
- het antwoord op de CNAME request (r5---sn-5hne6nlr.googlevideo.com is een CNAME) is het A record (r5.sn-5hne6nlr.googlevideo.com) EN het correcte IP address, deze worden nu beide in de dnsmasq cache opgenomen., het antwoord op de query wordt ook naar de client verstuurd.
- je doet opnieuw een query naar de CNAME (r5---sn-5hne6nlr.googlevideo.com). deze keer zit het resultaat in de cache, ook het A record zit in de cache, deze keer komt het resultaat voor het A record uit /etc/hosts.youtube
Dus, eerste keer (geen cache) antwoord van de forwarded query integraal naar client.
Tweede keer, CNAME uit de cache en A record uit /etc/hosts.youtube naar de client.

Waarom ik denk dat dit de verklaring is:
Als je een dig r5---sn-5hne6nlr.googlevideo.com uitvoerd, komt alle info (het is een CNAME, het A record is r5.sn-5hne6nlr.googlevideo.com en het IP) terug als één antwoord (één request, één reply met alle noodzakelijke info). Ik ga er vanuit dat dnsmasq het antwoord niet gaat evalueren (kijken of het A record toch eventueel in een config voorkomt), omdat een en ander simpelweg voor te veel vertraging zou zorgen (je zou dit voor elke query moeten doen). Met andere woorden, het lijkt erop dat dnsmasq de query resultaten kan beinvloeden (geeft een antwoord uit de config) vóór het een query forward, dnsmasq lijkt nooit een reply te wijzigen (antwoord op een query die geforward is). Omdat er dus queries voor de CNAMEs worden uitgevoerd (telkens wanneer een video laad), en die in de config (/etc/hosts.youtube) niet voorkomen, krijg je de eerste keer altijd het echte IP als antwoord.

Let wel, deze analyse doe ik op basis van jouw log entries, om een of andere, mij voorlopig nog onduidelijke reden, zie ik NOOIT entries zoals /etc/hosts.youtube r5.sn-5hne6nlr.googlevideo.com is 172.217.132.104. Er worden bij mij nooit entries uit /etc/hosts.youtube als antwoord aan de client gegeven (dat is ook een van de redenen dat ik geen verklaring vind, waarom het script werkt).

Nogmaals, vermoedens… Het is, bij mijn weten, niet mogelijk de cache van dnsmasq te bekijken, je weet dus nooit wat daar juist in zit. De code van dnsmasq uitpluizen om een sluitend antwoord te vinden, is een optie.

Als je met dit antwoord niet tevreden bent, stel ik voor dat je de vraag stelt aan Simon ([e-mail]), de developer van dnsmasq.

[jpgview]

rvk schreef op woensdag 20 mei 2020 @ 11:04:
Enige wat ik nog kan bedenken is na de "restartdns reload" eventjes de hele hosts.youtube parsen en van alle domeinen een ping opvragen. Want hoe meer domeinen in die host komen, hoe meer domeinen bij elke flush weer toegankelijk worden (ondanks dat ze in die host staan).

Om mijn theorie van hierboven te staven heb ik even het volgende gedaan (let op dit is géén oplossing om youtube ads te onderdrukken, video's zullen niet meer laden)

aan /etc/dnsmasq.d/99-youtube.grublets.conf volgende toegevoegd (tweede lijn):

addn-hosts=/etc/hosts.youtube
cname=r5---sn-5hne6nlr.googlevideo.com,r5.sn-5hne6nlr.googlevideo.com

na restart (dnsmasq) een dnslookup r5---sn-5hne6nlr.googlevideo.com
je krijgt nu onmiddelijk het correcte (geconfigureerde IP address), omdat dnsmasq geen forward hoeft te doen (alle info bekend in config files).

May 20 11:14:10 dnsmasq[31918]: query[A] r5---sn-5hne6nlr.googlevideo.com from 192.168.2.228
May 20 11:14:10 dnsmasq[31918]: config r5---sn-5hne6nlr.googlevideo.com is <CNAME>
May 20 11:14:10 dnsmasq[31918]: /etc/hosts.youtube r5.sn-5hne6nlr.googlevideo.com is 208.117.238.16
May 20 11:14:10 dnsmasq[31918]: query[AAAA] r5---sn-5hne6nlr.googlevideo.com from 192.168.2.228
May 20 11:14:10 dnsmasq[31918]: config r5---sn-5hne6nlr.googlevideo.com is <CNAME>
May 20 11:14:10 dnsmasq[31918]: /etc/hosts.youtube r5.sn-5hne6nlr.googlevideo.com is 2620:11a:a036::10

[jpgview]

nero355 schreef op maandag 25 mei 2020 @ 18:12:
Als ik heel eerlijk ben vind ik dat hele DNS over HTTPS gedoe maar een irritante hype en zou ik het liever kwijt dan rijk zijn als Pi-Hole + Unbound voorstander!

Freee!! schreef op maandag 25 mei 2020 @ 18:51:
[...]

AMEN!

DoH op de firewall blocken? Lees dit discourse topic. Niet voor alle gebruikers, maar voor diegenen die een firewall hebben die het aankan (pfsense, opnsense, …).

IPv4 en IPv6 lijsten worden dagelijks geupdate (indien er wijzigingen zijn).

Indien iemand een DoH lijst kent, die niet vermeld is, graag een seintje via GitHub issue.

[jpgview]

sapphire schreef op donderdag 28 mei 2020 @ 23:06:
Vanavond alle lijsten bijgewerkt, gravity geupdate, reset gedaan, router nagekeken, telefoon nagekeken (caches geleegd, ect) en gewoon nog ads

Geen idee of dit een oplossing is.
Op discourse zijn er ook een paar klachten over. Een user geeft aan dat hij pihole -r heeft gedraaid (full reinstall), en het privacy level heeft gewijzigd van level 5 naar level 0, probleem opgelost, lees hier.

Een aantal privacy levels zouden in v5.1 gewoon verwijderd worden, omdat ze blocking problemen veroorzaken (zie hier - GitHub). Alles over privacy levels... De documentatie is al aangepast.. Zelf draai ik pihole met privacy level 0, en heb geen enkel probleem met v5.0 (ik draai beta5 al sinds dag 1, nooit blocking problemen ondervonden;, een aantal devices zijn 24/7 actief).

Room42 schreef op donderdag 28 mei 2020 @ 23:07:
Als je DNS-over-HTTPS gebruikt, zal de Pi-hole genegeerd worden, ja.

zie mijn post van maandag, indien mogelijk, block DoH op je firewall... Je zal heel snel merken dat een device DoH gebruikt, omdat niets meer werkt (op dat device).

[ Voor 15% gewijzigd door jpgview op 28-05-2020 23:36 ]

[jpgview]

sapphire schreef op vrijdag 29 mei 2020 @ 20:23:
Geen helemaal verse install gedaan maar wel opnieuw en Privacylevel op 0 maar geen verandering

fsfikke schreef op vrijdag 29 mei 2020 @ 22:01:
Maar een ding snap ik niet, ik zie opeens weer overal (verschillende brosers) Google ads

TL;DR: zodra je onverwachte advertenties ziet, run (windows) ipconfig /all en controleer welke DNS servers het systeem gebruikt.

Als dit allemaal te ingewikkeld is, kan je ook overwegen een topic aan te maken op discourse, met een debug token erbij, de devlopers en moderators kunnen je log dan eens bekijken, en mogelijks een oorzaak aangeven. Voor het verzenden van het debug log moeten bepaalde outgoing ports op je firewall open zijn.

Vragen:
1. Gebruiken jullie windows 10
2. Indien ja, heeft dat device (windows 10) een IPv6 address.
3. Indien ja, zodra je een advertentie ziet, waarvan je zeker bent, dat die geblocked zou moeten zijn, run cmd en ipconfig /all en kijk naar de DNS servers

Lees verder als je op de twee eerste vragen ja hebt geantwoord, anders bied ook dit géén oplossing...

Reden voor de vraag.
Ik draai pihole, mijn DHCP server (niet pihole, maar dat doet er niet toe) geeft alleen een IPv4 address (pihole address) als DNS server uit. Mijn windows 10 machine krijgt van pfsense een IPv4 (DHCP) en IPv6 (track interface) GUA address.
Wanneer ik de machine opstart, en ik ipconfig /all run, toont deze als DNS alleen het IPv4 address van de pihole. Na verloop van tijd (nog steeds niet achterhaald wat de exacte trigger is) toont ipconfig /all een IPv4 DNS address (pihole address) EN een IPv6 DNS address. Blijkt nu dat er in IPv6 een mechanisme zit, dat er voor zorgt dat de client een IPv6 DNS server address krijgt (leert), ook als dat niet geconfigureerd is via DHCP.
Na onderzoek, op mijn eigen omgeving, bleek al snel dat de client (windows 10) het DNS IPv6 address dat de router (pfsense in mijn geval) gebruikt, verkreeg. Door er voor te zorgen dat pfsense het IPv6 address van mijn pihole als IPV6 DNS address ging gebruiken, was het probleem opgelost.

Ik ben mij die vraag beginnen stellen toen, op een keer mijn pihole een keertje down was (full rebuild - new OS), en ik op mijn windows 10 toch geen DNS errors kreeg (gewoon surfen as usual). Alle DNS queries werden gewoon opgelost door de IPv6 resolver die windows 10 geleerd had.

[ Voor 9% gewijzigd door jpgview op 29-05-2020 23:48 ]

[jpgview]

sapphire schreef op zaterdag 30 mei 2020 @ 00:14:
Nee die Windows 10 desktop heeft geen IPV6 adres en ja de PC (en alle andere apparaten for that matter) gebruiken als DNS de router die op zijn beurt ingesteld staat om de Pi-Hole te gebruiken.

Waarom gebruiken je apparaten de router als DNS, waarom configureer je de apparaten (DHCP) niet zo dat ze als DNS server de pihole gebruiken?

vb.
router 192.168.2.1
pihole 192.168.2.10

DHCP instellingen: DNS 192.1682.10

Zorg ervoor dat je slechts één DNS server opgeeft (DHCP configuratie). Als de router dat niet toelaat, vul dan twee keer het IP address van de pihole in. Als dat ook niet mogelijk is, geef dan je pihole een secondary IP address, zodat je er twee verschillende kan opgeven.
De benaming secondary DNS is vreselijk misleidend, er zijn tientallen topics op discourse, die dit aangeven. Als je een primary and secondary DNS opgeeft, zullen beide gebruikt worden…

Ik kan me niet voorstellen dat dit een pihole v5 bug is, Vier maanden beta test, door ervaren gebruikers, geen klachten. Als dit een bug zou zijn in de final release, zou discourse verzuipen in de topics over blocking problemen, dat is niet zo.

nero355 schreef op zaterdag 30 mei 2020 @ 00:44:
Wat ik wel heb gedaan bij mij meteen na de installatie : Alle bekende apparaten handmatig in een hernoemde Default Group gezet!

Alle apparaten, die niet als client zijn gedefineerd (group management) zijn per definitie member van the default group.
In mijn manual geef ik aan (sectie 9) hoe je een local LAN lijst kan maken, wat het probleem 'IP address i.p.v. device name' oplost. Ik weet dat er nu via met menu 'Local DNS Records' kunnen aangemaakt worden, maar die lijst voldoet niet aan de hosts file specification. In de manual, sectie 17.2 staat ook een script, om die lijst scripted te importeren in pihole.
Ik raad iedereen aan om DHCP fixed IP addressen te gebruiken (gebaseerd op het MAC address), om toekomstige ellende te voorkomen.

[ Voor 38% gewijzigd door jpgview op 30-05-2020 09:17 ]

[jpgview]

nero355 schreef op zaterdag 30 mei 2020 @ 18:27:
Dat is dus niet waar : Alleen de GUI moet daarop nog aangepast worden, maar volgens dit Topic is het verder geen probleem => https://discourse.pi-hole...al-dns-records-page/33124

Of bedoel je wat anders

uit de Wikipedia pagina:

The hosts file contains lines of text consisting of an IP address in the first text field followed by one or more host names. Each field is separated by white space – tabs are often preferred for historical reasons, but spaces are also used. Comment lines may be included; they are indicated by an octothorpe (#) in the first position of such lines. Entirely blank lines in the file are ignored.

Als je een hosts entry aanmaakt, via de web interface, word een entry IP, single space, name toegevoegd aan /etc/pihole/custom.list. System administrators gebruiken meestal een TAB om de verschillende velden te scheiden. Als je ook maar iets anders dan een single space gebruikt, of meerdere hostnames toevoegd, toont de web interface de entries niet meer.
Je geeft zelf aan dat er web interface aanpassingen nodig zijn, wat deze zullen inhouden is nog niet helemaal duidelijk. Als je het bestand begint te gebruiken, met een formaat, verschillend van het origineel, is het mogelijk dat, bij een volgende release de web interface crashed, omdat een en ander niet meer voldoet aan wat verwacht word. Ik wil niet de oorzaak zijn van crashende interfaces (of zelfs failed upgrades) in toekomstige releases, vandaar de aanbeveling om de feature niet te gebruiken.
Dat dnsmasq (pihole-FTL) het bestand wel correct verwerkt is logish, er word gewoon een standaard dnsmasq setting gebruikt (addn-hosts=/etc/pihole/custom.list in /etc/dnsmasq.d/01-pihole.conf), die het hosts format wel correct leest en verwerkt.
Ze zijn trouwens ook al bezig met een web interface voor CNAME entries, zie hier, hopelijk doen ze het deze keer een beetje meer in lijn met algemeen geldende Linux standaarden.

[jpgview]

MoiZie schreef op zaterdag 13 juni 2020 @ 20:10:
Wat blijkt; apache was default met php7.0 geinstalleerd. 'apt install php7.3' 'a2enmod php7.3 a2dismod php7.0' en alles werkt weer.

Pihole 5.0 vereist kennelijk php7.3 om de website goed te laten functioneren! Gek dat die bash dat niet ondervangt...

Je zou er goed aan doen om dit aan de developers te melden, op discourse of GitHub.

[jpgview]

Group Management is een prachtige uitbreiding, beschikbaar sinds pihole v5.0. De web interface echter, verplicht je om op verschillende pagina's (whitelist, blacklist, domains , clients, adlists) de nodige dingen te configureren, waardoor het vinden van een foute configuratie niet altijd even eenvoudig is, je kijkt er gewoon snel overheen, doordat er heel informatie op de veschillende pagina's te vinden is.

Zelf heb ik al tijd verloren, omdat ik een simple foutje gewoon niet zag, uiteindelijk lukt het wel…

Omdat, zeker voor nieuwe gebruikers, het niet altijd even eenvoudig is, foutjes te vinden, heb ik een script gemaakt, dat een poging doet om fouten te identificeren, je vind het hier. Lees ook de comments in het begin van het script...

Het script op je system zetten:

sudo wget https://raw.githubusercon...manual/master/diagnose.sh -O /home/pi/diagnose.sh
sudo chmod +x /home/pi/diagnose.sh

Om een en ander te testen, heb ik in mijn eigen omgeving een aantal fouten gesimuleerd, deze werden door het script allemaal geidentificeerd, maar elke omgeving is natuurlijk anders, geen idee of het script de fouten in jouw omgeving ook kan identificeren.

Het script doet geen wijzigingen aan je configuratie, het geeft allen maar hints over wat er mis is.
Het is niet nodig het script te runnen met sudo, er is slechts een commando dat met sudo word uitgevoerd (nmap), en dit alleen om een warning van nmap te vermijden.

Om een en ander te laten werken, is het nodig telnet en nmap op je system te instaleren (sudo apt-get -y install telnet nmap)

Telnet wordt gebruikt om de clients van de default group te vinden. Een client die je niet hebt gedefineerd in group management, is altijd lid van de default group.

Nmap wordt gebruikt om de clients van een client subnet entry te vinden. Als je een home network hebt met IP range 192.168.2.0/24, kan je een client entry aanmaken voor een subnet. Voorbeeld 192.168.2.224/31 Deze client subnet entry is een alternatief voor 2 client entries, nl. 192.168.2.224 en 192.168.2.225. Je kan heel eenvoudig onderzoeken over welke clients het gaat met het commando sudo nmap -sL -n 192.168.2.224/31

Gebruik je putty of OpenSSH? Het is nodig om je window size groot genoeg te maken (of full screen), anders maakt whiptail (de dialogs) er een zooitje van!

Het script kan op twee manieren gebruikt worden:

1. run ./diagnose.sh
Er word dan een analyse gemaakt van de keuzes die jij maakt, de summary geeft aan wat de resultaten van jouw keuzes zijn.

2. gebruik de output van pihole -q, voorbeeld pihole -q -exact -all eulerian.net | ./diagnose.sh
Het resultaat van de pihole -q search word gebruikt om een diagnose te stellen.

Het is niet alleen een zaak te kijken naar wat je ziet, ook wat je niet ziet is belangrijk.
- Je kan er van overtuigd zijn dat je een regex aan een group hebt toegewezen, als die group niet voorkomt in de lijst, is dat een mogelijke oorzaak van je probleem.
- Je kan er van overtuigd zijn dat je een client aan een group hebt toegevoegd,, als die client niet voorkomt in de lijst, is dat een mogelijke oorzaak van je probleem.

Het script is getest met Raspberry Pi OS (32-bit) Lite, Version: May 2020 op een Raspberry pi 3B
Gelieve eventuele bugs hier te melden, dit komt het overzicht ten goede. Ik onderzoek alleen problemen op hoger vermelde, gelijkaardige omgevingen, problemen op andere combinaties kan ik helaas niet testen.

Ik heb begrepen dat in pihole v5.1 group management diagnostics zullen toegevoegd worden aan de web interface, misschien maakt die toevoeging dit script overbodig…

[ Voor 4% gewijzigd door jpgview op 16-06-2020 12:51 ]

[jpgview]

iAR schreef op dinsdag 16 juni 2020 @ 11:44:
Ik zit nu al een tijdje op versie 5 en wil toch eens werk gaan maken van de client optie. Bijvoorbeeld, ik, mijn partner, en IoT. Die laatste zou ik dan willen onder verdelen in strict en minder streng. Mijn Dyson en Pi hoeven namelijk niet zo veel maar mijn Homey bijvoorbeeld wel (to be sure).

Iemand tips?

In mijn manual beschrijf ik een whitelist regex voorbeeld voor andoid devices (sectie 18), In dit document beschrijf ik hoe je googleads kan toelaten voor specifieke devices (solution for WAG complaints).

[jpgview]

Follow up on this article

versie 2 van dit script:
- bug fixes
- diagnose voor clients en groups (database) en discovered clients (telnet API).

Gelieve eventuele bugs hier te melden.

[jpgview]

excitative new feature in pihole v5.1 (en je kunt die feature nu al gebruiken).

In pihole v5.0 is er (voor mij) een groot dilemma:
Je moet een keuze maken of je een regex als whitelist OF als blacklist wil gebruiken.
Voorbeeld, een facebook regex:

^(.+\.)?(facebook|fb(cdn|sbx)?|tfbnw)\.[^.]+$

Waneer je voor bepaalde clients facebook wil blocken en voor andere clients facebook wil (moet) toelaten, moet je een keuze maken:
- regex als blacklist gebruiken (assign to default group), en individuele domains whitelisten, assign whitelisted domains to allowfacebook group (moeilijk, het aantal facebook domains is enorm groot)
- regex als whitelist gebruiken (assign to allowfacebook group, geen gezeur meer) en individuele domains blacklisten, assign blacklisted domains to default group (hopen dat je alles hebt opgelijst en geblacklist)

In pihole v5.1 is deze beperking weg, je kan nu een identieke whitelist en blacklist entry aanmaken
regex whitelist -> assign to group allowfacebook
regex blacklist -> assign to group default (of een andere group)
voeg nu de clients die facebook moeten kunnen gebruiken toe aan de group allowfacebook, klaar.

remember Whitelist always wins!

Wat je moet doen om dit met pihole v5.0 al te gebruiken.

WEES VOORZICHTIG, NAUWGEZET. GEBRUIK OP EIGEN RISICO, ADVANCED USERS ONLY!

- rename /etc/.pihole/advanced/Templates/gravity.db.sql naar gravity.db.bck (maak een backup
- download (sudo wget) https://raw.githubusercon.../Templates/gravity.db.sql (plaats het bestand in /etc/.pihole/advanced/Templates)

Je hebt nu twee bestanden met de naam gravity.db in /etc/.pihole/advanced/Templates (gravity.db.bck en gravity.db.sql). Controleer dit, controleer ook de permissions !!!



- run pihole -g

Zodra pihole -g klaar is kan je de hierboven beschreven (of gelijkaardig) configuratie gebruiken.



de regex whitelist en regex blacklist matches zijn identiek.

ongedaan maken?
- verwijder alle entries die in pihole v5.0 een conflict veroorzaken (niet mogelijk zijn)
- rename gravity.db.sql -> gravity.db.new
- rename gravity.db.bck -> gravity.db.sql
- pihole -g

mijn script, diagnose.sh, (lees hier) kan met deze nieuwe feature al overweg (vannacht aangepast en getest)

[jpgview]

briecht schreef op zondag 21 juni 2020 @ 11:18:
Mijn vriendin vraagt of het mogelijk is om google ads bij zoekresultaten toch toe te laten. Is het mogelijk om daar wel adds toe te laten maar ergens anders niet?

hier vind je een manual (en een script) met daarin de stappen, nodig om dit mogelijk te maken, voor één of meerdere clients. De whitelist entries gelden wel voor de client (IP address), niet specifiek voor de search engine dus ...

[ Voor 15% gewijzigd door jpgview op 21-06-2020 23:00 ]

[jpgview]

briecht schreef op maandag 22 juni 2020 @ 10:48:
[...]

Schitterend, merci!

Laat eens weten of de gewhiteliste domains correct zijn (of het werkt).

Er is namelijk een verschil tusen de domains die ik whitelist (overgenomen uit deze post) en de domains, vermeld in het discourse topic waar @nero355 naar verwijst.

Doel is om het aantal whitelist entries zo beperkt mogelijk te houden…

[jpgview]

Hier vermelde ik de mogelijkheid om met pihole v5.1 (nog niet gereleased, maar je kan de feature nu al gebruiken) duplicate whitelist/blacklist entries te gebruiken.

Hier vermelde ik een script om Group Management problemen op te sporen met behulp van een script (command line).

Dit script is nu uitgebreid om eventuele problemen met duplicate whitelist/blacklist entries op te sporen (whitelist always wins!). Run ./diagnose.sh (géén sudo nodig) en selecteer duplicate.

Uiteraard geeft dit alleen resultaten als je het v5.1 database schema gebruikt en duplicate entries hebt.

Je moet diagnose.sh EN duplicate.sh op je systeem plaatsen (ik zet ze gewoon beide in /home/pi)

[jpgview]

another excitative new feature in pihole v5.2 (en je kunt die feature nu al gebruiken).

lees hier

Basically komt het er op neer (eenvoudigste voorbeeld) dat, wanneer je een regex blacklist entry hebt aangemaakt voor b.v. www.google.com, je toch op die site geraakt door een (bewuste) typfout e.g. www.gogle.com (missing 'o'), en pihole dit niet kon blocken. Er zijn nogal wat websites die handig inspelen op typfouten, en zo DNS blockers proberen te omzeilen.
Door een regex met approximative matching te gebruiken, kan je er voor zorgen dat dit niet meer door de mazen van het net zal glippen.

Je kan de binary (pihole-FTL) nu ook gebruiken om te testen of er een hit is voor een bepaald domain (vergelijkbaar met pihole -q), maar, let wel, alleen de eerste whitelist en blacklist entry match worden getoond. Voorbeeld:

pihole-FTL regex-test "facebook.com"

Wat je moet doen om dit met pihole v5.0 al te gebruiken.

pihole checkout ftl new/tre-regex

ongedaan maken?
- verwijder alle entries die in pihole v5.0 een conflict veroorzaken (niet mogelijk zijn)
- pihole checkout ftl master

[jpgview]

pihole v5.0 crashes? kijk eens hier of je de situatie herkent. De pihole-FTL code is gebaseerd op de code van dnsmasq, sterker nog, wanneer er een nieuwe versie van dnsmasq wordt gereleased, zal de code van pihole-FTL volgen, dit om het mogelijk te maken custom configs te maken, aan de hand van deze guide.

Blijkt nu dat in de laatste versie van dnsmasq (v2.81) een bug zit, die crashes veroorzaakt. Hier word aan gewerkt, het zal in pihole v5.1 opgelost zijn.

Echt niet te doen (te veel crashes)? gebruik een beta versie van pihole-FTL, waarmee het probleem waarschijnlijk mee verdwijnt. Er zijn verschillende branches waar je uit kan kiezen, zie hier. De branch update/dnsmasq-v2.82 lijkt mij mogelijkerwijs een oplossing (samenwerking pihole developers en dnsmasq developer Simon Kelley)

Om over te schakelen op een test branch (voorbeeld):

pihole checkout ftl update/dnsmasq-v2.82

Let wel, voor je een upgrade naar pihole v5.1 doet, moet je eerst dit doen:

pihole checkout ftl master

[ Voor 28% gewijzigd door jpgview op 01-07-2020 10:35 ]

[jpgview]

Videopac schreef op woensdag 1 juli 2020 @ 13:21:
Ik heb (weer) problemen dat youtube filmpjes niet meer werken. Ik heb een stukje uit de log gedestilleerd, maar kan het niet interpreteren en dus het probleem niet oplossen.

de output die je post toont geen problemen.

om problemen met blocked sites snel te pakken te krijgen draai ik dit scriptje, veroorzaak het probleem (met de browser), en stop het script (CTRL-C). Het probleem zit er dan meestal tussen.

#!/bin/bash

logfile=/var/log/pihole.log

tail -F $logfile | grep --line-buffered "is 0.0.0.0\|is ::" | \
while read x; do
echo "$x"
done

edit
het script vind geen problemen (blocked domains), veroorzaakt door deep CNAME inspection, feature request hier.
/edit

[ Voor 13% gewijzigd door jpgview op 02-07-2020 10:25 ]

[jpgview]

Anoniem: 111246 schreef op zaterdag 4 juli 2020 @ 18:04:
Dat heb ik op mijn OnePlus ook.
Heb het opgelost door mijn PiHole zowel via LAN als WiFi aan te sluiten op mijn netwerk.
De twee IP's heb ik dan in DHCP opgegeven.
En weg was de Google DNS op mijn telefoon.

2x hetzelfde IP werkte niet.

prima oplossing, maar het kan ook eenvoudiger:
pihole luistert op een bepaalde interface (bij mij interface=eth0 in /etc/dnsmasq.d/01-pihole.conf)
door een secondary IP address toe te voegen heb je ook twee IPs ter beschikking en word alles via ethernet afgehandeld.

de eenvoudigste manier om een secondary IP toe te voegen (Raspberry Pi OS (32-bit) Lite - may 2020):
- maak een bestand /etc/dhcpcd.exit-hook (naam is belangrijk, niet wijzigen)
- content (wel IP, mask en interface aanpassen):

#add secondary IP address
if [ "$reason" = "PREINIT" ]; then
sudo ip -4 addr add 192.168.2.47/27 dev eth0 label eth0:1
exit 0
fi

-reboot

[jpgview]

Hier heb ik al melding gemaakt van een nieuwe feature, die er mogelijks aankomt (approximative matching).

De ontwikkeling gaat onvermoeid verder, in dezelfde branch (pihole checkout ftl new/tre-regex) word het nu mogelijk om bepaalde types queries te blocken, lees hier. Een user maakt hier melding van het feit dat zijn chromecast AAAA queries doet in een IPv4 only network omgeving. Deze nieuwe feature maakt het mogelijk om dit type queries (AAAA) te blocken, de A queries worden wel gewoon doorgelaten.



edit
nog een wijziging, optie invert, het resultaat van een regex, lees hier.
hoe werkt invert?
- pihole-FTL evalueert de regex e.g. ^abc$;querytype=a
- pihole-FTL inverts het resultaat (match -> no match, no match -> match)
ik heb hiervoor nog geen nuttige toepassing gevonden


/edit

edit2
nog een toevoeging, NOT querytype, dus, voorbeeld hieronder, geen AAAA, PTR, NS, ...


Ik heb een aantal devices aan de allowAqueriesonly groep toegevoegd en test het resultaat (ongoing). een PS4 kan blijkbaar zonder problemen met deze beperking omgaan (PS4 in een IPv4 only omgeving doet toch AAAA queries), test loopt nog op andere devices, maar eerste resultaten zijn positief.
/edit2

[ Voor 40% gewijzigd door jpgview op 10-07-2020 09:57 ]

[jpgview]

Er is een oplossing in de maak voor mensen die problemen hebben met deep CNAME inspection blocks (nieuwe feature sinds pihole v5.0). Lees het hele verhaal (feature request) hier, voor comments vanaf de aankondiging van de test, begin hier te lezen.

basically komt het er op neer dat er nu log entries zijn (/var/log/pihole.log) en dat de info niet langer verloren is na een restart van pihole-FTL (of een reboot).

Er is een test branch, om dit te uit te proberen (testers gezocht, graag ook feedback in het topic).

overschakelen op die branch (let op, als je al in een andere branch dan master zit, zijn alle opties van die nieuwe branch mogelijks niet beschikbaar, zie ook de comment van DL6ER in het topic:

pihole checkout ftl new/cname_inspection_logging

er word nog stevig aan gewerkt, dus regelmatig pihole -up uitvoeren, en het topic volgen...

terug naar de officiele branch (zeker uitvoeren voor een upgrade naar pihole v5.1 - hopefully coming soon)?

pihole checkout ftl master

[jpgview]

De hier vermelde feature (duplicate blacklist / whitelist regex) is nu beschikbaar, pihole v5.1.1 werd deze nacht gereleased.

Niet helemaal duidelijk? Stap voor stap handleiding in mijn manual (chapter 19).

[jpgview]

Op donderdag pihole v5.1.1 opnieuw geinstalleerd
Na de wekelijkse update van de adlists (wordt door cron automatisch gestart), zie ik in /var/log/pihole_updateGravity.log een foutmelding:

/usr/local/bin/pihole: line 129: service: command not found

Ik heb een halve dag besteed aan het zoeken van een oorzaak en een oplossing, lees hier, maar de moderators / developers vinden die fout niet (kunnen ze niet repliceren).
Nu wil ik graag weten of andere gebruikers die foutmelding ook hebben (in het log).
Als dat zo is, graag melden in het topic, alleen wanneer meerder users dit aanmelden, word er verder onderzoek gedaan.

Met dank voor de eventuele reacties (in het topic)

[jpgview]

@CH4OS hier? Gaat over YouTube add blocking, maar dat script schrijft niet naar sqlite3, flat file...

[jpgview]

beerns schreef op maandag 20 juli 2020 @ 10:23:
[...]
Jep. ook hier. Precies dezelfde melding

Volgens mij wordt daardoor pihole-FTL niet op de hoogte gebracht van de nieuwe / gewijzigde gravity entries (entries in de adlists), en word dus de data van vorige week gebruikt (geen updates meer). Natuurlijk zal sudo pihole-FTL stop && sudo service piholeFTL start dit oplossen, maar dat moet je dan wekelijks doen (zondag ochtend), dit kan niet de bedoeling zijn.

Mag ik je vragen dit ook te melden in het topic, waar dit al besproken word, kwestie van de developers duidelijk te maken dat dit géén aleenstaand geval is?

Met dank

Als oplossing heb ik een tijdelijke fix getest, één commando, maar dit zou eigenlijk overbodig moeten zijn:

# symbolic link for service
# https://discourse.pi-hole...e-updategravity-log/35862
sudo ln -s /usr/sbin/service /usr/local/bin/service

dit werkt op Raspberry Pi OS (previously called Raspbian) en gaat er vanuit dat de service binary te vinden is in /usr/sbin

om de locatie van de service binary op jouw systeem te vinden, het volgende commando:

which service

Nadat je de symbolic link hebt aangemaakt (eerste commando) zal de nieuwe locatie worden aangegeven (/usr/local/bin/service)

[ Voor 17% gewijzigd door jpgview op 20-07-2020 11:23 ]

[jpgview]

Anoniem: 736981 schreef op maandag 20 juli 2020 @ 11:41:
'connectivitycheck.gstatic.com'

'connectivitycheck.gstatic.com' word onder andere gebruikt door Chromecast (in mijn omgeving). Als je die blocked, geeft de Chromecast aan dat je géén internet verbinding hebt.



Er zijn in het verleden verschillende pogingen gedaan om dit te omzeilen, toch te blocken, mits lokaal alternatief, maar dat lukt alleen als het device een http request doet naar het domain, zodra het device de https methode gebruikt, faalt dit, wegens géén certificaat.

ninjazx9r98 schreef op maandag 20 juli 2020 @ 11:14:
[...]

Voor $PATH kom ik dan op "/usr/bin:/bin" zonder "/usr/local/bin" dus daar maak ik even een denk of typefoutje maar in ieder geval staat "/usr/sbin" er niet bij.

Je maakt geen denkfout, volgens wat ik gelezen heb, hier, heeft cron een hardcoded path in de binary, ik heb het ook getest, het klopt, lees hier.

[ Voor 24% gewijzigd door jpgview op 20-07-2020 12:06 ]

[jpgview]

ninjazx9r98 schreef op maandag 20 juli 2020 @ 13:53:
[...]
Zit net ook nog even wat te lezen op discourse en het lijkt er op dat er deels langs elkaar heen gepraat wordt. Bij jou wordt de service herstart om welke reden dan ook terwijl yubiuser het heeft over een reload van DNS.

Dat is helaas, waar ik al jaren mee moet omgaan, ik ken zelfs users, die overgeschakeld zijn naar adguard home, omwille van de negatieve houding van sommige (niet allemaal) developers en moderators. Heel vermoeiend soms, daarom is het zo belangrijk dat meerdere users dit aanmelden, maakt het veel moeilijker om te negeren.

ninjazx9r98 schreef op maandag 20 juli 2020 @ 13:53:
[...]

code:

PATH=/bin:/usr/bin:/my/path/bin
5 3 * * * command_that_requires_my_path

Bron: https://unix.stackexchang...set-crontab-path-variable

Iets gelijkaardig had ik ook gevonden, lees hier, nadeel is dat je dat moet toevoegen aan de cron job, die word bij elke pihole -up of pihole -r overschreven, dus elke keer opnieuw aanpassen…

edit
Ik heb een deel van jouw bevindingen overgenomen op discourse (topic), kan je helaas niet bij naam vermelden, geen idee of je daar ook een account hebt. Toch bedankt voor de nuttige info.
/edit

[ Voor 10% gewijzigd door jpgview op 20-07-2020 15:57 ]

[jpgview]

CH4OS schreef op maandag 20 juli 2020 @ 18:09:
[...]
ik heb het script gevonden.

lijkt verdacht veel op het script uit mijn pihole manual (sectie 15, deep cname inspection). Je kan trouwens alle scripts uit de manual op GitHub vinden.

@beerns @ninjazx9r98
Het probleem met de weekly gravity update, hier besproken op het forum, hier op het pihole forum heeft een, door een pihole developer aangereikte oplossing, lees hier.

[jpgview]

CH4OS schreef op maandag 20 juli 2020 @ 21:15:
[...]
Is er een vergelijkbaar script beschikbaar voor YouTube ads?

geen vergelijkbaar script voor YouTube. Het hele YouTube script, zoals het hier een tijd geleden op het forum werd besproken, werkt volgens mij niet op lange termijn. Het zal, naar alle waarschijnlijkheid, een tijdje goed gaan, na verloop van tijd begin je domains met echte content te blokeren. Dan moet je ofwel opnieuw beginnen (lege lijst), ofwel beginnen whitelisten. Zelf gebruik ik gewoon ublock origin, en heb zelden last van YouTube ads.

[ Voor 39% gewijzigd door jpgview op 20-07-2020 21:32 ]

[jpgview]

beerns schreef op dinsdag 21 juli 2020 @ 08:13:
Ik zag het. Volg mij heb jij een vergelijkbare vraag als ik: hoe voer je de fix uit

@Church of Noise @beerns

gelukkig is nu DL6ER betrokken bij het probleem en toont er intresse voor. Dit is de aangewezen persoon voor het oplossen van problemen. Na twee dagen zoeken, en het gevecht op het forum om het probleem acknowledged te krijgen, heb ik er eindelijk goede hoop in dat het ooit wel opgelost zal geraken.

Voor de andere lezers, hier heb ik aangegeven wat je moet doen om de oplossing, voorgesteld door een developer, te implementeren. Let wel pihole -up of pihole -r (en voor testers pihole checkout, als de core ook geupdate wordt) verwijderen die aanpassing, je moet ze dan opnieuw implementeren, dit zolang todat een definitieve oplossing in pihole v5.x beschikbaar wordt.

[jpgview]

beerns schreef op dinsdag 21 juli 2020 @ 08:54:
de fiks werkt niet bij mij.

het log bestand word alleen geupdate wanneer het script uitgevoerd word met cron.
kijk naar de tijd van het bestand:

ls -l /var/log/pihole_updateGravity.log

Het probleem zal worden opgelost in pihole v5.1.2, code hier, zoals aangegeven door developer DL6ER

[ Voor 44% gewijzigd door jpgview op 21-07-2020 21:51 ]

[jpgview]

TomGear schreef op dinsdag 21 juli 2020 @ 22:00:
is er hier een andere manier voor zonder dhcp op mijn modem uit te zetten ?

Lees een mogelijke oplossing in mijn manual, sectie 9 (Adding a local LAN list)

Ik gebruik zelf deze oplossing, en geef de voorkeur aan die oplossing boven de pihole oplossing (local dns records), omdat de oplossing full hosts file compatibility heeft.

Het is wel aan te raden om dan in je router entries aan te maken, gebaseerd op MAC address, zodat je met zekerheid steeds hetzefde IP krijgt aangeboden.

[jpgview]

Church of Noise schreef op woensdag 22 juli 2020 @ 07:36:
Zitten die laatste veranderingen nu in de Dev versie? Want toen ik die vanochtend updatete, was er een update voor het Web deel

Er zijn drie repositories voor pihole op GitHub:
- core (daar zitten de nieuwe bestanden in), je vind die terug in /etc/.pihole, die locale copy wordt door de installer gebruikt voor pihole -up of pihole -r
- web, wordt rechstreeks gecloned in /var/www/html
- FTL, bevat de code voor de fork van dnsmasq, die pihole gebruikt, alleen de binary wordt op je system gezet

dus, nee, de web update vanochtend heeft die nieuwe bestanden niet toegevoegd.

zelf draai ik nooit dev, omdat je re meestal geen idee van hebt, wat er nu wel en niet in zit. Ik beperk mij tot het gebruik van speciefieke branches, die een specifiek problem oplossen, waar ik ook hinder van ondervind, meestal op verzoek van DL6ER, om een en ander te testen.

Voor dit specifieke geval, heb ik de 4 gewijzigde files uit de repository geplukt en op mijn system gezet, lijkt goed te werken. Let op! Als je dat ook wil doen, altijd eerst de bestaande versie dupliceren (WinSCP of iets dergelijks) daarna de bestanden vervangen. contoleer steeds permissions, owner en group als je dit doet, anders loopt het fout.

[jpgview]

sOid schreef op woensdag 29 juli 2020 @ 17:23:
[...]


Ik heb dit in mei gebookmarkt maar ben er nog niet aan toe gekomen. Werkt dit nog steeds goed? Met andere woorden: is het de moeite waard om hier een uurtje in te steken om het te implementeren?

Nee, na verloop van tijd begin je ook content te blokkeren. Ik heb deze methode getest, maar helaas, voor mij is ublock origin (op PC) de oplossing.

[jpgview]

basown13 schreef op woensdag 29 juli 2020 @ 18:10:
Vraagje ik heb het script nu op mijn pihole draaien en de pihole draait op mijn synology nas in docker.

Alleen zie ik in de Query lijst dat er meerdere XXXXX.googlevideo.com zijn , met verschillende ipadressen.
Kan ik in het sh script meerdere ipadressen toevoegen?
r2---sn-j5pfqpxonuxo-guhl.googlevideo.com
r1---sn-5hne6ns6.googlevideo.com

deze ben ik nu tegengekomen. misschien met ip,ip,ip ?


[...]

voor zover ik het begrijp is het net de bedoeling van alle domains naar hetzelfde IP om te leiden (forceIP="123.456.789.999" in het originele script).

de enige mogelijkheid, om meerder IP's als resultaat weer te geven zou (nooit getest) de alias optie van dnsmasq (zie man) kunnen zijn, maar dan wordt het wel heel complex.

Nogmaals, ik heb dit van mijn systeem verwijderd, omdat, na verloop van tijd content (filmpjes) worden geblocked, en doe hier géén verder onderzoek naar.

Ander onderwerp…

Zeer interessante bevinding van een tweaker (@Raymond Deen) over chrome / edge, lees hier. Don't use chrome ???

edit
- Ook gemeld op het pihole forum. Oorzaak DoH (DNS over HTTPS)?
- Firefox 79 zet blijkbaar DoH nu ook aan, gemeld op reddit
/edit

[ Voor 21% gewijzigd door jpgview op 29-07-2020 23:26 ]

[jpgview]

hp-got schreef op zondag 9 augustus 2020 @ 15:31:
de vraag is hoe ik de boekhouding van Pi-hole zo inricht dat alle apparaten met hetzelfde MAC adres op één hoop geveegd worden in plaats van dat elk IP adres apart in de overzichten verschijnt.

lees hier, in ontwikkeling, als je beta tester wil zijn, zullen de developers je dankbaar zijn.

let wel, ikzelf gebruik het niet, omdat het voor mij geen zin heeft (pihole ziet de MAC addressen van de clients niet), dus NOOIT GETEST

om te zien of het zin heeft, volgende commando's op je pi uitvoeren:

- arp -a
- ip neigh

als je al je devices dan ziet te voorschijn komen (de MAC addressen) kan het, zie je ze niet, heeft het geen zin.

[jpgview]

De lijst van tweaker sjhgvr heeft op het pihole forum zojuist de status questionable verkregen, lees hier.

Hoewel ik het dikwijls oneens ben met de comments en solutions van deze moderator, moet ik het bij deze toch wel eens zijn dat een lijst van excluded (whitelisted) domains, toegevoegde waarde zou hebben (als die al niet bestaat, nooit achter gezocht).

Verder draai ik regelmatig een script, dat de toegevoegde waarde van adlists aangeeft, voor zover mogelijk.
Ik heb pihole vorige nacht opnieuw geinstaleerd en gebruik de setting MAXDBDAYS=3 (/etc/pihole/pihole-FTL.conf), de resultaten zijn dus altijd beperkt, maar, om er een paar voorbeelden uit te halen:

| hits | unique | adlist
| 9 | 0 | https://raw.githubusercon...nBlack/hosts/master/hosts
| 6 | 0 | https://dbl.oisd.nl
| 10 | 3 | https://raw.githubusercon...list/master/adservers.txt
| 10 | 0 | https://raw.githubusercon...rgon/hostsVN/master/hosts
| 4 | 0 | https://winhelp2002.mvps.org/hosts.txt
| 15 | 4 | https://www.github.develo...and-tracking-extended.txt

De laatste versies van pihole bieden slechts twee lijsten aan, de StevenBlack list is er één van, en heeft meer matches (hits) dan de oisd lijst, ook een paar andere lijsten hebben meer matches.

Het script (experimental, thus not published) kijkt hoeveel queries (pihole-FTL.db) matching adlists entries hebben.

Als je een lijst zou verwijderen met een unique count, hoger dan 0, zijn er domains die niet langer geblocked worden. De (beperkte - nieuwe install) test toont aan dat ik de oisd lijst zou kunnen verwijderen, zonder domain blocking te beinvloeden. Natuurlijk zal dit resultaat verschillen voor iedere pihole installatie, het is een weergave van de lijsten die ik gebruik EN mijn surf gedrag.

De oisd lijst werkt, maar is zeker niet zalig makend.

edit
unique test toegevoegd
/edit

[ Voor 17% gewijzigd door jpgview op 10-08-2020 12:17 . Reden: added unique ]