[Pi-Hole] Request in log die niet van mij zijn

[period!]

Vraag, (misschien niet helemaal pihole)
setup:
Bij mijn vorige iteratie van de 2e rpi 3b+ setup had ik een 64 bit image gebruikt. (van hier downloads.raspberrypi.org)
Basis setup met pihole en unbound, en een docker container met een tor proxy.
zelfde instellingen als mn 32 bit image.
De tor proxy gebruikt tor upstream dns.
Mijn router setup forceerd met 2 nat regels dns requests naar de piholes.

Ik zat te kijken naar de query log en zag dns requests voorbij komen die van die loclhost afkomstig leken die iig niet van mij kwamen, een webserver van iemand, die ssh brute force attacks met geolocatie plotte, en andere vreemde zaken.
Heb zeker ook geen dns relay, althans, niet via mn router.

Ik kon het niet verklaren en heb eerlijk gezegd niet veel onderzoek gedaan, maar zou dat met die tor proxy van doen hebben? zou vreemd zijn draai nu in mij overtuiging precies de zelfde setup maar dan op 32 bit.
Daar schiet mijn kennis te kort.
Ik had, voor de volledigheid bij, de tor proxy eerst de pihole als dns ingesteld maar dat was een overduidelijke dns leak.

Iemand die dit kan duiden?

[ Voor 5% gewijzigd door period! op 08-06-2021 00:12 ]

[deHakkelaar]

Als je het niet uit de logs kan halen:

pi@ph5b:~ $ apt show auditd
[..]
Description: User space tools for security auditing
 The audit package contains the user space utilities for
 storing and searching the audit records generated by
 the audit subsystem in the Linux 2.6 kernel.
 .
 Also contains the audit dispatcher "audisp".

pi@ph5b:~ $ apt-file list auditd
[..]
auditd: /sbin/auditctl

https://blog.frankreimer.de/?p=832

EDIT: ow je zal waarschijnlijk arch=b64 moeten veranderen naar arch=arm64 of mogelijk zelfs:

pi@ph5b:~ $ arch
armv6l

... weet niet zeker.

code:

man auditctl

EDIT2: correctie voor 64 bits arm64 ipv 32 bits armhf
Maar is die 64 bits versie niet gewoon nog in beta?

[ Voor 32% gewijzigd door deHakkelaar op 07-06-2021 15:59 ]

[period!]

Dank je voor de pointer naar auditd en het artikel.
Ik heb de manpages snel gelezen ,daar kan wel wat mee.

Ja het is een beta image, daarom ben ik ook snel terug gegaan. Maar het laat me toch niet los.
Zal de image nog is opstarten, auditd loslaten, en kijken wat ik kan vinden.

[laurens0619]

Ben je niet per ongeluk een tor exit node?

[period!]

Volgens de maker van de container niet.

NOTE 1: this image is setup by default to be a relay only (not an exit node)

ik heb daar verder niet mee gerommeld
https://hub.docker.com/r/dperson/torproxy/

Maar idd, de hoofdverdachte is wat mij betreft nog even tor, of misschien privoxy of eigen stommiteit voor dat ik aan os bugs ga denken. Daarom wil ik ook graag weten wat er aan de hand is.
Zeker omdat ik deze container nu ook nog draai in een andere omgeving, zonder klachten overigens.

[ Voor 29% gewijzigd door period! op 07-06-2021 19:58 ]

[geenwindows]

heb je eens gekeken met Tor Metric of je je node kan vinden?: (nicknaam staat in de torrc bestand.)
https://metrics.torproject.org/rs.html#simple

Ik kan op de docker en github pagina niet zien wat de torrc bestand er ongeveer uit ziet, "torrc" bestand is de configuratie van de node. er zijn online voorbeelden te vinden van relay, brigde relay en exit nodes configuraties.
https://community.torproject.org/relay/setup/

zolang er geen "ExitRelay 1" in staat ben je geen exit node.

[period!]

Ik heb m'n image weer geflasht en geboot, maar de dperson/torproxy container start niet eens meer en geeft een exit code 134. Ook met een verse pull het zelfde resultaat.
Op de github pagina staan ook wat vegelijkbare klachten.

Als test een andere tor-proxy gepulled (avpnusr/torprivoxy) , geen enkel probleem
Dns requests van de localhost zien er ook gezond uit.
Ook met andere containers geen problemen.

Maargoed verdere tests met dperson/torproxy zijn onmogelijk.