Fail2ban may provide a false sense of security
New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

Fail2ban may provide a false sense of security

Just throwing this out there for discussion...

The old stalwart fail2ban may not be providing the security you think it is.

Specifically, a "low and slow" attack from a botnet will go unnoticed.

Fail2ban will detect and block multiple attempts from the same IP, but not repeated attempts from different IPs.

You may want to try:

grep -c Found /var/log/fail2ban.log

and

grep -c Ban /var/log/fail2ban.log

and ponder the numbers.

«1

Comments

  • msg7086msg7086 Member

    We use fail2ban to save a few disk space for the auth log, not for making it secure. Key pairs or certificates are the way to security.

    Thanked by 2Aidan willie
  • sleddogsleddog Member

    @msg7086 said:
    We use fail2ban to save a few disk space for the auth log, not for making it secure. Key pairs or certificates are the way to security.

    For SSH yes, but fail2ban has much wider applicability -- e.g. for public services such as imap, smtp that aren't secured the same as SSH.

    Thanked by 1msg7086
  • simonindiasimonindia Member
    edited August 7

    Make your choice on your own But i can help you to make them right.

  • You can always tweak the config to tighten the time limits before banning.

    Decent password strength makes a world of difference. Usually the time to crack with a "low and slow" is incredibly futile.

  • sleddogsleddog Member

    Certainly interesting. Thanks.

    Thanked by 1simonindia
  • FHRFHR Member, Provider

    Fail2ban should be used as a tool used for reducing clutter in logs caused by automated scanning, not as a defense mechanism in the first place.

    SkylonHost | Affordable Semi-Dedicated VPS - Enjoy performance to the fullest extent. | 40% OFF promo
    Prague, CZ location coming soon!

  • FHRFHR Member, Provider

    sleddog said: For SSH yes, but fail2ban has much wider applicability -- e.g. for public services such as imap, smtp that aren't secured the same as SSH.

    The applications themselves often have rate limiting, use it if possible. To go with your mail server example, both Dovecot and Postfix have that.

    Thanked by 1jar

    SkylonHost | Affordable Semi-Dedicated VPS - Enjoy performance to the fullest extent. | 40% OFF promo
    Prague, CZ location coming soon!

  • sleddogsleddog Member

    @FHR said:
    Fail2ban should be used as a tool used for reducing clutter in logs caused by automated scanning, not as a defense mechanism in the first place.

    How would you protect an imap or smtp server from a botnet low and slow authentication attack?

  • eva2000eva2000 Member

    Mark_O_Polo said: You can always tweak the config to tighten the time limits before banning.

    indeed lowering the threshold works too in conjunction with rate limiting and using native jail fail2ban-client status info can reveal same stats as the greps

    my custom fail2ban status output statistics

    you can also parse your fail2ban logs to get some stats as to patterns for banned and repeated ban (restored bans) IP addresses too i.e.

    ---------------------------------------
    All Time: Top 10 Banned IP Addresses:
          4 149.xxx.xxx.xxx [nginx-req-limit]
          3 104.237.xxx.xxx [wordpress-pingback]
          2 149.xxx.xxx.xxx [wordpress-auth]
          2 149.xxx.xxx.xxx [http-xensec]
    ---------------------------------------
    All Time: Top 10 Restored Banned IP Addresses:
         25 104.237.xxx.xxx [wordpress-pingback]
          2 149.xxx.xxx.xxx [nginx-req-limit]
    ---------------------------------------
    Yesterday: Top 10 Banned IP Addresses:
          4 149.xxx.xxx.xxx [nginx-req-limit]
          2 149.xxx.xxx.xxx [wordpress-auth]
          2 149.xxx.xxx.xxx [http-xensec]
          2 104.237.xxx.xxx [wordpress-pingback]
    ---------------------------------------
    Yesterday: Top 10 Restored Banned IP Addresses:
         12 104.237.xxx.xxx [wordpress-pingback]
          2 149.xxx.xxx.xxx [nginx-req-limit]
    ---------------------------------------
    Today: Top 10 Banned IP Addresses:
    ---------------------------------------
    Today: Top 10 Restored Banned IP Addresses:
          8 104.237.xxx.xxx [wordpress-pingback]
    ---------------------------------------
    1 hr ago: Top 10 Banned IP Addresses:
    ---------------------------------------
    1 hr ago: Top 10 Restored Banned IP Addresses:
    ---------------------------------------
    
    Thanked by 1Mark_O_Polo
    * Centmin Mod Project (HTTP/2 support + ngx_pagespeed + Nginx Lua + Vhost Stats)
    * Centmin Mod LEMP Stack Quick Install Guide
  • @FHR said:
    Fail2ban should be used as a tool used for reducing clutter in logs caused by automated scanning, not as a defense mechanism in the first place.

    Why would you not use it as an early defense mechanism in a layered strategy?

    It has it's place beyond just log clutter.

  • sleddogsleddog Member

    @FHR said:

    sleddog said: For SSH yes, but fail2ban has much wider applicability -- e.g. for public services such as imap, smtp that aren't secured the same as SSH.

    The applications themselves often have rate limiting, use it if possible. To go with your mail server example, both Dovecot and Postfix have that.

    Rate-limiting for postfix and dovecot are usually scaled in connections/second, or per minute, and track connecting IPs, and do nothing for a low and slow attack.

  • FHRFHR Member, Provider
    edited August 7

    @sleddog said:

    @FHR said:
    Fail2ban should be used as a tool used for reducing clutter in logs caused by automated scanning, not as a defense mechanism in the first place.

    How would you protect an imap or smtp server from a botnet low and slow authentication attack?

    Bots brute forcing mail servers usually don't go slow nor change IPs that often. What you can do with e.g. Dovecot is to insert delay after each unsuccessful attempt.

    That means that if someone tries to log in with a wrong password, Dovecot will artificially insert a delay before the "auth failed" response - that way the bot will have to wait for let's say 5 seconds before trying again. I would call that enough.

    Brute forcing at a rate 1 attempt per 5 seconds becomes "slightly" ineffective very quickly.

    SkylonHost | Affordable Semi-Dedicated VPS - Enjoy performance to the fullest extent. | 40% OFF promo
    Prague, CZ location coming soon!

  • sleddogsleddog Member

    FHR said: That means that if someone tries to log in with a wrong password, Dovecot will artificially insert a delay before the "auth failed" response - that way the bot will have to wait for let's say 5 seconds before trying again. I would call that enough.

    But again, these are tracked by IP, and aren't applied in a situation where different IPs attempt a login to the same mail account.

  • FHRFHR Member, Provider

    sleddog said: But again, these are tracked by IP, and aren't applied in a situation where different IPs attempt a login to the same mail account.

    That's certainly true - and as far as I know, there is no solution to this issue. I would say set minimum password complexity policies and let the bots do their thing.

    SkylonHost | Affordable Semi-Dedicated VPS - Enjoy performance to the fullest extent. | 40% OFF promo
    Prague, CZ location coming soon!

  • @sleddog said:
    But again, these are tracked by IP, and aren't applied in a situation where different IPs attempt a login to the same mail account.

    Block with iptable by range /24 or whatever you need.

  • @FHR said:

    @sleddog said:

    @FHR said:
    Fail2ban should be used as a tool used for reducing clutter in logs caused by automated scanning, not as a defense mechanism in the first place.

    How would you protect an imap or smtp server from a botnet low and slow authentication attack?

    Bots brute forcing mail servers usually don't go slow nor change IPs that often. What you can do with e.g. Dovecot is to insert delay after each unsuccessful attempt.

    That means that if someone tries to log in with a wrong password, Dovecot will artificially insert a delay before the "auth failed" response - that way the bot will have to wait for let's say 5 seconds before trying again. I would call that enough.

    Brute forcing at a rate 1 attempt per 5 seconds becomes "slightly" ineffective very quickly.

    Yes. That would do for most setups. In my case I manage couple mail servers for my clients. The thing that bothers and made me setup defense is how many in house attacks happen. how meticulous the attackers are in my case the assistant of the CFO tried for whole year are more brute forcing the CFO's email getting banned every single day. She gained access in the last. Unfortunate for them I joined them just last year. Checking the logs show me that there were same ratio of attacks from internet and intranet.

    I'm surprised that this had happen this firm don't have anything to steal data wise. There is no industrial espionage even after there is one bad actor who had the patience for this kind of attack. She worked there 15+ years so yes these kind of protection is required in some cases.

    Make your choice on your own But i can help you to make them right.

  • sleddogsleddog Member

    FHR said: That's certainly true - and as far as I know, there is no solution to this issue. I would say set minimum password complexity policies and let the bots do their thing.

    I experienced a distributed attack on smtps recently, which fail2ban did not detect and which I noticed only by looking at log files. I changed the fail2ban smtps config to ban after 1 failure, and collected 500 IPs in an hour. Let it run for a few hours, then dumped them all into an ipset.

  • eva2000eva2000 Member

    sleddog said: But again, these are tracked by IP, and aren't applied in a situation where different IPs attempt a login to the same mail account.

    You probably need to lower the threshold for fail2ban and for postfix at least see smtpd_client_auth_rate_limit http://www.postfix.org/smtpd.8.html

       smtpd_client_auth_rate_limit (0)
              The maximal number of AUTH commands that any client  is  allowed
              to  send to this service per time unit, regardless of whether or
              not Postfix actually accepts those commands.
    

    Dovecot has it's own mechanisms I believe with auth_failure_delay i.e. https://wiki.dovecot.org/Authentication/Penalty

    If the server only has you as one user, you could set fail2ban threshold to ban after 1 failure like you did. As if you ever enter the wrong details, you could unblock yourself via out of band console access anyway heh.

    Thanked by 1sleddog
    * Centmin Mod Project (HTTP/2 support + ngx_pagespeed + Nginx Lua + Vhost Stats)
    * Centmin Mod LEMP Stack Quick Install Guide
  • FHRFHR Member, Provider

    sleddog said: changed the fail2ban smtps config to ban after 1 failure

    Depending on the environment, you might ban legitimate people with this

    SkylonHost | Affordable Semi-Dedicated VPS - Enjoy performance to the fullest extent. | 40% OFF promo
    Prague, CZ location coming soon!

  • eva2000eva2000 Member

    FHR said: Depending on the environment, you might ban legitimate people with this

    Actually might serve as a good tool to weed out repeat offenders - sitting them down and explaining the virtues of using a password manager hehe

    * Centmin Mod Project (HTTP/2 support + ngx_pagespeed + Nginx Lua + Vhost Stats)
    * Centmin Mod LEMP Stack Quick Install Guide
  • sleddogsleddog Member

    FHR said: Depending on the environment, you might ban legitimate people with this

    Maybe but doubtful. There's a whitelist for local ISPs. But if one of my users is vacationing in Brazil it's possible :)

  • williewillie Member

    The "recidive" (Iirc they spell it like that) rule implements longer bans and it was added a few versions ago. The version of fail2ban in the debian 9 (but not earlier) repo has it.

  • oneilonlineoneilonline Member, Provider

    Yea, I would call fail2ban a security tool, not to secure something. Used properly it's a great tool!

  • @willie said:
    The "recidive" (Iirc they spell it like that) rule implements longer bans and it was added a few versions ago. The version of fail2ban in the debian 9 (but not earlier) repo has it.

    Yep the same thing I shared earlier with official tag on it.

    But the fail2ban team just named it bad. So bad I still share a link than this name.

    Make your choice on your own But i can help you to make them right.

  • h2oh2o Member
    edited August 8

    i used a 6-digit password and it havn't been bursted so far.

    my auth.log has 20+MB big.

    the more dangerous, the safer it is.

    LOL

    Thanked by 1klikli
  • wgetwget Member

    @h2o said:
    i used a 6-digit password and it havn't been bursted so far.

    my auth.log has 20+MB big.

    the more dangerous, the safer it is.

    LOL

    But have your installed fail2ban or any similar tool?

    If nothing similar is installed, it does sound quite dangerous. :)

  • h2oh2o Member

    @wget said:

    @h2o said:
    i used a 6-digit password and it havn't been bursted so far.

    my auth.log has 20+MB big.

    the more dangerous, the safer it is.

    LOL

    But have your installed fail2ban or any similar tool?

    If nothing similar is installed, it does sound quite dangerous. :)

    Nope, believe or not, my vps is naked for a few months.

    Fail2ban will cause a cpu high load due to a large auth.log when startup.

    However, weakly password is not recommended.

    Still waiting to be bursted... LOL

  • strict pubkey auth + multi-day ban times + a couple of whitelisted IPs.

    I think I'll stick with this for a while.

  • sleddogsleddog Member

    What I've done is create a ipset whitelist of Canada/US, that should cover all networks from which my users are authenticating to postfix & dovecot, and then...

    • Gathered all IPs ("Found") from the fail2ban log, sorted and removed dups.

    • Iterated through the IP list, removing any found in the ipset whitelist.

    • Added the remainder to a permanent ipset blacklist.

    There's an hourly cron script that looks for new fail2ban log entries, tests then against the whitelist and adds then to the blacklist as required.

    You might be interested to know that of the 1,200+ collected IPs, 94% were not found in the whitelist :)

    Thanked by 1eva2000
  • @eva2000 said:
    you can also parse your fail2ban logs to get some stats as to patterns for banned and repeated ban (restored bans) IP addresses too i.e.

    Yup. Thanks to that I got a nice blacklist where at least a lot of those china dudes are in.

    Thanked by 1eva2000
  • sleddogsleddog Member

    Here's the cron script if anyone's interested.

    #!/bin/bash
    DATADIR='/root/scripts/ipset/data'
    LOGFILE=/var/log/fail2ban.log
    LINEFILE=${DATADIR}/lastline
    LASTLINE=$(wc -l $LOGFILE | awk '{print $1}')
    
    STARTLINE=0
    if [ -e "$LINEFILE" ]; then
        STARTLINE=$(cat $LINEFILE)
    fi
    # Allow for rotation of the log.
    if [ "$STARTLINE" -gt "$LASTLINE" ]; then
        STARTLINE=0
    fi
    
    DATA=$(/usr/bin/tail -n +${STARTLINE} $LOGFILE | grep Found | awk '{print $8}')
    
    echo $LASTLINE > $LINEFILE
    
    if [ -z "$DATA" ]; then
        exit 0
    fi
    
    DATA_ARRAY=($DATA)
    for IP in ${DATA_ARRAY[@]}; do
        if [[ $IP =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
            /usr/sbin/ipset -q test whitelist $IP
            if [ "$?" -eq "0" ]; then
                echo $IP >> ${DATADIR}/foundwhite
            else
                /usr/sbin/ipset -q add ipBlack $IP
                if [ "$?" -eq "0" ]; then
                    echo $IP >> ${DATADIR}/autoblack
                fi
            fi
        fi
    done
    
    exit 0
    
  • vovlervovler Member

    Create a VPS that you use as VPN, on the main VPS/Dedicated only allow logins using the IP of the secondary VPS.

  • sidewindersidewinder Member
    edited August 8

    fail2ban is pretty overrated imo. There is no way to permaban an ip, I always spend about an hour setting it up and configuring it for every new server - it doesn't matter what operating system it is either - there is always some tweaking to get it working right.

    Recidive won't block forever - wtf?

    I'd probably bet 20% of the people that have it configured did it wrong and it's actually doing nothing.

    I ran BFD for around 5 years and there were thousands of entries in my deny file - no idea if this is a bad idea but the log files were way quieter than with fail2ban

  • @sidewinder said:
    fail2ban is pretty overrated imo. There is no way to permaban an ip, I always spend about an hour setting it up and configuring it for every new server - it doesn't matter what operating system it is either - there is always some tweaking to get it working right.

    I actually generate a blacklist file and iterate it in a script and add it to iptables. But yeah it's getting messy there :D

  • Ole_JuulOle_Juul Member
    edited August 9

    It seems to me that this is not a case where generalizations are useful. I use fail2ban and no root login. The latter takes care of 99.99 percent it seems like since they all try to guess the root password which would be useless for login. I tend to use 12 digit passwords and I set fail2ban to 10 days mostly. How long would it take somebody using this so-called "slow" method? They would have 2 guesses per 10 days to figure out a user name, then when they got that they'd have another 2 guesses per 10 days to get a 12 digit password. If they got that far, they'd then have 2 guesses per 10 days to guess the root password. You do the math*.

    That said, I'm under no illusion that there isn't some other way in which I have yet to learn about. On my personal mail relay I've set fail2ban to allow 2 tries as well, and of course the same 10 day ban. In that case they would only have to guess the user names, which would not actually be that easy since there are very few of them.

    *Yes I'm aware that an attacker will keep changing IP, but it seems in practice that they have limited amounts of those, and 2 tries is still not enough under those circumstances, since they seem to have their own delay as well.

  • sleddogsleddog Member

    Consider these dovecot auth logs entries (which are real except for the 'domain.com'):

    Aug 09 08:47:02 auth-worker(27406): Info: sql([email protected],200.23.231.147): Password mismatch
    Aug 09 08:55:21 auth-worker(27821): Info: sql([email protected],200.152.107.102): Password mismatch
    Aug 09 09:35:16 auth-worker(30377): Info: sql([email protected],191.53.215.147): Password mismatch
    Aug 09 09:44:47 auth-worker(30573): Info: sql([email protected],187.111.58.219): Password mismatch
    
    

    Do they represent 4 random hackers, or are they conceivably part of a coordinated effort?

  • h2oh2o Member
    edited August 9

    Hey you guys, who have the honey pot to take a look what they'r going to do after login?

    I am very curious. XD

  • HxxxHxxx Member

    Alright Sir, we will help you with your math. Is over 9000 according to my 500IQ.

    @Ole_Juul said:
    It seems to me that this is not a case where generalizations are useful. I use fail2ban and no root login. The latter takes care of 99.99 percent it seems like since they all try to guess the root password which would be useless for login. I tend to use 12 digit passwords and I set fail2ban to 10 days mostly. How long would it take somebody using this so-called "slow" method? They would have 2 guesses per 10 days to figure out a user name, then when they got that they'd have another 2 guesses per 10 days to get a 12 digit password. If they got that far, they'd then have 2 guesses per 10 days to guess the root password. You do the math*.

    That said, I'm under no illusion that there isn't some other way in which I have yet to learn about. On my personal mail relay I've set fail2ban to allow 2 tries as well, and of course the same 10 day ban. In that case they would only have to guess the user names, which would not actually be that easy since there are very few of them.

    *Yes I'm aware that an attacker will keep changing IP, but it seems in practice that they have limited amounts of those, and 2 tries is still not enough under those circumstances, since they seem to have their own delay as well.

  • Well this has worked out nicely I think.

    Changes:

    • I moved to blocking /24s rather than IPs. Wanted to see results in my lifetime.

    Blocking:

    • I'm currently blocking 1,048 /24s outside Canada/US, with 0-3 new ones being added per hour. At the start it was 15-20 per hour.
    • That's less than 0.01% of the internet blocked (please correct me).

    Affect on my users:

    • No blocking is done in Canada/US.
    • I estimate maybe 1% of my users travel outside Canada/US.
    • Abroad, users have a 1/10,000 chance worldwide of being on a blocked /24. Higher in some countries that shall go unnamed.
    • Port 443 is not blocked. Users can still access webmail even if their laptop/phone is blocked. (Repeated webmail login failures are dealt with separately - 3 strikes your out for a short time).

    Collateral damage:

    • Port 25 is not blocked. If there's a legitimate mailserver in a blocked /24 it can still send mail on port 25 to our server.

    Feedback appreciated!

  • But why can't it be forever? I don't get it...

    @willie said:
    The "recidive" (Iirc they spell it like that) rule implements longer bans and it was added a few versions ago. The version of fail2ban in the debian 9 (but not earlier) repo has it.

  • williewillie Member

    sidewinder said: But why can't it be forever? I don't get it...

    IP addresses come and go... it doesn't let that many queries through.

  • Sounds great, how are you blocking /24s that aren't in US or Canada? I like this strategy, just don't get how you can do it automagically and on the fly...

    @sleddog said:
    Well this has worked out nicely I think.

    Changes:

    • I moved to blocking /24s rather than IPs. Wanted to see results in my lifetime.

    Blocking:

    • I'm currently blocking 1,048 /24s outside Canada/US, with 0-3 new ones being added per hour. At the start it was 15-20 per hour.
    • That's less than 0.01% of the internet blocked (please correct me).

    Affect on my users:

    • No blocking is done in Canada/US.
    • I estimate maybe 1% of my users travel outside Canada/US.
    • Abroad, users have a 1/10,000 chance worldwide of being on a blocked /24. Higher in some countries that shall go unnamed.
    • Port 443 is not blocked. Users can still access webmail even if their laptop/phone is blocked. (Repeated webmail login failures are dealt with separately - 3 strikes your out for a short time).

    Collateral damage:

    • Port 25 is not blocked. If there's a legitimate mailserver in a blocked /24 it can still send mail on port 25 to our server.

    Feedback appreciated!

  • SplitIceSplitIce Member, Provider

    The problem with fail2ban and similar common security tools is often not the tool (which is reasonably well developed, and does what it says) but the user. A large percentage of users install these tools in a belief that doing so makes them secure (as if 100% secure is possible), it doesn't.

    Whats worse is this can lead to issues later on (something we see reasonably often) when incorrect IPs get banned (made even better by some users who don't even know they installed fail2ban/csf etc). A common cause of this is CSF more so than fail2ban due to bans enacted on udp ports or on unallocated ports (aka port scan protection) both of which are vulnerable to bans on spoofed addresses (targetting infrastructure, large clients or even other players on games that disclose player ips).

    X4B - DDoS Protection: EU & US affordable DDoS protection including Layer 7 mitigation.
    Latest Offer: 1TB and 2TB Anycast DDoS Protection (March Madness)
  • Jona4sJona4s Member
    edited August 13

    If you close all your ports (-j DROP), and only connect to SSH using Port Knocking, nobody will scan your box anymore, because all ports will timeout.

    The only port that needs to be open is 80, and you have Cloudflare for that.

    Just shout WOW

  • sidewinder said: Sounds great, how are you blocking /24s that aren't in US or Canada? I like this strategy, just don't get how you can do it automagically and on the fly...

    I created an ipset called 'whitelist' and then downloaded & imported CIDR-format files from ipdeny.com

    [prompt:] wget http://www.ipdeny.com/ipblocks/data/aggregated/ca-aggregated.zone
    [prompt:] wget http://www.ipdeny.com/ipblocks/data/aggregated/us-aggregated.zone
    [prompt:] ipset create whitelist hash:net
    [prompt:] ./loadwhite.sh ca-aggregated.zone
    [prompt:] ./loadwhite.sh us-aggregated.zone
    

    The loadwhite.sh script:

    #!/bin/bash
    if [ -z "$1" ]; then
            echo "Usage: ./loadwhite.sh "
            exit 0
    fi
    FILE=$1
    if [ -e "$FILE" ]; then
            while read LINE
            do
                    if [ ! -z "$LINE" ]; then
                            IP=$LINE
                            ipset add whitelist $IP
                    fi
            done < $FILE
    fi
    exit 0

    The you can test an IP against the whitelist.

    Thanked by 1plumberg
  • mfsmfs Member

    A couple of suggestions on this ipset approach: rather than adding each ip with a loop (which is painfully painful for big sets, even more for sets meant to be updated on a daily or weekly basis) you may want to create an ipset restore list to import, and before that you may want to optimize its performance; both goals may be accomplished with iprange's print-prefix, ipset-reduce and ipset-reduce-entries switches.

    Thanked by 1sleddog
  • Fun stats! Failed authentications for smtp/imap/pop are now down to barely a handful per day.

    Here's the number of unique /24's blocked during the past week.

                               China   331  26%
                              Brazil   166  13%
                             Vietnam   122  10%
                  Russian Federation    55   4%
                             Unknown    36   3%
                               India    35   3%
                             Ecuador    30   2%
                               Egypt    29   2%
                           Indonesia    29   2%
                              Poland    27   2%
                               Korea    26   2%
                               Italy    25   2%
                            Malaysia    23   2%
                            Thailand    20   2%
                              Taiwan    16   1%
                              Mexico    15   1%
                           Argentina    13   1%
                      Czech Republic    12   1%
                               Spain    12   1%
                            Pakistan    11   1%
                            Colombia    10   1%
                             Ukraine    10   1%
                        South Africa    10   1%
                 Antigua and Barbuda     9   1%
                            Bulgaria     9   1%
                          Bangladesh     9   1%
                         Netherlands     8   1%
                               Japan     7   1%
                              Serbia     7   1%
                            Cambodia     7   1%
                         New Zealand     6   0%
                           Singapore     6   0%
                               Ghana     6   0%
                      United Kingdom     6   0%
                         Philippines     6   0%
                              Zambia     6   0%
                                Oman     5   0%
                             Belarus     5   0%
                              Belize     5   0%
                            Portugal     4   0%
                             Albania     4   0%
                               Nepal     4   0%
                             Romania     4   0%
    Lao People's Democratic Republic     4   0%
                             Georgia     3   0%
                              Turkey     3   0%
                             Lebanon     3   0%
                              Jordan     3   0%
                              Panama     3   0%
                             Hungary     3   0%
                               Kenya     3   0%
                              France     3   0%
                          Azerbaijan     3   0%
                               Chile     3   0%
                              Israel     3   0%
                  Dominican Republic     3   0%
                             Bahrain     2   0%
                            Tanzania     2   0%
                       United States     2   0%
                          Kazakhstan     2   0%
                             Moldova     2   0%
                             Germany     2   0%
                           Lithuania     2   0%
                           Australia     2   0%
                   Brunei Darussalam     2   0%
                                Iran     2   0%
                           Hong Kong     2   0%
                            Slovenia     2   0%
                United Arab Emirates     2   0%
                          Tajikistan     1   0%
                                Peru     1   0%
                           Venezuela     1   0%
                                Iraq     1   0%
                               Niger     1   0%
                             Somalia     1   0%
                             Bolivia     1   0%
                             Morocco     1   0%
                          Uzbekistan     1   0%
                          Costa Rica     1   0%
                             Belgium     1   0%
              Bosnia and Herzegovina     1   0%
                               Qatar     1   0%
                              Greece     1   0%
                  Satellite Provider     1   0%
                             Myanmar     1   0%
                            Paraguay     1   0%
                             Denmark     1   0%
                            Slovakia     1   0%
                           Macedonia     1   0%
    
                               TOTAL  1272
    
  • edited August 21

    It's almost useless now a days imo. Only gets very low hanging fruit. Most bots spread scans out over hundreds/thousands of IP's with a large amount of time between hits on the same IP. So then you gotta increase your scan time which increases the likelyhood of false positives and banning legitimate stuff.

    It's almost not worth it for the amount of administrative overhead it adds fiddling around with it. I just use the SSH filters. Binary installs are usually configured to do that by default so no real setup required.

    I suppose it's useful to reduce noise/logging activity but not much else.

  • LosPollosHermanos said: Most bots spread scans out over hundreds/thousands of IP's with a large amount of time between hits on the same IP

    You haven't read the thread?

  • edited August 21

    @eva2000 said:-------

    The script kiddies are about 10 steps ahead of you. They know all about fail2ban and exactly how to get around it. So you are just stopping the lowest hanging fruit by fiddling with scan/ban times etc and trying to optimize filters etc. It's a never ending thing once you start doing that.

Sign In or Register to comment.