On Fri, Jul 16, 2021 at 3:03 PM Kevin Zheng <kevinz5...@gmail.com> wrote: > > Hi all, > > On 7/16/21 12:41 PM, Sven F. wrote: > > The website first page: > > > > sshguard can read log messages from standard input (suitable for > > piping from syslog) > > > > But since (openbsd 6.8) 2.4.1 > > > > # cat /var/log/authlog | sshguard > > sshguard: /etc/sshguard.conf is missing FILES and LOGREADER; please specify > > one > > > > It s in the release note of 2.4.0: > > > > No longer accept logs given via standard input > > > > And it makes no sense at all given the statement of the home page > The home page is out of date. I will go update the home page. > > Originally, SSHGuard allowed piping logs to its standard input, for the > purpose of piping from syslog. However, folks were unhappy about > SSHGuard restarting every 24-hours or so, forgetting the attackers that > it had kept in memory.
Attackers are supposed to be in a pf table , extern to the daemon > > I don't know if OpenBSD's syslog has this behavior, but my man page says > (about piping output to commands): > > The command itself runs > with stdout and stderr redirected to /dev/null. Upon receipt of a > SIGHUP, syslogd(8) will close the pipe to the process. If the > process did not exit voluntarily, it will be sent a SIGTERM signal > after a grace period of up to 60 seconds. > > It was decided that it was better not to support piping from standard > input, than to deal with this. How is this a problem ? closing stdin will trigger a read at 0, a lot of basix unix command run | like | that -TERM is just improving the situation in case the sub program got stuck > > > Is there a proposed workaround using a silly LOGREADER ? > > I believe your workaround works, but please be aware of the above issue > if you choose to pipe from syslogd. I have no idea what issue you're talking about and the daemon is broken out of the box without STDIN ( se below ) > > Since I have you OpenBSD folks around, how's pledge() support working > out? I have not tested on OpenBSD for some time now. > Much poorly ( 200% cpu crap loop unkillable using default config ) # kdump -f /tmp/ktrace.out | tail 83231 sshg-blocker CALL sched_yield() 83231 sshg-blocker RET sched_yield 0 83231 sshg-blocker RET sched_yield 0 83231 sshg-blocker CALL sched_yield() 83231 sshg-blocker CALL sched_yield() This is all very confusing > Thanks, > Kevin -- -- --------------------------------------------------------------------------------------------------------------------- Knowing is not enough; we must apply. Willing is not enough; we must do
