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?

  • ShortN0te@lemmy.mlEnglish
    25·
    13 hours ago

    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.

      • cecilkorik@lemmy.caEnglish
        8·
        11 hours ago

        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.