Hi, recently (ironically, right after sharing some of my posts here on Lemmy) I had a higher (than usual, not high in general) number of “attacks” to my website (I am talking about dumb bots, vulnerability scanners and similar stuff). While all of these are not really critical for my site (which is static and minimal), I decided to take some time and implement some generic measures using (mostly) Crowdsec (fail2ban alternative?) and I made a post about that to help someone who might be in a similar situation.

The whole thing is basic, in the sense that is just a way to reduce noise and filter out the simplest attacks, which is what I argue most of people hosting websites should be mostly concerned with.

  • incogtino@lemmy.zip
    link
    fedilink
    English
    arrow-up
    0
    ·
    3 months ago

    Genuine question from someone with a single page static site - why is Cloudflare a useless suggestion?

  • xinayder@infosec.pub
    link
    fedilink
    English
    arrow-up
    0
    ·
    2 months ago

    Can you use CrowdSec to track logs from a k8s pod? Say I have my website and some other services hosted on a k3s cluster, do I need to spin up a new pod for CrowdSec or should it be installed on the host?

    • loudwhisper@infosec.pubOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 months ago

      Hey, the short answer is yes, you can.

      I would elaborate a little more:

      • First, you have the problem of sourcing the data. In essence, Crowdsec won’t be able to go and fetch those logs for you dynamically, but can go and take those logs from a file (you can do a dirty solution like a sidecar deployment) or from a stream. You can deploy crowdsec in multiple modes, and you can have many instances that talk to each other. You can also simply have some process tailing the pod logs and sending them to a file crowdsec has access to or serving them as a stream (see https://doc.crowdsec.net/docs/data_sources/intro).
      • The above means that it doesn’t really matter whether you run Crowdsec inside your cluster (it does have a Helm chart) or on the host. Ultimately all it matters is that crowdsec has access to your pods logs (for example, the logs of your ingress controller).
      • The next piece is the remediation component. What do you want crowdsec to do, once it is able to detect bad IPs? If you want to just add IPs to the firewall, then it might make more sense running it on the host(s) you use in ingress, if you want to add the IPs to network policies you can do it, but you need to develop your own remediation components. I am planning to write a remediation component that will add the IPs to Hetzner firewall, some other systems are already supported, but this would be a way to basically block the IPs outside your cluster. For nginx ingress controller there is already a pre-made remediation component .

      In practice I personally would choose a simple setup where the interesting logs are just forwarded (in Syslog format for example) to a single crowdsec instance. If you have ingress from a single node, I’d go for running it on the host and banning via firewall, if you have multiple ingress nodes, then I would run it inside the cluster and ban via a loadBalancer/cloud firewall/whatever you have in front.

      In essence, I would spend some time to think about your preferences, and it might take a little bit to make the setup clean, but I think you have plenty of flexibility to do what you prefer. Let me know if you want to bounce some more ideas!

  • 9tr6gyp3@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    3 months ago

    Good read.

    I would just like to add some additional information that favors changing your SSH port to something other than the default. When crawlers are going around the internet looking for vulnerable SSH servers, they’re more than likely going to have an IP range and specifically look for port 22.

    Now can they go through and scan your IP and all of its ports to look for the SSH service? Yes. But you will statistically have less interactions with bad actors this way since they might specifically be looking for port 22.

    • loudwhisper@infosec.pubOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 months ago

      Thanks! I did mention this briefly, although I belong to the school that “since I am anyway banning IPs that fail authentication a few times, it’s not worth changing the port”. I think that it’s a valid thing especially if you ingest logs somewhere, but if you do don’t choose 2222! I have added a link to shodan in the post, which shows that almost everybody who changes port, changes to 2222!

    • schizo@forum.uncomfortable.business
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 months ago

      As a side note, don’t be cute and pick port 221 or 2222 or 22022 or whatever that’s got “22” in it.

      I know that sounds silly but the slightly less stupid bots are written by people who understand people do things like that and account for them, and thus port 2222 isn’t actually better than 22, or whatever.

      • kitnaht@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        3 months ago

        imho - never expose that shit anyways, and VPN into your local network first. Only thing I ever expose to the internet is 80/443.

        At the very least, if you’re going to expose an SSH session to the internet, set up some sort of port-knocking. It’s security by obscurity, sure - but it will keep all but the most ardent intruders out.