Look at the mirror. π¨βπ¦±
this post was submitted on 08 Oct 2023
1 points (100.0% liked)
Selfhosted
40347 readers
365 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (donβt cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
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.
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]
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.