I'm curious to see what information I'm blasting out to the various services I depend on for internet (ISP, DNS, probably Cloudflare, etc.).
Are there any easy to setup, entirely self-hosted tools I can run on my home network that would allow me to snoop on my own traffic.
I want more than just DNS, so I'm not just looking for pihole and its ilk. I want to see things like SNI and any non-protected traffic that any of the devices on my network might be sending that I just don't know about.
Ideally, it would be something I could leave on without affecting my speed/latency, but something to turn on occasionally and spot check would be better than nothing.
My router runs VyOS, so I should have quite a bit of flexibility in what I do with my traffic, though I never have figured out if/how to deploy custom software to it…
SPAN port on the switch, send it all into a server running Suricata which can analyze, classify, and log all the traffic. Don’t run it in IPS mode online unless you’re willing to suffer a little…
Oh, this the exact use case for a tool that I’m writing right now! It’s a daemon that runs on the gateway and acts as a DNS + DHCP + Firewall to monitor the activity of IoT devices.
https://github.com/mafik/gatekeeper
In the 1.6 (expected next weekend) I’m adding traffic graphs for each device and remote domain that it talks to.
Since we’re talking specifically about network traffic, let’s clarify the scope of the problem for reference.
You want to see what is being sent outside, to the wide internet from your network, and how might you be compromised by this traffic.
The logical method would be to snoop on this information. The question is, how would you do that?
- There are network analysis tools, including DPI, that might be able to help you in this journey. Suricata/Snort and Splunk are three such applications, although perhaps you’d also like to consider an application suite like Security Onion.
- The second problem is, how do you get the outward facing traffic to analyse it? The easier way to do this is to utilise
port-mirroring
- mirror the traffic through your WAN-facing port into an analyser to check just what is it that you’re sending out. Note that this will likely require extensive effort and time since everyone has different traffic they would like to check, and coming up with robust checks is entering the field of security professionals.
Some considerations:
- As you know, most x86 computers have a backdoor installed in hardware. This is either the Intel ME or AMD PSP (if you know what this is and are worried about your privacy, I suggest looking at AMD’s OpenSIL initiative slated to release in 2027).
- This is a problem since these backdoors utilise the same hardware NIC of your computer but act as a completely different system (different MAC, encrypted traffic using different keys, and a different style of traffic).
- The problem manifests like so: one would reasonably expect to find the traffic from said processes in the traffic that one analyses, however, how would one find them (perhaps through logging their MAC address)? It is possible that Intel already uses dynamic MAC addresses, which makes it harder to find them - although, in theory, one should be able to script this.
- Now that you’re enraged about such atrocious behaviour on your network, let me point you towards the fact that people who run mini PCs as routers with x86 processors in them (for OPNSense/PFSense) should also be running into this problem, theoretically. It is a bigger issue for them however, since in their case the network edge itself is reasonably compromised. How are you sure that the ME/PSP processor isn’t going to mask its traffic from the port-mirroring setup you have got running? How can one be sure of the capabilities of such proprietary systems and how they can mask their traffic?
I know people will come up with “but they don’t spy on you! It needs to be explicitly turned on to spy on you!” and “get a thinkpad bro, modify the HAP bit!”, however, both arguments don’t hold much weight considering the hardware readily available to the common user (bit of a fallacy, but we’ll go with it). The point stands; such behaviour shall not be tolerated in a self-aware user’s network, and needs to eradicated the second the user gets a whiff of such mischief playing out. I hope my note has ignited a willingness in you to prevent such rabid deanonymisation attempts to one’s self in this age, and will spur you to fortify your network to prevent such malice from breaking anonymity and trust on hardware.
Look at the mirror. 👨🦱
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System HTTP Hypertext Transfer Protocol, the Web HTTPS HTTP over SSL IP Internet Protocol IoT Internet of Things for device controllers SSL Secure Sockets Layer, for transparent encryption
4 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.
[Thread #201 for this sub, first seen 8th Oct 2023, 23:35] [FAQ] [Full list] [Contact] [Source code]