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

Michael Grimm trashcan at ellael.org
Fri Jun 22 16:54:35 UTC 2018


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





More information about the freebsd-ports mailing list