anon2963
@anon2963@infosec.pub
- Submitted 2 months ago to selfhosted@lemmy.world | 14 comments
- Submitted 6 months ago to selfhosted@lemmy.world | 3 comments
- Comment on Many Network Interfaces per VM/CT - Good Practice? 6 months ago:
Thank you, that is a very good point, I never thought of that. Just to confirm, best standard practice is for every connection, even as simple as a Nextcloud server accessing an NFS server, to go through the firewall?
Then I could just have one interface per host but use Proxmox host ID as the VLAN so they are all unique. Then, I would make a trunk on the guest OPNsense VM. In that way it is a router on a stick.
I was a bit hesitant to do firewall rules based off of IP addresses, as a compromised host could change its IP address. However, if each host is on its own VLAN, then I could add a firewall rule to only allow through the 1 “legitimate” IP per VLAN. The rules per subnet would still work though.
I feel like I may have to allow a couple CT/VMs to communicate without going through the firewall simply for performance reasons. Has that ever been a concern for you? None of the routing or switching would be hardware accelerated.
- Comment on Need recommandations for a home server 6 months ago:
Search eBay for used gaming laptops. Comes with a built in UPS.
- Submitted 6 months ago to selfhosted@lemmy.world | 13 comments
- Submitted 6 months ago to 3dprinting@lemmy.world | 12 comments
- Comment on Do I Need to Harden SSH over Tor? 7 months ago:
Thanks for the wise words. However I have some questions:
If you’re worried about someone malicious having access to your network connection, ssh is going to do a DNS lookup to map the hostname to an IP for the client.
Are you sure that this is true for Tor? .onion addresses never resolve to an IP address, even for the end user client. If I was on an untrusted network, both for the client and the server, the attacker could find out that I was using Tor, but not know literally anything more than that.
And attackers have aimed to exploit things like buffer overflows in IDSes before – this is a real thing.
I would expect an IDS to be an order of magnitude larger attack surface than Wireguard, and significantly less tested. Although I could also say that about SSH, and we had the recent backdoor. However, I think it is a lot more likely that a bug will cause a security method to be ineffective than actively turn it in to a method for exfiltration or remote access though. For example, with the recent SSH backdoor, if those servers had protected SSH behind Wireguard then they would have been safe even if SSH was compromised.
- Submitted 7 months ago to selfhosted@lemmy.world | 28 comments