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.

  • vext01@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    6
    ·
    4 months ago

    I recall hearing that openssh has something like fail2ban built-in now. I forget the name of the feature.

    • loudwhisper@infosec.pub
      cake
      OP
      link
      fedilink
      English
      arrow-up
      5
      ·
      4 months ago

      AFAIK I know that SSH has MaxAuthTries and LoginGraceTime, but all it does is terminating the SSH session (I.e. slow down at most), it won’t block the IP via firewall or configuration.

      Not sure if there is a recent feature that does the same.

      • vext01@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        5
        ·
        4 months ago

        It’s this (excuse formatting): https://www.openssh.com/releasenotes.html

        sshd(8) will now penalise client addresses that, for various reasons, do not successfully complete authentication. This feature is controlled by a new sshd_config(5) PerSourcePenalties option and is on by default.

        sshd(8) will now identify situations where the session did not authenticate as expected. These conditions include when the client repeatedly attempted authentication unsucessfully (possibly indicating an attack against one or more accounts, e.g. password guessing), or when client behaviour caused sshd to crash (possibly indicating attempts to exploit bugs in sshd).

        When such a condition is observed, sshd will record a penalty of some duration (e.g. 30 seconds) against the client’s address. If this time is above a minimum configurable threshold, then all connections from the client address will be refused (along with any others in the same PerSourceNetBlockSize CIDR range) until the penalty expire.

        Repeated offenses by the same client address will accrue greater penalties, up to a configurable maximum. Address ranges may be fully exempted from penalties, e.g. to guarantee access from a set of trusted management addresses, using the new sshd_config(5) PerSourcePenaltyExemptList option.