Check out the “Open Source Security Podcast” with Kurt Siegfried and Josh Bressers. It’s not about specifics so much as how to build a mindset around security for IOT and hosting, generally dealing with opensource offerings.
I believe the UDP ports are for discovery on your local network so no need to handle them with your reverse proxy. If you’ve got them passed through docker your local devices should pick them up.
They’re also not required since you can always just enter the address manually. I don’t bother passing them into my container.
Lots of people contributed really good answers, so I don’t have anything valuable to add to their answers. But I wanted to point out for your detailed question, you include what you have done, what is your understanding and what are your shortcomings clearly. As opposed to a lot of posts with vague, detail-challenged narratives, that’s a top notch post.
And the community delivered by giving good answers, so go community!
Also, you didn’t just ghost after the initial post and interacted.with the people who graciously donated their time, so another bonus point there, as well.
I have personally been very happy with FreshRSS. Nowadays I use Nextcloud News (just a Nextcloud) app for it. So if you already have Nextcloud you don’t even need to selfhost something extra.
They both have WebApps. FreshRSS has a few themes to fit your taste and Nextcloud News will obviously follow your Nextcloud theming.
As far as apps go, FreshRSS has (probably) more than Nextcloud News. I personally like Feeder (only in PlayStore but worth it imo). For Nextcloud there is an App with the same name. Also good imo, but FreshRSS/Feeder has more customization options.
I use wireguard and nginx but I set my WG DNS as the server ip. I have adguardhome running on the server and have added the external domains to map to their LAN address so they resolved locally when using the vpn or the LAN. A similar setup should work for you.
Are you taking about security for your homelab? It essentially comes down to good key hygiene, network security and keeping everything updated.
Don’t open ports, use a good firewall at the border of the network, use a seedbox for torrenting. Use ACLs alongside VLANs in your network. Understand DNS in terms of how your requests are forwarded and how they are processed.
What does using a good firewall mean exactly? As I understand it a port is either open or closed right? So what does a good firewall do that a bad one doesn’t?
Projects like OpenWRT and OPNsense take care to maintain their code and address security issues in firewall/router software that can be exploited. Perhaps firewall might not have been the best way to put it, but companies like TP-Link aren’t really the most scrupulous with their software
I’ve setup wireguard, because it’s only me and an employee using the services. But with that, externally I don’t even seem to have a port open. But wireguard is so fast to be online, that I’m just always connected as soon as I’m online - using a domain and an IP update script
Something like Wireguard, Tailscale (uses Wireguard but provides easier administration), Reverse Proxy, VPN, are the best approaches.
Since OP doesn’t need for anyone else to access, I’d use Tailscale (Wireguard if you want a little more effort). Tailscale has a full self-host option with Headscale, though I have no problem with letting them provide discovery.
With Tailscale, you don’t even need the client on devices to access your Tailscale network, by enabling the Funnel feature. This does something similar to Reverse Proxy, by having a Web-exposed service hosted by Tailscale which then routes traffic (encrypted) to your Tailscale network.
Yeah, but then I’ve a web exposed service and I want keep a low profile as possible with what I’m exposing. So I guess as long as there aren’t many users to manage, wireguard (or a tailscale configuration) could work out for OP
No, because I am worried the NSA may try to collate data from them. In fact, I zero-wipe, drill bit the drives in the platters and the PCB, and drop them off at e-waste for recycling.
You’re going to get a lot of bad or basic advice with no reasoning (use a firewall) in here… And as you surmised this is a very big topic and you haven’t provided a lot of context about what you intend to do. I don’t have any specific links, but I do have some advice for you:
First - keep in mind that security is a process not a thing. 90% of your security will come from being diligent about applying patches, keeping software up-to-date, and paying attention to security news. If you’re not willing to apply regular patches then don’t expose anything to the internet. There are automated systems that simply scan for known vulnerabilities on the internet. Self-hosting is NOT “set it and forget it”. Figuring out ways to automate this help make it easy to do and thus more likely to be done. Checkout things like Ansible for that.
Second is good authentication hygiene. Choose good passwords. Better yet long passphrases. Or enable MFA and other additional protections. And BE SURE TO CHANGE ANY DEFAULT PASSWORDS for software you setup. Often there is some default ‘admin’ user.
Beyond that your approach is"security in depth" - you take a layered approach to security understanding what your exposure is and what will happen should one of your services / systems be hacked.
Examples of security in depth:
Proper firewalling will ensure that you don’t accidentally expose services you don’t intend to expose (adds a layer of protection). Sometimes there are services running that you didn’t expect.
Use things like “fail2ban” that will add IP addresses to temporary blocklists if they start trying user/passwords that don’t work. This could catch a bot from finding that “admin/password” user on your Nextcloud server that you haven’t changed yet…
Minimize your attack surface area. If it doesn’t need to be exposed to the internet then don’t expose it. VPNs can help with the “I want to connect to my home server while I’m away” problem and are easy to setup (tailscale and wireguard being two popular options). If your service needs to be “public” to the internet understand that this is a bigger step and that everything here should be taken more seriously.
Minimize your exposure. Think though the question of “if a malicious person got this password what would happen and how would I handle it?” Would they have access to files from other services running on the same server (having separation between services can help with this)? Would they have access to unencrypted files with sensitive data? It’s all theoretical, until it isn’t…
If you do expose services to the internet monitor your logs to see if there is anything “unusual” happening. Be prepared to see lots of bots attempting to hack services. It may be scary at first, but relatively harmless if you’ve followed the above recommendations. “Failed logins” by the thousands are fine. fail2ban can help cut that down a bit though.
Overall I’d say start small and start “internal” (nothing exposed to the internet). Get through a few update/upgrade cycles to see how things go. And ask questions! Especially about any specific services and how to deploy them securely. Some are more risky than others.
Going off of what you said, I am going to take what I currently have, scale it back, and attempt to get more separation between services.
Containerization and virtualization can help with the separation of services - especially in an environment where you can’t throw hardware at the problem. Containers like Docker/podman and LXD/LXC aren’t “perfect” (isolation-wise) but do provide a layer of isolation between things that run in the container and the host (as well as other services). A compromised service would still need to find a way out of the container (adding a layer of protection). But they still all share the same physical resources and kernel so any vulnerabilities in the kernel would potentially be vulnerable (keep your systems up-to-date). A full VM like VirtualBox or VMWare will provide greater separation at the cost of using more resources.
Docker’s isolation is generally “good enough” for the most part though. Your aggressors are more likely to be bot nets scanning for low-hanging fruit (poorly configured services, known exploits, default admin passwords, etc.) rather than targeted attacks by state-funded hackers anyway.
selfhosted
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.