Michael Grimm
2018-Jun-22 16:54 UTC
py-fail2ban turned silent after syslogd rollout (r335059, stable/11)
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 downAh, 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
Ed Schouten
2018-Jun-22 19:11 UTC
py-fail2ban turned silent after syslogd rollout (r335059, stable/11)
Hi Marek, [ +glebius ] Thanks for reporting this! 2018-06-22 18:54 GMT+02:00 Michael Grimm <trashcan at ellael.org>:>> 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 [?]This is interesting. As fail2ban uses Python's logging framework, I managed to reproduce this with the following script: #!/usr/bin/env python3 import logging.handlers logging.basicConfig(handlers=[ logging.handlers.SysLogHandler( '/var/run/log', facility=logging.handlers.SysLogHandler.LOG_LOCAL7) ]) logging.warning('Hi') This will write the following message to syslogd: sendto(3,"<188>WARNING:root:Hi\0",21,0,NULL,0) = 21 (0x15) This message gets rejected by syslogd, due to the change made in r326573, which later got adjusted by me and subsequently MFCed: https://svnweb.freebsd.org/base?view=revision&revision=326573 Gleb, what are your thoughts on the attached patch? It alters syslogd to let the 'legacy' RFC 3164 parser also accept messages without a timestamp. The time on the syslogd server will be used instead. Michael, Marek, could you please give this patch a try? Thanks! -- Ed Schouten <ed at nuxi.nl> Nuxi, 's-Hertogenbosch, the Netherlands -------------- next part -------------- A non-text attachment was scrubbed... Name: syslogd-optional-timestamp.diff Type: text/x-patch Size: 2720 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20180622/9f1e848e/attachment.bin>