sshguard-users — User questions and answers, bugs, and general support

Re: [SSHGuard-users] Blocked attackers can still access docker containers

[<gi1...@gm...>]

OK, going through my nft rules again, I see a chain called
"DOCKER-USER". I found the (possibly outdated) documentation here:

    https://docs.docker.com/network/iptables/

and it says:

    By default, all external source IPs are allowed to connect to the
    Docker daemon. To allow only a specific IP or network to access the
    containers, insert a negated rule at the top of the DOCKER filter
    chain. For example, the following rule restricts external access to
    all IP addresses except 192.168.1.1:

	iptables -I DOCKER-USER -i ext_if ! -s 192.168.1.1 -j DROP

So I'm guessing the documentation is outdated (iptables instead of
nftables), and also slightly incorrect (it says DOCKER instead of
DOCKER-USER).

If we could also add sshguards blacklist rule to the DOCKER-USER chain
it might solve the problem. I don't know how to do this reliably though.

GI

-- 
A plateau is a high form of flattery.

Re: [SSHGuard-users] Blocked attackers can still access docker containers

[<gi1...@gm...>]

On Wed, Oct 30, 2019 at 11:14:04AM -0700, Kevin Zheng wrote:

> Thanks for the report. I think you're right in pointing out that the
> priority for SSHGuard is -10, but the priority for Docker is -100.
> 
> Is someone on the list familiar with firewalls on Linux? Is the right
> fix here just to decrease the priority for SSHGuard?

>From the nft man page:

    The priority parameter accepts a signed integer value  which
    specifies the  order  in which chains with same hook value are
    traversed. The ordering is ascending, i.e. lower priority values
    have  precedence  over higher ones.

I just opened /usr/lib/x86_64-linux-gnu/sshg-fw-nft-sets. In fw_init()
sshguard does
    
    run_nft "add chain" "${NFT_CHAIN}"' { type filter hook input priority -10 ; }' 4
    run_nft "add chain" "${NFT_CHAIN}"' { type filter hook input priority -10 ; }' 6

I changed priority to -200 (Docker had -100), and restarted sshguard.
There was  no change in the behavior. I can still access containers from
blocked IPs.

Best,

GI

PS: If you're trying to reproduce it, it might be simpler to run a
    vanilla nginx container instead of the gitolite container I
    suggested in my last email.

	mkdir ./html

	# put static web content in ./html. Plain text files are fine

	docker run --rm --name=nginx-test \
	    -v ./html:/usr/share/nginx/html:ro -p 8080:80 -d nginx

    This exposes port 8080 on the host. The exposed port stays
    accessible from all sshguard blocked attackers.

-- 
'Civilization' -- Going from shoeless toes to toeless shoes.

Re: [SSHGuard-users] Blocked attackers can still access docker containers

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

Thanks for the report. I think you're right in pointing out that the
priority for SSHGuard is -10, but the priority for Docker is -100.

Is someone on the list familiar with firewalls on Linux? Is the right
fix here just to decrease the priority for SSHGuard?

Thanks,
Kevin

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

[SSHGuard-users] Blocked attackers can still access docker containers

[<gi1...@gm...>]

Hi All,

Thanks for sshguard; I've been using it happily for some time now.

I'm writing to report a security issue I noticed recently: In short,
blocked attackers are still able to access docker containers.

Steps to reproduce:

    1. Run any docker container with an exposed port. Personally I'm
       running https://hub.docker.com/r/jgiannuzzi/gitolite

	docker run -p 2022:22 jgiannuzzi/gitolite

    2. Attack the host machine from some remote until it gets blocked.

	    remote> repeat 10 ssh spam@host
	    ...

	    host> journalctl --unit=sshguard.service
	    ...
	    Oct 30 11:19:20 gi sshguard[962]: Blocking "HOSTIP/32" for
		960 secs (4 attacks in 345 secs, after 4 abuses over
		2721 secs.)

    3. Check that the remote attacker is blocked as expected:

	    remote> ping host
	    (no response)
	    remote> ssh host
	    (no response)

    4. The exposed ports from docker containers are still visible to
       attackers:

	    remote> ssh -p 2022 git@host
	    SUCCEEDED

Any container with an exposed port will do. Doesn't have to be the one I
used above. I used to use iptables back in the day, but looks like
modern systems use nft. I checked out the rules added. Looks like the
relevant parts (from nft list ruleset) are:

    table ip sshguard {
        set attackers {
                type ipv4_addr
                flags interval
                elements = { REMOTE_IP, ... }
        }

        chain blacklist {
                type filter hook input priority -10; policy accept;
                ip saddr @attackers drop
        }
    }

    table ip nat {
        chain PREROUTING {
	    type nat hook prerouting priority -100; policy accept;
	    fib daddr type local counter packets 64 bytes 4890 jump DOCKER
        }

        chain INPUT {
	    type nat hook input priority 100; policy accept;
        }

        chain POSTROUTING {
	    type nat hook postrouting priority 100; policy accept;
	    oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade 
	    meta l4proto tcp ip saddr 172.17.0.3 ip daddr 172.17.0.3 tcp dport 22 counter packets 0 bytes 0 masquerade 
        }

	chain OUTPUT {
	    type nat hook output priority -100; policy accept;
	    ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER
        }

        chain DOCKER {
	    iifname "docker0" counter packets 0 bytes 0 return
	    iifname != "docker0" meta l4proto tcp ip daddr HOST_IP tcp dport 2022 counter packets 0 bytes 0 dnat to 172.17.0.3:22
        }
    }

I replaced the IP addresses with HOST_IP / REMOTE_IP above. I don't
fully understand the sequence above. Perhaps because sshguard adds rules
with priority -10 and docker with prority -100?

Regardless, the upshot is that docker containers are not protected at
all by sshguard. Moreover, if your container runs a ssh service, you
can't currently use sshguard on the host to test/block ssh attacks on
the container. (This is what I was trying to setup when I found the
above problem. My container passes logs to sshguard fine, and sshguard
claims to have blocked the IP of the attacker. But it only blocks the
attacker from accessing other ports on the host. The attacker still has
full access to all container exposed ports, and so can continue with his
ssh brute force attack.)

If you know how to fix this, or if I should report this somewhere else,
please let me know.

GI

-- 
'Confidence' -- The feeling a person has before he fully understands the
situation.

Re: [SSHGuard-users] Increasing danger level?

[Christopher E. <ce...@lc...>]

On 27.10.19 17:59, @lbutlr wrote:
> However, there’s a long list of usernames that would be appropriate on my systems for this beyond root. Admin, postmaster, toor, postfix, mysql, and many many others that are attempted all the time.

You could treat attacks with invalid or disallowed-by-ssh usernames more
severly:
Sshguard assigns all matches for invalid or disallowed users the token
'ssh_illegaluser', so instead of creating your own match, you could
increase the severity of that.

To set the danger level to <number>, in attack_parser.y, line 211, change

ssh_illegaluser

to

ssh_illegaluser  { attack->dangerousness = <number>; }

That should do the trick.

Re: [SSHGuard-users] Increasing danger level?

[@lbutlr <kr...@kr...>]

On 26 Oct 2019, at 04:51, Christopher Engelhard <ce...@lc...> wrote:
> However, if you're OK with building sshguard yourself, it's not too
> difficult to add these additional rules to your local version. Have a
> look at attack_(parser.y|scanner.l) in the linked PR as a guide to the
> necessary changes.
> 
> [1]
> https://bitbucket.org/robohack/sshguard/commits/43c8542552e8f5a3413d5c5984555bea4d77bb7e?at=master

Thanks. Grabbed that and am hoping to add it in.

However, there’s a long list of usernames that would be appropriate on my systems for this beyond root. Admin, postmaster, toor, postfix, mysql, and many many others that are attempted all the time.

In fact, a mechanism in sshguard that increased the danger or decreased the threshold for non-existent accounts would be great.



-- 
"It's like those French have a different word for *everything*" - Steve
Martin

Re: [SSHGuard-users] Increasing danger level?

[Christopher E. <ce...@lc...>]

On 26.10.19 10:43, @lbutlr wrote:
> Is it possible for me to increase the danger level for certain users?

To my knowledge, sshguard currently does not match usernames in the
attack signatures, only hosts/ips.

It's easy to add a fixed, escalated seriousness for a fixed (list of)
username(s) (In fact, someone did some work on this a while ago [1]).
Since that's neither dynamic not user-configurable, it's not really
ideal as a general solution:
 - it could only be justified for root
 - even then, would mean that people who do allow root logins would see
themselves rapidly blocked after mistyping a password ...

However, if you're OK with building sshguard yourself, it's not too
difficult to add these additional rules to your local version. Have a
look at attack_(parser.y|scanner.l) in the linked PR as a guide to the
necessary changes.


Christopher

[1]
https://bitbucket.org/robohack/sshguard/commits/43c8542552e8f5a3413d5c5984555bea4d77bb7e?at=master

[SSHGuard-users] Increasing danger level?

[@lbutlr <kr...@kr...>]

Is it possible for me to increase the danger level for certain users?

For example, my server does not allow logins on the accounts “root” or “admin” or several others, so I would like attempts to login to these accounts to instantly result in a maximal ban of the IP address and not to allow them to try to connect several times until they exceed a threshold; especially since I am seeing large attacks where an IP only tries to connect a few times an hour over the course of weeks, nearly never exceeding the thresholds, but many Its are coordinating attempts to login

Re: [SSHGuard-users] sshguard) exited with status 1.

[lists <li...@la...>]

<html><head><meta http-equiv="Content-Security-Policy" content="script-src 'self'; img-src * cid: data:;"><style id="outgoing-font-settings">#response_container_BBPPID{font-family: initial; font-size:initial; color: initial;}</style></head><body style="background-color: rgb(255, 255, 255); background-image: initial; line-height: initial;"><div id="response_container_BBPPID" style="outline:none;" dir="auto" contenteditable="false"> <div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"> Just an FYI, it helps to indicate the rev of the program and your OS (uname - a).&nbsp;</div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;"><br></div><div name="BB10" id="BB10_response_div_BBPPID" dir="auto" style="width:100%;">Because SSHGuard isn't in my repos, it doesn't get updated all the time. I find it occasionally breaks when I do OS updates. But if I get the latest SSHGuard, the problem is already solved.&nbsp;</div>                                                                                                                                      <div name="BB10" id="response_div_spacer_BBPPID" dir="auto" style="width:100%;"> <br style="display:initial"></div> <div id="blackberry_signature_BBPPID" name="BB10" dir="auto">     <div id="_signaturePlaceholder_BBPPID" name="BB10" dir="auto"></div> </div></div><div id="_original_msg_header_BBPPID" dir="auto">                                                                                                                                             <table width="100%" style="background-color: white; border-spacing: 0px; display: table; outline: none;" contenteditable="false"><tbody><tr><td colspan="2" style="padding: initial; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);">                           <div style="border-right: none; border-bottom: none; border-left: none; border-image: initial; border-top: 1pt solid rgb(181, 196, 223); padding: 3pt 0in 0in; font-family: Tahoma, &quot;BB Alpha Sans&quot;, &quot;Slate Pro&quot;; font-size: 10pt;">  <div id="from"><b>From:</b> ssh...@li...</div><div id="sent"><b>Sent:</b> October 22, 2019 12:51 PM</div><div id="to"><b>To:</b> ssh...@li...</div><div id="reply_to"><b>Reply-to:</b> ja...@ka...</div><div id="subject"><b>Subject:</b> [SSHGuard-users] sshguard) exited with status 1.</div></div></td></tr></tbody></table> <br> </div><!--start of _originalContent --><div name="BB10" dir="auto" style="background-image: initial; line-height: initial; outline: none;" contenteditable="false"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""></div>I a having an issue with SSHGuard . &nbsp; I have had it installed for a while and now I am getting thses error messages<div class=""><br class=""></div><div class=""><br class=""></div><div class=""><pre style="background-color:rgb( 255 , 255 , 255 )" class="">ct 22 11:53:21 triggerfish syslogd: Logging subprocess 8460 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:53:21 triggerfish syslogd: Logging subprocess 8461 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:53:59 triggerfish syslogd: Logging subprocess 8464 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:54:02 triggerfish syslogd: Logging subprocess 8467 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:54:46 triggerfish syslogd: Logging subprocess 8504 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:54:46 triggerfish syslogd: Logging subprocess 8506 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:55:00 triggerfish syslogd: Logging subprocess 8523 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:55:24 triggerfish syslogd: Logging subprocess 8528 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:55:24 triggerfish syslogd: Logging subprocess 8529 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:56:13 triggerfish syslogd: Logging subprocess 8548 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:56:19 triggerfish syslogd: Logging subprocess 8551 (exec /usr/local/sbin/sshguard) exited with status 1.</pre><div class="">&nbsp;I have no idea what it s trying to tell me</div></div><div class=""><br class=""></div><div class="">Anu help woud be greatly appreciated</div><div class=""><br class=""></div><div class=""><br class=""></div><!--end of _originalContent --></div></body></html>

Re: [SSHGuard-users] sshguard) exited with status 1.

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

Hi Jason,

On 10/22/19 9:07 AM, jason hirsh via sshguard-users wrote:
> I a having an issue with SSHGuard .   I have had it installed for a
> while and now I am getting thses error messages
> 
> ct 22 11:53:21 triggerfish syslogd: Logging subprocess 8460 (exec /usr/local/sbin/sshguard) exited with status 1.

Did you recently upgrade SSHGuard? Are you running SSHGuard as a
subprocess from syslogd? Starting SSHGuard is no longer supported. Check
`man sshguard-setup` for details.

Regards,
Kevin

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

[SSHGuard-users] sshguard) exited with status 1.

[jason h. <ja...@ka...>]

I a having an issue with SSHGuard .   I have had it installed for a while and now I am getting thses error messages


ct 22 11:53:21 triggerfish syslogd: Logging subprocess 8460 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:53:21 triggerfish syslogd: Logging subprocess 8461 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:53:59 triggerfish syslogd: Logging subprocess 8464 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:54:02 triggerfish syslogd: Logging subprocess 8467 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:54:46 triggerfish syslogd: Logging subprocess 8504 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:54:46 triggerfish syslogd: Logging subprocess 8506 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:55:00 triggerfish syslogd: Logging subprocess 8523 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:55:24 triggerfish syslogd: Logging subprocess 8528 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:55:24 triggerfish syslogd: Logging subprocess 8529 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:56:13 triggerfish syslogd: Logging subprocess 8548 (exec /usr/local/sbin/sshguard) exited with status 1.
Oct 22 11:56:19 triggerfish syslogd: Logging subprocess 8551 (exec /usr/local/sbin/sshguard) exited with status 1.
 I have no idea what it s trying to tell me

Anu help woud be greatly appreciated

Re: [SSHGuard-users] sshguard 1.7.1

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

On 9/24/19 7:00 PM, Ivan Avery Frey wrote:
> If I run sshguard 1.7.1 with a complete set of logs to monitor it will
> replace the sshguard currently running?

No.

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

Re: [SSHGuard-users] sshguard 1.7.1

[Ivan A. F. <iva...@gm...>]

On Tue, Sep 24, 2019, 21:40 Kevin Zheng, <kev...@gm...> wrote:

>
> > What if I want to add more logs for SSHGuard to monitor; is
> > there a way to tell the running daemon to monitor these additional
> > logs?
>
> While running, no. If you care about this, SSHGuard is experimenting
> with the ability to save blocks on exit, so restarting SSHGuard won't
> cause you to lose existing blocks.
>

If I run sshguard 1.7.1 with a complete set of logs to monitor it will
replace the sshguard currently running?

Ivan.

>

Re: [SSHGuard-users] sshguard 1.7.1

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

On 9/24/19 6:30 PM, Ivan Avery Frey wrote:
> I'm runnng SSHGuard 1.7.1 on Debian Stretch with kernel 4.1.48-vs.
> 
> This is a kernel running with the Linux-VServer patches.
> 
> What happens if I run "sshguard -v"? Will it kill the daemon that is 
> currently running?

It shouldn't; `sshguard -v` only reports the version.

> Is there a configuration file like in version
> 2.3.1?

No, you'd have to upgrade.

> What if I want to add more logs for SSHGuard to monitor; is
> there a way to tell the running daemon to monitor these additional
> logs?

While running, no. If you care about this, SSHGuard is experimenting
with the ability to save blocks on exit, so restarting SSHGuard won't
cause you to lose existing blocks.

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

[SSHGuard-users] sshguard 1.7.1

[Ivan A. F. <iva...@gm...>]

I'm runnng SSHGuard 1.7.1 on Debian Stretch with kernel 4.1.48-vs.

This is a kernel running with the Linux-VServer patches.

What happens if I run "sshguard -v"? Will it kill the daemon that is
currently running? Is there a configuration file like in version
2.3.1? What if I want to add more logs for SSHGuard to monitor; is
there a way to tell the running daemon to monitor these additional
logs?

Thanks in advance,
Ivan.

Re: [SSHGuard-users] SSHGuard website is down

[Jos C. <ssh...@cl...>]

On 30-8-19 17:05, Kevin Zheng wrote:
> SSHGuard's web host suffered a catastrophic failure, and as a result the
> SSHGuard web site is currently down. We're working on bringing it back up.

No worries - hope you will find a solution for this.

-- With both feed on the ground you will never make a step forward

[SSHGuard-users] SSHGuard website is down

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

Hi there,

SSHGuard's web host suffered a catastrophic failure, and as a result the
SSHGuard web site is currently down. We're working on bringing it back up.

In spite of this, business as usual on the mailing list, Bitbucket,
SourceForge, and IRC channel.

Regards,
Kevin

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

Re: [SSHGuard-users] sshguard-users Digest, Vol 98, Issue 3

[Christos C. <ch...@cr...>]

Hello Kevin,

This error appears mostly when PHP doesn't respond to Nginx.

Kind regards,
Christos Chatzaras

> 
> On 8/29/19 2:52 AM, Christopher Engelhard wrote:
>> Hi,
>> for a while now the project website www.sshguard.net has been
>> unavailable (502 Bad Gateway). Maintenance of error?
> 
> Thanks for the report. I haven't been paying attention -- I don't think
> this is planned maintenance.
> 
> Regards,
> Kevin

Re: [SSHGuard-users] Website down?

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

On 8/29/19 2:52 AM, Christopher Engelhard wrote:
> Hi,
> for a while now the project website www.sshguard.net has been
> unavailable (502 Bad Gateway). Maintenance of error?

Thanks for the report. I haven't been paying attention -- I don't think
this is planned maintenance.

Regards,
Kevin

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

[SSHGuard-users] Website down?

[Christopher E. <ce...@lc...>]

Hi,
for a while now the project website www.sshguard.net has been 
unavailable (502 Bad Gateway). Maintenance of error?

Best,
Christopher

[SSHGuard-users] SSHGuard IRC channel on Freenode

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

Hi there,

SSHGuard is now in the #sshguard IRC channel on Freenode.

You're welcome to join us for help, discussions, suggestions, or just to
stop by and say hi.

If you need help connecting to Freenode, see:
https://freenode.net/kb/answer/chat

Regards,
Kevin

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

[SSHGuard-users] SSHGuard 2.4.0 release announcement

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

Dear SSHGuard users,

SSHGuard 2.4.0 is now available. If you are running an earlier version,
and had issues with SSHGuard leaving processes running after killing the
wrong process, you can upgrade to get a fix.

**Added**

- Match "Failed authentication attempt" for Gitea

**Changed**

- Log human-readable service names instead of service code

**Fixed**

- Correctly terminate child processes when ``sshguard`` is killed

**Removed**

- No longer accept logs given via standard input

Regards,
Kevin

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xEACF0F76C22E1090
XMPP: ke...@ee...

Re: [SSHGuard-users] openrc incorrect status

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

Thanks for the report. I think there's a suggestion on how to completely
kill things off, but we need to test more to make sure things work
consistently across all operating systems.

I think eventually we'll have to rewrite the driver script in C to get
some sort of consistency... I was hoping we wouldn't have to do that but
shells seem to do different things across the board.

On 4/7/19 3:51 PM, gi...@co... wrote:
> This is in reply to the mail thread last written to on 2019-02-14.
> 
> I also stumbled across this issue. OpenRC can track sshguard better if
> you use the --pidfile flag in start-stop-daemon, as such
> 
>   start-stop-daemon --start --wait ${SSHGUARD_WAIT} --background --quiet
> --pidfile ${SSHGUARD_PIDFILE} --exec \
>    /usr/sbin/sshguard -- -i ${SSHGUARD_PIDFILE} ${SSHGUARD_OPTS}
> 
> However, referring to below excerpt from the sshguard shell-script
> (/usr/sbin/sshguard on Alpine Linux), when the service is stopped,
> sshg-blocker and the shell-script will be killed, but the $tailcmd and
> sshg-parser will continue, orphaned.
> 
> eval $tailcmd | $libexec/sshg-parser | \
>     $libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$)
> 
> I don't know why that is.
> 
> 
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users


-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

Re: [SSHGuard-users] openrc incorrect status

[<gi...@co...>]

This is in reply to the mail thread last written to on 2019-02-14.

I also stumbled across this issue. OpenRC can track sshguard better if 
you use the --pidfile flag in start-stop-daemon, as such

   start-stop-daemon --start --wait ${SSHGUARD_WAIT} --background --quiet 
--pidfile ${SSHGUARD_PIDFILE} --exec \
    /usr/sbin/sshguard -- -i ${SSHGUARD_PIDFILE} ${SSHGUARD_OPTS}

However, referring to below excerpt from the sshguard shell-script 
(/usr/sbin/sshguard on Alpine Linux), when the service is stopped, 
sshg-blocker and the shell-script will be killed, but the $tailcmd and 
sshg-parser will continue, orphaned.

eval $tailcmd | $libexec/sshg-parser | \
     $libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$)

I don't know why that is.

Re: [SSHGuard-users] openrc incorrect status

[Toby P. <tob...@gm...>]

Kevin -

Here you go:
------------------------------------------------------------------------------------------------------
#!/sbin/openrc-run
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

depend() {
  after iptables
  use logger
}

SSHGUARD_PIDFILE=${SSHGUARD_PIDFILE:-/var/run/${SVCNAME}.pid}

start() {
  ebegin "Starting sshguard"
  [ -z "${SSHGUARD_WAIT}" ] && SSHGUARD_WAIT=999
  start-stop-daemon --start --wait ${SSHGUARD_WAIT} --background --quiet 
--exec \
   /usr/sbin/sshguard -- -i ${SSHGUARD_PIDFILE} ${SSHGUARD_OPTS}
  eend $?
}

stop() {
  ebegin "Stopping sshguard"
  start-stop-daemon --stop -p ${SSHGUARD_PIDFILE}
  eend $?
}
------------------------------------------------------------------------------------------------------




------ Original Message ------
From: "Kevin Zheng" <kev...@gm...>
To: "Toby Poynder" <to...@wh...>
Cc: ssh...@li...
Sent: 14/02/2019 19:20:30
Subject: Re: [SSHGuard-users] openrc incorrect status

>Hi Toby,
>
>Glad to hear. Do you know where we can find the init.d scripts for Gentoo so that we might be able to debug the issue?
>
>I suspect it has something to do with where we write the PID file.
>
>Regards,
>Kevin
>
>On 2/14/19 2:49 AM, Toby Poynder wrote:
>>I'm running Safeguard on two Gentoo linux servers (both openrc)  and both show the status as "crashed" even when the system is running finel
>>
>>[elvis] /etc/init.d# rc-service sshguard status
>>* status: crashed
>>
>>Apart from this I ave no complaints - much easier to set up and use than fail2ban.
>>-- Toby Poynder
>>London, UK
>>
>>
>>_______________________________________________
>>sshguard-users mailing list
>>ssh...@li...
>>https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>
>
>
>-- Kevin Zheng
>kev...@gm... | ke...@be... | PGP: 0xC22E1090

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus