this post was submitted on 24 Feb 2026
24 points (100.0% liked)

Selfhosted

56907 readers
764 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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. 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.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
24
Network Security Audit (lemmy.world)
submitted 1 day ago by irmadlad@lemmy.world to c/selfhosted@lemmy.world
23 comments fedilink hide all child comments
 

From time to time I like to review my network to see where I can tighten up. Review logs, check out the landscape, and make sure there are no gaps. Today, I have some downtime, so I figured it'd be a good for it. Since I am not a certified IT professional, this is what I have cobbled together reading, and seeing what others have done. I'd like to bounce this off you guys who are more experienced than I and get your impressions. If you have any recommendations, I'm always down to be schooled.

So if you'd like to participate in my audit, I have a home network as follows:

  • Modem receiving IP from ISP. Modem to router. Router to stand alone pfsense firewall. Router has a 54 character complex password for WiFi. There are no guest provisions for WiFi.
  • Pfsense firewall with pfblockerng & suricata running on both lan and wan, both with a full array of rules/feeds updated daily. pfsense has tailscale as an overlay vpn. Server traffic and PC traffic have their own VLAN provided by pfsense. My approach is to deny all until something complains and address that on a case by case basis. Additionally ntopng is utilized for traffic analysis. IPv6 is disabled.
  • Server running Tailscale as an overlay VPN, UFW deny all posture, and fail2ban with an aggressive posture. Server has been hardened against Lynis spec where applicable. Not all recommendations apply to my server. Server is utilizing host deny/host allow and SSH keys.
  • Server is utilizing containers for services.
  • Server is using Cloudflare tunnel/zero trust.
  • Server and pfsense communicate via Tailscale encrypted tunnel. PC/Phone/mobile device can communicate with pfsense via Tailscale.
  • Server services are accessed via https.
  • PC connected to pfsense firewall with same rules as server. PC is using a VPN with Cloudflare 1.1.1.1/1.0.0.1 for DNS queries. Firefox is using 1.1.1.1/1.0.0.1. Settings for Firefox are the strictest for Enhanced Tracking Protection, and DOH. HTTPS-Only mode enabled. PC is also running a soft firewall.
  • All other devices such as phones, laptops, and tablets run a VPN with Cloudflare 1.1.1.1/1.0.0.1 for DNS queries.
  • IoT devices are isolated. Phones are isolated. Smart TVs are isolated.

How secure would you say this network is and give any recommendations to further harden the network besides keeping up with current updates, monitoring and auditing logs.

Thanks

top 23 comments
sorted by: hot top controversial new old
[–] Archer@lemmy.world 3 points 23 hours ago (1 children)

As a certified IT professional I can tell you I’d much rather have a coworker who got down in the weeds and did things. Anyone can pick up a cert, that’s resume padding. Operational experience is the real prize

[–] irmadlad@lemmy.world 2 points 18 hours ago (1 children)

Operational experience is the real prize

Perhaps, but I've found that HR likes paper tigers. LOL Not discounting anyone's hard work at all. I do learn from others more knowledgeable than I. I've had a computer of some sort in front of me since the mid 70s with the Altair. Don't mistake longevity with knowledge tho. What little I do know came from reading, doing, screwing it up, rinse, repeat ad nauseam until success, and then write that shit down because it will come up again more than likely.

[–] Archer@lemmy.world 2 points 14 hours ago (1 children)

You’re ahead of an alarming number of my colleagues by just trying until you can get it working then documenting things

[–] irmadlad@lemmy.world 2 points 11 hours ago

I have to document. At 71, with a TBI, my brain is not what it used to be. Sometimes I don't even remember what I had for breakfast. LOL

[–] drkt@scribe.disroot.org 8 points 1 day ago (1 children)

Why disable IPv6?

[–] irmadlad@lemmy.world 5 points 1 day ago* (last edited 1 day ago) (2 children)

My commercial VPN does not do IPv6. I didn't want there to be any situation where any IPV6 traffic was leaked out because the VPN is not IPv6 compatible. That may be errant thinking on my part tho. If you see it a different way, I'd entertain your thoughts.

[–] litchralee@sh.itjust.works 5 points 1 day ago* (last edited 1 day ago) (1 children)

The approach isn't invalid, but seeing as you already have the framework set up to deny all and log for IPv4, the same could be done with IPv6.

That is to say, your router advertises an IPv6 gateway to the global internet, but you then reject it because your VPN doesn't support v6 (sadly). I specifically say reject, rather than drop, because you want that ICMP Unreachable (administratively prohibited) message to get returned to any app trying to use v6. That way, Happy Eyeballs will gracefully and quickly fall back to v6. Unless your containers have some exceptionally weird routing rules, v6 connections will only be attempted once, and will always use the route advertised. So if your router denies this attempt, your containers won't try again in a way that could leak. v6 leaks are more likely when there isn't even a route advertised.

This makes your apps able to use v6, for that day when your VPN supports it, and so it's just a question of when the network itself can be upgraded. IMO, apps should always try for v6 first and the network (if it can't support it) will affirmatively reply that it can't, and then apps will gracefully fall back.

This also benefits you by logging all attempted v6 traffic, to know how much of your stuff is actually v6-capable. And more data is always nice to have.

[–] irmadlad@lemmy.world 0 points 1 day ago (1 children)

because your VPN doesn’t support v6 (sadly)

I have no problem with IPv6, in fact it would probably be a bit more faster/streamlined since IPv6 has simpler headers, eliminates the need for NAT.....so direct addressing, and IPV6 has smaller routing tables. So, all in all, yes IPV6 would be more desirable. For the time being until, as you say, my sad VPN provider upgrades to IPv6, I figured it would be best to just disable it and wait. From what I can tell, there are only a small handful of reputable VPNs that support IPv6 like Proton and Mullvad.

[–] litchralee@sh.itjust.works 3 points 1 day ago* (last edited 1 day ago) (1 children)

Fair, though I personally don't let my ISP indirectly dictate what I do with my LAN. If I didn't already have a v6-enabled WAN, I would still manage my LAN using IPv6 private range addresses. There are too many benefits to me, like having VMs and containers be first-class citizens on my LAN, rather than sitting behind yet another layer of NAT. That lets me avoid port forwarding at the border of my home Kubernetes cluster (or formerly, my Docker Swarm), and it means my DNS names correctly resolve to a valid IP address that's usable anywhere on my network (because no NAT when inside the LAN).

I will admit that NAT64 is kinda a drag to access v4-only resources like GitHub, but that's only necessary because they've not lit up support for v6 (despite other parts of their site supporting v6).

This is my idea of being future-ready: when the future comes, I'm already there.

[–] irmadlad@lemmy.world 1 points 1 day ago

I would still manage my LAN using IPv6 private range addresses

That is something to consider. Thanks.

[–] drkt@scribe.disroot.org 3 points 1 day ago

No, that makes sense.

I see a lot of people disable it because they assume it's inherently insecure. Just wanted to check if that was the reason.

[–] non_burglar@lemmy.world 3 points 1 day ago* (last edited 1 day ago) (1 children)

Running suricata on your wan interface is just generating a ton of noise and will be really confusing for you if you haven't reviewed packet inspection alerts before. Not a lot of value in it unless you have many users "phoning home".

Just run it on the lan interface.

Your approach of deny all until something complains is pretty much the most solid way to get a grip on security.

I assess and recommend security practices for a living, and I would say the most important first step is understanding where your data lives and where it goes. Once you know that, the rest is relatively easy with the tools available to us.

[–] irmadlad@lemmy.world 1 points 1 day ago (1 children)

I've been told this before. I also acknowledge and appreciate your advice coming from a professional pov. However, here's the thing...my OCD would never allow me not to know. It would drive me up the wall not knowing. I get what you are saying, and you are right. It is my kryptonite not to know. It is a curse I can tell you.

[–] non_burglar@lemmy.world 2 points 1 day ago* (last edited 1 day ago) (1 children)

OK, well it's not harming anything, so if you're game to learn, by all means.

When you look at traffic on a public interface, besides learning what to filter out that is just normal (probes, crawls, etc from legit sources), but you also will run into badly-formed TCP traffic:

Martian packets: https://en.wikipedia.org/wiki/Martian_packet IP spoofing: https://en.wikipedia.org/wiki/IP_address_spoofing (I used to have a better resource for this,I'll try to find it)

How RPC works: https://pentest.co.uk/labs/research/researching-remote-procedure-call-rpc-vulnerabilities/

That should help clarify a lot of what you'll see in traffic on your segment.

You may also want to briefly read about how CDNs work, you'll see a lot of akamai and cloudflare traffic too.

[–] irmadlad@lemmy.world 1 points 18 hours ago

That should help clarify a lot of what you’ll see in traffic on your segment.

Thank you for the links and guidance. I will definitely read those. Yeah I do see a lot of things like:

  • SURICATA STREAM FIN2 FIN with wrong seq (this is from local chatter)
  • ET INFO DNS Query for Suspicious .ml Domain (must check out this suspicious domain /s)
  • ET INFO Observed DNS Query to .world TLD (same as above)
  • SURICATA STREAM Packet with invalid timestamp (local chatter - common triggered event from what I understand)
  • SURICATA STREAM FIN invalid ack (known domain speedtest)

So, since I am working within the framework of my own personal shortcomings and have to know, I research them to find out why they get triggered. That way I don't freak out over them A lot of them are benign and due to normal occurrences between server and user.

[–] frongt@lemmy.zip 3 points 1 day ago (2 children)

No scanning? External, internal, and host scans. I'd also set up a network traffic analyzer if you want to go really advanced.

[–] irmadlad@lemmy.world 3 points 1 day ago

I have chkrootkit, IPTraf-ng, and rkhunter doing daily scans. I use ntopng for traffic analysis. What would you recommend.

[–] non_burglar@lemmy.world 1 points 1 day ago

Op is running suricata

[–] wabasso@lemmy.ca 2 points 1 day ago (1 children)

Do you place any restrictions on the containers or the container daemon as a whole?

Moreso asking so I can copy your settings. But I have had my server brought down just from the services themselves consuming too much memory or disk space, so something to look into if you haven’t already.

[–] irmadlad@lemmy.world 2 points 1 day ago (1 children)

I have had my server brought down just from the services themselves consuming too much memory or disk space

Server is utilizing a 8 TB SSD and 40 GB RAM. I can go into Portainer and regulate how much resources I allot to each container, however, I've never had any issues in that regard. Server generally hums along at 15-25% for around 75 different containers.

[–] wabasso@lemmy.ca 2 points 16 hours ago (1 children)

Awesome! You’re making me want to give Portainer another go.

I’m running a potato pi with 0.5 TB and 8 GB RAM so…slightly different situation here :P

[–] irmadlad@lemmy.world 2 points 15 hours ago

It doesn't really matter if you're running a pi or a full stack rack in the closet, it's all good. I use Portainer because I learned how to drive that bus and it just seemed to click with me so I kept it. There are other similar and even better options out there.

[–] Decronym@lemmy.decronym.xyz 2 points 1 day ago* (last edited 11 hours ago)

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
IP Internet Protocol
NAT Network Address Translation
SSD Solid State Drive mass storage
TCP Transmission Control Protocol, most often over IP
VPN Virtual Private Network

6 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.

[Thread #116 for this comm, first seen 24th Feb 2026, 20:31] [FAQ] [Full list] [Contact] [Source code]