Hoe verdacht netwerkverkeer herleiden?

[Sharky]

Ik maak thuis gebruik van een Unifi Security Gateway (USG 3P, ouder model dus) met daarachter 2 TP Link switches en 2 Unifi AP's. DNS requests worden afgevangen door Adguard in een Docker op mijn NAS. Op dezelfde NAS draait de Unifi Network Application en alles is up to date.

Zo nu en dan kijk ik in de stats van Adguard en ik zag extreem wel verkeer (duizenden requests) naar gdb.voanews.com. Geen idee waar dit vandaag komt maar het werd doorgelaten dus ik heb het meteen in de blocklist van Adguard gezet. Dit was een week geleden, en ik zie nu dat er nog steeds heel veel requests worden gedaan, maar die worden geblokkeerd. De herkomst is 192.168.1.1, de gateway dus.

Hoe kan ik het zo configureren dat ik zie van welk device dit komt? Ik heb overal antivirus draaien, maar dit lijkt me nogal verdacht.

Wat betreft DHCP: ik heb in de Unifi software onder settings>internet handmatig ingesteld dat de DNS server 192.168.1.4 is, oftewel het adres van mijn NAS met Adguard.

Ter illustratie:

[TommieW]

Ik denk dat je nu in Unifi geconfigureerd hebt staan dat de USG zichzelf meegeeft als DNS server en deze de lookups doorstuurt naar je Adguard. Je kan ook je Adguard meegeven als DNS server in je DHCP server. Dat zit in Unifi --> Settings --> Networks --> <je netwerk> --> DHCP Service management (onderaan, uitklappen) --> DNS Server.

[Sharky]

TommieW schreef op maandag 11 november 2024 @ 12:37:
Ik denk dat je nu in Unifi geconfigureerd hebt staan dat de USG zichzelf meegeeft als DNS server en deze de lookups doorstuurt naar je Adguard. Je kan ook je Adguard meegeven als DNS server in je DHCP server. Dat zit in Unifi --> Settings --> Networks --> <je netwerk> --> DHCP Service management (onderaan, uitklappen) --> DNS Server.

Die had ik over het hoofd gezien, thanks. Wat ik heb ingesteld onder 'settings>internet' kan ik die dan weer beter op 'auto' zetten of zo laten als het nu is en ook handmatig naar Adguard laten verwijzen?

[TommieW]

Sharky schreef op maandag 11 november 2024 @ 12:41:
[...]


Die had ik over het hoofd gezien, thanks. Wat ik heb ingesteld onder 'settings>internet' kan ik die dan weer beter op 'auto' zetten of zo laten als het nu is en ook handmatig naar Adguard laten verwijzen?

Mooi, graag gedaan! Dat maakt niet heel veel uit. Die DNS Server wordt ook gebruikt voor resolving binnen de USG zelf, bijvoorbeeld software updates. Ik vertrouw de DNS server van m'n provider niet echt helemaal, dus ik heb 'm zelf op iets anders staan.

[laurens0619]

Staat je USG niet per ongeluk DNS verzoeken te accepteren vanaf internet?

[Sharky]

laurens0619 schreef op maandag 11 november 2024 @ 12:56:
Staat je USG niet per ongeluk DNS verzoeken te accepteren vanaf internet?

Ik heb geen forwards ingesteld en diensten die ik wel van buitenaf wil benaderen zitten achter een reverse proxy. DNS is alleen lokaal benaderbaar.

[laurens0619]

Sharky schreef op maandag 11 november 2024 @ 13:06:
[...]


Ik heb geen forwards ingesteld en diensten die ik wel van buitenaf wil benaderen zitten achter een reverse proxy. DNS is alleen lokaal benaderbaar.

Belangrijkste is eerst idd de clients direct te communiceren met je dns server ipv de USG. Als het goed is zag je nu alleen 1.1 als client in adguard omdat al je verkeer via de USG liep. Dat maakt de analyse lastig

Probleem met DNS op de router is dat het een ingebouwde service heeft en geen port forward. Je zou niet de eerste zijn dat DNS onbewust open staat op de wan kan en misbruikt wordt voor dns amplification attacks.
Tegelijk het kan ook prima vanaf intern komen/legitiem zijn. Ik zou sowieso een port scan vanaf internet doen op je wan ip om te bevestigen dat het dicht staat

Bv via http://en.dnstools.ch/port-scan.html

[ Voor 3% gewijzigd door laurens0619 op 11-11-2024 13:25 ]

[Sharky]

laurens0619 schreef op maandag 11 november 2024 @ 13:20:
[...]

Belangrijkste is eerst idd de clients direct te communiceren met je dns server ipv de USG. Als het goed is zag je nu alleen 1.1 als client in adguard omdat al je verkeer via de USG liep. Dat maakt de analyse lastig

Probleem met DNS op de router is dat het een ingebouwde service heeft en geen port forward. Je zou niet de eerste zijn dat DNS onbewust open staat op de wan kan en misbruikt wordt voor dns amplification attacks.
Tegelijk het kan ook prima vanaf intern komen/legitiem zijn. Ik zou sowieso een port scan vanaf internet doen op je wan ip om te bevestigen dat het dicht staat

Bv via http://en.dnstools.ch/port-scan.html

Volgens die scan zit alles gelukkig helemaal dicht, ook DNS

eric.1 schreef op maandag 11 november 2024 @ 13:29:
Even los van het technische vraagstuk:

"voanews.com" is volgens mij gewoon een deugdelijke nieuws-organisatie. Heeft/had iemand niet gewoon een verkiezings-poll open staan o.i.d.? Al dan niet via een standaard start-pagina van een browser.

Volgens mij is de site zelf inderdaad niet onbetrouwbaar. Maar als er een Russiche bot op mijn netwerk zit die een ddos probeert uit te voeren ben ik ook niet heel gelukkig.

laurens0619 schreef op maandag 11 november 2024 @ 14:17:
[...]

Zou prima kunnen maar het domein heeft (nu) een TTL van 15 minuten. Ik weet dat niet ieder OS/forwarder hier netjes mee omgaat maar “duizenden” wat de TS schetst vind ik wel veel voor legitieme dns lookups

Stipt elke 10 seconden.

Toevoeging: Ik zie een aantal devices nu in de overzichten met hun eigen ip, als alle leases zijn vernieuwd ga ik ervan uit dat 192.168.1.1 vrijwel volledig verdwijnt, dat zie ik morgen dan wel weer.

[ Voor 48% gewijzigd door Sharky op 11-11-2024 14:56 ]

[eric.1]

Even los van het technische vraagstuk:

"voanews.com" is volgens mij gewoon een deugdelijke nieuws-organisatie. Heeft/had iemand niet gewoon een verkiezings-poll open staan o.i.d.? Al dan niet via een standaard start-pagina van een browser.

[laurens0619]

eric.1 schreef op maandag 11 november 2024 @ 13:29:
Even los van het technische vraagstuk:

"voanews.com" is volgens mij gewoon een deugdelijke nieuws-organisatie. Heeft/had iemand niet gewoon een verkiezings-poll open staan o.i.d.? Al dan niet via een standaard start-pagina van een browser.

Zou prima kunnen maar het domein heeft (nu) een TTL van 15 minuten. Ik weet dat niet ieder OS/forwarder hier netjes mee omgaat maar “duizenden” wat de TS schetst vind ik wel veel voor legitieme dns lookups

[hcQd]

laurens0619 schreef op maandag 11 november 2024 @ 14:17:
[...]

Zou prima kunnen maar het domein heeft (nu) een TTL van 15 minuten. Ik weet dat niet ieder OS/forwarder hier netjes mee omgaat maar “duizenden” wat de TS schetst vind ik wel veel voor legitieme dns lookups

Waarschijnlijk zijn het er nu duizenden omdat TS het domein heeft geblokkeerd.

[Sharky]

The plot thickens. Adguard ziet nu welk device telkens deze site wil bezoeken, en het zijn mijn AP's Het zijn ze ook gewoon beide en beide elke 10 seconden op hetzelfde moment. Ik heb eentje al een reboot gegeven (stroom eraf) maar hij blijft het gewoon doen. Kan iemand dit verklaren?

Adguard:



Unifi network application:

[laurens0619]

Welke dns adressen zie je op de verbonden clients? Geen idee of een unifi ap ook dns forwarder kan spelen?

[sOid]

Ik heb het al even niet gebruikt; maar kun je dit niet goed onderzoeken door Wireshark te gebruiken?

[Sharky]

laurens0619 schreef op maandag 11 november 2024 @ 21:15:
Welke dns adressen zie je op de verbonden clients?

Deze vraag volg ik niet helemaal.

sOid schreef op maandag 11 november 2024 @ 23:01:
Ik heb het al even niet gebruikt; maar kun je dit niet goed onderzoeken door Wireshark te gebruiken?

Mijn netwerkkennis is beperkt dus tools als Wireshark zijn wat te hoog gegrepen.

Ik zie nu ook ander verkeer dat ik niet kan plaatsen, of het echt van de AP komt weet ik niet, maar Adguard denkt van wel. Dit gaat ook onafgebroken door.

[laurens0619]

@Sharky
Ik bedoel wat zie je bij clients die met wifi verbonden zijn bij de ip configuratie
dus in cmd: ipconfig /all

en dan kijken wat er ingevuld staat als DNS server

[MasterL]

Unifi AP's hebben standaard TCPdump aan boord (althans mijne) log eens in op je AP's (ssh, zelfde credentials als je controller) en draai dit commando eens:

tcpdump --interface any -n udp port 53

Je zou (DNS) packets moeten zien. Ik zou niet weten waarom je AP's zelf requests zouden doen (tenzij er een botnet op je AP's draait o.i.d.) maar het zou best kunnen dat client isolation o.i.d. een soort van SNAT gebruikt waardoor het lijkt alsof het verkeer vanaf het AP komt.

Het zou toch niet zo moeilijk moeten zijn om vanaf hier de source te identificeren

[ Voor 8% gewijzigd door MasterL op 12-11-2024 11:23 ]

[Sharky]

laurens0619 schreef op dinsdag 12 november 2024 @ 11:03:
@Sharky
Ik bedoel wat zie je bij clients die met wifi verbonden zijn bij de ip configuratie
dus in cmd: ipconfig /all

en dan kijken wat er ingevuld staat als DNS server

Dat staat allemaal zoals het hoort.

MasterL schreef op dinsdag 12 november 2024 @ 11:22:
Unifi AP's hebben standaard TCPdump aan boord (althans mijne) log eens in op je AP's (ssh, zelfde credentials als je controller) en draai dit commando eens:

tcpdump --interface any -n udp port 53

Je zou (DNS) packets moeten zien. Ik zou niet weten waarom je AP's zelf requests zouden doen (tenzij er een botnet op je AP's draait o.i.d.) maar het zou best kunnen dat client isolation o.i.d. een soort van SNAT gebruikt waardoor het lijkt alsof het verkeer vanaf het AP komt.

Het zou toch niet zo moeilijk moeten zijn om vanaf hier de source te identificeren

Even gedaan. Je ziet zowel de aanvragen voor *.test als gdb.voanews.com:



Ik word er meteen niet veel wijzer van, wellicht kan iemand hier meer informatie uithalen. In ieder geval hartelijk dank voor het meedenken allemaal

[eric.1]

Die [random].test requests is blijkbaar een feature van dnsmasq: https://community.ui.com/...2d-404e-a5da-ff1555d13379 > https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html --dns-loop-detect

Die .test-TLD is trouwens gereserveerd, en kan dus vrij voor dergelijke tests worden gebruikt. Dit fenomeen is dus niets bijzonders, de frequentie ervan is mogelijk wel apart.

Verder heb ik geen verstand van Unify APs, maar het is wellicht een idee om deze naar factory settings te resetten en opnieuw te configureren. Baat het niet dan schaadt het niet.

[ Voor 9% gewijzigd door eric.1 op 12-11-2024 12:21 ]

[MasterL]

Ik denk dat @eric.1 op het juiste spoor zit. Je ziet duidelijk het AP (192.168.1.7) een request doen naar zowel 8.8.8.8 (Google DNS) als naar 192.168.1.4 (ADguard).
De source is dus wel echt het AP en geen andere clients

[ Voor 14% gewijzigd door MasterL op 12-11-2024 12:57 ]

[Sharky]

eric.1 schreef op dinsdag 12 november 2024 @ 12:16:
Die [random].test requests is blijkbaar een feature van dnsmasq: https://community.ui.com/...2d-404e-a5da-ff1555d13379 > https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html --dns-loop-detect

Die .test-TLD is trouwens gereserveerd, en kan dus vrij voor dergelijke tests worden gebruikt. Dit fenomeen is dus niets bijzonders, de frequentie ervan is mogelijk wel apart.

Verder heb ik geen verstand van Unify APs, maar het is wellicht een idee om deze naar factory settings te resetten en opnieuw te configureren. Baat het niet dan schaadt het niet.

MasterL schreef op dinsdag 12 november 2024 @ 12:56:
Ik denk dat @eric.1 op het juiste spoor zit. Je ziet duidelijk het AP (192.168.1.7) een request doen naar zowel 8.8.8.8 (Google DNS) als naar 192.168.1.4 (ADguard).
De source is dus wel echt het AP en geen andere clients

Ik heb de AP's een factory reset gegeven en ze blijven voanews requesten en de frequentie van *.test lijkt alleen maar omhoog te zijn gegaan. Ik ben het spoor voor nu bijster

[jeroen3]

Als alle ap's wereldwijd dit doen is dat nogal een hoop verkeer of niet?

[laurens0619]

Sharky schreef op dinsdag 12 november 2024 @ 13:44:
[...]


[...]


Ik heb de AP's een factory reset gegeven en ze blijven voanews requesten en de frequentie van *.test lijkt alleen maar omhoog te zijn gegaan. Ik ben het spoor voor nu bijster

De logs laten zien dat het inderdaad vanaf het AP komt en niet een client maar wie wet pakt je tcpdump niet alle informatie en mis je een stukje (en zie je de forward).

Heb je factory reset gedaan en daarna GEEN ssid's ingesteld? maw: geen verbonden clients?
Als je dan nog steeds het verkeer ziet dan moet het wel het AP zijn

[Sharky]

laurens0619 schreef op dinsdag 12 november 2024 @ 13:51:
[...]

De logs laten zien dat het inderdaad vanaf het AP komt en niet een client maar wie wet pakt je tcpdump niet alle informatie en mis je een stukje (en zie je de forward).

Heb je factory reset gedaan en daarna GEEN ssid's ingesteld? maw: geen verbonden clients?
Als je dan nog steeds het verkeer ziet dan moet het wel het AP zijn

Daar had ik nog niet aan gedacht. Ik heb 2 ssid's thuis en beide heb ik losgekoppeld van het AP in de studeerkamer, op het andere AP heb ik beide ssid's gekoppeld gehouden. Het resultaat is dat dit AP (studeerkamer) nu normaal doet (geen *.test en geen voanews meer) en de andere (meterkast) nog steeds raar gedraag vertoont. Vervolgens heb ik de koppeling omgedraaid en hetzelfde gebeurde met het gedrag, dan ligt het dus niet aan de AP's.

Dat maakt het nog wel bijzonder dat beide AP's zo consequent deze requests doen. Ik heb nog even overwogen over het misschien een Tuya-lamp is, maar die volledig uitschakelen maakte niets uit. Vervolgens heb ik het gastennetwerk uitgeschakeld. Dit is een standaard open netwerk met een Unifi captive portal met wachtwoord. En vervolgens hield het op! Dat betekent dus dat er *ergens* een device is dat via dit netwerk de requests doet. De exacte oorzaak valt denk ik lastig te achterhalen, maar voor nu is het opgelost.

Iedereen nogmaals dank!

[laurens0619]

Gastnetwerk was het volgende waar ik aan zat te denken. Helemaal als hier iets van een captive portal actief is dan zou deze wel een actieve rol in DNS afhandeling kunnen spelen (lees je AP is een DNS server en forward het).

Wat wel gek is dat je met tcpdump alleen de "forward" ziet van je AP en niet het initiele request van client naar AP.

Wat nog gekker is dat er een guest wifi client is die schijnbaar met beide ap's verbonden is en dit genereert?

Ik zou bijna verwachten dat het guestwifi dit zelf doet, zonder een verbonden client maar dat is ook wel makkelijk uit te sluiten: Zag je uberhaupt verbonden clients met het guest wifi SSID?

[Sharky]

laurens0619 schreef op dinsdag 12 november 2024 @ 14:41:
Gastnetwerk was het volgende waar ik aan zat te denken. Helemaal als hier iets van een captive portal actief is dan zou deze wel een actieve rol in DNS afhandeling kunnen spelen (lees je AP is een DNS server en forward het).

Wat wel gek is dat je met tcpdump alleen de "forward" ziet van je AP en niet het initiele request van client naar AP.

Wat nog gekker is dat er een guest wifi client is die schijnbaar met beide ap's verbonden is en dit genereert?

Ik zou bijna verwachten dat het guestwifi dit zelf doet, zonder een verbonden client maar dat is ook wel makkelijk uit te sluiten: Zag je uberhaupt verbonden clients met het guest wifi SSID?

Het is inderdaad een vaag issue. Er waren geen verbonden clients. Dit netwerk wordt überhaupt amper gebruikt en het wachtwoord was niet heel voor de hand liggend.

[laurens0619]

Sharky schreef op dinsdag 12 november 2024 @ 14:46:
[...]


Het is inderdaad een vaag issue. Er waren geen verbonden clients. Dit netwerk wordt überhaupt amper gebruikt en het wachtwoord was niet heel voor de hand liggend.

Je kunt het natuurlijk laten zoals het is, want opgelost , maar persoonlijk kan ik er slecht tegen als ik de echte oorzaak niet weet van een IT probleem.

Je zou het guest wifi met een ander wachtwoord kunnen activeren en kijken wat die dan doet. Daar zou niemand mee moeten kunnen verbinden dus zou er geent traffic voorbij moeten komen.

Of je hebt een custom captive portal actief staan waar wat vaags in de code zit

code:

Customize the Splash Page
In the "Guest Control" section, click on "Customize Portal".
You can use the built-in editor to modify the splash page or upload your own HTML file for full customization.
Add your company logo, welcome message, and terms of service to give the portal a branded look.
Save your changes.

Die code zou je kunnen nakijken

[Sharky]

laurens0619 schreef op dinsdag 12 november 2024 @ 14:50:
[...]

Je kunt het natuurlijk laten zoals het is, want opgelost , maar persoonlijk kan ik er slecht tegen als ik de echte oorzaak niet weet van een IT probleem.

Je zou het guest wifi met een ander wachtwoord kunnen activeren en kijken wat die dan doet. Daar zou niemand mee moeten kunnen verbinden dus zou er geent traffic voorbij moeten komen.

Of je hebt een custom captive portal actief staan waar wat vaags in de code zit

code:

Customize the Splash Page
In the "Guest Control" section, click on "Customize Portal".
You can use the built-in editor to modify the splash page or upload your own HTML file for full customization.
Add your company logo, welcome message, and terms of service to give the portal a branded look.
Save your changes.

Die code zou je kunnen nakijken

Nou, ik ben verder gaan onderzoeken omdat ik ook wel eens wilde kijken wat er gebeurde als ik hem weer aan zou zetten met een ander wachtwoord bijvoorbeeld. En tot mijn schaamte moet ik bekennen dat ik zelf de oorzaak ben

Mijn gastennetwerk en mijn captive portal heb ik alle wappiejargon ingestopt die je kunt bedenken, gewoon om kinderachtig te zijn. Als je succesvol inlogt word je geredirect naar deze afbeelding. The rest is history.

Dat verklaart nog niet helemaal dit gekke gedrag en waarom het zo plotseling begint, maar het is weer puzzelstukje. Mea culpa.

[laurens0619]

hahahha super vet

Dus het zat uiteindelijk in de custom code van je captive portal? Of puur de redirect url?

Mijn aanname is dat het komt door het blokkeren. Waarschijnlijk doet je AP een validatie of de url wel werkt en probeert die DNS lookup te doen. Omdat jouw DNS server geen geldige response teruggeeft blijft die dat proberen. Dat verklaart dus ook waarom je het request van je AP af zag komen

Eigenlijk beetje wat hcQd in "Hoe verdacht netwerkverkeer herleiden?" postte
Enige wat dan vaag is waarom het je initieel opgevallen is, die excessie requests zie je pas wss na een blokkade. Ervoor zou je hem sporadisch moeten zien.

Wel tof dat je de oorzaak hebt weten te achterhalen

[ Voor 13% gewijzigd door laurens0619 op 12-11-2024 15:04 ]

[Sharky]

laurens0619 schreef op dinsdag 12 november 2024 @ 15:03:
hahahha super vet

Dus het zat uiteindelijk in de custom code van je captive portal? Of puur de redirect url?

Je kunt een url instellen waar een client naar redirect als hij via de portal succesvol inlogt.

Mijn aanname is dat het komt door het blokkeren. Waarschijnlijk doet je AP een validatie of de url wel werkt en probeert die DNS lookup te doen. Omdat jouw DNS server geen geldige response teruggeeft blijft die dat proberen. Dat verklaart dus ook waarom je het request van je AP af zag komen

Eigenlijk beetje wat hcQd in "Hoe verdacht netwerkverkeer herleiden?" postte
Enige wat dan vaag is waarom het je initieel opgevallen is, die excessie requests zie je pas wss na een blokkade. Ervoor zou je hem sporadisch moeten zien.

Wel tof dat je de oorzaak hebt weten te achterhalen

Ik heb hem geblokkeerd omdat er zoveel extreem veel requests waren de laatste paar weken, na het blokkeren (een week geleden) werden het er niet meer of minder. Deze portal draait zeker al een half jaar, dus dit deel kan ik nog niet echt verklaren.

[laurens0619]

Sharky schreef op dinsdag 12 november 2024 @ 15:10:
[...]


Je kunt een url instellen waar een client naar redirect als hij via de portal succesvol inlogt.


[...]


Ik heb hem geblokkeerd omdat er zoveel extreem veel requests waren de laatste paar weken, na het blokkeren (een week geleden) werden het er niet meer of minder. Deze portal draait zeker al een half jaar, dus dit deel kan ik nog niet echt verklaren.

Misschien werd die al geblokkeerd (dmv een filter die je aan had gezet oid) en is daarna de stortvloed gekomen. Maar dat zou je makkelijk kunnen testen om vanaf het ap een nslookup te doen naar dat domein als je handmatige blokkade eraf is

[NeFoRcE]

Bijzonder dat jij alleen op die manier dat traffic inzichtelijk hebt.

Ik heb m'n DNS onder 'Internet' en lijk op die manier alles goed te kunnen monitoren:



en dan per ip:


Ik heb zelf ook even gezocht op da voanews in mijn adguard, maar zie 0 resultaten.