freebsd stable - Jun 2018 - py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

On Fri, Jun 22, 2018 at 03:12:05PM +0200, Michael Grimm
wrote:
> Hi,
> 
> this is 11.2-STABLE (r335532), and I am referring to the recent MFC of
syslogd modifications [1].
> 
> Because I cannot judge whether fail2ban lacks support for the renewed
syslogd or syslogd has an issue in receiving fail2ban messages I do crosspost
this mail to ports and stable.
> 
> I do have fail2ban configured to report to SYSLOG:
> 
> 	logtarget = SYSLOG
> 	syslogsocket = auto
> 
> But now, after upgrading to the new syslogd fail2ban refuses to report to
syslogd; no single message gets recorded [2].
> 
> I did try to modify the syslogsocket setting to /var/run/log without
success. Pointing logtarget to a regular files tells me that fail2ban is running
as expected, it only lacks reporting to SYSLOG.
> 
> #) Does anyone else has running py-fail2ban at >= r335059 and can
confirm my observations?
> #) Any ideas how to debug this issue?
> 
> Thank you in advance and regards,
> Michael
> 
> 
> [1]
https://svnweb.freebsd.org/base/stable/11/usr.sbin/syslogd/Makefile?revision=335059&view=markup&sortby=file
> [2] both syslogd and fail2ban are running at the host, thus another issue
with syslogd fixed in
>    
https://svnweb.freebsd.org/base?view=revision&sortby=file&revision=335314
does not apply
> 
This is probably connected with the lack of handling of non-RFC
compliant timestamps. 

My syslog server also suffers from this issue. It stopped logging
messages from old Cisco equipment and some newer Netgear switches.
Running it in debug mode gives some clue:

Failed to parse TIMESTAMP from x.x.x.x: 12403: Jun 22 17:31:38 CEST:
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/17,
changed state to down

Could you please give any advice or workaround for this issue?


-- 
Marek Zarychta
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20180622/462ca52d/attachment.sig>

Marek Zarychta <zarychtam at plan-b.pwste.edu.pl>
wrote:
> On Fri, Jun 22, 2018 at 03:12:05PM +0200, Michael Grimm wrote:
>> Hi,
>> 
>> this is 11.2-STABLE (r335532), and I am referring to the recent MFC of
syslogd modifications [1].
>> 
>> Because I cannot judge whether fail2ban lacks support for the renewed
syslogd or syslogd has an issue in receiving fail2ban messages I do crosspost
this mail to ports and stable.
>> 
>> I do have fail2ban configured to report to SYSLOG:
>> 
>> 	logtarget = SYSLOG
>> 	syslogsocket = auto
>> 
>> But now, after upgrading to the new syslogd fail2ban refuses to report
to syslogd; no single message gets recorded [2].
>> 
>> I did try to modify the syslogsocket setting to /var/run/log without
success. Pointing logtarget to a regular files tells me that fail2ban is running
as expected, it only lacks reporting to SYSLOG.
>> 
>> #) Does anyone else has running py-fail2ban at >= r335059 and can
confirm my observations?
>> #) Any ideas how to debug this issue?
>> 
>> Thank you in advance and regards,
>> Michael
>> 
>> 
>> [1]
https://svnweb.freebsd.org/base/stable/11/usr.sbin/syslogd/Makefile?revision=335059&view=markup&sortby=file
>> [2] both syslogd and fail2ban are running at the host, thus another
issue with syslogd fixed in
>>   
https://svnweb.freebsd.org/base?view=revision&sortby=file&revision=335314
does not apply
>> 
> 
> This is probably connected with the lack of handling of non-RFC
> compliant timestamps. 
> 
> My syslog server also suffers from this issue. It stopped logging
> messages from old Cisco equipment and some newer Netgear switches.
> Running it in debug mode gives some clue:
> 
> Failed to parse TIMESTAMP from x.x.x.x: 12403: Jun 22 17:31:38 CEST:
> %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/17,
> changed state to down
Ah, yes! Haven't thought about running syslogd in debugging mode:

	Failed to parse TIMESTAMP from x.x.x.x: fail2ban.filter [79598]: INFO [?]
> Could you please give any advice or workaround for this issue?
I cannot answer whether it might be possible to either tell syslogd to accept
legacy timestamps [1] or configure fail2ban (or your applications) to switch to
using RFC5424 compliant timestamps.

[1] I did try to set '-O rfc3164' starting syslogd to no avail

Anyone?

Regards,
Michael

On 22. Jun 2018, at 17:59, Marek Zarychta <zarychtam at
plan-b.pwste.edu.pl> wrote:
> Could you please give any advice or workaround for this issue?
I switched to a workaround for the time being which you might use as well in a
similar way:

#) configure fail2ban to use /var/log/faillog
#) run something like that in the background:

	nohup tail -q -F /var/log/fail2ban.log | logger -t fail2ban.filter -p
daemon.notice &

#) to let this workaround survive a reboot you need to use a script fired up
from /etc/rc.d

Regards,
Michael