How do I avoid becoming one with the botnet?
from bitcrafter@programming.dev to selfhosted@lemmy.world on 25 Jan 21:07
https://programming.dev/post/44650104

I find the idea of self-hosting to be really appealing, but at the same time I find it to be incredibly scary. This is not because I lack the technical expertise, but because I have gotten the impression that everyone on the Internet would immediately try to hack into it to make it join their bot net. As a result, I would have to be constantly vigilant against this, yet one of the numerous assailants would only have to succeed once. Dealing with this constant threat seems like it would be frightening enough as a full-time job, but this would only be a hobby project for me.

How do the self-hosters on Lemmy avoid becoming one with the botnet?

#selfhosted

threaded - newest

ryokimball@infosec.pub on 25 Jan 21:10 next collapse

They don’t have to succeed once.

Use antivirus and other endpoint security measures. Rotate your passwords and keys. Use Everything as Code, and for goodness sake make backups.

If you find yourself compromised, rotate and burn the keys, wipe and redeploy.

bitcrafter@programming.dev on 25 Jan 21:54 collapse

Everything that you mention is sensible, but it seems like it would take so much time not only to set up but to perform the ongoing maintenance you described that it just is not worth the trouble to self-host, which is a significant factor in why I have not taken a shot at it.

frongt@lemmy.zip on 25 Jan 22:17 next collapse

Self-hosting means taking on those maintenance responsibilities yourself. Same as doing your own plumbing or car maintenance. Either you spend the time and effort yourself, or you pay someone else to do it.

bitcrafter@programming.dev on 25 Jan 23:35 collapse

Right, but there is an entire spectrum of plumbing maintenance. I am perfectly capable of plunging toilets, but when a drain fails to work after several attack on my part then it is time to call in the plumber.

ryokimball@infosec.pub on 25 Jan 22:17 next collapse

I think most home lab/shelf hosters start off because they want to learn something. I think (generally, philosophically) many people never start something new even if it interests them because they are afraid. To this point, it sounds like you can either let the fear prevent you from doing what you want, or you can use the fear as a learning tool.

Start simple. Build something very easy and isolated, air gap it if you need to. Figure out how logs and monitoring work, maybe even try attacking it yourself, so you have confidence that even if it’s compromised you will see how and why. Then you can connect it to the internet, isolated from the rest of your network, and then you will learn how well- or un-founded those fears are. Learn even more about monitoring and defending, then start looking for a job as a cybersecurity professional because you are already well underway.

bitcrafter@programming.dev on 25 Jan 23:28 collapse

I mostly just like building and tinkering with things, and I really like the idea of setting up services that I control that host my own data that I can access from anywhere. I have no real interest in learning about more than the minimum amount needed to do that simply because that is not how I would like to spend my time.

(Lest you continue to have the wrong impression that I am afraid of learning new things: There was a period in my life where I was constantly learning new technologies, programming languages, etc. Eventually I realized that I had demonstrated that I was capable of learning anything that I wanted, and there were so many things out there to learn that I needed to start becoming more selective. At the moment my learning goals tend to be more math focused; currently I am trying to learn graduate-level category theory and measure theory.)

If I really need to master all of the steps that you’ve described before deploying my host on the Internet, then my conclusion is that it is more trouble than it is worth, because my concern is that if I screw up then I will make the Internet a worse place by contributing to botnets.

irmadlad@lemmy.world on 25 Jan 23:53 collapse

If I really need to master all of the steps that you’ve described before deploying my host on the Internet, then my conclusion is that it is more trouble than it is worth, because my concern is that if I screw up then I will make the Internet a worse place by contributing to botnets.

Nah dude. You’re not going to make the internet worse because a bot opened a door you thought was locked and let himself in. That’s rubbish. Do some reading, study up, deploy the server. Monitor before you start putting any PII on the server. Deploy a couple fun Docker containers. Monitor. Build your confidence.

Don’t let fear get the best of you. I have a load of fun with my set up as, like you, I love to tinker. Nothing I have done can’t be replicated through studying, asking questions, deploying in gradual steps. I have no certifications or any of that pro stuff some of these guys have. Just a regular schmoe. It really isn’t that much hassle once you get everything set up and you have confidence in your server’s defenses.

DO IT!!!

Wxfisch@lemmy.world on 25 Jan 22:29 collapse

Honestly it’s not a ton of time. A few minutes to run patches every few weeks, and the initial investment to plan, install, and configure your services (but then that’s the fun part no?). Self hosting IMO isn’t a great way to save time and money, or even to get out of the pocket of big tech. If those are your goals you’re better off looking at hosted solutions that are Open, and likely paying for it since running IT stacks isn’t free. Self hosting is a hobby, something you do to learn and because you enjoy it. It is hard sometimes, takes time, and comes with risks, but so do most other hobbies.

bitcrafter@programming.dev on 25 Jan 23:15 collapse

That does not sound so bad; the parent comment made it sound a lot worse than that.

Wxfisch@lemmy.world on 25 Jan 23:25 collapse

Eh, it can be a lot of work but doesn’t have to be. I’ve automated backups, and if you follow current best practice guidance from industry, you should use long pass phrases and not worry about regularly rotating them. For things like SSH keys, you can rotate them if you think you’ve had a breach but in normal usage there isn’t a huge benefit security-wise since they functionally can’t be guessed and would need to be stolen. If an adversary steals your SSH keys then you’re already pretty hosed as the next step is for them to establish another backdoor to access your server without needing your key.

Wxfisch@lemmy.world on 25 Jan 21:23 next collapse

Only expose services internally then use a secure VPN to access your services, this makes your network no more vulnerable in practice than not self hosting. If you need/want to expose something to the internet, make sure you setup your network right. Use a DMZ to separate that service and leverage something like CrowdSec along with good passwords, antivirus, and keep things patched.

a1studmuffin@aussie.zone on 25 Jan 22:01 next collapse

Thanks for the CrowdSec tip, I’ve already got an nginx reverse proxy set up but wasn’t aware I could integrate this for extra protection.

corvus@lemmy.ml on 25 Jan 22:02 next collapse

Should I do the same if I want to expose an OpenAI compatible API to access an LLM to chat remotely on local technical documents?

Wxfisch@lemmy.world on 25 Jan 22:24 collapse

It doesn’t usually matter what the service is, the basic concepts are the same. If you want to access a service you host on your internal network from another external network you either need to use a VPN to securely connect into your network, or expose the service directly. If you are exposing it directly you should put it (or a proxy like NPM) in your DMZ. The specifics of how to do this though will vary from service to service and with your specific network config.

BingBong@sh.itjust.works on 25 Jan 22:11 collapse

How do I check this? I route everything on my internal network only. But how should I make sure its not accessible remotely? I cannot just have these on an air gapped network.

Wxfisch@lemmy.world on 25 Jan 22:21 next collapse

You can run a port scan against your public IP from another network to see what is open. But if you haven’t specifically set something up for external access through port forwarding you are probably fine.

slazer2au@lemmy.world on 25 Jan 22:32 collapse

Throw your IP into Shodan.io and see what it comes back with.

ShortN0te@lemmy.ml on 25 Jan 21:48 next collapse

The ‘immediate attacks’ ppl mention is just static background noise. Server / scripts that run trying to find misconfigured, highly out to date or exploitable endpoints/servers/software.

Once you update your software, set up basic brute force protection and maybe regional blocking, you do not have to worry about this kind of attack.

Much more scary are so called 0-Day attacks.

  1. No one will waste an expensive exploit on you
  2. It sometimes can happen that 0-Days that get public get widly exploited and take long time to get closed like for example log4shell was. Here is work necessary to inform yourself and disable things accorsing to what is patched and what not.

As i already said, no one will waste time on you, there are so much easier targets out there that do not follow those basic rules or actually valuable targets.

There is obviously more that you can do, like hiding everything behind a VPN or advanced thread detections. Also choosing the kind of software you want to run is relevant.

krashmo@lemmy.world on 25 Jan 22:13 collapse

What are you referring to when you say basic brute force protection?

cecilkorik@lemmy.ca on 26 Jan 00:01 next collapse

fail2ban mainly, but also things like scaling login delays (some sort of option often built into the software you’re running, but just as often not configured by default), or if you’re feeling particularly paranoid account locking after too many failures, and in general just not using default, predictable, common usernames or weak passwords, and honestly it’s even helped a bit by having slow hardware and throttled network bandwidth.

The goal is to make it so that someone can’t run a script that sends 100 million login attempts per second for common or stolen usernames and passwords and your server just helpfully tries them all and obediently tells them none of those worked… until one of them does.

Not only does this encourage them to TRY sending 100 million login attempts per second because your server isn’t refusing it, which is a huge waste of bandwidth and resources, it also makes it really likely that they’re eventually going to guess one right.

ShortN0te@lemmy.ml on 26 Jan 14:01 collapse

The other answer is already good but I answer more general.

Rate limiting. Do not allow as many requests as your CPU can handle but limit authentication requests. Like a couple requests per second already goes a long way.

Kolanaki@pawb.social on 25 Jan 21:59 next collapse

I don’t think you’re in any danger if you are truly a human.

Your devices, OTOH…

bitcrafter@programming.dev on 25 Jan 22:07 collapse

I admit nothing.

Decronym@lemmy.decronym.xyz on 25 Jan 22:05 next collapse

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

Fewer Letters More Letters
Git Popular version control system, primarily for code
HTTP Hypertext Transfer Protocol, the Web
IP Internet Protocol
NAS Network-Attached Storage
NAT Network Address Translation
SSH Secure Shell for remote terminal access
TCP Transmission Control Protocol, most often over IP
VPN Virtual Private Network
VPS Virtual Private Server (opposed to shared hosting)
nginx Popular HTTP server

[Thread #1019 for this comm, first seen 25th Jan 2026, 22:05] [FAQ] [Full list] [Contact] [Source code]

irmadlad@lemmy.world on 27 Jan 02:54 collapse

I have often wondered since our friendly and helpful bot arrived, what would happen if we made a thread where everyone used as many acronyms as possible in our comments. It’s actually one of the more cooler bots I’ve seen in a while. Especially for new arrivals who don’t spreken ze Lingley. Crackin’ iidea.

bizdelnick@lemmy.ml on 25 Jan 22:21 next collapse

By default your OS is secure. You only have to think about what you expose and how can it be broken in. Disable SSH password authentication. Don’t run software that is provided by hobbyists who have no enough security expertise (i. e. random github projects with 1 or 2 contributors and any software that recommends install method curl <something> | sudo bash). Read how to harden the services you run, if it is not described in the documentation — avoid such services. Ensure that services you installed are not running under root. Better use containerized software, but don’t run anything as root even inside containers. Whenever possible, prefer software from your distro official repos because maintainers likely take care about safe setup even if upstream developers don’t. Automate installing security updates at the day they released.

What doesn’t help:

  • Security through obscurity. Changing SSH port etc. Anyone can scan open ports and find where SSH is listening.
  • Antivirus. It is simply unable to detect each of numerous malicious scripts that appears every day. It just eats your system resources.The best it can do is to detect that your host is compromised, but not prevent this. It is not security, just marketing.
  • Making different rules for public internet and DMZ. Consider there’s no DMZ. Assume that your host can be accessed by crackers from anywhere.
bitcrafter@programming.dev on 25 Jan 23:40 collapse

Thanks, your comment is an antidote to my paranoia that it is impossible to do anything to address all threats. 😀

Given that your advice is very sound, I have a question: would I gain much by using OpenBSD? The conventional wisdom when I last checked is that it is the most secure unix-like operating system on the planet.

bizdelnick@lemmy.ml on 26 Jan 10:08 collapse

I don’t think you gain much from OpenBSD. It is focused on preventing vulnerabilities that are hard to exploit and unlikely used by botnets. Most dangerous are vulnerabilities caused by software misconfiguration. The OS cannot prevent your mistake. Also, in OpenBSD you will be unable to use modern containers like docker, podman etc.

Stez827@sh.itjust.works on 25 Jan 22:31 next collapse

Just use tailscale and don’t forward any ports and you’ll be fine

bridgeenjoyer@sh.itjust.works on 25 Jan 23:44 next collapse

Is it bad to forward ports temporarily to game with friends? And deactivate after?

I dont have the energy to learn new fanglad networking since everything is so insecure now…im used to 2009 servers.

planish@sh.itjust.works on 25 Jan 23:49 next collapse

No?

I mean, how else are you meant to play the game actually?

I guess you could be like opening ports just to particular IPs. And you need a game that isn’t Swiss cheese that gets immediately hacked.

But like hackers don’t sort of seep in through port forwards; they need to physically identify and exploit a particular vulnerability.

bridgeenjoyer@sh.itjust.works on 26 Jan 02:17 collapse

Ah. Well mostly it’s for voxelibre or armegatron nowadays

Stez827@sh.itjust.works on 26 Jan 08:46 collapse

It’s not really complicated at all you just download the tailscale app make an account and then hit share to your friends. That’s how I run a Minecraft server for me and my friends because I was too lazy to figure out how to port forward. It was easier to just sudo apt install tailscale and essentially be done.

bridgeenjoyer@sh.itjust.works on 26 Jan 16:53 collapse

That sounds so easy my friends could do it! Ill need to read up

k4j8@lemmy.world on 26 Jan 05:12 next collapse

There’s a lot of technical answers here, but Tailscale is what you want OP. Self-hosting is only a risk if you open ports. Tailscale doesn’t require opening any ports.

Alternatively, you could set up your own VPN and forward one port to the VPN. The risk of port forwarding to VPN such as Wireguard or OpenVPN is minimal.

The risk of being attacked applies to those that port forward web traffic so it can be accessed without a VPN by themselves or others. If you don’t do that, the risk is very low.

dieTasse@feddit.org on 26 Jan 07:42 collapse

Exactly what I wanted to say + don’t install something you don’t trust.

CompactFlax@discuss.tchncs.de on 25 Jan 22:32 next collapse

I have snort running on my firewall monitoring my LAN port. Does it help? No idea. Does it make me feel good because it blocks stuff? Yup. It does enforce IP blacklists from a feed, so it’s a start.

Keeping an loose eye on things and watching for extra network traffic, cpu, ram usage is what I do.

irmadlad@lemmy.world on 26 Jan 15:28 collapse

I run the Suricata package in pFsense which I would say is kissing cousins to Snort. It actually does work very well. In fact, on occasion, too well. I’d rather that that just having my jimmy hanging out in traffic. I also employ the pfblockerng’s massive feed lists, and Tailscale packages on the standalone pFsense firewall, and a VPN on all devices. Network so tight they call it virgin. LOL Not really, but I tend to go a bit overboard on security measures.

neidu3@sh.itjust.works on 25 Jan 22:36 next collapse

It’s mostly automated exploit finders looking for low hanging fruit. fail2ban and up to date software is your friend.

Priyathium@lemmy.ml on 25 Jan 23:03 next collapse

That’s the point. It taught me things that I wouldn’t learn if it weren’t for that scared feeling. I agree that some sensitive things are better off my server.

You should start small and keep only things you want to be public, and services under basic logins. First logins, maybe admin admin but slowly you will get better and also place fail2ban and crowdsec. Once you have enough confidence and years of service on your belt. You can trust it with sensitive files under heavy guard.

irmadlad@lemmy.world on 25 Jan 23:22 next collapse

Dealing with this constant threat seems like it would be frightening enough as a full-time job, but this would only be a hobby project for me.

Hobbyist/Enthusiast here. Most of the bots are autonomous. They are deployed and constantly sniff for any little cracks and crevasses in the armor. Don’t be fooled tho, they are quite sophisticated. I see some have mentioned fail2ban, and Crowdsec. Both are very capable. UFW (uncomplicated firewall) is also very good. When I set up UFW and my external, standalone pfsense firewall, the way I go about it is to block everything, then step by step, open only the ports that absolutely have to be opened.

Tailscale is also a great overlay vpn along with netbird. Tailscale can also be used as an emergency entry to your server should you lock yourself out, so it has multiple uses. Additionally, since you say you have technical knowledge, Cloudflare Tunnel/Zero Trust pretty much wraps everything up. I know there are a lot of selfhosters dead set against Cloudflare, so that’s a decision you have to make. Cloudflare does not require you to open ports or fiddle with NAT. You set it up on your server, Cloudflare takes care of the rest. If you wanted additional protection, you could install Tailscale as an overlay on the server. The caveat to using Cloudflare Tunnel/Zero Trust is that you have to have a domain name that allows you to enter and use Cloudflare’s name servers for obvious reasons. You can get a domain anywhere although Cloudflare will sell you one if you wish to go that route.

Since I am the only user of my server, I’ve taken the additional step of implementing the hosts.allow/hosts.deny TCP Wrapper ACL files (although you can have multiple users with hosts.allow/hosts.deny). If you go this route, make sure you do the hosts.allow, so that when you edit the hosts.deny you’ll enter ALL : ALL for a default‑deny stance. For my purposes, multiple users cause multiple issues, so I don’t share. :p

Probably should go without saying you should use ssh keys when administrating the server via ssh.

ETA: Hope everyone is safe in the US with this frigid weather. ETA2: If you decide to go with Cloudflare Tunnel/Zero Trust, I have some notes that seems to have helped several people and I would be happy to share them.

excursion22@piefed.ca on 26 Jan 04:38 collapse

Please do share your Cloudflare notes.

irmadlad@lemmy.world on 26 Jan 12:30 collapse

I left tit in the box

irmadlad@lemmy.world on 26 Jan 00:25 next collapse

Yes…yet another comment. LOL Something you should do from the very start is take notes of everything you do on the server. I use Notepad++ for the rough draft while I’m setting something up. Copy/paste, write out commands, notations, what this or that does. Take prolific notes. I really can’t stress that enough. That way, if you need to back out of something, or if the wheels fall off, you can go right back to your notes. Don’t be lulled into the idea that you will be able to remember every last keystroke you’ve made. That rarely happens. Take notes.

When I have successfully deployed whatever I’m working on, then I go back, take my notes, clean them up, and place them in Obsidian and make backups of them.

bizdelnick@lemmy.ml on 26 Jan 10:23 collapse

Makin notes is good for sonething very simple. It’s better to automate deployment with salt, ansible or something similar. A bit more effort at first setup, much easier restoration. Self-documented.

irmadlad@lemmy.world on 26 Jan 12:20 collapse

In another life I worked as a Mech Eng for a Contractor firm. The rule was ‘If you didn’t write it down, it didn’t happen’. Over the years, that has bled into my personal life as well. I hear what you’re saying, and from what I’ve digested regarding Ansible, it is a quite powerful and capable package. However, let’s let OP stand up his first server. He’s already stressed about not being a botnet victim. So, perhaps some rudimentary steps are in order. Then you can blow his mind with Ansible. LOL

tal@lemmy.today on 26 Jan 00:57 next collapse

Have a limited attack surface will reduce exposure.

If, say, the only thing that you’re exposing is, oh, say, a Wireguard VPN, then unless there’s a misconfiguration or remotely-exploitable bug in Wireguard, then you’re fine regarding random people running exploit scanners.

I’m not too worried about stuff like (vanilla) Apache, OpenSSH, Wireguard, stuff like that, the “big” stuff that have a lot of eyes on them. I’d be a lot more dubious about niche stuff that some guy just threw together.

To put perspective on this, you gotta remember that most software that people run isn’t run in a sandbox. It can phone home. Games on Steam. If your Web browser has bugs, it’s got a lot of sites that might attack it. Plugins for that Web browser. Some guy’s open-source project. That’s a potential vector too. Sure, some random script kiddy running an exploit scanner is a potential risk, but my bet is that if you look at the actual number of compromises via that route, it’s probably rather lower than plain old malware.

It’s good to be aware of what you’re doing when you expose the Internet to something, but also to keep perspective. A lot of people out there run services exposed to the Internet every day; they need to do so to make things work.

RIotingPacifist@lemmy.world on 26 Jan 01:06 next collapse

Outbound firewall and SMAC protections.

If you compromise my server you’ll struggle to phone home without manual intervention, which is good enough to stop botnets.

irmadlad@lemmy.world on 26 Jan 01:50 collapse

pFsense + IDS/IPS segmenting network and a robust set of rules would pretty much get you there.

glizzyguzzler@piefed.blahaj.zone on 26 Jan 02:00 next collapse

The only thing that can get hacked is something that responds on the World Wide Web.

So you limit the scope of what talks to the WWW:

Wireguard VPN will not respond unless the magic keys are correct, it’s ideal security and obscurity. Put everything you can behind it.

For things I want on the WWW without a VPN, I split out two options otherwise.

1) Caddy checking mTLS certificates that basically allows a device access without extra steps - relying on Caddy to be strong and mTLS to be strong.

2) Authentik’s proxy check, I think Authelia has this too, but to access a site you hit an Authentik login first.

For both of those, you rely on those services not having 0-day hacks. More likely for these services to stay ahead of the game and/or fix quick than something that doesn’t exist just to do authentication. I run them in containers that are run by independent users and are read-only with capabilities limited, in a VM.

I’d say the Caddy route is more secure than Authentik, but it needs more effort to setup the certificate stuff. Authentik route needs a web browser to log in with. Obviously the WG VPN is primo.

Edit: also tailscale is just managed wireguard, so it has the same benefits as a wireguard vpn with the catch a company has access to your network also now. But really simplifies setup…..

Jakeroxs@sh.itjust.works on 26 Jan 16:15 collapse

Authelia does have it too, I use that with traefik

BigTurkeyLove@lemmy.world on 26 Jan 02:42 next collapse

Damn dawg, reading this made me not wanna self host my own instance. I was considering it.

bitcrafter@programming.dev on 26 Jan 04:05 collapse

Hey, now, just because I am an overly paranoid person does not mean that you have to be as well!

FreedomAdvocate@lemmy.net.au on 26 Jan 06:28 next collapse

What are you wanting to host? It’s pretty simple to not get hacked.

melroy@kbin.melroy.org on 26 Jan 10:48 next collapse

It's all about server hardening. See https://blog.melroy.org/2023/server-hardening/

Atemu@lemmy.ml on 26 Jan 13:13 collapse

Wow is that ever a load of snake oil.

I see this kind of guide as actively harmful because it creates a false sense of security.

lefaucet@slrpnk.net on 26 Jan 15:30 collapse

Is there bad advise on there?

I skimmed it and there’s lots of good advice I think.

I’m no security expert and this is an honest question.

[deleted] on 26 Jan 13:00 next collapse

.

Atemu@lemmy.ml on 26 Jan 13:35 next collapse

Yikes, lot’s of bad advice in this thread.

My advice: Go develop an actual threat model and find and implement mitigations to the threats you’ve identified.

If you can’t do that, that’s totally okay; it’s a skill that takes a lot of time and effort to learn and is well-compensated in the industry.

You will need to pay for it. Either through an individual assessment by someone who knows what they’re doing, managed hosting services where the hoster is contractually liable and has implemented such measures, by risking becoming part of a botnet or by not hosting in a world-public manner.

My recommendations:

  • Pay for proper managed hosting for every part of your system that you are not capable of securing yourself. This is a general rule that even experienced people follow by i.e. renting a VPS rather than exposing their own physical HW. There are multiple grades to this such as SaaS, PaaS and IaaS.
  • Research, evalue and implement low-hanging fruit measures that massively reduce the attack surface. One such measure would be to not host in a manner that is accessible to the entire world and instead pay for managed authenticated access that is limited to select people (i.e. VPN such as Tailscale)
  • git gud
Sanctus@anarchist.nexus on 26 Jan 16:45 next collapse

Well for one its not as automatic as it sounds. Basic protections will get you far. I have a minecraft server exposed but it only accepts connections from 3 specific places. Remember its the same as ever other real life deterrant, make yourself less of a target than the next guy. It also really helps not having juicy company data on your network. Home networks are way less of a target because you dont have any fine booty to loot.

teawrecks@sopuli.xyz on 26 Jan 20:32 next collapse

Step 1 is to do everything inside your network with data you don’t care about. Get comfortable starting services, visiting them locally, and playing around with them. See what you like and don’t like. Feel free to completely nuke everything and start from scratch a few times. (Containers like Docker make this super easy).

Step 2 is to start relying on it for things inside your network. Have a NAS, maybe home assistant, or some other services like Immich or Navidrome. Figure out how to give services access to your data without relying on them to not harm it (use read only mounts, permissions, snapshots, etc.)

Step 3 is to figure out how to make services more accessible away from home. Whether that is via a VPN, or something like tailscale, or just carefully opening specific ports to specific secure and up-to-date services. This is the part you’re feeling anxious about, and I think you’ll feel less anxious if you do steps 1 and 2 first and not even think about 3 yet. Consider it its own challenge, and just do one challenge at a time.

golden_zealot@lemmy.ml on 26 Jan 21:37 next collapse

If you don’t need stuff publicly accessible, and just need it accessible to you, then set up a small computer on the network as an ssh Bastion host/jump server, put it on a VPN connection with a VPN provider that offers dyndns, forward the ssh port through the dyndns, and then off network, reverse proxy in with socks5 via key based ssh -D to gain access to all the services available inside the LAN.

Been doing this for a few years, works great and no one is getting in without my ssh key.

Appoxo@lemmy.dbzer0.com on 26 Jan 22:05 collapse

Or with a exploit/zero day.
Chance is close to zero but never absolute 0 ;)

golden_zealot@lemmy.ml on 26 Jan 22:15 collapse

True enough.

dil@lemmy.zip on 26 Jan 21:56 next collapse

Tailscale on everything

GreenKnight23@lemmy.world on 27 Jan 01:38 next collapse

  • routine patching
  • siem log aggregation
  • proper alerting metrics and notifications
  • routine virus scanning
  • proper network segregation between your NATd network and your personal network
  • firewall firewall firewall
  • expose your applications to the internet through a WAF, never directly

if you can do all these things properly, then there shouldn’t be too much danger in selfhosting your apps publicly.

wonderingwanderer@sopuli.xyz on 27 Jan 05:15 collapse

Would something like Anubis or Iocaine prevent what you’re worried about?

I haven’t used either, but from what I understand they’re both lightweight programs to prevent bot scraping. I think Anubis analyzes web traffic and blocks bots when detected, and Iocaine does something similar but also creates a maze of garbage data to redirect those bots into, in order to poison the AI itself and consume excessive resources on the end of the companies attempting to scrape the data.

Obviously what others have said about firewalls, VPNs, and antivirus still applies; maybe also a rootkit hunter and Linux Malware Detect? I’m still new to this though, so you probably know more about all that than I do. Sorry if I’m stating the obvious.

Not sure if this is overkill but maybe Network Security Toolkit might have some helpful tools as well?