sshguard-users

Re: [SSHGuard-users] Tiny fix to security/sshguard to allow use of daemon_flags

[Sven F. <sve...@gm...>]

On Fri, Jul 16, 2021 at 1:13 PM Sven F. <sve...@gm...> wrote:
>
>
>
> On Tue, Mar 23, 2021 at 7:11 AM Andreas Kusalananda Kähäri <and...@ab...> wrote:
>>
>> A user contacted me about the security/sshguard port.  They wanted to
>> use daemon_flags with the port, which means this needs to be added to
>> the pexp expression in the rc.d file.
>>
>> The attached patch does this in the similar manner as is done for e.g.
>> sshd and unbound.
>>
>>
>> Regards,
>> Andreas (port maintainer)
>>
>> --
>> Andreas (Kusalananda) Kähäri
>> SciLifeLab, NBIS, ICM
>> Uppsala University, Sweden
>>
>> .
>
>
> Running current i had issue with sshguard
>
> Note:
> OpenBSD j1800 6.9 GENERIC.MP#129 amd64
> # grep pexp /etc/rc.d/rc.subr
> [..]
> pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
>
> sshg-blocker ran full cpu load and rcctl restart did not kill it,
> only kill -9 was able to stop the process.
>
> I also notice than in 6.8 reading STDIN was broken
>
> I was able to ktrace sshg-blocker :
>
> # kdump  -f /tmp/ktrace.out  | head
>  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()
>  83231 sshg-blocker RET   sched_yield 0
>
> # 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()
>  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()
>  83231 sshg-blocker PSIG  SIGKILL SIG_DFL
>
> I can perform compilation and test
>
> I will now try to run sshguard with STDIN as an input ,
> I have no method to produce the problem so far.
>
> # sshguard -v
> SSHGuard 2.4.1
>
>

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:

2.4.0

[..]

Removed

No longer accept logs given via standard input

And it makes no sense at all given the statement of the home page

Is there a proposed workaround using a silly LOGREADER ?

like ?
# grep LOGREADER /etc/sshguard.conf
#LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -t
sendmail -o cat"
LOGREADER=/bin/cat
# SSHGUARD_DEBUG=1 cat /var/log/authlog | sshguard
Terminated

Best.


--
--
---------------------------------------------------------------------------------------------------------------------
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: [SSHGuard-users] Tiny fix to security/sshguard to allow use of daemon_flags

[Kevin Z. <kev...@gm...>]

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.

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.

> 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.

Since I have you OpenBSD folks around, how's pledge() support working 
out? I have not tested on OpenBSD for some time now.

Thanks,
Kevin

Re: [SSHGuard-users] Tiny fix to security/sshguard to allow use of daemon_flags

[Sven F. <sve...@gm...>]

On Fri, Jul 16, 2021 at 3:03 PM Kevin Zheng <kev...@gm...> 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

Re: [SSHGuard-users] Tiny fix to security/sshguard to allow use of daemon_flags

[kaycee gb <kis...@ho...>]

Le Fri, 16 Jul 2021 20:00:05 -0400,
"Sven F." <sve...@gm...> a écrit :

> On Fri, Jul 16, 2021 at 3:03 PM Kevin Zheng <kev...@gm...> wrote:
...
> > 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

pf table is freed when daemon is stopped.

...

K.