>>I still rely on F2B but found this is a good compliment. Like others
here, I got tired of seeing repeat offenders. And the recidive
function is nice, but it's still way more granular and resource
hogging as it should be. With the ability, for example, to stop an
entire class A or B block of
I share the exact same philosophy Mike…I have F2B as my "last line" in a sense
with my FW and cloud infosec devices taking the brunt of the attack at the
border…and of course, both border devices are running some mix of
auto-maintained and updated blacklists.
Also, not sure what others may
I need to re-iterate what Mike is saying here and in fact, I would argue that
if one is running an EM server without some type of SPAM + bad actor lists,
they are remiss in their admin duties. LoginShield is one of the many
available out there with SpamHaus and Barracuda probably being the
On 7/8/20 3:29 PM, Mike wrote:
As an aside, instead of using a recidive jail, I've been using a more
permanent ban of login ports using this system
https://github.com/dpsystems/login-shield
This also includes logging of banned connections and some analysis
reports.
That is an
As an aside, instead of using a recidive jail, I've been using a more
permanent ban of login ports using this system
https://github.com/dpsystems/login-shield
This also includes logging of banned connections and some analysis reports.
___
On 7/8/20 9:24 AM, Tom Hendrikx wrote:
Hi Yassine,
The shorewall action does not ban on a per-jail basis, but puts all
ip-addresses on a single blacklist, as that is how shorewall works.
In the original recidive implementation (which I wrote) it was
especially mentioned that you shouldn't
On 7/7/20 5:33 PM, Mike wrote:
This can happen if there is still an active connection with the jailed
IP. f2b only affects future, new connections.
Dear Mike,
This is an excerpt of //usr/share/doc/fail2ban/readme.debian.gz/ from
the 0.8.13 version
* Blocking of NEW connections only
Hi Yassine,
The shorewall action does not ban on a per-jail basis, but puts all
ip-addresses on a single blacklist, as that is how shorewall works.
In the original recidive implementation (which I wrote) it was
especially mentioned that you shouldn't use the same jail action for the
This can happen if there is still an active connection with the
jailed IP. f2b only affects future, new connections.
At 06:32 AM 7/7/2020, Yassine Chaouche wrote:
Let us examine what f2b logs for 185.143.72.27 say :
1. Is is banned/unbanned by postfix-sasl 4 times
2. on the fifth
Am 07.07.2020 um 15:22 schrieb Yassine Chaouche:
>
> Thank you Peter, that was much appreciated.
>
> Maybe the problem comes from the shorewall action I am using, which
> isn't as feature-rich as the iptables action. Compare :
>
> root@messagerie[10.10.10.19] ~ # removeblanks
>
Thank you Peter, that was much appreciated.
Maybe the problem comes from the shorewall action I am using, which
isn't as feature-rich as the iptables action. Compare :
root@messagerie[10.10.10.19] ~ # removeblanks
/etc/fail2ban/action.d/iptables.conf
[INCLUDES]
before = iptables-blocktype.conf
Am 07.07.2020 um 13:32 schrieb Yassine Chaouche:
>
> Let us examine what f2b logs for 185.143.72.27 say :
>
> 1. Is is banned/unbanned by *postfix-sasl* 4 times
>
> 2. on the fifth occurence, it is first banned by the *postfix-sasl*
> jail then by the *recidive* jail. Curiously, the *recidive*
Let us examine what f2b logs for 185.143.72.27 say :
1. Is is banned/unbanned by POSTFIX-SASL 4 times
2. on the fifth occurence, it is first banned by the POSTFIX-SASL jail
then by the RECIDIVE jail. Curiously, the RECIDIVE jail doesn't detect
that it has already been banned before. Maybe
On 7/2/20 3:45 PM, Steve Murphy wrote:
We've been having mysterious non-blockages of attacking sites, where
the site was banned in iptables by fail2ban,
but sliding thru the iptables and being "ACCEPT"-ed. The cause? At
least, on CentOS6, where this happens, the connection
tracking isn't
We've been having mysterious non-blockages of attacking sites, where the
site was banned in iptables by fail2ban,
but sliding thru the iptables and being "ACCEPT"-ed. The cause? At least,
on CentOS6, where this happens, the connection
tracking isn't working so hot. SO what we do is turn off
Am 01.07.2020 um 16:53 schrieb Yassine Chaouche:
>
> From: Peter Heirich - 2020-07-01 14:22:19
>
>> try command
>>
>> sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "SELECT * FROM bans WHERE
>> jail='recidive';"
>
> I don't have that file in /var/lib/. Also, I can't find any reference
> to sqlite or
From: Peter Heirich - 2020-07-01 14:22:19
try command
sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "SELECT * FROM bans WHERE
jail='recidive';"
I don't have that file in /var/lib/. Also, I can't find any reference to
sqlite or database in the config file.
root@messagerie[10.10.10.19] /var #
try command
sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "SELECT * FROM bans WHERE
jail='recidive';"
to see if ip in database
[root@genf132:4 log]0# sqlite3 /var/lib/fail2ban/fail2ban.sqlite3
"SELECT * FROM bans WHERE jail='recidive';"
should give answer like
I forgot to mention the version of f2b here :
root@messagerie[10.10.10.19] ~ # fail2ban-server --version | sed -n 1p
Fail2Ban v0.8.13
root@messagerie[10.10.10.19] ~ #
Yassine.
On 7/1/20 1:23 PM, Yassine Chaouche wrote:
Dear list,
Here is my problem : I have configured a recidive jail, taken
19 matches
Mail list logo
