UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Andreas Kusalananda Kähäri

Please find the diffs for an updated port of sshguard attached.

This updates sshguard from version 1.5 to 2.1.0.  One of the main
reasons to update to this version is that sshguard now seems to
correctly parse the OpenBSD sshd logs.  One can now also block an entire
subnet rather than individual IP addresses, if one is so inclined.

I have been running this port for a few weeks, and it seems to work as
advertised.

Note that the /etc/sshguard.conf file now is required (I modified the
sample file so that it hopefully fits a vanilla OpenBSD system).

I posted about this update in late March when I had issues getting the
sshguard service to properly shut down, but that issue has since been
resolved (rc_stop() needs to send it the HUP signal).

Release announcements for sshguard are available at
https://www.sshguard.net/litenewz/feeds/

Regards,

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Andreas Kusalananda Kähäri
On Sun, Apr 22, 2018 at 04:03:23PM +0200, Andreas Kusalananda Kähäri wrote:
>
> Please find the diffs for an updated port of sshguard attached.

Now actually attached, duh.


>
> This updates sshguard from version 1.5 to 2.1.0.  One of the main
> reasons to update to this version is that sshguard now seems to
> correctly parse the OpenBSD sshd logs.  One can now also block an entire
> subnet rather than individual IP addresses, if one is so inclined.
>
> I have been running this port for a few weeks, and it seems to work as
> advertised.
>
> Note that the /etc/sshguard.conf file now is required (I modified the
> sample file so that it hopefully fits a vanilla OpenBSD system).
>
> I posted about this update in late March when I had issues getting the
> sshguard service to properly shut down, but that issue has since been
> resolved (rc_stop() needs to send it the HUP signal).
>
> Release announcements for sshguard are available at
> https://www.sshguard.net/litenewz/feeds/
>
> Regards,
>
> --
> Andreas Kusalananda Kähäri,
> National Bioinformatics Infrastructure Sweden (NBIS),
> Uppsala University, Sweden.
--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

sshguard.diff (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Klemens Nanni-2
On Sun, Apr 22, 2018 at 04:04:02PM +0200, Andreas Kusalananda Kähäri wrote:

> On Sun, Apr 22, 2018 at 04:03:23PM +0200, Andreas Kusalananda Kähäri wrote:
> > This updates sshguard from version 1.5 to 2.1.0.  One of the main
> > reasons to update to this version is that sshguard now seems to
> > correctly parse the OpenBSD sshd logs.  One can now also block an entire
> > subnet rather than individual IP addresses, if one is so inclined.
> >
> > I have been running this port for a few weeks, and it seems to work as
> > advertised.
> >
> > Note that the /etc/sshguard.conf file now is required (I modified the
> > sample file so that it hopefully fits a vanilla OpenBSD system).
> >
> > I posted about this update in late March when I had issues getting the
> > sshguard service to properly shut down, but that issue has since been
> > resolved (rc_stop() needs to send it the HUP signal).
> >
> > Release announcements for sshguard are available at
> > https://www.sshguard.net/litenewz/feeds/

> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/security/sshguard/Makefile,v
> retrieving revision 1.11
> diff -u -p -u -r1.11 Makefile
> --- Makefile 11 Jan 2018 19:27:09 -0000 1.11
> +++ Makefile 22 Apr 2018 13:47:55 -0000
> @@ -2,8 +2,7 @@
>  
>  COMMENT= protect against brute force attacks on sshd and others
>  
> -DISTNAME= sshguard-1.5
> -REVISION= 4
> +DISTNAME= sshguard-2.1.0
>  CATEGORIES= security
>  
>  # BSD
> @@ -13,11 +12,20 @@ WANTLIB+= c pthread
>  
>  HOMEPAGE= http://www.sshguard.net/
This has TLS.

>  MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=sshguard/}
> -EXTRACT_SUFX= .tar.bz2
> +EXTRACT_SUFX= .tar.gz
.tar.gz is the default, just drop it.

>  CONFIGURE_STYLE=gnu
Upstream ships a configure script already, `simple' is enough and the
port builds fine.

>  NO_TEST= Yes
>  
> -CONFIGURE_ARGS = --with-firewall=pf
> +pre-install:
SUBST_CMD should usually go into post-patch. No issue with sshguard but
that's where it's generally safe to do as some ports copy/modify sources
during configure.

> + ${SUBST_CMD} ${WRKSRC}/doc/sshguard.8
> + ${SUBST_CMD} ${WRKSRC}/examples/sshguard.conf.sample
> +
> +post-install:
> + ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/sshguard
> + ${INSTALL_DATA} ${WRKSRC}/examples/sshguard.conf.sample \
> +    ${PREFIX}/share/examples/sshguard
> + ${INSTALL_DATA} ${WRKSRC}/examples/whitelistfile.example \
> +    ${PREFIX}/share/examples/sshguard
>  
>  .include <bsd.port.mk>

Manual pages are installed under share/man/ as opposed to man/ as seen
after `make update-plist', this can be fixed by passing prefix and
mandir through CONFIGURE_ARGS.

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Jeremie Courreges-Anglas-2
On Mon, Apr 23 2018, Klemens Nanni <[hidden email]> wrote:

> On Sun, Apr 22, 2018 at 04:04:02PM +0200, Andreas Kusalananda Kähäri wrote:
>> On Sun, Apr 22, 2018 at 04:03:23PM +0200, Andreas Kusalananda Kähäri wrote:
>> > This updates sshguard from version 1.5 to 2.1.0.  One of the main
>> > reasons to update to this version is that sshguard now seems to
>> > correctly parse the OpenBSD sshd logs.  One can now also block an entire
>> > subnet rather than individual IP addresses, if one is so inclined.
>> >
>> > I have been running this port for a few weeks, and it seems to work as
>> > advertised.
>> >
>> > Note that the /etc/sshguard.conf file now is required (I modified the
>> > sample file so that it hopefully fits a vanilla OpenBSD system).
>> >
>> > I posted about this update in late March when I had issues getting the
>> > sshguard service to properly shut down, but that issue has since been
>> > resolved (rc_stop() needs to send it the HUP signal).
>> >
>> > Release announcements for sshguard are available at
>> > https://www.sshguard.net/litenewz/feeds/
>
>> Index: Makefile
>> ===================================================================
>> RCS file: /cvs/ports/security/sshguard/Makefile,v
>> retrieving revision 1.11
>> diff -u -p -u -r1.11 Makefile
>> --- Makefile 11 Jan 2018 19:27:09 -0000 1.11
>> +++ Makefile 22 Apr 2018 13:47:55 -0000
>> @@ -2,8 +2,7 @@
>>  
>>  COMMENT= protect against brute force attacks on sshd and others
>>  
>> -DISTNAME= sshguard-1.5
>> -REVISION= 4
>> +DISTNAME= sshguard-2.1.0
>>  CATEGORIES= security
>>  
>>  # BSD
>> @@ -13,11 +12,20 @@ WANTLIB+= c pthread
>>  
>>  HOMEPAGE= http://www.sshguard.net/
> This has TLS.
>
>>  MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=sshguard/}
>> -EXTRACT_SUFX= .tar.bz2
>> +EXTRACT_SUFX= .tar.gz
> .tar.gz is the default, just drop it.
>
>>  CONFIGURE_STYLE=gnu
> Upstream ships a configure script already, `simple' is enough and the
> port builds fine.

This is a proper autoconf script thus "gnu" is correct here and helps
passing sane defaults.  Any reason to use "simple" here?

>>  NO_TEST= Yes
>>  
>> -CONFIGURE_ARGS = --with-firewall=pf
>> +pre-install:
> SUBST_CMD should usually go into post-patch. No issue with sshguard but
> that's where it's generally safe to do as some ports copy/modify sources
> during configure.
>
>> + ${SUBST_CMD} ${WRKSRC}/doc/sshguard.8
>> + ${SUBST_CMD} ${WRKSRC}/examples/sshguard.conf.sample
>> +
>> +post-install:
>> + ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/sshguard
>> + ${INSTALL_DATA} ${WRKSRC}/examples/sshguard.conf.sample \
>> +    ${PREFIX}/share/examples/sshguard
>> + ${INSTALL_DATA} ${WRKSRC}/examples/whitelistfile.example \
>> +    ${PREFIX}/share/examples/sshguard
>>  
>>  .include <bsd.port.mk>
>
> Manual pages are installed under share/man/ as opposed to man/ as seen
> after `make update-plist', this can be fixed by passing prefix and
> mandir through CONFIGURE_ARGS.

No need to do that with CONFIGURE_STYLE=gnu.

py-docutils can be detected at configure time if present, the build
doesn't fail if removed after configure and the manpage content doesn't
change.  So there's probably no need to force-disable it.

Can't really comment on the rest of the port or the rc.d glue.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Stuart Henderson
In reply to this post by Klemens Nanni-2
On 2018/04/23 00:12, Klemens Nanni wrote:
>
> >  CONFIGURE_STYLE=gnu
> Upstream ships a configure script already, `simple' is enough and the
> port builds fine.

Huh? See highlighted lines below.


   CONFIGURE_STYLE
           Set to style of configuration that needs to happen.

           If ‘perl’, assume perl(1)'s ExtUtils::MakeMaker(3p) style.  Add
           ‘modbuild’ to enable Module::Build(3p), ‘modbuild tiny’ to enable
           Module::Build::Tiny(3p), or ‘modinst’ for Module::Install(3p) style.

>>>        If ‘gnu’, assume GNU configure style.  Add ‘dest’ if port does not
           handle DESTDIR correctly, and needs to be configured to add DESTDIR
           to prefixes (see also DESTDIRNAME).  Add ‘old’ if port is an older
           autoconf port that does not recognize --sysconfdir.  Add ‘autoconf’
           if autoconf needs to be rerun first, but set ‘no-autoheader’ to
           prevent autoheader from running.  Add ‘automake’ if automake may
           need to be rerun.  Otherwise, automake will be explicitly disabled.
           Note that automake is never run automatically.  In order to use it,
           CONFIGURE_STYLE should include ‘automake’ and there should be a
           {pre,do}-configure target running automake.

           If ‘imake’, assume port configures using X11 ports Imakefile
           framework.  Add ‘noman’ if port has no man pages the Imakefile
           should try installing.

>>>        If ‘simple’, there is a configure script, but it does not fit the
>>>        normal GNU configure conventions.

           Extensions may be defined by specific MODULES.  See port-modules(5)
           for details.

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Andreas Kusalananda Kähäri
In reply to this post by Andreas Kusalananda Kähäri
On Sun, Apr 22, 2018 at 04:04:02PM +0200, Andreas Kusalananda Kähäri wrote:
> On Sun, Apr 22, 2018 at 04:03:23PM +0200, Andreas Kusalananda Kähäri wrote:
> >
> > Please find the diffs for an updated port of sshguard attached.
>
> Now actually attached, duh.
>

Updated patch attached with comments from kn@ taken into account, but
with CONFIGURE_STYLE=gnu left in place as suggested by Jeremie and
Stuart.

Regards,

>
> >
> > This updates sshguard from version 1.5 to 2.1.0.  One of the main
> > reasons to update to this version is that sshguard now seems to
> > correctly parse the OpenBSD sshd logs.  One can now also block an entire
> > subnet rather than individual IP addresses, if one is so inclined.
> >
> > I have been running this port for a few weeks, and it seems to work as
> > advertised.
> >
> > Note that the /etc/sshguard.conf file now is required (I modified the
> > sample file so that it hopefully fits a vanilla OpenBSD system).
> >
> > I posted about this update in late March when I had issues getting the
> > sshguard service to properly shut down, but that issue has since been
> > resolved (rc_stop() needs to send it the HUP signal).
> >
> > Release announcements for sshguard are available at
> > https://www.sshguard.net/litenewz/feeds/
> >
> > Regards,

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

sshguard.diff (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Klemens Nanni-2
On Mon, Apr 23, 2018 at 11:12:55AM +0200, Andreas Kusalananda Kähäri wrote:

> On Sun, Apr 22, 2018 at 04:04:02PM +0200, Andreas Kusalananda Kähäri wrote:
> > On Sun, Apr 22, 2018 at 04:03:23PM +0200, Andreas Kusalananda Kähäri wrote:
> > >
> > > Please find the diffs for an updated port of sshguard attached.
> >
> > Now actually attached, duh.
> >
>
> Updated patch attached with comments from kn@ taken into account, but
> with CONFIGURE_STYLE=gnu left in place as suggested by Jeremie and
> Stuart.
I forgot about this diff when removing -O2 earlier (portroach also
wouldn't detect an update due to EXTRACT_SUFX change), thanks Andreas
for reminding me.

The diff looks good, I made a few additional changes:

- Drop README: sshguard-intro(7) contains all relevant information
- sshguard.rc: $pexp -> ${pexp}, unfold rc_stop()
- Makefile: Use SUBST_CMD and INSTALL_DATA just once

On amd64 sshguard continues to work.

1.5.0 is broken on sparc64 due to an assertion failure when parsing log
lines, 2.1.0 fixed this.

OK?

Index: Makefile
===================================================================
RCS file: /cvs/ports/security/sshguard/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile 24 Jun 2018 10:54:19 -0000 1.12
+++ Makefile 24 Jun 2018 14:45:49 -0000
@@ -2,8 +2,7 @@
 
 COMMENT= protect against brute force attacks on sshd and others
 
-DISTNAME= sshguard-1.5
-REVISION= 5
+DISTNAME= sshguard-2.1.0
 CATEGORIES= security
 
 # BSD
@@ -13,11 +12,18 @@ WANTLIB+= c pthread
 
 HOMEPAGE= https://www.sshguard.net/
 MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=sshguard/}
-EXTRACT_SUFX= .tar.bz2
 
 CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS= --with-firewall=pf
 
 NO_TEST= Yes
+
+post-patch:
+ ${SUBST_CMD} ${WRKSRC}/doc/sshguard.8 \
+    ${WRKSRC}/examples/sshguard.conf.sample
+
+post-install:
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/sshguard/
+ ${INSTALL_DATA} ${WRKSRC}/examples/*.{example,sample} \
+    ${PREFIX}/share/examples/sshguard/
 
 .include <bsd.port.mk>
Index: distinfo
===================================================================
RCS file: /cvs/ports/security/sshguard/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo 27 Jan 2014 15:49:15 -0000 1.3
+++ distinfo 24 Jun 2018 14:45:49 -0000
@@ -1,2 +1,2 @@
-SHA256 (sshguard-1.5.tar.bz2) = tTf4dlRV/fhCT4fUvWleW2dbiOXRZIZUUhN5Rwk+fhk=
-SIZE (sshguard-1.5.tar.bz2) = 303767
+SHA256 (sshguard-2.1.0.tar.gz) = ISUqSDSthAjfOE7k3fRoYkqp3pzq1a/eHHc4CkjPAoo=
+SIZE (sshguard-2.1.0.tar.gz) = 1117466
Index: patches/patch-configure
===================================================================
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- patches/patch-configure 24 Jun 2018 10:54:19 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,13 +0,0 @@
-$OpenBSD: patch-configure,v 1.1 2018/06/24 10:54:19 kn Exp $
-
-Index: configure
---- configure.orig
-+++ configure
-@@ -5949,7 +5949,6 @@ then
-     STD99_CFLAGS="-xc99"
- else
-     # other compiler (assume gcc-compatibile :( )
--    OPTIMIZER_CFLAGS="-O2"
-     WARNING_CFLAGS="-Wall"
-     STD99_CFLAGS="-std=c99"
- fi
Index: patches/patch-doc_sshguard_8
===================================================================
RCS file: patches/patch-doc_sshguard_8
diff -N patches/patch-doc_sshguard_8
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-doc_sshguard_8 24 Jun 2018 14:45:49 -0000
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: doc/sshguard.8
+--- doc/sshguard.8.orig
++++ doc/sshguard.8
+@@ -119,7 +119,7 @@ Set to enable verbose output from sshg\-blocker.
+ .SH FILES
+ .INDENT 0.0
+ .TP
+-.B %PREFIX%/etc/sshguard.conf
++.B ${SYSCONFDIR}/sshguard.conf
+ See sample configuration file.
+ .UNINDENT
+ .SH WHITELISTING
Index: patches/patch-examples_sshguard_conf_sample
===================================================================
RCS file: patches/patch-examples_sshguard_conf_sample
diff -N patches/patch-examples_sshguard_conf_sample
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-examples_sshguard_conf_sample 24 Jun 2018 14:45:49 -0000
@@ -0,0 +1,31 @@
+$OpenBSD$
+
+Index: examples/sshguard.conf.sample
+--- examples/sshguard.conf.sample.orig
++++ examples/sshguard.conf.sample
+@@ -7,9 +7,11 @@
+ #### REQUIRED CONFIGURATION ####
+ # Full path to backend executable (required, no default)
+ #BACKEND="/usr/local/libexec/sshg-fw-iptables"
++BACKEND="${TRUEPREFIX}/libexec/sshg-fw-pf"
+
+ # Space-separated list of log files to monitor. (optional, no default)
+ #FILES="/var/log/auth.log /var/log/authlog /var/log/maillog"
++FILES="/var/log/authlog"
+
+ # Shell command that provides logs on standard output. (optional, no default)
+ # Example 1: ssh and sendmail from systemd journal:
+@@ -40,11 +42,11 @@ DETECTION_TIME=1800
+ # !! Warning: These features may not work correctly with sandboxing. !!
+
+ # Full path to PID file (optional, no default)
+-#PID_FILE=/run/sshguard.pid
++#PID_FILE=/var/run/sshguard.pid
+
+ # Colon-separated blacklist threshold and full path to blacklist file.
+ # (optional, no default)
+-#BLACKLIST_FILE=90:/var/lib/sshguard/enemies
++#BLACKLIST_FILE=90:/var/db/sshguard/enemies
+
+ # IP addresses listed in the WHITELIST_FILE are considered to be
+ # friendlies and will never be blocked.
Index: patches/patch-src_fwalls_command_c
===================================================================
RCS file: patches/patch-src_fwalls_command_c
diff -N patches/patch-src_fwalls_command_c
--- patches/patch-src_fwalls_command_c 9 Sep 2011 20:13:28 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,15 +0,0 @@
-$OpenBSD: patch-src_fwalls_command_c,v 1.1 2011/09/09 20:13:28 naddy Exp $
-
-Allow building with gcc3.
-
---- src/fwalls/command.c.orig Fri Sep  9 22:07:56 2011
-+++ src/fwalls/command.c Fri Sep  9 22:08:12 2011
-@@ -59,7 +59,7 @@ int fw_block(const char *restrict addr, int addrkind,
-     return (run_command(COMMAND_BLOCK, addr, addrkind, service) == 0 ? FWALL_OK : FWALL_ERR);
- }
-
--int fw_block_list(const char *restrict addresses[], int addrkind, const int service_codes[]) {
-+int fw_block_list(const char *restrict *addresses, int addrkind, const int service_codes[]) {
-     /* block each address individually */
-     int i;
-
Index: patches/patch-src_sshguard_fw_h
===================================================================
RCS file: patches/patch-src_sshguard_fw_h
diff -N patches/patch-src_sshguard_fw_h
--- patches/patch-src_sshguard_fw_h 9 Sep 2011 20:13:28 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,15 +0,0 @@
-$OpenBSD: patch-src_sshguard_fw_h,v 1.1 2011/09/09 20:13:28 naddy Exp $
-
-Allow building with gcc3.
-
---- src/sshguard_fw.h.orig Fri Sep  9 22:07:03 2011
-+++ src/sshguard_fw.h Fri Sep  9 22:07:20 2011
-@@ -85,7 +85,7 @@ int fw_block(const char *restrict addr, int addrkind,
-  *
-  * @return FWALL_OK or FWALL_ERR
-  */
--int fw_block_list(const char *restrict addresses[], int addrkind, const int service_codes[]);
-+int fw_block_list(const char *restrict *addresses, int addrkind, const int service_codes[]);
-
-
- /**
Index: patches/patch-src_sshguard_in
===================================================================
RCS file: patches/patch-src_sshguard_in
diff -N patches/patch-src_sshguard_in
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_sshguard_in 24 Jun 2018 14:45:49 -0000
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: src/sshguard.in
+--- src/sshguard.in.orig
++++ src/sshguard.in
+@@ -3,7 +3,7 @@
+
+ # Unregister recursive SIGTERM, and make sure to kill
+ # entire process group (subshell) on exit/interrupts.
+-trap "trap - SIGTERM && kill 0" SIGINT SIGTERM EXIT
++trap "trap - TERM && kill 0" INT TERM EXIT
+
+ libexec="@libexecdir@"
+ version="@sshguardversion@"
Index: patches/patch-src_sshguard_logsuck_c
===================================================================
RCS file: patches/patch-src_sshguard_logsuck_c
diff -N patches/patch-src_sshguard_logsuck_c
--- patches/patch-src_sshguard_logsuck_c 7 Mar 2011 17:44:16 -0000 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src_sshguard_logsuck_c,v 1.2 2011/03/07 17:44:16 rpointel Exp $
---- src/sshguard_logsuck.c.orig Wed Feb  9 13:01:47 2011
-+++ src/sshguard_logsuck.c Sat Mar  5 19:27:53 2011
-@@ -242,7 +242,7 @@ int logsuck_getline(char *restrict buf, size_t buflen,
-         if (ret > 0) {
-             if (kevs[0].filter == EVFILT_READ) {
-                 /* got data on this one. Read from it */
--                sshguard_log(LOG_DEBUG, "Searching for fd %lu in list.", kevs[0].ident);
-+                sshguard_log(LOG_DEBUG, "Searching for fd %u in list.", kevs[0].ident);
-                 readentry = list_seek(& sources_list, & kevs[0].ident);
-                 assert(readentry != NULL);
-                 assert(readentry->active);
Index: patches/patch-src_sshguard_procauth_c
===================================================================
RCS file: patches/patch-src_sshguard_procauth_c
diff -N patches/patch-src_sshguard_procauth_c
--- patches/patch-src_sshguard_procauth_c 7 Sep 2010 12:23:43 -0000 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src_sshguard_procauth_c,v 1.1.1.1 2010/09/07 12:23:43 millert Exp $
---- src/sshguard_procauth.c.orig Mon Aug  9 02:44:15 2010
-+++ src/sshguard_procauth.c Mon Aug 30 13:05:40 2010
-@@ -192,7 +192,7 @@ static int procauth_ischildof(pid_t child, pid_t paren
-         dup2(ps2me[1], 1);
-
-         sshguard_log(LOG_DEBUG, "Running 'ps axo pid,ppid'.");
--        execlp("ps", "ps", "axo", "pid,ppid", NULL);
-+        execlp("ps", "ps", "axo", "pid,ppid", (char *)0);
-
-         sshguard_log(LOG_ERR, "Unable to run 'ps axo pid,ppid': %s.", strerror(errno));
-         exit(-1);
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/security/sshguard/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 25 Mar 2014 12:33:31 -0000 1.4
+++ pkg/PLIST 24 Jun 2018 14:45:49 -0000
@@ -1,6 +1,20 @@
-@comment $OpenBSD: PLIST,v 1.4 2014/03/25 12:33:31 ajacoutot Exp $
-@pkgpath security/sshguard,tcpd
-@man man/man8/sshguard.8
-@bin sbin/sshguard
-share/doc/pkg-readmes/${FULLPKGNAME}
+@comment $OpenBSD: PLIST,v$
 @rcscript ${RCDIR}/sshguard
+@bin libexec/sshg-blocker
+libexec/sshg-fw-firewalld
+@bin libexec/sshg-fw-hosts
+libexec/sshg-fw-ipfilter
+libexec/sshg-fw-ipfw
+libexec/sshg-fw-ipset
+libexec/sshg-fw-iptables
+libexec/sshg-fw-nft-sets
+libexec/sshg-fw-null
+libexec/sshg-fw-pf
+libexec/sshg-logtail
+@bin libexec/sshg-parser
+@man man/man7/sshguard-setup.7
+@man man/man8/sshguard.8
+sbin/sshguard
+share/examples/sshguard/
+share/examples/sshguard/sshguard.conf.sample
+share/examples/sshguard/whitelistfile.example
Index: pkg/README
===================================================================
RCS file: pkg/README
diff -N pkg/README
--- pkg/README 25 Mar 2014 12:31:50 -0000 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,12 +0,0 @@
-$OpenBSD: README,v 1.2 2014/03/25 12:31:50 ajacoutot Exp $
-
-+-----------------------------------------------------------------------
-| Running ${FULLPKGNAME} on OpenBSD
-+-----------------------------------------------------------------------
-
-To use sshguard with pf(4), add the following to /etc/pf.conf:
-
-table <sshguard> persist
-
-block in quick on egress proto tcp from <sshguard> \
- to any port ssh label "ssh bruteforce"
Index: pkg/sshguard.rc
===================================================================
RCS file: /cvs/ports/security/sshguard/pkg/sshguard.rc,v
retrieving revision 1.4
diff -u -p -r1.4 sshguard.rc
--- pkg/sshguard.rc 11 Jan 2018 19:27:09 -0000 1.4
+++ pkg/sshguard.rc 24 Jun 2018 14:45:49 -0000
@@ -3,11 +3,15 @@
 # $OpenBSD: sshguard.rc,v 1.4 2018/01/11 19:27:09 rpe Exp $
 
 daemon="${TRUEPREFIX}/sbin/sshguard"
-daemon_flags="-l /var/log/authlog"
 
 . /etc/rc.d/rc.subr
 
 rc_bg=YES
 rc_reload=NO
+pexp="/bin/sh ${pexp}"
+
+rc_stop() {
+ pkill -HUP -xf "${pexp}"
+}
 
 rc_cmd $1

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Andreas Kusalananda Kähäri
On Sun, Jun 24, 2018 at 04:49:27PM +0200, Klemens Nanni wrote:

> On Mon, Apr 23, 2018 at 11:12:55AM +0200, Andreas Kusalananda Kähäri wrote:
> > On Sun, Apr 22, 2018 at 04:04:02PM +0200, Andreas Kusalananda Kähäri wrote:
> > > On Sun, Apr 22, 2018 at 04:03:23PM +0200, Andreas Kusalananda Kähäri wrote:
> > > >
> > > > Please find the diffs for an updated port of sshguard attached.
> > >
> > > Now actually attached, duh.
> > >
> >
> > Updated patch attached with comments from kn@ taken into account, but
> > with CONFIGURE_STYLE=gnu left in place as suggested by Jeremie and
> > Stuart.
> I forgot about this diff when removing -O2 earlier (portroach also
> wouldn't detect an update due to EXTRACT_SUFX change), thanks Andreas
> for reminding me.
>
> The diff looks good, I made a few additional changes:
>
> - Drop README: sshguard-intro(7) contains all relevant information
> - sshguard.rc: $pexp -> ${pexp}, unfold rc_stop()
> - Makefile: Use SUBST_CMD and INSTALL_DATA just once
>
> On amd64 sshguard continues to work.
>
> 1.5.0 is broken on sparc64 due to an assertion failure when parsing log
> lines, 2.1.0 fixed this.
>
> OK?
>
[cut]

The issue with this is that it won't start properly at reboots.  One
may start it manually through "doas rcctl start sshguard" but if
it's started automatically through pkg_scripts, its sshg-blocker and
sshg-fw-pf (backend) process dies and leaves the tail and sshg-parser
processes, as well as the main sshguard script, hanging.

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.








När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/om-uu/dataskydd-personuppgifter/

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Gonzalo L. Rodriguez-2
In reply to this post by Andreas Kusalananda Kähäri
On Sun, 22 Apr 2018 at 16:03:23 +0200, Andreas Kusalananda Kähäri wrote:

>
> Please find the diffs for an updated port of sshguard attached.
>
> This updates sshguard from version 1.5 to 2.1.0.  One of the main
> reasons to update to this version is that sshguard now seems to
> correctly parse the OpenBSD sshd logs.  One can now also block an entire
> subnet rather than individual IP addresses, if one is so inclined.
>
> I have been running this port for a few weeks, and it seems to work as
> advertised.
>
> Note that the /etc/sshguard.conf file now is required (I modified the
> sample file so that it hopefully fits a vanilla OpenBSD system).
>
> I posted about this update in late March when I had issues getting the
> sshguard service to properly shut down, but that issue has since been
> resolved (rc_stop() needs to send it the HUP signal).
>
> Release announcements for sshguard are available at
> https://www.sshguard.net/litenewz/feeds/
>
> Regards,
>
> --
> Andreas Kusalananda Kähäri,
> National Bioinformatics Infrastructure Sweden (NBIS),
> Uppsala University, Sweden.
>
Update to 2.2.0.

OK? Comments?


--
Sending from my toaster.

sshguard-2.2.0.diff (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Stuart Henderson
> On Sun, 22 Apr 2018 at 16:03:23 +0200, Andreas Kusalananda Kähäri wrote:
> > I posted about this update in late March when I had issues getting the
> > sshguard service to properly shut down, but that issue has since been
> > resolved (rc_stop() needs to send it the HUP signal).

HUP to shutdown?! is there some analysis on this, that's really weird.

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Andreas Kusalananda Kähäri-4
On Thu, Nov 22, 2018 at 02:39:54PM +0000, Stuart Henderson wrote:
> > On Sun, 22 Apr 2018 at 16:03:23 +0200, Andreas Kusalananda Kähäri wrote:
> > > I posted about this update in late March when I had issues getting the
> > > sshguard service to properly shut down, but that issue has since been
> > > resolved (rc_stop() needs to send it the HUP signal).
>
> HUP to shutdown?! is there some analysis on this, that's really weird.

Looking at

https://bitbucket.org/sshguard/sshguard/src/ff8b525254a6c6e01e0f484cc3feba93e28a326e/src/sshguard.in?at=master&fileviewer=file-view-default


The main sshguard utility is a shell script that starts a log "tail"
reader, a log parser, a "blocker" (which I presume decides whether a
behaviour warrants blocking or not) and a firewall-specific backend that
actually does the blocking.  These are started in a shell pipeline:

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

(the unquoted variable expansions..., I won't comment more on them)

The bulk of the main shell script is just setting up the values of the
variables used in this pipeline.

At the start of the script, there's

trap "trap - TERM && kill 0" INT TERM EXIT

... which does my head in a bit.  It's *really* easy to start sshguard
and have one of the components of this pipeline not work correctly (it's
usually one and the same, but I forget which one now).  This usually
happens when it's started from pkg_scripts at boot (but not when started
manually later for some reason).  Sending the main script a HUP was
about the *only* way I could reliably get all components of the pipeline
to exit cleanly.

I'm assuming that it expects /bin/sh to be bash, and this could be one
of the reasons why it misbehaves under our /bin/sh (I haven't tested
with bash).

I have only ever looked at the shell script portion of sshguard 2.1.0
and the BitBucket Git thing I linked to and quoted above may well be
newer than that.  I gave up when I couldn't get it to start/shut down
reliably.

When it *ran*, it worked flawlessly.

I've been meaning to get back to this to sort it out for OpenBSD, but
have forgotten and have had other things getting in the way.

Andreas

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

Reply | Threaded
Open this post in threaded view
|

Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Stuart Henderson
On 2018/11/22 21:05, Andreas Kusalananda Kähäri wrote:

> On Thu, Nov 22, 2018 at 02:39:54PM +0000, Stuart Henderson wrote:
> > > On Sun, 22 Apr 2018 at 16:03:23 +0200, Andreas Kusalananda Kähäri wrote:
> > > > I posted about this update in late March when I had issues getting the
> > > > sshguard service to properly shut down, but that issue has since been
> > > > resolved (rc_stop() needs to send it the HUP signal).
> >
> > HUP to shutdown?! is there some analysis on this, that's really weird.
>
> Looking at
>
> https://bitbucket.org/sshguard/sshguard/src/ff8b525254a6c6e01e0f484cc3feba93e28a326e/src/sshguard.in?at=master&fileviewer=file-view-default
>
>
> The main sshguard utility is a shell script that starts a log "tail"
> reader, a log parser, a "blocker" (which I presume decides whether a
> behaviour warrants blocking or not) and a firewall-specific backend that
> actually does the blocking.  These are started in a shell pipeline:
>
> eval $tailcmd | $libexec/sshg-parser | \
>     $libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$)
>
> (the unquoted variable expansions..., I won't comment more on them)
>
> The bulk of the main shell script is just setting up the values of the
> variables used in this pipeline.
>
> At the start of the script, there's
>
> trap "trap - TERM && kill 0" INT TERM EXIT
>
> ... which does my head in a bit.  It's *really* easy to start sshguard
> and have one of the components of this pipeline not work correctly (it's
> usually one and the same, but I forget which one now).  This usually
> happens when it's started from pkg_scripts at boot (but not when started
> manually later for some reason).  Sending the main script a HUP was
> about the *only* way I could reliably get all components of the pipeline
> to exit cleanly.
>
> I'm assuming that it expects /bin/sh to be bash, and this could be one
> of the reasons why it misbehaves under our /bin/sh (I haven't tested
> with bash).
>
> I have only ever looked at the shell script portion of sshguard 2.1.0
> and the BitBucket Git thing I linked to and quoted above may well be
> newer than that.  I gave up when I couldn't get it to start/shut down
> reliably.
>
> When it *ran*, it worked flawlessly.
>
> I've been meaning to get back to this to sort it out for OpenBSD, but
> have forgotten and have had other things getting in the way.

Thanks - no objection to the update then, but would appreciate a link to
the list archive for this (https://marc.info/?l=openbsd-ports&m=154291717732337&w=2)
in commit log for the benefit of people looking later :)

Reply | Threaded
Open this post in threaded view
|

sshguard-2.2.0 (still problems with startup) Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Andreas Kusalananda Kähäri-4
On Fri, Nov 23, 2018 at 03:36:09PM +0000, Stuart Henderson wrote:
> On 2018/11/22 21:05, Andreas Kusalananda Kähäri wrote:
> > On Thu, Nov 22, 2018 at 02:39:54PM +0000, Stuart Henderson wrote:
> > > > On Sun, 22 Apr 2018 at 16:03:23 +0200, Andreas Kusalananda Kähäri wrote:
> > > > > I posted about this update in late March when I had issues getting the
> > > > > sshguard service to properly shut down, but that issue has since been
> > > > > resolved (rc_stop() needs to send it the HUP signal).
> > >
> > > HUP to shutdown?! is there some analysis on this, that's really weird.

This has now been resolved.
(but startup remains an issue, see end)

> >
> > Looking at
> >
> > https://bitbucket.org/sshguard/sshguard/src/ff8b525254a6c6e01e0f484cc3feba93e28a326e/src/sshguard.in?at=master&fileviewer=file-view-default
> >
> >
> > The main sshguard utility is a shell script that starts a log "tail"
> > reader, a log parser, a "blocker" (which I presume decides whether a
> > behaviour warrants blocking or not) and a firewall-specific backend that
> > actually does the blocking.  These are started in a shell pipeline:
> >
> > eval $tailcmd | $libexec/sshg-parser | \
> >     $libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$)
> >
> > (the unquoted variable expansions..., I won't comment more on them)
> >
> > The bulk of the main shell script is just setting up the values of the
> > variables used in this pipeline.
> >
> > At the start of the script, there's
> >
> > trap "trap - TERM && kill 0" INT TERM EXIT
> >
> > ... which does my head in a bit.  It's *really* easy to start sshguard
> > and have one of the components of this pipeline not work correctly (it's
> > usually one and the same, but I forget which one now).  This usually
> > happens when it's started from pkg_scripts at boot (but not when started
> > manually later for some reason).  Sending the main script a HUP was
> > about the *only* way I could reliably get all components of the pipeline
> > to exit cleanly.
> >
> > I'm assuming that it expects /bin/sh to be bash, and this could be one
> > of the reasons why it misbehaves under our /bin/sh (I haven't tested
> > with bash).
> >
> > I have only ever looked at the shell script portion of sshguard 2.1.0
> > and the BitBucket Git thing I linked to and quoted above may well be
> > newer than that.  I gave up when I couldn't get it to start/shut down
> > reliably.
> >
> > When it *ran*, it worked flawlessly.
> >
> > I've been meaning to get back to this to sort it out for OpenBSD, but
> > have forgotten and have had other things getting in the way.
>
> Thanks - no objection to the update then, but would appreciate a link to
> the list archive for this (https://marc.info/?l=openbsd-ports&m=154291717732337&w=2)
> in commit log for the benefit of people looking later :)
Attached is a port of sshguard-2.2.0 which appears to work, sort of.  It
does not start at boot when started from pkg_scripts.  It *does* start
reliably when started manually with "rcctl start sshguard" and it shuts
down reliably both at system shutdown and manually (and in-between, it
runs well).

Any help with possible diagnoses of the startup problem would be
helpful.  I haven't found any other port that starts a shell script as a
daemon, but I have only looked for "/bin/sh" in the rc scripts for that.

The "stop" action in the rc script is a bit unorthodox:

kill -- "-$( ps -o pgid= -p "$( pgrep -o -T "${daemon_rtable}" -fx "${pexp}" )" )"

... and that's to send a TERM signal to all the processes in the
relevant process group (sshguard consists of a total of seven separate
processes).  The main script does do something similar to this ("kill 0"
in a trap), but this may require bash to work (and even then it doesn't
seem to work reliably).

I have attached a diff for the port as well as a tar archive of it.


Regards,

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

sshguard.diff (8K) Download Attachment
sshguard.tar.gz (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: sshguard-2.2.0 (still problems with startup) Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Stuart Henderson
On 2018/12/05 00:21, Andreas Kusalananda Kähäri wrote:

> Attached is a port of sshguard-2.2.0 which appears to work, sort of.  It
> does not start at boot when started from pkg_scripts.  It *does* start
> reliably when started manually with "rcctl start sshguard" and it shuts
> down reliably both at system shutdown and manually (and in-between, it
> runs well).
>
> Any help with possible diagnoses of the startup problem would be
> helpful.  I haven't found any other port that starts a shell script as a
> daemon, but I have only looked for "/bin/sh" in the rc scripts for that.
>
> The "stop" action in the rc script is a bit unorthodox:
>
> kill -- "-$( ps -o pgid= -p "$( pgrep -o -T "${daemon_rtable}" -fx "${pexp}" )" )"
>
> ... and that's to send a TERM signal to all the processes in the
> relevant process group (sshguard consists of a total of seven separate
> processes).  The main script does do something similar to this ("kill 0"
> in a trap), but this may require bash to work (and even then it doesn't
> seem to work reliably).
>
> I have attached a diff for the port as well as a tar archive of it.

It may be worth removing from pkg_scripts and running from rc.local
to see if it fails there. If so then run from there under ktrace e.g.
"ktrace -f /tmp/ktrace.out -i /usr/sbin/rcctl start sshguard" and
see if anything can be gleaned from running kdump on that file.

A couple of porting notes,

> +CONFIGURE_STYLE=simple
> +CONFIGURE_ARGS= --sysconfdir="${SYSCONFDIR}" \
> + --mandir="${TRUEPREFIX}/man"

This has crept back in, it should stay at CONFIGURE_STYLE=gnu and
remove the manual setting of --sysconfdir= and --mandir.

> +share/examples/sshguard/
> +share/examples/sshguard/sshguard.conf.sample
> +share/examples/sshguard/whitelistfile.example
> Index: pkg/README
> ===================================================================
> RCS file: /extra/cvs/ports/security/sshguard/pkg/README,v
> retrieving revision 1.3
> diff -u -p -r1.3 README
> --- pkg/README 4 Sep 2018 12:46:21 -0000 1.3
> +++ pkg/README 4 Dec 2018 21:10:55 -0000
> @@ -4,7 +4,13 @@ $OpenBSD: README,v 1.3 2018/09/04 12:46:
>  | Running ${PKGSTEM} on OpenBSD
>  +-----------------------------------------------------------------------
>  
> -To use sshguard with pf(4), add the following to /etc/pf.conf:
> +Copy the example configuration file:
> +
> +    cp ${PREFIX}/share/examples/sshguard/sshguard.conf.sample \
> +       ${SYSCONFDIR}/sshguard.conf

Should use @sample in PLIST instead of telling people to do that by
hand, e.g.

share/examples/sshguard/
share/examples/sshguard/sshguard.conf.sample
@sample ${SYSCONFDIR}/sshguard.conf

Simpler, and helps pkg_delete -c.

> +
> +pexp="/bin/sh $pexp"
> +
> +rc_stop () {
> +    # Need to send TERM to all processes in the process group not just
> +    # to the ones matching "$pexp".  The main sshguard shell script does
> +    # set up a trap for doing this, but it relies on running under bash.
> +    kill -- "-$( ps -o pgid= -p "$( pgrep -o -T "${daemon_rtable}" -fx "${pexp}" )" )"
> +}
>  
>  rc_bg=YES
>  rc_reload=NO

<insert see-no-evil-monkey emoji here> ;)

Reply | Threaded
Open this post in threaded view
|

Re: sshguard-2.2.0 (still problems with startup) Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Markus Lude-3
In reply to this post by Andreas Kusalananda Kähäri-4
On Wed, Dec 05, 2018 at 12:21:33AM +0100, Andreas Kusalananda Khri wrote:

> On Fri, Nov 23, 2018 at 03:36:09PM +0000, Stuart Henderson wrote:
> > On 2018/11/22 21:05, Andreas Kusalananda Kähäri wrote:
> > > On Thu, Nov 22, 2018 at 02:39:54PM +0000, Stuart Henderson wrote:
> > > > > On Sun, 22 Apr 2018 at 16:03:23 +0200, Andreas Kusalananda Kähäri wrote:
> > > > > > I posted about this update in late March when I had issues getting the
> > > > > > sshguard service to properly shut down, but that issue has since been
> > > > > > resolved (rc_stop() needs to send it the HUP signal).
> > > >
> > > > HUP to shutdown?! is there some analysis on this, that's really weird.
>
> This has now been resolved.
> (but startup remains an issue, see end)
>
> > >
> > > Looking at
> > >
> > > https://bitbucket.org/sshguard/sshguard/src/ff8b525254a6c6e01e0f484cc3feba93e28a326e/src/sshguard.in?at=master&fileviewer=file-view-default
> > >
> > >
> > > The main sshguard utility is a shell script that starts a log "tail"
> > > reader, a log parser, a "blocker" (which I presume decides whether a
> > > behaviour warrants blocking or not) and a firewall-specific backend that
> > > actually does the blocking.  These are started in a shell pipeline:
> > >
> > > eval $tailcmd | $libexec/sshg-parser | \
> > >     $libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$)
> > >
> > > (the unquoted variable expansions..., I won't comment more on them)
> > >
> > > The bulk of the main shell script is just setting up the values of the
> > > variables used in this pipeline.
> > >
> > > At the start of the script, there's
> > >
> > > trap "trap - TERM && kill 0" INT TERM EXIT
> > >
> > > ... which does my head in a bit.  It's *really* easy to start sshguard
> > > and have one of the components of this pipeline not work correctly (it's
> > > usually one and the same, but I forget which one now).  This usually
> > > happens when it's started from pkg_scripts at boot (but not when started
> > > manually later for some reason).  Sending the main script a HUP was
> > > about the *only* way I could reliably get all components of the pipeline
> > > to exit cleanly.
> > >
> > > I'm assuming that it expects /bin/sh to be bash, and this could be one
> > > of the reasons why it misbehaves under our /bin/sh (I haven't tested
> > > with bash).
> > >
> > > I have only ever looked at the shell script portion of sshguard 2.1.0
> > > and the BitBucket Git thing I linked to and quoted above may well be
> > > newer than that.  I gave up when I couldn't get it to start/shut down
> > > reliably.
> > >
> > > When it *ran*, it worked flawlessly.
> > >
> > > I've been meaning to get back to this to sort it out for OpenBSD, but
> > > have forgotten and have had other things getting in the way.
> >
> > Thanks - no objection to the update then, but would appreciate a link to
> > the list archive for this (https://marc.info/?l=openbsd-ports&m=154291717732337&w=2)
> > in commit log for the benefit of people looking later :)
>
> Attached is a port of sshguard-2.2.0 which appears to work, sort of.  It
> does not start at boot when started from pkg_scripts.  It *does* start
> reliably when started manually with "rcctl start sshguard" and it shuts
> down reliably both at system shutdown and manually (and in-between, it
> runs well).

Similar happens with the in-tree version sshguard-1.5p6 on 6.4-stable.
sshguard _does_ start (as noticed in the log file), but terminates shortly after:

shortly after reboot:
Dec  5 22:30:14 myhost sshd[33894]: Server listening on 0.0.0.0 port 22.
Dec  5 22:30:14 myhost sshd[33894]: Server listening on :: port 22.
Dec  5 22:30:15 myhost sshguard[5454]: Started successfully [(a,p,s)=(40, 420, 1200)], now ready to scan.
Dec  5 22:30:15 myhost sshd[25608]: Received disconnect from 222.87.49.93 port 27657:11: Bye Bye [preauth]
Dec  5 22:30:15 myhost sshd[25608]: Disconnected from 222.87.49.93 port 27657 [preauth]
Dec  5 22:30:16 myhost sshguard[5454]: Got exit signal, flushing blocked addresses and exiting...

If started manually, it keeps running.

> Any help with possible diagnoses of the startup problem would be
> helpful.  I haven't found any other port that starts a shell script as a
> daemon, but I have only looked for "/bin/sh" in the rc scripts for that.

Regards
Markus

Reply | Threaded
Open this post in threaded view
|

Re: sshguard-2.2.0 (still problems with startup) Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

trondd-2
On Wed, December 5, 2018 4:37 pm, Markus Lude wrote:

> On Wed, Dec 05, 2018 at 12:21:33AM +0100, Andreas Kusalananda Khri wrote:
>> On Fri, Nov 23, 2018 at 03:36:09PM +0000, Stuart Henderson wrote:
>> > On 2018/11/22 21:05, Andreas Kusalananda Kähäri wrote:
>> > > On Thu, Nov 22, 2018 at 02:39:54PM +0000, Stuart Henderson wrote:
>> > > > > On Sun, 22 Apr 2018 at 16:03:23 +0200, Andreas Kusalananda
>> Kähäri wrote:
>> > > > > > I posted about this update in late March when I had issues
>> getting the
>> > > > > > sshguard service to properly shut down, but that issue has
>> since been
>> > > > > > resolved (rc_stop() needs to send it the HUP signal).
>> > > >
>> > > > HUP to shutdown?! is there some analysis on this, that's really
>> weird.
>>
>> This has now been resolved.
>> (but startup remains an issue, see end)
>>
>> > >
>> > > Looking at
>> > >
>> > > https://bitbucket.org/sshguard/sshguard/src/ff8b525254a6c6e01e0f484cc3feba93e28a326e/src/sshguard.in?at=master&fileviewer=file-view-default
>> > >
>> > >
>> > > The main sshguard utility is a shell script that starts a log "tail"
>> > > reader, a log parser, a "blocker" (which I presume decides whether a
>> > > behaviour warrants blocking or not) and a firewall-specific backend
>> that
>> > > actually does the blocking.  These are started in a shell pipeline:
>> > >
>> > > eval $tailcmd | $libexec/sshg-parser | \
>> > >     $libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$)
>> > >
>> > > (the unquoted variable expansions..., I won't comment more on them)
>> > >
>> > > The bulk of the main shell script is just setting up the values of
>> the
>> > > variables used in this pipeline.
>> > >
>> > > At the start of the script, there's
>> > >
>> > > trap "trap - TERM && kill 0" INT TERM EXIT
>> > >
>> > > ... which does my head in a bit.  It's *really* easy to start
>> sshguard
>> > > and have one of the components of this pipeline not work correctly
>> (it's
>> > > usually one and the same, but I forget which one now).  This usually
>> > > happens when it's started from pkg_scripts at boot (but not when
>> started
>> > > manually later for some reason).  Sending the main script a HUP was
>> > > about the *only* way I could reliably get all components of the
>> pipeline
>> > > to exit cleanly.
>> > >
>> > > I'm assuming that it expects /bin/sh to be bash, and this could be
>> one
>> > > of the reasons why it misbehaves under our /bin/sh (I haven't tested
>> > > with bash).
>> > >
>> > > I have only ever looked at the shell script portion of sshguard
>> 2.1.0
>> > > and the BitBucket Git thing I linked to and quoted above may well be
>> > > newer than that.  I gave up when I couldn't get it to start/shut
>> down
>> > > reliably.
>> > >
>> > > When it *ran*, it worked flawlessly.
>> > >
>> > > I've been meaning to get back to this to sort it out for OpenBSD,
>> but
>> > > have forgotten and have had other things getting in the way.
>> >
>> > Thanks - no objection to the update then, but would appreciate a link
>> to
>> > the list archive for this
>> (https://marc.info/?l=openbsd-ports&m=154291717732337&w=2)
>> > in commit log for the benefit of people looking later :)
>>
>> Attached is a port of sshguard-2.2.0 which appears to work, sort of.  It
>> does not start at boot when started from pkg_scripts.  It *does* start
>> reliably when started manually with "rcctl start sshguard" and it shuts
>> down reliably both at system shutdown and manually (and in-between, it
>> runs well).
>
> Similar happens with the in-tree version sshguard-1.5p6 on 6.4-stable.
> sshguard _does_ start (as noticed in the log file), but terminates shortly
> after:
>
> shortly after reboot:
> Dec  5 22:30:14 myhost sshd[33894]: Server listening on 0.0.0.0 port 22.
> Dec  5 22:30:14 myhost sshd[33894]: Server listening on :: port 22.
> Dec  5 22:30:15 myhost sshguard[5454]: Started successfully [(a,p,s)=(40,
> 420, 1200)], now ready to scan.
> Dec  5 22:30:15 myhost sshd[25608]: Received disconnect from 222.87.49.93
> port 27657:11: Bye Bye [preauth]
> Dec  5 22:30:15 myhost sshd[25608]: Disconnected from 222.87.49.93 port
> 27657 [preauth]
> Dec  5 22:30:16 myhost sshguard[5454]: Got exit signal, flushing blocked
> addresses and exiting...
>
> If started manually, it keeps running.
>
>> Any help with possible diagnoses of the startup problem would be
>> helpful.  I haven't found any other port that starts a shell script as a
>> daemon, but I have only looked for "/bin/sh" in the rc scripts for that.
>
> Regards
> Markus
>

The init process send HUP.  If HUP means to shutdown, it's not going to
work.  Spampd had a similar problem and had to do the right thing on
SIGHUP.

On Wed, December 5, 2018 4:37 pm, Markus Lude wrote:

> On Wed, Dec 05, 2018 at 12:21:33AM +0100, Andreas Kusalananda Khri wrote:
>> On Fri, Nov 23, 2018 at 03:36:09PM +0000, Stuart Henderson wrote:
>> > On 2018/11/22 21:05, Andreas Kusalananda Kähäri wrote:
>> > > On Thu, Nov 22, 2018 at 02:39:54PM +0000, Stuart Henderson wrote:
>> > > > > On Sun, 22 Apr 2018 at 16:03:23 +0200, Andreas Kusalananda
>> Kähäri wrote:
>> > > > > > I posted about this update in late March when I had issues
>> getting the
>> > > > > > sshguard service to properly shut down, but that issue has
>> since been
>> > > > > > resolved (rc_stop() needs to send it the HUP signal).
>> > > >
>> > > > HUP to shutdown?! is there some analysis on this, that's really
>> weird.
>>
>> This has now been resolved.
>> (but startup remains an issue, see end)
>>
>> > >
>> > > Looking at
>> > >
>> > > https://bitbucket.org/sshguard/sshguard/src/ff8b525254a6c6e01e0f484cc3feba93e28a326e/src/sshguard.in?at=master&fileviewer=file-view-default
>> > >
>> > >
>> > > The main sshguard utility is a shell script that starts a log "tail"
>> > > reader, a log parser, a "blocker" (which I presume decides whether a
>> > > behaviour warrants blocking or not) and a firewall-specific backend
>> that
>> > > actually does the blocking.  These are started in a shell pipeline:
>> > >
>> > > eval $tailcmd | $libexec/sshg-parser | \
>> > >     $libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$)
>> > >
>> > > (the unquoted variable expansions..., I won't comment more on them)
>> > >
>> > > The bulk of the main shell script is just setting up the values of
>> the
>> > > variables used in this pipeline.
>> > >
>> > > At the start of the script, there's
>> > >
>> > > trap "trap - TERM && kill 0" INT TERM EXIT
>> > >
>> > > ... which does my head in a bit.  It's *really* easy to start
>> sshguard
>> > > and have one of the components of this pipeline not work correctly
>> (it's
>> > > usually one and the same, but I forget which one now).  This usually
>> > > happens when it's started from pkg_scripts at boot (but not when
>> started
>> > > manually later for some reason).  Sending the main script a HUP was
>> > > about the *only* way I could reliably get all components of the
>> pipeline
>> > > to exit cleanly.
>> > >
>> > > I'm assuming that it expects /bin/sh to be bash, and this could be
>> one
>> > > of the reasons why it misbehaves under our /bin/sh (I haven't tested
>> > > with bash).
>> > >
>> > > I have only ever looked at the shell script portion of sshguard
>> 2.1.0
>> > > and the BitBucket Git thing I linked to and quoted above may well be
>> > > newer than that.  I gave up when I couldn't get it to start/shut
>> down
>> > > reliably.
>> > >
>> > > When it *ran*, it worked flawlessly.
>> > >
>> > > I've been meaning to get back to this to sort it out for OpenBSD,
>> but
>> > > have forgotten and have had other things getting in the way.
>> >
>> > Thanks - no objection to the update then, but would appreciate a link
>> to
>> > the list archive for this
>> (https://marc.info/?l=openbsd-ports&m=154291717732337&w=2)
>> > in commit log for the benefit of people looking later :)
>>
>> Attached is a port of sshguard-2.2.0 which appears to work, sort of.  It
>> does not start at boot when started from pkg_scripts.  It *does* start
>> reliably when started manually with "rcctl start sshguard" and it shuts
>> down reliably both at system shutdown and manually (and in-between, it
>> runs well).
>
> Similar happens with the in-tree version sshguard-1.5p6 on 6.4-stable.
> sshguard _does_ start (as noticed in the log file), but terminates shortly
> after:
>
> shortly after reboot:
> Dec  5 22:30:14 myhost sshd[33894]: Server listening on 0.0.0.0 port 22.
> Dec  5 22:30:14 myhost sshd[33894]: Server listening on :: port 22.
> Dec  5 22:30:15 myhost sshguard[5454]: Started successfully [(a,p,s)=(40,
> 420, 1200)], now ready to scan.
> Dec  5 22:30:15 myhost sshd[25608]: Received disconnect from 222.87.49.93
> port 27657:11: Bye Bye [preauth]
> Dec  5 22:30:15 myhost sshd[25608]: Disconnected from 222.87.49.93 port
> 27657 [preauth]
> Dec  5 22:30:16 myhost sshguard[5454]: Got exit signal, flushing blocked
> addresses and exiting...
>
> If started manually, it keeps running.
>
>> Any help with possible diagnoses of the startup problem would be
>> helpful.  I haven't found any other port that starts a shell script as a
>> daemon, but I have only looked for "/bin/sh" in the rc scripts for that.
>
> Regards
> Markus
>

The init process send HUP.  If HUP means to shutdown, it's not going to
work.  Spampd had a similar problem and had to do the right thing on
SIGHUP.

On Wed, December 5, 2018 4:37 pm, Markus Lude wrote:

> On Wed, Dec 05, 2018 at 12:21:33AM +0100, Andreas Kusalananda Khri wrote:
>> On Fri, Nov 23, 2018 at 03:36:09PM +0000, Stuart Henderson wrote:
>> > On 2018/11/22 21:05, Andreas Kusalananda Kähäri wrote:
>> > > On Thu, Nov 22, 2018 at 02:39:54PM +0000, Stuart Henderson wrote:
>> > > > > On Sun, 22 Apr 2018 at 16:03:23 +0200, Andreas Kusalananda
>> Kähäri wrote:
>> > > > > > I posted about this update in late March when I had issues
>> getting the
>> > > > > > sshguard service to properly shut down, but that issue has
>> since been
>> > > > > > resolved (rc_stop() needs to send it the HUP signal).
>> > > >
>> > > > HUP to shutdown?! is there some analysis on this, that's really
>> weird.
>>
>> This has now been resolved.
>> (but startup remains an issue, see end)
>>
>> > >
>> > > Looking at
>> > >
>> > > https://bitbucket.org/sshguard/sshguard/src/ff8b525254a6c6e01e0f484cc3feba93e28a326e/src/sshguard.in?at=master&fileviewer=file-view-default
>> > >
>> > >
>> > > The main sshguard utility is a shell script that starts a log "tail"
>> > > reader, a log parser, a "blocker" (which I presume decides whether a
>> > > behaviour warrants blocking or not) and a firewall-specific backend
>> that
>> > > actually does the blocking.  These are started in a shell pipeline:
>> > >
>> > > eval $tailcmd | $libexec/sshg-parser | \
>> > >     $libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$)
>> > >
>> > > (the unquoted variable expansions..., I won't comment more on them)
>> > >
>> > > The bulk of the main shell script is just setting up the values of
>> the
>> > > variables used in this pipeline.
>> > >
>> > > At the start of the script, there's
>> > >
>> > > trap "trap - TERM && kill 0" INT TERM EXIT
>> > >
>> > > ... which does my head in a bit.  It's *really* easy to start
>> sshguard
>> > > and have one of the components of this pipeline not work correctly
>> (it's
>> > > usually one and the same, but I forget which one now).  This usually
>> > > happens when it's started from pkg_scripts at boot (but not when
>> started
>> > > manually later for some reason).  Sending the main script a HUP was
>> > > about the *only* way I could reliably get all components of the
>> pipeline
>> > > to exit cleanly.
>> > >
>> > > I'm assuming that it expects /bin/sh to be bash, and this could be
>> one
>> > > of the reasons why it misbehaves under our /bin/sh (I haven't tested
>> > > with bash).
>> > >
>> > > I have only ever looked at the shell script portion of sshguard
>> 2.1.0
>> > > and the BitBucket Git thing I linked to and quoted above may well be
>> > > newer than that.  I gave up when I couldn't get it to start/shut
>> down
>> > > reliably.
>> > >
>> > > When it *ran*, it worked flawlessly.
>> > >
>> > > I've been meaning to get back to this to sort it out for OpenBSD,
>> but
>> > > have forgotten and have had other things getting in the way.
>> >
>> > Thanks - no objection to the update then, but would appreciate a link
>> to
>> > the list archive for this
>> (https://marc.info/?l=openbsd-ports&m=154291717732337&w=2)
>> > in commit log for the benefit of people looking later :)
>>
>> Attached is a port of sshguard-2.2.0 which appears to work, sort of.  It
>> does not start at boot when started from pkg_scripts.  It *does* start
>> reliably when started manually with "rcctl start sshguard" and it shuts
>> down reliably both at system shutdown and manually (and in-between, it
>> runs well).
>
> Similar happens with the in-tree version sshguard-1.5p6 on 6.4-stable.
> sshguard _does_ start (as noticed in the log file), but terminates shortly
> after:
>
> shortly after reboot:
> Dec  5 22:30:14 myhost sshd[33894]: Server listening on 0.0.0.0 port 22.
> Dec  5 22:30:14 myhost sshd[33894]: Server listening on :: port 22.
> Dec  5 22:30:15 myhost sshguard[5454]: Started successfully [(a,p,s)=(40,
> 420, 1200)], now ready to scan.
> Dec  5 22:30:15 myhost sshd[25608]: Received disconnect from 222.87.49.93
> port 27657:11: Bye Bye [preauth]
> Dec  5 22:30:15 myhost sshd[25608]: Disconnected from 222.87.49.93 port
> 27657 [preauth]
> Dec  5 22:30:16 myhost sshguard[5454]: Got exit signal, flushing blocked
> addresses and exiting...
>
> If started manually, it keeps running.
>
>> Any help with possible diagnoses of the startup problem would be
>> helpful.  I haven't found any other port that starts a shell script as a
>> daemon, but I have only looked for "/bin/sh" in the rc scripts for that.
>
> Regards
> Markus
>

The init process sends a HUP.  If HUP means to shutdown, it's not going to
work.  Spampd had a similar problem and had to do the right thing on
SIGHUP.

https://marc.info/?l=openbsd-ports&m=153513465119913&w=2

Reply | Threaded
Open this post in threaded view
|

Re: sshguard-2.2.0 (still problems with startup) Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Craig Skinner-3
On Wed, 5 Dec 2018 17:11:46 -0500 trondd wrote:
> The init process send HUP. If HUP means to shutdown, it's not going
> to work.

Ohhhhh.... That could explain these 2014/15 hack "solutions":

http://marc.info/?l=openbsd-ports&m=142109480706198

http://marc.info/?l=openbsd-ports&m=141951815113690


Cheers,
--
Craig Skinner | http://linkd.in/yGqkv7

Reply | Threaded
Open this post in threaded view
|

Re: sshguard-2.2.0 (still problems with startup) Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Stuart Henderson
How about just removing the rc script?

Reply | Threaded
Open this post in threaded view
|

Re: sshguard-2.2.0 (start/stop issues resolved)

Andreas Kusalananda Kähäri-4
In reply to this post by Stuart Henderson
On Wed, Dec 05, 2018 at 12:05:07AM +0000, Stuart Henderson wrote:

> On 2018/12/05 00:21, Andreas Kusalananda Kähäri wrote:
> > Attached is a port of sshguard-2.2.0 which appears to work, sort of.  It
> > does not start at boot when started from pkg_scripts.  It *does* start
> > reliably when started manually with "rcctl start sshguard" and it shuts
> > down reliably both at system shutdown and manually (and in-between, it
> > runs well).
> >
> > Any help with possible diagnoses of the startup problem would be
> > helpful.  I haven't found any other port that starts a shell script as a
> > daemon, but I have only looked for "/bin/sh" in the rc scripts for that.
> >
> > The "stop" action in the rc script is a bit unorthodox:
> >
> > kill -- "-$( ps -o pgid= -p "$( pgrep -o -T "${daemon_rtable}" -fx "${pexp}" )" )"
> >
> > ... and that's to send a TERM signal to all the processes in the
> > relevant process group (sshguard consists of a total of seven separate
> > processes).  The main script does do something similar to this ("kill 0"
> > in a trap), but this may require bash to work (and even then it doesn't
> > seem to work reliably).
> >
> > I have attached a diff for the port as well as a tar archive of it.
>
> It may be worth removing from pkg_scripts and running from rc.local
> to see if it fails there. If so then run from there under ktrace e.g.
> "ktrace -f /tmp/ktrace.out -i /usr/sbin/rcctl start sshguard" and
> see if anything can be gleaned from running kdump on that file.
Yes, it's getting hupped.  I have now patched out the installing of the
signal handler for HUP in one of the helper programs, and I'm ignoring
the same signal in the main script.  The daemon now survives the boot.
Termination has also been improved (see end).

>
> A couple of porting notes,

I appreciate these.  Thanks!  They are all incorporated.

>
> > +CONFIGURE_STYLE=simple
> > +CONFIGURE_ARGS= --sysconfdir="${SYSCONFDIR}" \
> > + --mandir="${TRUEPREFIX}/man"
>
> This has crept back in, it should stay at CONFIGURE_STYLE=gnu and
> remove the manual setting of --sysconfdir= and --mandir.
>
> > +share/examples/sshguard/
> > +share/examples/sshguard/sshguard.conf.sample
> > +share/examples/sshguard/whitelistfile.example
> > Index: pkg/README
> > ===================================================================
> > RCS file: /extra/cvs/ports/security/sshguard/pkg/README,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 README
> > --- pkg/README 4 Sep 2018 12:46:21 -0000 1.3
> > +++ pkg/README 4 Dec 2018 21:10:55 -0000
> > @@ -4,7 +4,13 @@ $OpenBSD: README,v 1.3 2018/09/04 12:46:
> >  | Running ${PKGSTEM} on OpenBSD
> >  +-----------------------------------------------------------------------
> >  
> > -To use sshguard with pf(4), add the following to /etc/pf.conf:
> > +Copy the example configuration file:
> > +
> > +    cp ${PREFIX}/share/examples/sshguard/sshguard.conf.sample \
> > +       ${SYSCONFDIR}/sshguard.conf
>
> Should use @sample in PLIST instead of telling people to do that by
> hand, e.g.
>
> share/examples/sshguard/
> share/examples/sshguard/sshguard.conf.sample
> @sample ${SYSCONFDIR}/sshguard.conf
>
> Simpler, and helps pkg_delete -c.
>
> > +
> > +pexp="/bin/sh $pexp"
> > +
> > +rc_stop () {
> > +    # Need to send TERM to all processes in the process group not just
> > +    # to the ones matching "$pexp".  The main sshguard shell script does
> > +    # set up a trap for doing this, but it relies on running under bash.
> > +    kill -- "-$( ps -o pgid= -p "$( pgrep -o -T "${daemon_rtable}" -fx "${pexp}" )" )"
> > +}
> >  
> >  rc_bg=YES
> >  rc_reload=NO
>
> <insert see-no-evil-monkey emoji here> ;)
It was evil and have now been removed.  I noticed that this way of doing
it would probably have killed the kernel relinking that happens after
boot, had anyone manually stopped the sshguard daemon with "rcctl stop
sshguard" early enough.  This is not the way to do it.

Instead, I do what I believe the sshguard-devs intended people to do,
which is to kill the "sshg-blocker" process instead.  This leads to the
rest of the group of processes terminating, except for a "tail" process
(but this will exit as soon as it discovers that there is nobody
reading from the pipe it's writing to).

This leads me to believe that the diff attached is an actual working
port of sshguard-2.2.0.  A tar archive of the port is also attached, as
before.

I'm happy to be maintainer of this port if nobody else feels that they
should be.

Regards,
Andreas

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

sshguard.diff (8K) Download Attachment
sshguard.tar.gz (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: sshguard-2.2.0 (still problems with startup) Re: UPDATE: security/sshguard, 1.5-->2.1.0 (2nd try)

Andreas Kusalananda Kähäri-4
In reply to this post by Stuart Henderson
On Thu, Dec 06, 2018 at 01:12:52PM +0000, Stuart Henderson wrote:
> How about just removing the rc script?

No. I resolved it by making sure that every relevant part of sshguard is
ignoring HUP.  See just submitted updated port.


Anderas

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

12