Return to Answer

As mentioned by Michael Hampton in a couple of comments, the reaction time, how often fail2ban checks the logs, has nothing to do with the findtime parameter. fail2ban is expected to read new log data every second or so (it will depend on your computer load, but it should be really fast since in most case new log data will still be in memory, in a kernel buffer.)

The findtime=... defines how far back logs are checked. The filter is checked against input that has a date between now - findtime and now. If the filter found maxretry or more lines of log that matched (not counting those that also match the ignoreregex) within that period of time (now - findtime to now), then it emits the ban action.

  ancient past  |     past       |       ban         |   future
----------------+--*--*-*--*---*-+-------------------+------------->
                |                |                   |
                |                |                   +--> now + bantime
                |                +--> now
                +--> now - findtime

There is a graph showing the timeline. Logs part of ancient past are ignored. Logs between now - findtime and now, section named past, are checked for matches. If the number of matches (represented by asterisks) is >= maxretry then a ban is started at now. The ban lasts until now + bantime. Note that hits with the same IP once the IP was banned should not happen for the port for which it was banned. It could still happen for other ports, though.

So by increasing the findtime=... you do not affect the reaction time, however, you increase the chance for an IP to get banned by the corresponding filter.

As mentioned by Michael Hampton in a couple of comments, the reaction time, how often fail2ban checks the logs, has nothing to do with the findtime parameter. fail2ban is expected to read new log data every second or so (it will depend on your computer load, but it should be really fast since in most cases new log data will still be in memory, in a kernel buffer.)

The findtime=... defines how far back logs are checked. The filter is checked against input that has a date between now - findtime and now. If the filter found maxretry or more lines of log that matched (not counting those that also match the ignoreregex) within that period of time (now - findtime to now), then it emits the ban action.

  ancient past  |     past       |       ban         |   future
----------------+--*--*-*--*---*-+-------------------+------------->
                |                |                   |
                |                |                   +--> now + bantime
                |                +--> now
                +--> now - findtime

There is a graph showing the timeline. Logs part of ancient past are ignored. Logs between now - findtime and now, section named past, are checked for matches. If the number of matches (represented by asterisks) is >= maxretry then a ban is started at now. The ban lasts until now + bantime. Note that hits with the same IP once the IP was banned should not happen for the port for which it was banned. It could still happen for other ports, though.

So by increasing the findtime=... you do not affect the reaction time, however, you increase the chance for an IP to get banned by the corresponding filter.

As mentioned by Michael Hampton in a couple of comments, the reaction time, how often fail2ban checks the logs, has nothing to do with the findtime parameter. fail2ban is expected to read new log data every second or so (it will depend on your computer load, but it should be really fast since in most case new log data will still be in memory, in a kernel buffer.)

The findtime=... defines how far back logs are checked. The filter is checked against input that has a date between now - findtime and now. If the filter found maxretry or more lines of log that matched (not counting those that also match the ignoreregex) within that period of time (now - findtime to now), then it emits the ban action.

  ancient past  |     past       |       ban         |   future
----------------+--*--*-*--*---*-+-------------------+------------->
                |                |                   |
                |                |                   +--> now + bantime
                |                +--> now
                +--> now - findtime

There is a graph show the timeline. Logs part of ancient past are ignored. Logs between now - findtime and now, named past, are checked for matches. If the number of match (represented by asterisks) is >= maxretry then a ban is started at now. The ban lasts until now + bantime. Note that hits with the same IP once the IP was banned should not happen for the port for which it was banned. It could still happen for other ports, though.

So by increasing the findtime=... you do not affect the reaction time, however, you increase the chance for an IP to get banned by the corresponding filter.

As mentioned by Michael Hampton in a couple of comments, the reaction time, how often fail2ban checks the logs, has nothing to do with the findtime parameter. fail2ban is expected to read new log data every second or so (it will depend on your computer load, but it should be really fast since in most case new log data will still be in memory, in a kernel buffer.)

The findtime=... defines how far back logs are checked. The filter is checked against input that has a date between now - findtime and now. If the filter found maxretry or more lines of log that matched (not counting those that also match the ignoreregex) within that period of time (now - findtime to now), then it emits the ban action.

  ancient past  |     past       |       ban         |   future
----------------+--*--*-*--*---*-+-------------------+------------->
                |                |                   |
                |                |                   +--> now + bantime
                |                +--> now
                +--> now - findtime

There is a graph showing the timeline. Logs part of ancient past are ignored. Logs between now - findtime and now, section named past, are checked for matches. If the number of matches (represented by asterisks) is >= maxretry then a ban is started at now. The ban lasts until now + bantime. Note that hits with the same IP once the IP was banned should not happen for the port for which it was banned. It could still happen for other ports, though.

So by increasing the findtime=... you do not affect the reaction time, however, you increase the chance for an IP to get banned by the corresponding filter.

As mentioned by Michael Hampton in a couple of comments, the reaction time, how often fail2ban checks the logs, has nothing to do with the findtime parameter. fail2ban is expected to read new log data every second or so (it will depend on your computer load, but it should be really fast since in most case new log data will still be in memory, in a kernel buffer.)

The findtime=... defines how far back logs are checked. The filter is checked against input that has a date between now and now - findtime. If the filter found maxretry or more lines of log that matched (not counting those that also match the ignoreregex) within that period of time (now - findtime to now), then it emits the ban action.

So by increasing the findtime=... you do not affect the reaction time, however, you increase the chance for an IP to get banned by the corresponding filter.

As mentioned by Michael Hampton in a couple of comments, the reaction time, how often fail2ban checks the logs, has nothing to do with the findtime parameter. fail2ban is expected to read new log data every second or so (it will depend on your computer load, but it should be really fast since in most case new log data will still be in memory, in a kernel buffer.)

The findtime=... defines how far back logs are checked. The filter is checked against input that has a date between now - findtime and now. If the filter found maxretry or more lines of log that matched (not counting those that also match the ignoreregex) within that period of time (now - findtime to now), then it emits the ban action.

  ancient past  |     past       |       ban         |   future
----------------+--*--*-*--*---*-+-------------------+------------->
                |                |                   |
                |                |                   +--> now + bantime
                |                +--> now
                +--> now - findtime

There is a graph show the timeline. Logs part of ancient past are ignored. Logs between now - findtime and now, named past, are checked for matches. If the number of match (represented by asterisks) is >= maxretry then a ban is started at now. The ban lasts until now + bantime. Note that hits with the same IP once the IP was banned should not happen for the port for which it was banned. It could still happen for other ports, though.

So by increasing the findtime=... you do not affect the reaction time, however, you increase the chance for an IP to get banned by the corresponding filter.