fail2ban-users — The mailing list for help on getting Fail2Ban up and running on your machine

Re: [Fail2ban-users] my dovecot filter not working

[Stroller <str...@st...>]

> On 13 Dec 2017, at 17:46, Gao <ga...@pz...> wrote:
> 
> Hi list,
> 
> My mail server using dovecot v2.2.33 on CentOS 7. I installed fail2ban v0.9.7 from EPEL repo. I just noticed the dovecot filter seems not working. My maillog have entries:
> Dec 11 22:14:00 mail dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=208.100.26.233, lip=10.11.22.68, TLS handshaking: SSL_accept() failed: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher, session=<oBeRjh5gZ8nQZBrp>
> Dec 12 03:10:02 mail dovecot: pop3-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=208.100.26.235, lip=10.11.22.68, TLS handshaking: SSL_accept() failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol, session=</7xDsSJgZ+DQZBrr>
> 
> But the test show no match:
> # fail2ban-regex /var/log/maillog /etc/fail2ban/filter.d/dovecot.conf 

The dovecot filters showed no matches on my system, too, so I never enabled it.

I also get similar "no auth attempts in 0 secs" entries in the logs, 10 in the last 2 days.

I notice the first entry of this type in my current logs is from University of Michigan Internet-Wide Scanning Research, others from a datacenter in Hong Kong and other hosts on my hoster's network (Linode).

Stroller.
 

Re: [Fail2ban-users] f2b IPv6 on FC27

[Daniel L. S. <da...@is...>]

George:

Thanks for the feedback.  Your suggested change did in fact work, but
as you observe, it is less efficient than using ipset.


On Fri, 2017-12-15 at 03:29 +0100, Georges Racinet wrote:
> Hi,
> 
> As it turns out, I'm typing this on a system recently upgraded to
> F27,
> so I decided to install f2b and take a look. Thanks for noticing it
> has
> 0.10 for me ;-)
> 
> And long story short, I was initially convinced it'd rather be a
> remnant
> of something weird on your system, but I reproduce the issue, and I
> think it's a bug in (that version of) f2b's use of ipset with ipv6
> (at
> least in firewalld context).
> 
> To workaround the issue you may simply edit
> /etc/fail2ban/jail.d/00-firewalld.conf, replacing 'firewallcmd-ipset' 
> by
> 'firewallcmd-multiport', it worked for me.
> 
> Edit: while checking what the output of 'ipset list' would be for
> sets
> of IPv6 addresses, I got this in my search results
> https://github.com/fail2ban/fail2ban/issues/1990, which is fixed, and
> looks to be the same bug without ip6tables-restore (optional backend
> of
> firewalld).
> 
> Time for me to see how to use this package with nftables on Fedora…
> 
> On 12/13/2017 06:40 PM, Daniel L. Srebnick wrote:
> > I just upgraded Fedora to FC27, which includes the IPv6 capable
> > fail2ban (0.10.0).
> > 
> > IPv6 addresses are not being blocked because of an issue when f2b
> > calls
> > ip6tables:
> > 
> > Dec 13 12:36:14 myhost.com firewalld[1026]: WARNING:
> > '/usr/sbin/ip6tables-restore --wait=2 -n' failed:
> > Dec 13 12:36:14 myhost.com firewalld[1026]: ERROR: COMMAND_FAILED
> 
> It turns out that indeed firewalld uses the lower level
> iptables-apply/restore utilities (a fact I didn't know)
> By turning on firewalld debug log at level >=3, one can see what it
> tried to load with ip6tables-restore:
> 
>     2017-12-15 02:31:08 DEBUG1: direct.addRule('ipv6', 'filter',
> 'INPUT', 0,
> '-p','tcp','-m','multiport','--dports','ssh','-m','set','--match-
> set','f2b-sshd6','src','-j','REJECT','--reject-with','icmp6-port-
> unreachable')
>     2017-12-15 02:31:08 DEBUG2: <class
> 'firewall.core.ipXtables.ip6tables'>: /usr/sbin/ip6tables-restore
> /run/firewalld/temp.pxn873ip: 146
>            1: *filter
>            2: -I INPUT_direct 1 -p tcp -m multiport --dports ssh -m
> set
> --match-set f2b-sshd6 src -j REJECT --reject-with icmp6-port-
> unreachable
>            3: COMMIT
> 
> Now I tried the same directly to get a grasp :
> 
>     $ sudo ip6tables -I INPUT_direct 1 -p tcp -m multiport --dports
> ssh
> -m set --match-set f2b-sshd6 src -j REJECT --reject-with
> icmp6-port-unreachable
> 
>     ip6tables v1.6.1: The protocol family of set f2b-sshd6 is IPv4,
> which is not applicable.
> 
> And indeed :
> 
> $ sudo ipset list
>     Name: f2b-sshd6
>     Type: hash:ip
>     Revision: 4
>     Header: family inet hashsize 1024 maxelem 65536 timeout 600
>     Size in memory: 88
>     References: 0
>     Number of entries: 0
>     Members:
> 
> > 
> > Seems to be that the "--wait" parameter is not supported by
> > ip6tables-
> > restore.
> 
> It says so, but it behaves like a mere warning.
> 
> Regards,
> 
> > _______________________________________________
> > Fail2ban-users mailing list
> > Fai...@li...
> > https://lists.sourceforge.net/lists/listinfo/fail2ban-users
> 
> 
> 
> 
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Fail2ban-users mailing list
> Fai...@li...
> https://lists.sourceforge.net/lists/listinfo/fail2ban-users

Re: [Fail2ban-users] need info on permanent ban and persistent database storage

[Admin B. <ad...@be...>]

Hello Bill,
Thanks for the follow up and the vacuum; command
shrunk my sqlite database from 17MB to 10MB

greetings
Becki


On 15.12.2017 13:23, Bill Shirley wrote:
> File /etc/fail2ban/fail2ban.prune.sqlite.commands:
> delete from bans where timeofban <= strftime('%s', date('now', '-90 
> days'));
> vacuum;
> .quit
>
> From cli:
> sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 < 
> /etc/fail2ban/fail2ban.prune.sqlite.commands
>
> Can schedule in cron too.
>
> Bill
>
>
> On 12/15/2017 7:08 AM, Bill Shirley wrote:
>> Don't forget the 'vacuum' command:
>> -rw-------. 1 root root 164M Dec 15 06:56 fail2ban.sqlite3
>>
>> sqlite3 /var/lib/fail2ban/fail2ban.sqlite3
>> sqlite> delete from bans where timeofban <= strftime('%s', '2016-07-25');
>> sqlite> vacuum;
>> sqlite> .quit
>>
>> -rw-------. 1 root root 76M Dec 15 07:02 fail2ban.sqlite3
>>
>> Bill
>>
>> On 12/15/2017 6:11 AM, Admin Beckspaced wrote:
>>> Hello Mark,
>>>
>>> thanks for your reply. Also going to top post here and close the 
>>> topic ;)
>>>
>>> I also found that link about sqlite db actually never gets purged by 
>>> fail2ban.
>>>
>>> https://github.com/fail2ban/fail2ban/issues/1316
>>>
>>> Did play around a bit with the cron command they provide in that post:
>>>
>>> python -c "import sys, logging; 
>>> logging.basicConfig(stream=sys.stdout, level=logging.INFO); from 
>>> fail2ban.server.database import Fail2BanDb; db = 
>>> Fail2BanDb('/var/lib/fail2ban/fail2ban.sqlite3'); db.purge()"
>>>
>>> But be careful it purges the complete database so all data gets lost!
>>>
>>> you could instead delete older entries, e.g. older than 90 days, only.
>>> These are the command I ran in the sqlite cli.
>>>
>>> perhaps this might help someone?
>>>
>>> thanks & greetings
>>> Becki
>>>
>>> linux:~ # sqlite3
>>> sqlite> .open /var/lib/fail2ban/fail2ban.sqlite3
>>> sqlite> .database
>>> seq  name             file
>>> ---  --------------- 
>>> ----------------------------------------------------------
>>> 0    main             /var/lib/fail2ban/fail2ban.sqlite3
>>> sqlite> .tables
>>> bans        fail2banDb  jails       logs
>>> sqlite> .schema bans
>>> CREATE TABLE bans(jail TEXT NOT NULL, ip TEXT, timeofban INTEGER NOT 
>>> NULL, data JSON, FOREIGN KEY(jail) REFERENCES jails(name) );
>>> CREATE INDEX bans_jail_timeofban_ip ON bans(jail, timeofban);
>>> CREATE INDEX bans_jail_ip ON bans(jail, ip);
>>> CREATE INDEX bans_ip ON bans(ip);
>>> sqlite> SELECT count(*) from bans;
>>> sqlite> SELECT count(ip) FROM bans WHERE timeofban <= strftime('%s', 
>>> date('now', '-90 days'));
>>> sqlite> DELETE FROM bans WHERE timeofban <= strftime('%s', 
>>> date('now', '-90 days'));
>>>
>>>
>>>
>>> On 14.12.2017 20:33, Mark Costlow wrote:
>>>> I have been looking at dbpurgeage here recently as well.  
>>>> Unfortunately
>>>> I don't have an answer for you, just more questions.
>>>>
>>>> We've never set it to a specific value, so it is at the default
>>>> of 86400.  However, our sqlite data file does not seem to ever
>>>> have entries purged from the bans table.  On one set of machines
>>>> where fail2ban was first set up in March 2015, the entries go back
>>>> to then.  On another set initialized about 7 months ago, they
>>>> go back 7 months.
>>>>
>>>> Both of these setups are using recidive jails, in addition to several
>>>> "normal" jails.  They are all working fine.  We were trying to 
>>>> troubleshoot
>>>> why they take a very long time to shut down and start up. The 
>>>> months/years
>>>> of cruft in the bans table seems to be the answer ... if we trim
>>>> that table shutdown/startup is much faster.
>>>>
>>>> One set of these is running 0.9.3 on gentoo linux, the other set is 
>>>> running
>>>> 0.9.6 on FreeBSD.
>>>>
>>>> I just found this thread says stock fail2ban doesn't implement the
>>>> purge at all, and suggests you would need to add a cron job to do
>>>> so: https://github.com/fail2ban/fail2ban/issues/1316
>>>>
>>>> I think we are going to just add a cron job to purge the table 
>>>> periodically.
>>>>
>>>> Mark
>>>>
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Fail2ban-users mailing list
>>> Fai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org!http://sdm.link/slashdot
>>
>>
>> _______________________________________________
>> Fail2ban-users mailing list
>> Fai...@li...
>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Fail2ban-users mailing list
> Fai...@li...
> https://lists.sourceforge.net/lists/listinfo/fail2ban-users

Re: [Fail2ban-users] need info on permanent ban and persistent database storage

[Bill S. <bsh...@op...>]

File /etc/fail2ban/fail2ban.prune.sqlite.commands:
delete from bans where timeofban <= strftime('%s', date('now', '-90 days'));
vacuum;
.quit

 From cli:
sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 < /etc/fail2ban/fail2ban.prune.sqlite.commands

Can schedule in cron too.

Bill


On 12/15/2017 7:08 AM, Bill Shirley wrote:
> Don't forget the 'vacuum' command:
> -rw-------. 1 root root 164M Dec 15 06:56 fail2ban.sqlite3
>
> sqlite3 /var/lib/fail2ban/fail2ban.sqlite3
> sqlite> delete from bans where timeofban <= strftime('%s', '2016-07-25');
> sqlite> vacuum;
> sqlite> .quit
>
> -rw-------. 1 root root 76M Dec 15 07:02 fail2ban.sqlite3
>
> Bill
>
> On 12/15/2017 6:11 AM, Admin Beckspaced wrote:
>> Hello Mark,
>>
>> thanks for your reply. Also going to top post here and close the topic ;)
>>
>> I also found that link about sqlite db actually never gets purged by fail2ban.
>>
>> https://github.com/fail2ban/fail2ban/issues/1316
>>
>> Did play around a bit with the cron command they provide in that post:
>>
>> python -c "import sys, logging; logging.basicConfig(stream=sys.stdout, level=logging.INFO); from fail2ban.server.database 
>> import Fail2BanDb; db = Fail2BanDb('/var/lib/fail2ban/fail2ban.sqlite3'); db.purge()"
>>
>> But be careful it purges the complete database so all data gets lost!
>>
>> you could instead delete older entries, e.g. older than 90 days, only.
>> These are the command I ran in the sqlite cli.
>>
>> perhaps this might help someone?
>>
>> thanks & greetings
>> Becki
>>
>> linux:~ # sqlite3
>> sqlite> .open /var/lib/fail2ban/fail2ban.sqlite3
>> sqlite> .database
>> seq  name             file
>> ---  --------------- ----------------------------------------------------------
>> 0    main             /var/lib/fail2ban/fail2ban.sqlite3
>> sqlite> .tables
>> bans        fail2banDb  jails       logs
>> sqlite> .schema bans
>> CREATE TABLE bans(jail TEXT NOT NULL, ip TEXT, timeofban INTEGER NOT NULL, data JSON, FOREIGN KEY(jail) REFERENCES 
>> jails(name) );
>> CREATE INDEX bans_jail_timeofban_ip ON bans(jail, timeofban);
>> CREATE INDEX bans_jail_ip ON bans(jail, ip);
>> CREATE INDEX bans_ip ON bans(ip);
>> sqlite> SELECT count(*) from bans;
>> sqlite> SELECT count(ip) FROM bans WHERE timeofban <= strftime('%s', date('now', '-90 days'));
>> sqlite> DELETE FROM bans WHERE timeofban <= strftime('%s', date('now', '-90 days'));
>>
>>
>>
>> On 14.12.2017 20:33, Mark Costlow wrote:
>>> I have been looking at dbpurgeage here recently as well.  Unfortunately
>>> I don't have an answer for you, just more questions.
>>>
>>> We've never set it to a specific value, so it is at the default
>>> of 86400.  However, our sqlite data file does not seem to ever
>>> have entries purged from the bans table.  On one set of machines
>>> where fail2ban was first set up in March 2015, the entries go back
>>> to then.  On another set initialized about 7 months ago, they
>>> go back 7 months.
>>>
>>> Both of these setups are using recidive jails, in addition to several
>>> "normal" jails.  They are all working fine.  We were trying to troubleshoot
>>> why they take a very long time to shut down and start up.  The months/years
>>> of cruft in the bans table seems to be the answer ... if we trim
>>> that table shutdown/startup is much faster.
>>>
>>> One set of these is running 0.9.3 on gentoo linux, the other set is running
>>> 0.9.6 on FreeBSD.
>>>
>>> I just found this thread says stock fail2ban doesn't implement the
>>> purge at all, and suggests you would need to add a cron job to do
>>> so: https://github.com/fail2ban/fail2ban/issues/1316
>>>
>>> I think we are going to just add a cron job to purge the table periodically.
>>>
>>> Mark
>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Fail2ban-users mailing list
>> Fai...@li...
>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Fail2ban-users mailing list
> Fai...@li...
> https://lists.sourceforge.net/lists/listinfo/fail2ban-users

Re: [Fail2ban-users] need info on permanent ban and persistent database storage

[Bill S. <bsh...@op...>]

Don't forget the 'vacuum' command:
-rw-------. 1 root root 164M Dec 15 06:56 fail2ban.sqlite3

sqlite3 /var/lib/fail2ban/fail2ban.sqlite3
sqlite> delete from bans where timeofban <= strftime('%s', '2016-07-25');
sqlite> vacuum;
sqlite> .quit

-rw-------. 1 root root 76M Dec 15 07:02 fail2ban.sqlite3

Bill

On 12/15/2017 6:11 AM, Admin Beckspaced wrote:
> Hello Mark,
>
> thanks for your reply. Also going to top post here and close the topic ;)
>
> I also found that link about sqlite db actually never gets purged by fail2ban.
>
> https://github.com/fail2ban/fail2ban/issues/1316
>
> Did play around a bit with the cron command they provide in that post:
>
> python -c "import sys, logging; logging.basicConfig(stream=sys.stdout, level=logging.INFO); from fail2ban.server.database 
> import Fail2BanDb; db = Fail2BanDb('/var/lib/fail2ban/fail2ban.sqlite3'); db.purge()"
>
> But be careful it purges the complete database so all data gets lost!
>
> you could instead delete older entries, e.g. older than 90 days, only.
> These are the command I ran in the sqlite cli.
>
> perhaps this might help someone?
>
> thanks & greetings
> Becki
>
> linux:~ # sqlite3
> sqlite> .open /var/lib/fail2ban/fail2ban.sqlite3
> sqlite> .database
> seq  name             file
> ---  --------------- ----------------------------------------------------------
> 0    main             /var/lib/fail2ban/fail2ban.sqlite3
> sqlite> .tables
> bans        fail2banDb  jails       logs
> sqlite> .schema bans
> CREATE TABLE bans(jail TEXT NOT NULL, ip TEXT, timeofban INTEGER NOT NULL, data JSON, FOREIGN KEY(jail) REFERENCES jails(name) );
> CREATE INDEX bans_jail_timeofban_ip ON bans(jail, timeofban);
> CREATE INDEX bans_jail_ip ON bans(jail, ip);
> CREATE INDEX bans_ip ON bans(ip);
> sqlite> SELECT count(*) from bans;
> sqlite> SELECT count(ip) FROM bans WHERE timeofban <= strftime('%s', date('now', '-90 days'));
> sqlite> DELETE FROM bans WHERE timeofban <= strftime('%s', date('now', '-90 days'));
>
>
>
> On 14.12.2017 20:33, Mark Costlow wrote:
>> I have been looking at dbpurgeage here recently as well.  Unfortunately
>> I don't have an answer for you, just more questions.
>>
>> We've never set it to a specific value, so it is at the default
>> of 86400.  However, our sqlite data file does not seem to ever
>> have entries purged from the bans table.  On one set of machines
>> where fail2ban was first set up in March 2015, the entries go back
>> to then.  On another set initialized about 7 months ago, they
>> go back 7 months.
>>
>> Both of these setups are using recidive jails, in addition to several
>> "normal" jails.  They are all working fine.  We were trying to troubleshoot
>> why they take a very long time to shut down and start up.  The months/years
>> of cruft in the bans table seems to be the answer ... if we trim
>> that table shutdown/startup is much faster.
>>
>> One set of these is running 0.9.3 on gentoo linux, the other set is running
>> 0.9.6 on FreeBSD.
>>
>> I just found this thread says stock fail2ban doesn't implement the
>> purge at all, and suggests you would need to add a cron job to do
>> so: https://github.com/fail2ban/fail2ban/issues/1316
>>
>> I think we are going to just add a cron job to purge the table periodically.
>>
>> Mark
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Fail2ban-users mailing list
> Fai...@li...
> https://lists.sourceforge.net/lists/listinfo/fail2ban-users

Re: [Fail2ban-users] need info on permanent ban and persistent database storage

[Admin B. <ad...@be...>]

Hello Mark,

thanks for your reply. Also going to top post here and close the topic ;)

I also found that link about sqlite db actually never gets purged by 
fail2ban.

https://github.com/fail2ban/fail2ban/issues/1316

Did play around a bit with the cron command they provide in that post:

python -c "import sys, logging; logging.basicConfig(stream=sys.stdout, 
level=logging.INFO); from fail2ban.server.database import Fail2BanDb; db 
= Fail2BanDb('/var/lib/fail2ban/fail2ban.sqlite3'); db.purge()"

But be careful it purges the complete database so all data gets lost!

you could instead delete older entries, e.g. older than 90 days, only.
These are the command I ran in the sqlite cli.

perhaps this might help someone?

thanks & greetings
Becki

linux:~ # sqlite3
sqlite> .open /var/lib/fail2ban/fail2ban.sqlite3
sqlite> .database
seq  name             file
---  --------------- 
----------------------------------------------------------
0    main             /var/lib/fail2ban/fail2ban.sqlite3
sqlite> .tables
bans        fail2banDb  jails       logs
sqlite> .schema bans
CREATE TABLE bans(jail TEXT NOT NULL, ip TEXT, timeofban INTEGER NOT 
NULL, data JSON, FOREIGN KEY(jail) REFERENCES jails(name) );
CREATE INDEX bans_jail_timeofban_ip ON bans(jail, timeofban);
CREATE INDEX bans_jail_ip ON bans(jail, ip);
CREATE INDEX bans_ip ON bans(ip);
sqlite> SELECT count(*) from bans;
sqlite> SELECT count(ip) FROM bans WHERE timeofban <= strftime('%s', 
date('now', '-90 days'));
sqlite> DELETE FROM bans WHERE timeofban <= strftime('%s', date('now', 
'-90 days'));



On 14.12.2017 20:33, Mark Costlow wrote:
> I have been looking at dbpurgeage here recently as well.  Unfortunately
> I don't have an answer for you, just more questions.
>
> We've never set it to a specific value, so it is at the default
> of 86400.  However, our sqlite data file does not seem to ever
> have entries purged from the bans table.  On one set of machines
> where fail2ban was first set up in March 2015, the entries go back
> to then.  On another set initialized about 7 months ago, they
> go back 7 months.
>
> Both of these setups are using recidive jails, in addition to several
> "normal" jails.  They are all working fine.  We were trying to troubleshoot
> why they take a very long time to shut down and start up.  The months/years
> of cruft in the bans table seems to be the answer ... if we trim
> that table shutdown/startup is much faster.
>
> One set of these is running 0.9.3 on gentoo linux, the other set is running
> 0.9.6 on FreeBSD.
>
> I just found this thread says stock fail2ban doesn't implement the
> purge at all, and suggests you would need to add a cron job to do
> so: https://github.com/fail2ban/fail2ban/issues/1316
>
> I think we are going to just add a cron job to purge the table periodically.
>
> Mark
>
>
>

Re: [Fail2ban-users] f2b IPv6 on FC27

[Georges R. <geo...@af...>]

Hi,

As it turns out, I'm typing this on a system recently upgraded to F27,
so I decided to install f2b and take a look. Thanks for noticing it has
0.10 for me ;-)

And long story short, I was initially convinced it'd rather be a remnant
of something weird on your system, but I reproduce the issue, and I
think it's a bug in (that version of) f2b's use of ipset with ipv6 (at
least in firewalld context).

To workaround the issue you may simply edit
/etc/fail2ban/jail.d/00-firewalld.conf, replacing 'firewallcmd-ipset' by
'firewallcmd-multiport', it worked for me.

Edit: while checking what the output of 'ipset list' would be for sets
of IPv6 addresses, I got this in my search results
https://github.com/fail2ban/fail2ban/issues/1990, which is fixed, and
looks to be the same bug without ip6tables-restore (optional backend of
firewalld).

Time for me to see how to use this package with nftables on Fedora…

On 12/13/2017 06:40 PM, Daniel L. Srebnick wrote:
> I just upgraded Fedora to FC27, which includes the IPv6 capable
> fail2ban (0.10.0).
>
> IPv6 addresses are not being blocked because of an issue when f2b calls
> ip6tables:
>
> Dec 13 12:36:14 myhost.com firewalld[1026]: WARNING:
> '/usr/sbin/ip6tables-restore --wait=2 -n' failed:
> Dec 13 12:36:14 myhost.com firewalld[1026]: ERROR: COMMAND_FAILED

It turns out that indeed firewalld uses the lower level
iptables-apply/restore utilities (a fact I didn't know)
By turning on firewalld debug log at level >=3, one can see what it
tried to load with ip6tables-restore:

    2017-12-15 02:31:08 DEBUG1: direct.addRule('ipv6', 'filter',
'INPUT', 0,
'-p','tcp','-m','multiport','--dports','ssh','-m','set','--match-set','f2b-sshd6','src','-j','REJECT','--reject-with','icmp6-port-unreachable')
    2017-12-15 02:31:08 DEBUG2: <class
'firewall.core.ipXtables.ip6tables'>: /usr/sbin/ip6tables-restore
/run/firewalld/temp.pxn873ip: 146
           1: *filter
           2: -I INPUT_direct 1 -p tcp -m multiport --dports ssh -m set
--match-set f2b-sshd6 src -j REJECT --reject-with icmp6-port-unreachable
           3: COMMIT

Now I tried the same directly to get a grasp :

    $ sudo ip6tables -I INPUT_direct 1 -p tcp -m multiport --dports ssh
-m set --match-set f2b-sshd6 src -j REJECT --reject-with
icmp6-port-unreachable

    ip6tables v1.6.1: The protocol family of set f2b-sshd6 is IPv4,
which is not applicable.

And indeed :

$ sudo ipset list
    Name: f2b-sshd6
    Type: hash:ip
    Revision: 4
    Header: family inet hashsize 1024 maxelem 65536 timeout 600
    Size in memory: 88
    References: 0
    Number of entries: 0
    Members:

>
> Seems to be that the "--wait" parameter is not supported by ip6tables-
> restore.
It says so, but it behaves like a mere warning.

Regards,

> _______________________________________________
> Fail2ban-users mailing list
> Fai...@li...
> https://lists.sourceforge.net/lists/listinfo/fail2ban-users

Re: [Fail2ban-users] my dovecot filter not working

[Ben C. <ol...@be...>]

On 12/13/2017 01:14 PM, Tom Hendrikx wrote:
> This could be a bot (albeit a very stupid or simple
> one, because it does not try to use TLS), or it could be a user that has
> his IMAP client configured incorrectly.

If a Nagios server is running and checking the Dovecot ports, it will
produce these messages (I run Nagios and Dovecot (on different servers),
and get similar messages because of it).  While this probably doesn't
help the OP, it is an argument for not changing fail2ban's current
behavior.  Having fail2ban block the Nagios server isn't really useful.

Ben
-- 
Ben Coleman ol...@be... | For the wise man, doing right trumps
http://oloryn.benshome.net/     | looking right.  For the fool, looking
Amateur Radio NJ8J              | right trumps doing right.

Re: [Fail2ban-users] need info on permanent ban and persistent database storage

[Mark C. <ch...@sw...>]

I have been looking at dbpurgeage here recently as well.  Unfortunately
I don't have an answer for you, just more questions.

We've never set it to a specific value, so it is at the default
of 86400.  However, our sqlite data file does not seem to ever
have entries purged from the bans table.  On one set of machines
where fail2ban was first set up in March 2015, the entries go back
to then.  On another set initialized about 7 months ago, they
go back 7 months.

Both of these setups are using recidive jails, in addition to several
"normal" jails.  They are all working fine.  We were trying to troubleshoot
why they take a very long time to shut down and start up.  The months/years
of cruft in the bans table seems to be the answer ... if we trim
that table shutdown/startup is much faster.

One set of these is running 0.9.3 on gentoo linux, the other set is running
0.9.6 on FreeBSD.

I just found this thread says stock fail2ban doesn't implement the
purge at all, and suggests you would need to add a cron job to do
so: https://github.com/fail2ban/fail2ban/issues/1316

I think we are going to just add a cron job to purge the table periodically.

Mark


On Thu, Dec 14, 2017 at 03:17:59PM +0100, Admin Beckspaced wrote:
> 
> On 14.12.2017 14:35, Patrick Shanahan wrote:
> > * Admin Beckspaced <ad...@be...> [12-14-17 04:42]:
> >> Dear Fail2ban users,
> >>
> >> running fail2ban v.0.10.1 on an opensuse box.
> >>
> >> currently looking into the recidive jail to ban persistent abusers.
> >>  From what i understand the bans are stored in the persistent database
> >> storage so the bans can be added on restart without re-scanning the logs
> >> files.
> >>
> >> If i set a bantime of 1w in recidive jail the jail.conf informs me that i
> >> should increase the dbpurgeage to 7.5 days
> >> so the bans with 1w can live long enough before getting purged
> >>
> >> but if i do a permanent bantime -1 what value should I set the dbpurgeage?
> >> what's the relation between bantime, persistent storage and dbpurgeage?
> >>
> >> would be nice if someone could perhaps enlighten me on the topic ;)
> > man jail.conf states:
> >    dbpurgeage
> >      Database purge age in seconds. Default: 86400 (24hours)
> >      This sets the age at which bans should be purged from the database.
> >
> > you wouldn't want the subject address to be removed before bantime
> > expires.  and, since fail2ban complains when the dbpurgeage is less than
> > bantime, it is aware and respects bantime.  so if you set bantime to "-1",
> > forever, dbpurgeage would never purge that address.
> >
> > take this for what it is worth, just my reading/understanding.
> >
> > personally, I add persistent ban addresses to ipset rules.
> >
> Hello Patrick,
> thanks a lot for your reply ;)
> 
> one thing that made me unsure how bans in database and dbpurgeage work 
> together is the following note from the recidive jail in jail.conf
> 
> # Jail for more extended banning of persistent abusers
> # !!! WARNINGS !!!
> # 1. Make sure that your loglevel specified in fail2ban.conf/.local
> #?????? is not at DEBUG level -- which might then cause fail2ban to fall into
> #?????? an infinite loop constantly feeding itself with non-informative lines
> # 2. Increase dbpurgeage defined in fail2ban.conf to e.g. 648000 (7.5 days)
> #?????? to maintain entries for failed logins for sufficient amount of time
> [recidive]
> 
> logpath?? = /var/log/fail2ban.log
> banaction = %(banaction_allports)s
> bantime?? = 1w
> findtime = 1d
> 
> So if i set a bantime of 1 week they urge me to increase the dbpurgeage 
> to more than a week ... 7,5 days
> If it works the way you understand it then there would be no need to 
> adjust the dbpurgeage according to bantime.
> as dbpurgeage would always respect the bantime ...
> 
> if dbpurgeage would respect the bantime then there would be no need to 
> add a WARNING note and increase dbpurgeage to greater than bantime?
> 
> you see ... still not sure how this really works?
> anyone else out there who could enlighten me ;)
> 
> Thanks & greetings
> Becki
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Fail2ban-users mailing list
> Fai...@li...
> https://lists.sourceforge.net/lists/listinfo/fail2ban-users
> 
> 

-- 
Mark Costlow    | Southwest Cyberport | Fax:   +1-505-232-7975
ch...@sw... | Web:   www.swcp.com | Voice: +1-505-232-7992

Re: [Fail2ban-users] need info on permanent ban and persistent database storage

[Admin B. <ad...@be...>]

On 14.12.2017 14:35, Patrick Shanahan wrote:
> * Admin Beckspaced <ad...@be...> [12-14-17 04:42]:
>> Dear Fail2ban users,
>>
>> running fail2ban v.0.10.1 on an opensuse box.
>>
>> currently looking into the recidive jail to ban persistent abusers.
>>  From what i understand the bans are stored in the persistent database
>> storage so the bans can be added on restart without re-scanning the logs
>> files.
>>
>> If i set a bantime of 1w in recidive jail the jail.conf informs me that i
>> should increase the dbpurgeage to 7.5 days
>> so the bans with 1w can live long enough before getting purged
>>
>> but if i do a permanent bantime -1 what value should I set the dbpurgeage?
>> what's the relation between bantime, persistent storage and dbpurgeage?
>>
>> would be nice if someone could perhaps enlighten me on the topic ;)
> man jail.conf states:
>    dbpurgeage
>      Database purge age in seconds. Default: 86400 (24hours)
>      This sets the age at which bans should be purged from the database.
>
> you wouldn't want the subject address to be removed before bantime
> expires.  and, since fail2ban complains when the dbpurgeage is less than
> bantime, it is aware and respects bantime.  so if you set bantime to "-1",
> forever, dbpurgeage would never purge that address.
>
> take this for what it is worth, just my reading/understanding.
>
> personally, I add persistent ban addresses to ipset rules.
>
Hello Patrick,
thanks a lot for your reply ;)

one thing that made me unsure how bans in database and dbpurgeage work 
together is the following note from the recidive jail in jail.conf

# Jail for more extended banning of persistent abusers
# !!! WARNINGS !!!
# 1. Make sure that your loglevel specified in fail2ban.conf/.local
#    is not at DEBUG level -- which might then cause fail2ban to fall into
#    an infinite loop constantly feeding itself with non-informative lines
# 2. Increase dbpurgeage defined in fail2ban.conf to e.g. 648000 (7.5 days)
#    to maintain entries for failed logins for sufficient amount of time
[recidive]

logpath  = /var/log/fail2ban.log
banaction = %(banaction_allports)s
bantime  = 1w
findtime = 1d

So if i set a bantime of 1 week they urge me to increase the dbpurgeage 
to more than a week ... 7,5 days
If it works the way you understand it then there would be no need to 
adjust the dbpurgeage according to bantime.
as dbpurgeage would always respect the bantime ...

if dbpurgeage would respect the bantime then there would be no need to 
add a WARNING note and increase dbpurgeage to greater than bantime?

you see ... still not sure how this really works?
anyone else out there who could enlighten me ;)

Thanks & greetings
Becki

[Fail2ban-users] need info on permanent ban and persistent database storage

[Admin B. <ad...@be...>]

Dear Fail2ban users,

running fail2ban v.0.10.1 on an opensuse box.

currently looking into the recidive jail to ban persistent abusers.
 From what i understand the bans are stored in the persistent database 
storage so the bans can be added on restart without re-scanning the logs 
files.

If i set a bantime of 1w in recidive jail the jail.conf informs me that 
i should increase the dbpurgeage to 7.5 days
so the bans with 1w can live long enough before getting purged

but if i do a permanent bantime -1 what value should I set the dbpurgeage?
what's the relation between bantime, persistent storage and dbpurgeage?

would be nice if someone could perhaps enlighten me on the topic ;)

thanks & greetings
Becki

Re: [Fail2ban-users] my dovecot filter not working

[Gao <ga...@pz...>]

On 2017-12-13 10:14 AM, Tom Hendrikx wrote:
> Hi,
>
> The default jail does not check on the lines you mention.
>
> Not really weird, since the log message explicitly states that no auth
> attempt is performed. Somebody is connecting but did not send auth
> details, and your dovecot didn't tell them whether the auth credentials
> were working or not. This could be a bot (albeit a very stupid or simple
> one, because it does not try to use TLS), or it could be a user that has
> his IMAP client configured incorrectly.
>
> Anyway: no auth details, so no dictionary attack. Feel free to add
> custom regexes on your own system though.
>
> Kind regards,
> 	Tom

Thanks for the help.

The bot left lot lines in the maillog which is annoying. I'll try to 
learn to craft a failregex to block it.

Gao

[Fail2ban-users] f2b IPv6 on FC27

[Daniel L. S. <da...@is...>]

I just upgraded Fedora to FC27, which includes the IPv6 capable
fail2ban (0.10.0).

IPv6 addresses are not being blocked because of an issue when f2b calls
ip6tables:

Dec 13 12:36:14 myhost.com firewalld[1026]: WARNING:
'/usr/sbin/ip6tables-restore --wait=2 -n' failed:
Dec 13 12:36:14 myhost.com firewalld[1026]: ERROR: COMMAND_FAILED

Seems to be that the "--wait" parameter is not supported by ip6tables-
restore.

Can anyone advise whether this is a Fedora specific issue, or upstream?

Thanks.

Re: [Fail2ban-users] my dovecot filter not working

[Tom H. <to...@wh...>]

Hi,

The default jail does not check on the lines you mention.

Not really weird, since the log message explicitly states that no auth
attempt is performed. Somebody is connecting but did not send auth
details, and your dovecot didn't tell them whether the auth credentials
were working or not. This could be a bot (albeit a very stupid or simple
one, because it does not try to use TLS), or it could be a user that has
his IMAP client configured incorrectly.

Anyway: no auth details, so no dictionary attack. Feel free to add
custom regexes on your own system though.

Kind regards,
	Tom

On 13-12-17 18:46, Gao wrote:
> Hi list,
> 
> My mail server using dovecot v2.2.33 on CentOS 7. I installed fail2ban
> v0.9.7 from EPEL repo. I just noticed the dovecot filter seems not
> working. My maillog have entries:
> Dec 11 22:14:00 mail dovecot: imap-login: Disconnected (no auth attempts
> in 0 secs): user=<>, rip=208.100.26.233, lip=10.11.22.68, TLS
> handshaking: SSL_accept() failed: error:1408A0C1:SSL
> routines:ssl3_get_client_hello:no shared cipher, session=<oBeRjh5gZ8nQZBrp>
> Dec 12 03:10:02 mail dovecot: pop3-login: Disconnected (no auth attempts
> in 0 secs): user=<>, rip=208.100.26.235, lip=10.11.22.68, TLS
> handshaking: SSL_accept() failed: error:140760FC:SSL
> routines:SSL23_GET_CLIENT_HELLO:unknown protocol, session=</7xDsSJgZ+DQZBrr>
> 
> But the test show no match:
> # fail2ban-regex /var/log/maillog /etc/fail2ban/filter.d/dovecot.conf
> 
> Running tests
> =============
> 
> Use   failregex filter file : dovecot, basedir: /etc/fail2ban
> Use         log file : /var/log/maillog
> Use         encoding : UTF-8
> 
> Results
> =======
> *Failregex: 0 total*
> 
> Ignoreregex: 0 total
> 
> Date template hits:
> |- [# of hits] date format
> |  [24406] (?:DAY )?MON Day 24hour:Minute:Second(?:\.Microseconds)?(?:
> Year)?
> `-
> 
> Lines: 24406 lines, 0 ignored, *0 matched*, 24406 missed
> [processed in 3.56 sec]
> 
> Missed line(s): too many to print.  Use --print-all-missed to print all
> 24406 lines
> 
> I enabled dovecot in jail.local:
> [dovecot]
> enabled = true
> port    = pop3,pop3s,imap,imaps,submission,465,sieve
> logpath = %(dovecot_log)s
> backend = %(dovecot_backend)s
> 
> I just use the default dovecot filter:
> # cat /etc/fail2ban/filter.d/dovecot.conf
> # Fail2Ban filter Dovecot authentication and pop3/imap server
> #
> 
> [INCLUDES]
> 
> before = common.conf
> 
> [Definition]
> 
> _daemon = (auth|dovecot(-auth)?|auth-worker)
> 
> failregex =
> ^%(__prefix_line)s(?:%(__pam_auth)s(?:\(dovecot:auth\))?:)?\s+authentication
> failure; logname=\S* uid=\S* euid=\S* tty=dovecot ruser=\S*
> rhost=<HOST>(?:\s+user=\S*)?\s*$
>             ^%(__prefix_line)s(?:pop3|imap)-login: (?:Info: )?(?:Aborted
> login|Disconnected)(?::(?: [^ \(]+)+)? \((?:auth failed, \d+ attempts(
> in \d+ secs)?|tried to use (disabled|disallowed) \S+ auth)\):(
> user=<[^>]+>,)?( method=\S+,)? rip=<HOST>(?:, lip=\S+)?(?:, TLS(?:
> handshaking(?:: SSL_accept\(\) failed: error:[\dA-F]+:SSL
> routines:[TLS\d]+_GET_CLIENT_HELLO:unknown protocol)?)?(:
> Disconnected)?)?(, session=<\S+>)?\s*$
>             ^%(__prefix_line)s(?:Info|dovecot:
> auth\(default\)|auth-worker\(\d+\)): pam\(\S+,<HOST>\):
> pam_authenticate\(\) failed: (User not known to the underlying
> authentication module: \d+ Time\(s\)|Authentication failure \(password
> mismatch\?\))\s*$
>             ^%(__prefix_line)s(?:auth|auth-worker\(\d+\)):
> (?:pam|passwd-file)\(\S+,<HOST>\): unknown user\s*$
>             ^%(__prefix_line)s(?:auth|auth-worker\(\d+\)): Info:
> ldap\(\S*,<HOST>,\S*\): invalid credentials\s*$
> 
> ignoreregex =
> 
> [Init]
> 
> journalmatch = _SYSTEMD_UNIT=dovecot.service
> 
> 
> Could someone help me on this? I must missed something here. BTW other
> filters work fine.
> 
> Thanks.
> 
> Gao
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Fail2ban-users mailing list
> Fai...@li...
> https://lists.sourceforge.net/lists/listinfo/fail2ban-users
> 

[Fail2ban-users] my dovecot filter not working

[Gao <ga...@pz...>]

Hi list,

My mail server using dovecot v2.2.33 on CentOS 7. I installed fail2ban 
v0.9.7 from EPEL repo. I just noticed the dovecot filter seems not 
working. My maillog have entries:
Dec 11 22:14:00 mail dovecot: imap-login: Disconnected (no auth attempts 
in 0 secs): user=<>, rip=208.100.26.233, lip=10.11.22.68, TLS 
handshaking: SSL_accept() failed: error:1408A0C1:SSL 
routines:ssl3_get_client_hello:no shared cipher, session=<oBeRjh5gZ8nQZBrp>
Dec 12 03:10:02 mail dovecot: pop3-login: Disconnected (no auth attempts 
in 0 secs): user=<>, rip=208.100.26.235, lip=10.11.22.68, TLS 
handshaking: SSL_accept() failed: error:140760FC:SSL 
routines:SSL23_GET_CLIENT_HELLO:unknown protocol, session=</7xDsSJgZ+DQZBrr>

But the test show no match:
# fail2ban-regex /var/log/maillog /etc/fail2ban/filter.d/dovecot.conf

Running tests
=============

Use   failregex filter file : dovecot, basedir: /etc/fail2ban
Use         log file : /var/log/maillog
Use         encoding : UTF-8

Results
=======
*Failregex: 0 total*

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [24406] (?:DAY )?MON Day 24hour:Minute:Second(?:\.Microseconds)?(?: 
Year)?
`-

Lines: 24406 lines, 0 ignored, *0 matched*, 24406 missed
[processed in 3.56 sec]

Missed line(s): too many to print.  Use --print-all-missed to print all 
24406 lines

I enabled dovecot in jail.local:
[dovecot]
enabled = true
port    = pop3,pop3s,imap,imaps,submission,465,sieve
logpath = %(dovecot_log)s
backend = %(dovecot_backend)s

I just use the default dovecot filter:
# cat /etc/fail2ban/filter.d/dovecot.conf
# Fail2Ban filter Dovecot authentication and pop3/imap server
#

[INCLUDES]

before = common.conf

[Definition]

_daemon = (auth|dovecot(-auth)?|auth-worker)

failregex = 
^%(__prefix_line)s(?:%(__pam_auth)s(?:\(dovecot:auth\))?:)?\s+authentication 
failure; logname=\S* uid=\S* euid=\S* tty=dovecot ruser=\S* 
rhost=<HOST>(?:\s+user=\S*)?\s*$
             ^%(__prefix_line)s(?:pop3|imap)-login: (?:Info: 
)?(?:Aborted login|Disconnected)(?::(?: [^ \(]+)+)? \((?:auth failed, 
\d+ attempts( in \d+ secs)?|tried to use (disabled|disallowed) \S+ 
auth)\):( user=<[^>]+>,)?( method=\S+,)? rip=<HOST>(?:, lip=\S+)?(?:, 
TLS(?: handshaking(?:: SSL_accept\(\) failed: error:[\dA-F]+:SSL 
routines:[TLS\d]+_GET_CLIENT_HELLO:unknown protocol)?)?(: 
Disconnected)?)?(, session=<\S+>)?\s*$
             ^%(__prefix_line)s(?:Info|dovecot: 
auth\(default\)|auth-worker\(\d+\)): pam\(\S+,<HOST>\): 
pam_authenticate\(\) failed: (User not known to the underlying 
authentication module: \d+ Time\(s\)|Authentication failure \(password 
mismatch\?\))\s*$
             ^%(__prefix_line)s(?:auth|auth-worker\(\d+\)): 
(?:pam|passwd-file)\(\S+,<HOST>\): unknown user\s*$
             ^%(__prefix_line)s(?:auth|auth-worker\(\d+\)): Info: 
ldap\(\S*,<HOST>,\S*\): invalid credentials\s*$

ignoreregex =

[Init]

journalmatch = _SYSTEMD_UNIT=dovecot.service


Could someone help me on this? I must missed something here. BTW other 
filters work fine.

Thanks.

Gao