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

Re: [Sshguard-users] Patch to fix blacklist loading with ipfw

[Greg P. <gr...@n0...>]

Hi Kevin,

I gave it a shot, but it failed to build. Did make a minor mod 
to the diff. The file paths had a/ & b/, so removed those. 


The output from the make: 

===>  License BSD2CLAUSE accepted by the user
===>   sshguard-ipfw-1.6.0_1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by sshguard-ipfw-1.6.0_1 for building
===>  Extracting for sshguard-ipfw-1.6.0_1
=> SHA256 Checksum OK for sshguard-1.6.0.tar.xz.
===>  Patching for sshguard-ipfw-1.6.0_1
===>  Applying FreeBSD patches for sshguard-ipfw-1.6.0_1
===>   sshguard-ipfw-1.6.0_1 depends on executable: autoconf-2.69 - found
===>   sshguard-ipfw-1.6.0_1 depends on executable: autoheader-2.69 - found
===>   sshguard-ipfw-1.6.0_1 depends on executable: autoreconf-2.69 - found
===>   sshguard-ipfw-1.6.0_1 depends on executable: aclocal-1.15 - found
===>   sshguard-ipfw-1.6.0_1 depends on executable: automake-1.15 - found
===>  Configuring for sshguard-ipfw-1.6.0_1
configure: loading site script /usr/ports/Templates/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p
checking for gawk... (cached) /usr/bin/awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for ipfw... /sbin
checking for ip6fw... no
configure: ip6fw program not found. Assuming ipfw supports IPv6 rules on its own.
## -------------- ##
## Program Checks ##
## -------------- ##
checking for gawk... (cached) /usr/bin/awk
checking for gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking whether cc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of cc... gcc3
checking for cc option to accept ISO C99... none needed
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for egrep... (cached) /usr/bin/egrep
checking for ranlib... ranlib
checking for bison... bison -y
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
## -------------- ##
## Library Checks ##
## -------------- ##
checking for pthread_create in -lpthread... yes
checking how to run the C preprocessor... cpp
checking for ANSI C header files... (cached) yes
checking for sys/wait.h that is POSIX.1 compatible... (cached) yes
checking for sys/types.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for memory.h... (cached) yes
checking for strings.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for stdint.h... (cached) yes
checking for unistd.h... (cached) yes
checking for arpa/inet.h... (cached) yes
checking for malloc.h... (cached) no
checking for netdb.h... (cached) yes
checking for netinet/in.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for sys/socket.h... (cached) yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for unistd.h... (cached) yes
checking for getopt.h... (cached) yes
checking for off_t... (cached) yes
checking for pid_t... (cached) yes
checking for size_t... (cached) yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for C/C++ restrict keyword... __restrict
checking build system type... amd64-portbld-freebsd10.1
checking whether __SUNPRO_C is declared... no
## ----------------- ##
## Library Functions ##
## ----------------- ##
checking for vfork.h... (cached) no
checking for fork... (cached) yes
checking for vfork... (cached) yes
checking for working fork... yes
checking for working vfork... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... (cached) yes
checking for gethostbyname... (cached) yes
checking for inet_ntoa... (cached) yes
checking for strerror... (cached) yes
checking for strstr... yes
checking for strtol... (cached) yes
checking for library containing socket... none required
checking for library containing gethostbyname... none required
configure: Using /sbin as location for ipfw
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating man/Makefile
config.status: creating src/Makefile
config.status: creating src/parser/Makefile
config.status: creating src/fwalls/Makefile
config.status: creating src/config.h
config.status: executing depfiles commands
===>  Building for sshguard-ipfw-1.6.0_1
Making all in src
/usr/bin/make  all-recursive
Making all in parser
/usr/bin/make  all-am
  LEX      attack_scanner.c
  CC       attack_parser.o
  CC       attack_scanner.o
attack_scanner.c:27857:16: warning: function 'input' is not needed and will not be emitted [-Wunneeded-internal-declaration]
    static int input  (void)
               ^
1 warning generated.
  AR       libparser.a
Making all in fwalls
  CC       ipfw.o
ipfw.c:51:15: error: use of undeclared identifier 'ADDRLEN'
    char addr[ADDRLEN];
              ^
ipfw.c:109:5: warning: implicitly declaring library function 'strlcpy' with type 'unsigned long (char *, const char *, unsigned long)'
    strlcpy(addendum.addr, addr, sizeof(addendum.addr));
    ^
ipfw.c:109:5: note: please include the header <string.h> or explicitly provide a declaration for 'strlcpy'
ipfw.c:171:14: error: use of undeclared identifier 'ADDRKIND_IPv4'
        case ADDRKIND_IPv4:
             ^
ipfw.c:175:14: error: use of undeclared identifier 'ADDRKIND_IPv6'
        case ADDRKIND_IPv6:
             ^
ipfw.c:216:18: error: use of undeclared identifier 'ADDRKIND_IPv4'
            case ADDRKIND_IPv4:
                 ^
ipfw.c:219:18: error: use of undeclared identifier 'ADDRKIND_IPv6'
            case ADDRKIND_IPv6:
                 ^
ipfw.c:307:14: error: use of undeclared identifier 'ADDRKIND_IPv4'
        case ADDRKIND_IPv4:
             ^
ipfw.c:313:14: error: use of undeclared identifier 'ADDRKIND_IPv6'
        case ADDRKIND_IPv6:
             ^
ipfw.c:329:5: warning: implicitly declaring library function 'strlcat' with type 'unsigned long (char *, const char *, unsigned long)'
    strlcat(args, " from ", sizeof(args));
    ^
ipfw.c:329:5: note: please include the header <string.h> or explicitly provide a declaration for 'strlcat'
2 warnings and 7 errors generated.
*** [ipfw.o] Error code 1

make[4]: stopped in /usr/ports/security/sshguard-ipfw/work/sshguard-1.6.0/src/fwalls
1 error

make[4]: stopped in /usr/ports/security/sshguard-ipfw/work/sshguard-1.6.0/src/fwalls
*** [all-recursive] Error code 1

make[3]: stopped in /usr/ports/security/sshguard-ipfw/work/sshguard-1.6.0/src
1 error

make[3]: stopped in /usr/ports/security/sshguard-ipfw/work/sshguard-1.6.0/src
*** [all] Error code 2

make[2]: stopped in /usr/ports/security/sshguard-ipfw/work/sshguard-1.6.0/src
1 error

make[2]: stopped in /usr/ports/security/sshguard-ipfw/work/sshguard-1.6.0/src
*** [all-recursive] Error code 1

make[1]: stopped in /usr/ports/security/sshguard-ipfw/work/sshguard-1.6.0
1 error

make[1]: stopped in /usr/ports/security/sshguard-ipfw/work/sshguard-1.6.0
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make: stopped in /usr/ports/security/sshguard-ipfw




 Greg



Kevin Zheng said:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi there,
> 
> A patch that fixes blacklist loading when using the `ipfw` backend is
> available and attached here. It is mostly of interest to FreeBSD.
> 
> This patch has not been committed because it relies on the
> non-portable functions `strlcpy` and `strlcat`. While I work on
> bringing these to SSHGuard, FreeBSD users can enjoy a working
> blacklist now.
> 
> I've done rudimentary testing and this patch appears to work; before
> this hits the ports tree someone should really test it.
> 
> Thanks,
> Kevin Zheng
> 
> - -- 
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJVZRxRAAoJEOrPD3bCLhCQN2MIAJOMmgslZPV5aYsYEnX1quC+
> IXMc6t/rpFDybZPKz4LC4YI+WcsQ+fykKQ3mFZfJ2HITqqyBorNUe8JKzR8p59tX
> sX5ePTq4Jld+LOFklKOSS3NSZauMi6zS8tcCpz5gVdQ0iBizDssW/f70ZTD927lB
> 44VgAdv8FrHXsPpgEgcrZCsNm3uK8j48eh3aAo3elThM4BAIhoMYobLZl1Jgnq59
> hjWVk49Z1njypiP2SYASXVdy5x8AINQDY4R8Wqa0/mNGfzFKT2y5HPw/70YbAm3M
> E1o/V9apCH3p1Trq/NshZwvP9sFxfV0oJtATRXUvJxuI0BDHIM5F+/w72TJCVU4=
> =SKWp
> -----END PGP SIGNATURE-----

> diff --git a/src/fwalls/ipfw.c b/src/fwalls/ipfw.c
> index 29045b0..9bee0ad 100644
> --- a/src/fwalls/ipfw.c
> +++ b/src/fwalls/ipfw.c
> @@ -20,6 +20,7 @@
>  
>  #include <assert.h>
>  #include <errno.h>
> +#include <limits.h>
>  #include <time.h>
>  #include <time.h>
>  #include <string.h>
> @@ -37,8 +38,6 @@
>  
>  #define IPFWMOD_ADDRESS_BULK_REPRESENTATIVE     "FF:FF:FF:FF:FF:FF:FF:FF"
>  
> -#define MAXIPFWCMDLEN           90
> -
>  #ifndef IPFW_RULERANGE_MIN
>  #define IPFW_RULERANGE_MIN      55000
>  #endif
> @@ -56,14 +55,14 @@ struct addr_ruleno_s {
>  };
>  
>  static list_t addrrulenumbers;
> -static char command[MAXIPFWCMDLEN], args[MAXIPFWCMDLEN];
> +static char command[PATH_MAX], args[ARG_MAX];
>  
>  /* generate an IPFW rule ID for inserting a rule */
>  static ipfw_rulenumber_t ipfwmod_getrulenumber(void);
>  /* execute an IPFW command */
> -static int ipfwmod_runcommand(char *command, char *args);
> +static int ipfwmod_runcommand(const char *command, const char *args);
>  /* build an IPFW rule for blocking a list of addresses, all of the given kind */
> -static int ipfwmod_buildblockcommand(ipfw_rulenumber_t ruleno, const char *restrict addresses[], int addrkind, char *restrict command, char *restrict args);
> +static int ipfwmod_buildblockcommand(ipfw_rulenumber_t ruleno, const char *restrict addresses[], int addrkind);
>  
>  static size_t ipfw_rule_meter(const void *el) { return sizeof(struct addr_ruleno_s); }
>  static int ipfw_rule_comparator(const void *a, const void *b) {
> @@ -95,7 +94,7 @@ int fw_block(const char *restrict addr, int addrkind, int service) {
>      ruleno = ipfwmod_getrulenumber();
>      addresses[0] = addr;
>      addresses[1] = NULL;
> -    if (ipfwmod_buildblockcommand(ruleno, addresses, addrkind, command, args) != FWALL_OK)
> +    if (ipfwmod_buildblockcommand(ruleno, addresses, addrkind) != FWALL_OK)
>          return FWALL_ERR;
>  
>      /* run command */
> @@ -108,7 +107,7 @@ int fw_block(const char *restrict addr, int addrkind, int service) {
>      sshguard_log(LOG_DEBUG, "Command exited %d.", ret);
>  
>      /* success, save rule number */
> -    strcpy(addendum.addr, addr);
> +    strlcpy(addendum.addr, addr, sizeof(addendum.addr));
>      addendum.ruleno = ruleno;
>      addendum.addrkind = addrkind;
>  
> @@ -134,7 +133,7 @@ int fw_block_list(const char *restrict addresses[], int addrkind, const int serv
>  
>      ruleno = ipfwmod_getrulenumber();
>      /* insert rules under this rule number (in chunks of max_addresses_per_rule) */
> -    if (ipfwmod_buildblockcommand(ruleno, addresses, addrkind, command, args) != FWALL_OK)
> +    if (ipfwmod_buildblockcommand(ruleno, addresses, addrkind) != FWALL_OK)
>          return FWALL_ERR;
>  
>      /* run command */
> @@ -147,7 +146,7 @@ int fw_block_list(const char *restrict addresses[], int addrkind, const int serv
>      sshguard_log(LOG_DEBUG, "Command exited %d.", ret);
>  
>      /* insert a placeholder for the bulk */
> -    strcpy(addendum.addr, IPFWMOD_ADDRESS_BULK_REPRESENTATIVE);
> +    strlcpy(addendum.addr, IPFWMOD_ADDRESS_BULK_REPRESENTATIVE, sizeof(addendum.addr));
>      addendum.ruleno = ruleno;
>      addendum.addrkind = addrkind;
>      list_append(& addrrulenumbers, & addendum);
> @@ -161,7 +160,7 @@ int fw_release(const char *restrict addr, int addrkind, int service) {
>      int pos, ret = 0;
>  
>      /* retrieve ID of rule blocking "addr" */
> -    strcpy(data.addr, addr);
> +    strlcpy(data.addr, addr, sizeof(data.addr));
>      data.addrkind = addrkind;
>      if ((pos = list_locate(& addrrulenumbers, &data)) < 0) {
>          sshguard_log(LOG_ERR, "could not get back rule ID for address %s", addr);
> @@ -172,22 +171,22 @@ int fw_release(const char *restrict addr, int addrkind, int service) {
>      switch (data.addrkind) {
>          case ADDRKIND_IPv4:
>              /* use ipfw */
> -            sprintf(command, IPFW_PATH "/ipfw");
> +            strlcpy(command, IPFW_PATH "/ipfw", sizeof(command));
>              break;
>          case ADDRKIND_IPv6:
>  #ifdef FWALL_HAS_IP6FW
>              /* use ip6fw if found */
> -            sprintf(command, IPFW_PATH "/ip6fw");
> +            strlcpy(command, IPFW_PATH "/ip6fw", sizeof(command));
>  #else
>              /* use ipfw, assume it supports IPv6 rules as well */
> -            sprintf(command, IPFW_PATH "/ipfw");
> +            strlcpy(command, IPFW_PATH "/ipfw", sizeof(command));
>  #endif
>              break;
>          default:
>              return FWALL_UNSUPP;
>      }
>      /* build command arguments */
> -    snprintf(args, MAXIPFWCMDLEN, "delete %u", data.ruleno);
> +    snprintf(args, sizeof(args), "delete %u", data.ruleno);
>  
>      sshguard_log(LOG_DEBUG, "running: '%s %s'", command, args);
>  
> @@ -216,19 +215,19 @@ int fw_flush(void) {
>          data = (struct addr_ruleno_s *)list_iterator_next(& addrrulenumbers);
>          switch (data->addrkind) {
>              case ADDRKIND_IPv4:
> -                snprintf(command, MAXIPFWCMDLEN, IPFW_PATH "/ipfw");
> +                strlcpy(command, IPFW_PATH "/ipfw", sizeof(command));
>                  break;
>              case ADDRKIND_IPv6:
>  #ifdef FWALL_HAS_IP6FW
>                  /* use ip6fw if found */
> -                sprintf(command, IPFW_PATH "/ip6fw");
> +                strlcpy(command, IPFW_PATH "/ip6fw", sizeof(command));
>  #else
>                  /* use ipfw, assume it supports IPv6 rules as well */
> -                sprintf(command, IPFW_PATH "/ipfw");
> +                strlcpy(command, IPFW_PATH "/ipfw", sizeof(command));
>  #endif
>                  break;
>          }
> -        sprintf(args, "delete %u", data->ruleno);
> +        snprintf(args, sizeof(args), "delete %u", data->ruleno);
>          sshguard_log(LOG_DEBUG, "running: '%s %s'", command, args);
>          ret = ipfwmod_runcommand(command, args);
>          if (ret != 0) {
> @@ -250,7 +249,7 @@ static ipfw_rulenumber_t ipfwmod_getrulenumber(void) {
>      return (rand() % (IPFW_RULERANGE_MAX - IPFW_RULERANGE_MIN)) + IPFW_RULERANGE_MIN;
>  }
>  
> -static int ipfwmod_runcommand(char *command, char *args) {
> +static int ipfwmod_runcommand(const char *command, const char *args) {
>      char *argsvec[20];
>      pid_t pid;
>      int i, j, ret;
> @@ -258,8 +257,8 @@ static int ipfwmod_runcommand(char *command, char *args) {
>  
>      sshguard_log(LOG_DEBUG, "Running command: '%s %s'.", command, args);
>  
> -    argsvec[0] = command;
> -    strcpy(locargs, args);
> +    argsvec[0] = strdup(command);
> +    strlcpy(locargs, args, sizeof(locargs));
>  
>      /* tokenize command */
>      argsvec[1] = locargs;
> @@ -280,6 +279,7 @@ static int ipfwmod_runcommand(char *command, char *args) {
>          sshguard_log(LOG_ERR, "Unable to run command: %s", strerror(errno));
>          _Exit(1);
>      }
> +    free(argsvec[0]);
>      free(locargs);
>      waitpid(pid, &ret, 0);
>      ret = WEXITSTATUS(ret);
> @@ -287,7 +287,7 @@ static int ipfwmod_runcommand(char *command, char *args) {
>      return ret;
>  }
>  
> -static int ipfwmod_buildblockcommand(ipfw_rulenumber_t ruleno, const char *restrict addresses[], int addrkind, char *restrict command, char *restrict args) {
> +static int ipfwmod_buildblockcommand(ipfw_rulenumber_t ruleno, const char *restrict addresses[], int addrkind) {
>      int i;
>  
>      assert(addresses != NULL);
> @@ -307,19 +307,19 @@ static int ipfwmod_buildblockcommand(ipfw_rulenumber_t ruleno, const char *restr
>      switch (addrkind) {
>          case ADDRKIND_IPv4:
>              /* use ipfw */
> -            sprintf(command, IPFW_PATH "/ipfw");
> -            sprintf(args, "add %u drop ip", ruleno);
> +            strlcpy(command, IPFW_PATH "/ipfw", sizeof(command));
> +            snprintf(args, sizeof(args), "add %u drop ip", ruleno);
>              break;
>  
>          case ADDRKIND_IPv6:
>  #ifdef FWALL_HAS_IP6FW
>              /* use ip6fw if found */
> -            sprintf(command, IPFW_PATH "/ip6fw");
> +            strlcpy(command, IPFW_PATH "/ip6fw", sizeof(command));
>  #else
>              /* use ipfw, assume it supports IPv6 rules as well */
> -            sprintf(command, IPFW_PATH "/ipfw");
> +            strlcpy(command, IPFW_PATH "/ipfw", sizeof(command));
>  #endif
> -            sprintf(args, "add %u drop ipv6", ruleno);
> +            snprintf(args, sizeof(args), "add %u drop ipv6", ruleno);
>              break;
>  
>          default:
> @@ -327,13 +327,17 @@ static int ipfwmod_buildblockcommand(ipfw_rulenumber_t ruleno, const char *restr
>      }
>  
>      /* add the rest of the rule */
> -    sprintf(args + strlen(args), " from %s", addresses[0]);
> +    strlcat(args, " from ", sizeof(args));
> +    strlcat(args, addresses[0], sizeof(args));
>      for (i = 1; addresses[i] != NULL; ++i) {
> -        sprintf(args + strlen(args), ",%s", addresses[i]);
> +        strlcat(args, ",", sizeof(args));
> +        strlcat(args, addresses[i], sizeof(args));
> +    }
> +    if (strlcat(args, " to me", sizeof(args)) >= sizeof(args)) {
> +        fprintf(stderr, "Fatal: Argument buffer too small\n");
> +        exit(EXIT_FAILURE);
>      }
> -    strcat(args, " to me");
>  
>      return FWALL_OK;
>  }
>  
> -


> ------------------------------------------------------------------------------

> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] Patch to fix blacklist loading with ipfw

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi there,

A patch that fixes blacklist loading when using the `ipfw` backend is
available and attached here. It is mostly of interest to FreeBSD.

This patch has not been committed because it relies on the
non-portable functions `strlcpy` and `strlcat`. While I work on
bringing these to SSHGuard, FreeBSD users can enjoy a working
blacklist now.

I've done rudimentary testing and this patch appears to work; before
this hits the ports tree someone should really test it.

Thanks,
Kevin Zheng

- -- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVZRxRAAoJEOrPD3bCLhCQN2MIAJOMmgslZPV5aYsYEnX1quC+
IXMc6t/rpFDybZPKz4LC4YI+WcsQ+fykKQ3mFZfJ2HITqqyBorNUe8JKzR8p59tX
sX5ePTq4Jld+LOFklKOSS3NSZauMi6zS8tcCpz5gVdQ0iBizDssW/f70ZTD927lB
44VgAdv8FrHXsPpgEgcrZCsNm3uK8j48eh3aAo3elThM4BAIhoMYobLZl1Jgnq59
hjWVk49Z1njypiP2SYASXVdy5x8AINQDY4R8Wqa0/mNGfzFKT2y5HPw/70YbAm3M
E1o/V9apCH3p1Trq/NshZwvP9sFxfV0oJtATRXUvJxuI0BDHIM5F+/w72TJCVU4=
=SKWp
-----END PGP SIGNATURE-----

[Sshguard-users] New ipfw backend

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi there,

In light of the recent `ipfw` issues I've decided to re-implement the
`ipfw` backend using the command framework that is used for nearly all
of the other backends. Since I don't run `ipfw` on my machine, I'm
unable to test this patch.

If you are running `ipfw` and are willing to test-drive this new and
more than likely broken backend, apply the attached patch, compile,
and take it for a whirl. In particular, I'm not sure if the "add
multiple addresses" part works, so if you have a large blacklist that
crashed the original ipfw backend try it on the new one.

The new backend operates on ipfw tables. You'll need to set up your
firewall with a tabled named 'sshguard'. SSHGuard (should) add
attackers to this table; you'll need to set up the rules yourself.

Please don't test this in a production environment, and if you test it
at all, be aware that bad things can happen. Please take a look at the
patch before you try to run this code.

Best,
Kevin Zheng

- -- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVZPR5AAoJEOrPD3bCLhCQ4VsH/3mugV40W5hmj3sfVOV+AYDl
0hUssAIOdapw0yOoaRnGYP/2+IZNbtw1737iH10BBX1S59xmWDuqPT/Wi00kHuLv
WttvPCUuHBBJcJS6H0C+VG0yeQepFdmvln6zb7bKBAbarVb8z4Oq5sOBPDMtby9t
hAfYWr4CEKe1MI9x0wHY8y2Lz9yVBc+bPUJzYj+WS7a1qwdYqzyLIfB5NWMsRpdF
lv6ktXZYWwb/Gkw/ALTwPHm5xepz5suBjsyPS2eQgVnBMaNAzjsGy349BvKYOdkX
Q5wKaVwBWs0RcpfR0GmbYoSbT3Ya1Q+ToNl/9Ep8BUMbC/XuR+Py7u1kGghIlHA=
=JaPC
-----END PGP SIGNATURE-----

[Sshguard-users] Errata Notice: Crash when loading blacklists using the ipfw backend

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

This is an errata notice for SSHGuard. This issue impacts the 1.6.0
release, but has actually been around for quite some time.

## Problem ##

When blocking attackers from a loaded blacklist file, SSHGuard will
write past the boundaries of a fixed-length buffer.

This problem only affects users running SSHGuard with blacklisting
enabled, while using the `ipfw` backend.

## Impact ##

SSHGuard will crash with a segmentation fault upon startup when loading
a blacklist with enough (less than 100) entries. Because the blacklist
file is generally owned by the superuser, it is unlikely that this
vulnerability could be used to gain superuser privileges. If you are
affected, please consider using one of the workarounds:

## Workaround ##

Any one of these should work around the issue:

1. Don't use blacklisting.

2. Don't use the `ipfw` backend.

3. If you need blacklisting, delete the blacklist file before starting.

## Solution ##

We're working on one. The "long-term" solution is to switch `ipfw` to
the "command" backend and use ipfw tables instead of individual rules.
For the time being:

1. Increase the length of the fixed buffer. Eventually, though, this
will run into the same problem.

2. There is a patch on the mailing list that adds the blacklisted
addresses one at a time. I haven't taken a look at it yet.

## Credits ##

Thanks to Greg Putrich <gr...@n0...> for analyzing and proposing a
fix to this issue. Thanks to the many people who have reported this
issue beforehand, even though I never got around to acting on them.

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

Re: [Sshguard-users] Core dump on FreeBSD 10.1 with sshguard-ipfw 1.6.0

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

Hi Greg,

Thanks for tracking down the problem and providing a fix. This issue has
been around for quite some time and I never had enough motivation to
track it down (I never used the blacklist with ipfw).

(The original patch is attached with this message.)

On 05/26/2015 12:11, Greg Putrich wrote:
> On sshguard 1.6.0 (and 1.5.0) on FreeBSD 10.1 with ipfw, when starting up 
> sshguard with a "large" blacklist.db file, it would crash with a segmentation 
> fault & dump its core. Tracked this down to MAXIPFWCMDLEN being set to 90.

That would do it. The culprits are short fixed-length buffers used with
unbounded string functions. All the sprintf's should be taken out.

> Set it to 100 and it worked with a slightly larger blacklist.db file, but the
> problem is, changing that number is fine for a time, but my blacklist.db file
> for running for a couple of weeks is 212 entries and that would be one really
> long rule. I found this the hard way when I patched my system, rebooted and
> didn't check sshguard. I looked at it by chance later and it wasn't running
> and wouldn't start. Cleared out blacklist.db and it was fine. As you can see,
> this is not an ideal condition and makes blacklist.db useless.

A "fix" would be to bump the buffer up to something ridiculous like 2048
(or something in sys/limits.h). But you're right; that doesn't solve the
problem at hand.

> I decided to fix it by looping through each entry & adding a separate rule.

This was originally avoided to stop incurring the penalty of a system()
call for every IP. But this fix is better than crashing.

> What this also does is keeps the counters meaningful as can tell which IP
> addresses are actively being a pest.

The ipfw backend has been rotting in lots of different places. A while
ago someone pointed out some vulnerabilities concerning how the ipfw
backend assigns attackers to firewall rules, but that hasn't been fixed.

> Attached is the patch for 1.6.0. For the most part, I copied the code from two
> sections within ipfw.c then wrapped it in a for loop.
> 
> Also included in that diff is the existing patch for ipfw.c in sshguard-ipfw
> on FreeBSD.
> 
> I'm not much of a C coder, so this may not be the ideal way of doing it, but
> its been working here and no more core dumps when loading a big blacklist.db.

I'll take a look. In the future, you're more than welcome to post
patches to the mailing list for more eyes to look at it. Also, in case I
never get around to actually looking at it.

Thanks,
Kevin Zheng

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

Re: [Sshguard-users] On initiating sshguard

[Rick H. <ri...@ta...>]

Please ignore this issue I brought up.  I tried the service method (only,
i.e. no changes to syslog.conf) and everything seems to be working fine.
Sorry for the noise.  Cheers!

[Sshguard-users] On initiating sshguard

[Rick H. <ri...@ta...>]

Hi list!

n00b question here.  I'm on FreeBSD 10.1 and running the ipfw firewall.  I
installed the sshguard-ipfw package; so I'm assuming that was the right
thing to do to start.

My confusion is that I seem to see two different ways to launch/run
sshguard.  One is from syslogd in syslog.conf, e.g.

auth.info;authpriv.info |/usr/local/sbin/sshguard [options here]

and another is to run sshguard as daemon from (the package installed)
/usr/local/etc/rc.d/sshguard script, which tells sshguard to read auth.log.
(And is a very nicely documented script to boot BTW.)

Both methods together *seem* redundant, but how should I be running
sshguard: both ways or only one way (i.e. but not the other)?

I RTFM but didn't notice this detail.  I apologize if I missed something in
the reading.

Thanks for your help, --Rick

Re: [Sshguard-users] fedora21 systemd and journalctl with sshguard

[James H. <jam...@gm...>]

I use sshguard on FC 21. Below is the systemd unit file I use. You should
copy it to /etc/systemd/system/sshguard.service. Edit the ExecStart lineto
use the command line you want, be sure to use the correct path to sshguard,
yours might be /usr/local/sbin/sshguard
Then make sure the running systemd finds the new file ala "systemctl
daemon-reload'. You can start sshguard just once with 'systemctl start
sshguard' and use 'systemctl status sshguard' to verify it loaded without
problems. To have systemd start sshguard on boot use 'systemctl enable
sshguard'.

systemd is much more complicated than bsd init or sysv init, but it really
does have some useful features. As you can see this unit file will restart
the daemon should it exit or crash. Systemd is also integrated with
containers allowing it to easily start each daemon in an isolated
environment.


#
# sshguard systemd unit
#
#

[Unit]
Description=Ssh Guard dynamic firewall against brute force attempts
After=syslog.target
After=iptables.target
After=ip6tables.target
After=libvirtd.service
After=firewalld.service

[Service]
ExecStart=/usr/sbin/sshguard -w /etc/sshguard.whitelist -l /var/log/secure
-b 60:/var/db/sshguard/blacklist.db
Restart=always

[Install]
WantedBy=multi-user.target





On Tue, May 12, 2015 at 1:17 PM, Jason M <jk...@gm...> wrote:

> I upgraded fedora13 to fedora21 and am having a difficulty setting up the
> sshguard.  Unlike fedora13, fedora21 uses systemd and journalctl, and I
> need some guide how to set up the sshguard.  I downloded and compiled
> sshguard 1.5 version since I could not find the 64bit rpm version for
> fedora21.
>
> Thank you very much.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>


-- 
James Harris
Software Engineer
jam...@gm...

Re: [Sshguard-users] Subject: Re: Username Blacklisting

[James H. <jam...@gm...>]

Many of the logs already parsed include usernames so it sounds like
adjusting the lexer/ parser expressions to pick out the name and include
them in the values passed back. Since we already have internet scales for
block and black list a simple integer multiplier should work for vouching
up the threat level.

I would suggest something like
Username:multiplier
Which keeps it paswd like. We could add more values in the future. In
addition to a multiplier I could see someone wanting to just set a value
instead of using multipliers.

Username:multiplier:setvalue

root::100
bob:2:

Setting any root attempt to 100 threat level and doubling the value Bob
would otherwise get.
On May 15, 2015 9:16 AM, "Kevin Zheng" <kev...@gm...> wrote:

> On 05/15/2015 10:58, Laurence Perkins (OE) wrote:
> > It would pretty well have to be added as a configuration at runtime
> > since the list of prohibited usernames would vary per system.
>
> Perhaps a flat text file, with one username per line?
>
> > My original thought was to have a list where even attempting to log in
> > with one of the names resulted in an immediate block.  E.g.: The root
> > account on my machine is disabled.  Anyone who even attempts to use it
> > is necessarily an unauthorized attacker and should be blocked
> > immediately.  There is no reason to wait for them to try more than once
> > (or even to let them finish the first attempt really).  Same thing goes
> > for various other account names that are commonly tested by attackers
> > and that don't even exist on my machine.  User accounts that do exist
> > where someone could legitimately be having trouble remembering their
> > password need to not lock the user out for fat-fingering their password
> > a couple of times though.
>
> Makes sense. Especially at the point which a user account (e.g. root) is
> disabled, any attempted login is certainly an attack.
>
> > If the list were implemented as a "danger multiplier" then it could be
> > calibrated so that root login attempts get blocked instantly, logins to
> > my account get blocked after just a couple of attempts, and logins to
> > some of my more absent-minded users get a little extra grace.  It's
> > probably not worth going to a lot of extra trouble to implement it this
> > way, but if username blacklisting is easiest to do by adjusting the
> > danger for listed accounts then reading a custom multiplier from the
> > account list for each account wouldn't take much more effort.  Just
> > being able to blacklist accounts, however, would eliminate the vast
> > majority of attackers as nearly all of them seem to hit the same list of
> > default usernames.
>
> Actually, most of the work is probably going to be extracting the
> username and passing it to the attack reporter. I'll start working on a
> proof-of-concept soon and keep you updated.
>
> Thanks,
> Kevin Zheng
>
> --
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

Re: [Sshguard-users] Subject: Re: Username Blacklisting

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

On 05/15/2015 10:58, Laurence Perkins (OE) wrote:
> It would pretty well have to be added as a configuration at runtime
> since the list of prohibited usernames would vary per system.

Perhaps a flat text file, with one username per line?

> My original thought was to have a list where even attempting to log in
> with one of the names resulted in an immediate block.  E.g.: The root
> account on my machine is disabled.  Anyone who even attempts to use it
> is necessarily an unauthorized attacker and should be blocked
> immediately.  There is no reason to wait for them to try more than once
> (or even to let them finish the first attempt really).  Same thing goes
> for various other account names that are commonly tested by attackers
> and that don't even exist on my machine.  User accounts that do exist
> where someone could legitimately be having trouble remembering their
> password need to not lock the user out for fat-fingering their password
> a couple of times though.

Makes sense. Especially at the point which a user account (e.g. root) is
disabled, any attempted login is certainly an attack.

> If the list were implemented as a "danger multiplier" then it could be
> calibrated so that root login attempts get blocked instantly, logins to
> my account get blocked after just a couple of attempts, and logins to
> some of my more absent-minded users get a little extra grace.  It's
> probably not worth going to a lot of extra trouble to implement it this
> way, but if username blacklisting is easiest to do by adjusting the
> danger for listed accounts then reading a custom multiplier from the
> account list for each account wouldn't take much more effort.  Just
> being able to blacklist accounts, however, would eliminate the vast
> majority of attackers as nearly all of them seem to hit the same list of
> default usernames.

Actually, most of the work is probably going to be extracting the
username and passing it to the attack reporter. I'll start working on a
proof-of-concept soon and keep you updated.

Thanks,
Kevin Zheng

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

[Sshguard-users] Subject: Re: Username Blacklisting

[Laurence P. (OE) <lpe...@op...>]

Message-ID: <555...@gm...>


> >> Having the option of scoring certain usernames as high danger
> attempts,
> >> or perhaps as danger 1+fractional multipliers, could be a clean way
> to
> >> implement such a feature.
> > 
> > I hadn't thought of doing it that way, but that would likely be more
> useful as you could
> > use it to set up multiple, different levels of paranoia for
> different users.  Especially
> > if you can use a fractional multiplier to effectively raise the
> threshold for guest accounts
> > and the like.
> 
> How would this work? Raise the danger of the attack so that two
> attempted logins with 'root' or similar usernames would be blocked?
> How
> would SSHGuard know which usernames to do this for? Would it be built
> into the binary, or added as a configuration at run-time?
> 
> (With your use case, why not just lower the blocking threshold?)
> 
> Thanks,
> Kevin Zheng

It would pretty well have to be added as a configuration at runtime
since the list of prohibited usernames would vary per system.

My original thought was to have a list where even attempting to log in
with one of the names resulted in an immediate block.  E.g.: The root
account on my machine is disabled.  Anyone who even attempts to use it
is necessarily an unauthorized attacker and should be blocked
immediately.  There is no reason to wait for them to try more than once
(or even to let them finish the first attempt really).  Same thing goes
for various other account names that are commonly tested by attackers
and that don't even exist on my machine.  User accounts that do exist
where someone could legitimately be having trouble remembering their
password need to not lock the user out for fat-fingering their password
a couple of times though.

If the list were implemented as a "danger multiplier" then it could be
calibrated so that root login attempts get blocked instantly, logins to
my account get blocked after just a couple of attempts, and logins to
some of my more absent-minded users get a little extra grace.  It's
probably not worth going to a lot of extra trouble to implement it this
way, but if username blacklisting is easiest to do by adjusting the
danger for listed accounts then reading a custom multiplier from the
account list for each account wouldn't take much more effort.  Just
being able to blacklist accounts, however, would eliminate the vast
majority of attackers as nearly all of them seem to hit the same list of
default usernames.


LMP

Re: [Sshguard-users] fedora21 systemd and journalctl with sshguard

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

On 05/12/2015 15:17, Jason M wrote:
> I upgraded fedora13 to fedora21 and am having a difficulty setting up
> the sshguard.  Unlike fedora13, fedora21 uses systemd and journalctl,
> and I need some guide how to set up the sshguard.  I downloded and
> compiled sshguard 1.5 version since I could not find the 64bit rpm
> version for fedora21.

Does Fedora ship with startup scripts for SSHGuard? If so, you're
probably better off using those.

If your logs go to files, this is what you can do:

# sshguard -l /var/log/auth.log -l /other/log/files

If not, I don't know enough about systemd and journalctl to help.

Best,
Kevin Zheng

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

Re: [Sshguard-users] Username Blacklisting

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

On 05/11/2015 12:06, Laurence Perkins (OE) wrote:
> The CPU penalty comes primarily from doing all the calculations to set up the 
> encrypted channel and secondarily from hashing the password for verification.  
> (The order of those two subject to change depending on encryption settings)
> Setting SSH to block certain usernames eliminates the latter, but you still have 
> the first one.  On my old C3 machine (roughly equivalent power to a Raspberry Pi) 
> setting up the encrypted channel took it about 2-3 seconds. (I like large keys)  
> I started using SSHguard because the rapid-fire login attempts were redlining my 
> CPU and making the machine more-or-less useless (except, maybe, as a toaster...)

Makes sense; this is one of the things SSHGuard was designed to prevent.

>> Having the option of scoring certain usernames as high danger attempts,
>> or perhaps as danger 1+fractional multipliers, could be a clean way to
>> implement such a feature.
> 
> I hadn't thought of doing it that way, but that would likely be more useful as you could
> use it to set up multiple, different levels of paranoia for different users.  Especially
> if you can use a fractional multiplier to effectively raise the threshold for guest accounts
> and the like.

How would this work? Raise the danger of the attack so that two
attempted logins with 'root' or similar usernames would be blocked? How
would SSHGuard know which usernames to do this for? Would it be built
into the binary, or added as a configuration at run-time?

(With your use case, why not just lower the blocking threshold?)

Thanks,
Kevin Zheng

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

[Sshguard-users] fedora21 systemd and journalctl with sshguard

[Jason M <jk...@gm...>]

I upgraded fedora13 to fedora21 and am having a difficulty setting up the
sshguard.  Unlike fedora13, fedora21 uses systemd and journalctl, and I
need some guide how to set up the sshguard.  I downloded and compiled
sshguard 1.5 version since I could not find the 64bit rpm version for
fedora21.

Thank you very much.

Re: [Sshguard-users] Username Blacklisting

[Laurence P. (OE) <lpe...@op...>]

Attempting two birds with one message...

>Date: Fri, 8 May 2015 11:46:15 -0600
>From: Richard Johnson <rjt...@sa...>
>Subject: Re: [Sshguard-users] Username Blacklisting
>To: ssh...@li...
>Message-ID: <201...@ri...>
>Content-Type: text/plain; charset=us-ascii>>

>On Fri, May 08, 2015 at 12:20:46PM -0500, Kevin Zheng wrote:
>> On 05/08/2015 11:51, Laurence Perkins (OE) wrote:
>> > While we're discussing potential new features, I've noticed that nearly
>> > all attackers hit the same list of default usernames (root, pi, ubuntu,
>> > etc.)

>> Sounds interesting, especially with the use case you describe (running
>> on a Raspberry Pi). Have you taken a look at OpenSSH settings like
>> AllowUsers or DenyUsers? Do those incur the same CPU penalty?

The CPU penalty comes primarily from doing all the calculations to set up the 
encrypted channel and secondarily from hashing the password for verification.  
(The order of those two subject to change depending on encryption settings)
Setting SSH to block certain usernames eliminates the latter, but you still have 
the first one.  On my old C3 machine (roughly equivalent power to a Raspberry Pi) 
setting up the encrypted channel took it about 2-3 seconds. (I like large keys)  
I started using SSHguard because the rapid-fire login attempts were redlining my 
CPU and making the machine more-or-less useless (except, maybe, as a toaster...)

>> 
>> This sounds useful; I'll start poking around soon.


>Having the option of scoring certain usernames as high danger attempts,
>or perhaps as danger 1+fractional multipliers, could be a clean way to
>implement such a feature.

I hadn't thought of doing it that way, but that would likely be more useful as you could
use it to set up multiple, different levels of paranoia for different users.  Especially
if you can use a fractional multiplier to effectively raise the threshold for guest accounts
and the like.



LMP

Re: [Sshguard-users] Username Blacklisting

[James H. <jam...@gm...>]

That makes sense. So long as the whitelist is applied first. I can specify
the few machines I might rarely ssh in as root from all others would would
most likely be attacks.

How would this apply to other log scanning would there be other regex that
should increase the fractional attack value? For example are there http
paths that are common targets of exploit?
On May 8, 2015 11:03 AM, "Richard Johnson" <
rjt...@sa...> wrote:

> On Fri, May 08, 2015 at 12:20:46PM -0500, Kevin Zheng wrote:
> > On 05/08/2015 11:51, Laurence Perkins (OE) wrote:
> > > While we're discussing potential new features, I've noticed that nearly
> > > all attackers hit the same list of default usernames (root, pi, ubuntu,
> > > etc.)  It would be useful to be able to specify a list of usernames
> that
> > > result in an immediate block without waiting for the login to fail.
> > > (Processing the login attempt uses a not-insignificant amount of CPU on
> > > low-end machines like a Raspberry Pi.  Blocking the connection
> > > immediately would save quite a bit.)
> >
> > Sounds interesting, especially with the use case you describe (running
> > on a Raspberry Pi). Have you taken a look at OpenSSH settings like
> > AllowUsers or DenyUsers? Do those incur the same CPU penalty?
> >
> > This sounds useful; I'll start poking around soon.
>
>
> Having the option of scoring certain usernames as high danger attempts,
> or perhaps as danger 1+fractional multipliers, could be a clean way to
> implement such a feature.
>
>
> Richard
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

Re: [Sshguard-users] Username Blacklisting

[Richard J. <rjt...@sa...>]

On Fri, May 08, 2015 at 12:20:46PM -0500, Kevin Zheng wrote:
> On 05/08/2015 11:51, Laurence Perkins (OE) wrote:
> > While we're discussing potential new features, I've noticed that nearly
> > all attackers hit the same list of default usernames (root, pi, ubuntu,
> > etc.)  It would be useful to be able to specify a list of usernames that
> > result in an immediate block without waiting for the login to fail.
> > (Processing the login attempt uses a not-insignificant amount of CPU on
> > low-end machines like a Raspberry Pi.  Blocking the connection
> > immediately would save quite a bit.)
> 
> Sounds interesting, especially with the use case you describe (running
> on a Raspberry Pi). Have you taken a look at OpenSSH settings like
> AllowUsers or DenyUsers? Do those incur the same CPU penalty?
> 
> This sounds useful; I'll start poking around soon.


Having the option of scoring certain usernames as high danger attempts,
or perhaps as danger 1+fractional multipliers, could be a clean way to
implement such a feature.


Richard

Re: [Sshguard-users] Username Blacklisting

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

On 05/08/2015 11:51, Laurence Perkins (OE) wrote:
> While we're discussing potential new features, I've noticed that nearly
> all attackers hit the same list of default usernames (root, pi, ubuntu,
> etc.)  It would be useful to be able to specify a list of usernames that
> result in an immediate block without waiting for the login to fail.
> (Processing the login attempt uses a not-insignificant amount of CPU on
> low-end machines like a Raspberry Pi.  Blocking the connection
> immediately would save quite a bit.)

Sounds interesting, especially with the use case you describe (running
on a Raspberry Pi). Have you taken a look at OpenSSH settings like
AllowUsers or DenyUsers? Do those incur the same CPU penalty?

This sounds useful; I'll start poking around soon.

Best,
Kevin Zheng

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

Re: [Sshguard-users] Username Blacklisting

[James H. <jam...@gm...>]

This feels like something that would be better handled with PAM.  Maybe it
would be enhanced by providing a flat file 'firewall' backend, something
like hosts.deny PAM could reference.
On May 8, 2015 10:06 AM, "Laurence Perkins (OE)" <lpe...@op...>
wrote:

> While we're discussing potential new features, I've noticed that nearly
> all attackers hit the same list of default usernames (root, pi, ubuntu,
> etc.)  It would be useful to be able to specify a list of usernames that
> result in an immediate block without waiting for the login to fail.
> (Processing the login attempt uses a not-insignificant amount of CPU on
> low-end machines like a Raspberry Pi.  Blocking the connection
> immediately would save quite a bit.)
>
> LMP
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

[Sshguard-users] Username Blacklisting

[Laurence P. (OE) <lpe...@op...>]

While we're discussing potential new features, I've noticed that nearly
all attackers hit the same list of default usernames (root, pi, ubuntu,
etc.)  It would be useful to be able to specify a list of usernames that
result in an immediate block without waiting for the login to fail.
(Processing the login attempt uses a not-insignificant amount of CPU on
low-end machines like a Raspberry Pi.  Blocking the connection
immediately would save quite a bit.)

LMP

Re: [Sshguard-users] init scripts, large blocks, hit counts

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

On 05/06/2015 15:46, James Harris wrote:
> I see the freebsd init script was removed from the repo. Was the script
> removed because it is broken or unwanted? I have a systmed unit file
> that I have been debating make a pull-up request for. I thought if at
> least an example unit file was included we might be able to encourage
> others to package sshguard for their preferred OS/distro.

Mostly because the FreeBSD startup script is being maintained outside of
the SSHGuard tree. What was left in the repository was a very old
version that once upon a time was in the FreeBSD ports tree. Since
startup scripts tend to be OS-specific, I decided to take it out.

I'm not sure what to feel about a systemd unit file. It sounds like it
could be useful for every Linux distribution that uses systemd, and
wouldn't hurt anyone else. Different OSes are probably going to make
distro specific changes, though.

Full disclosure: I'm a FreeBSD user, so I'm inherently biased against
systemd. I don't have any convincing arguments against it, though,
except that I *did* take out the FreeBSD startup script.

> On another topic. I have see my current loaded blacklist is up to about
> 1260 addresses. Out curiosity I started writing some scripts to do some
> analysis of the  IPs. My thought was maybe people that get issued a DHCP
> address from their provider start to reject addresses until till they
> get a new one that hasn't been blocked by their targets. I would guess
> those addresses are rather close to each other or at least issued to the
> same AS. If many attacks came from the same net block it would be faster
> to block a range of addresses. Fewer rules should make the firewall
> faster also it would be proactive blocking the other addresses they are
> likely to get. Sorting by AS I can see I have 39 hits from AS12876 from
> France which has 4 allocations but most of my hits are from only one.
> From AS4837 I have 38 blacklisted but they have several /16 or /15
> ranges and my hits come from across many of them.  From AS4134 I have 
> 452 black listed and they also also have 20some /15/ or /16 allocated
> blocks. I can provide the scripts if anyone is interested. I pulled the
> AS data from Team cymru via their dns
> gateway http://www.team-cymru.org/IP-ASN-mapping.html#dns.

This proposal sounds promising. The biggest hurdle was getting block
information from IP addresses (a WHOIS on every incoming attacker
doesn't sound like a good plan). With DNS this seems more feasible.

So would attacks be recorded on a per-address-block basis? What if an
attacker sitting on a huge public block (say, a university's class A)
gets the block blacklisted. Isn't this a denial of service?

> Finally I was looking over the iptables capabilities and it looks like
> it is possible to get hit count on rules.I would suspect most of the
> backend support this. Would there be interest in adding hit count thrush
> holds to the temporary blocks, black listing  promotions? So as the
> temporary rules continue to receive hits they should stay in place
> resetting the expire timer and given enough hits be promoted to a
> blacklist. Instead of waiting for several violations to occur only one
> may be needed. Then as the rule is continued to be triggered by likely
> attacks it can be extended or made permanent never opening the service
> back to the attacker.

Perhaps. Again, this circles back to the issue of blacklists. I tend to
not like permanent blacklisting because dynamic IPs can be recycled very
frequently. One could argue that instead of using SSHGuard, a
low-traffic host might be better off blocking IP blocks from (insert
your favorite botnet region here) on a firewall.

But again, I'm super biased and am aware that some features would be
useful to SSHGuard even though *I* don't use them. I'm really interested
in hearing opinions on this.

Thanks,
Kevin Zheng

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

[Sshguard-users] init scripts, large blocks, hit counts

[James H. <jam...@gm...>]

I see the freebsd init script was removed from the repo. Was the script
removed because it is broken or unwanted? I have a systmed unit file that I
have been debating make a pull-up request for. I thought if at least an
example unit file was included we might be able to encourage others to
package sshguard for their preferred OS/distro.

On another topic. I have see my current loaded blacklist is up to about
1260 addresses. Out curiosity I started writing some scripts to do some
analysis of the  IPs. My thought was maybe people that get issued a DHCP
address from their provider start to reject addresses until till they get a
new one that hasn't been blocked by their targets. I would guess those
addresses are rather close to each other or at least issued to the same AS.
If many attacks came from the same net block it would be faster to block a
range of addresses. Fewer rules should make the firewall faster also it
would be proactive blocking the other addresses they are likely to get.
Sorting by AS I can see I have 39 hits from AS12876 from France which has 4
allocations but most of my hits are from only one. From AS4837 I have 38
blacklisted but they have several /16 or /15 ranges and my hits come from
across many of them.  From AS4134 I have
452 black listed and they also also have 20some /15/ or /16 allocated
blocks. I can provide the scripts if anyone is interested. I pulled the AS
data from Team cymru via their dns gateway
http://www.team-cymru.org/IP-ASN-mapping.html#dns.

Finally I was looking over the iptables capabilities and it looks like it
is possible to get hit count on rules.I would suspect most of the backend
support this. Would there be interest in adding hit count thrush holds to
the temporary blocks, black listing  promotions? So as the temporary rules
continue to receive hits they should stay in place resetting the expire
timer and given enough hits be promoted to a blacklist. Instead of waiting
for several violations to occur only one may be needed. Then as the rule is
continued to be triggered by likely attacks it can be extended or made
permanent never opening the service back to the attacker.









-- 
James Harris
Software Engineer
jam...@gm...

[Sshguard-users] Build fix for SSHGuard 1.6.0 using 'ipfw' and 'hosts' backends

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This is an errata notice for the SSHGuard 1.6.0 release:

## Problem ##

SSHGuard supports one of several firewall backends; of these, the
'ipfw' and 'hosts' backends failed to build due to a missing header
file after some code reorganization prior to the 1.6.0 release.

There is no workaround available; however, users who are not using the
'ipfw' or 'hosts' backends are not affected.

## Solution ##

Those who are affected should apply the attached patch against the
1.6.0 release tarball, or track the 1.6 branch on Bitbucket.

## Credits ##

Thanks to Mark Felder <fe...@Fr...> for reporting this issue.

- -- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVR+okAAoJEOrPD3bCLhCQlgQH+wUWoWLdBhzcppnc3CZ6eXol
CA+5uHa0+cuYdouTjqW5tayGOO8JT6Ng7ydw5tML6CjtBDRJ8aWIHeJcUI9l4yA3
htAD+CxhxJ4l2rWy0Upz1kLb0ylGkNfk8tE56oSwYlLCYptVGeIMw3OQhPI8gnpb
ZJt2YHpiS+Cf/qjhsmKQ6N9/8Tf7H8dZRXhUK5zhZ8LZ4ZQPJf2+1le3DMOy08P1
UjoQivl6Vh6m3ea3Cu9L3DLh2oqRfrh9ixYmkcPWIKKPO0Xnz1jPy8BF5NoTyGt2
KlsFKzbwKablGNOxUrEVaPEp48VP1heTVGsjHYfVK7CNp0yDtOvLBsvjAgWCORE=
=/iDp
-----END PGP SIGNATURE-----

Re: [Sshguard-users] SSHGuard 1.6.0 release announcement

[Mark F. <fe...@Fr...>]

On Sat, May 02, 2015 at 02:17:12PM -0500, Kevin Zheng wrote:
> 
> Greetings,
> 
> On behalf of the SSHGuard Team, it is my pleasure to announce the
> 1.6.0 release. This release is the first in the 1.6 branch and comes
> after more than four years of development.
> 

Fails to build with Clang due to missing include statement

hosts.c:47:15: error: use of undeclared identifier 'ADDRLEN'
    char addr[ADDRLEN];
              ^
hosts.c:234:22: error: use of undeclared identifier 'ADDRKIND_IPv4'
                case ADDRKIND_IPv4:
                     ^
hosts.c:238:22: error: use of undeclared identifier 'ADDRKIND_IPv6'
                case ADDRKIND_IPv6:
                     ^
3 errors generated.


See attached.


Thanks!

[Sshguard-users] SSHGuard 1.6.0 release announcement

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Greetings,

On behalf of the SSHGuard Team, it is my pleasure to announce the
1.6.0 release. This release is the first in the 1.6 branch and comes
after more than four years of development.

This release is tagged as 'v1.6.0' on Bitbucket [1] and source
tarballs are available from SourceForge [2]. Tarballs are available in
both `gzip` and `xz` formats. Checksums are signed with the same PGP
key as this announcement (0xC22E1090).

Notable changes in this release include:

- - Add rules for Postfix SASL login attempts
- - Add support for ISO 8601 timestamps (David Caldwell)
- - Add support for external commands run on firewall events (-e)
- - Blacklist file is now human-readable (Armando Miraglia)
- - Check tcpwrapper file permissions regardless of local umask
- - Detect additional pre-auth disconnects
- - Fix ipfw crash when loading an empty blacklist (Jin Choi)
- - Fix log parsing on days beginning with zero
- - Fix log polling on filesystems with many files (Johann H. Hauschild)
- - Fix matching for Cyrus IMAP login via SASL
- - Fix syslog format detection on hosts with undefined hostname
- - Match SSH login failures with "via" suffix
- - Remove broken kqueue(2) support
- - Tweak option names and help strings
- - Update SSH "Bad protocol" signature
- - Use case-insensitive "invalid user" signature
- - Wait for xtables lock when using iptables command (James Harris)

Please report any bugs, build failures, or OS-specific issues to the
mailing list or to the Bitbucket tracker [3].

Cheers,
Kevin Zheng

[1] https://bitbucket.org/sshguard/sshguard/commits/tag/v1.6.0
[2] https://sourceforge.net/projects/sshguard/files/sshguard/1.6.0/
[3] https://bitbucket.org/sshguard/sshguard/issues/

- -- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVRSK1AAoJEOrPD3bCLhCQvjAIANAD/Pfs3Etf2dwiztfsDUOo
VLdReSUj8B1wdxo58joIDde7muhdnfmRnrx9dwFZ9FScrQCVoYJUuBKkwy9tRBAy
hYjO/Zu6jmFaUvYmnAa2Z7accHTJZpnztd9vEsHK/xV9/4wLbnJi+biUoz0PY2AH
4YNNWh4EHbkOd4o/ZkDbmxf9MjXkmraPKSIFcklkyUydqbDI4QGodLZ0ZkvwoJPc
fY0lJGd/FonlfJOFdHahTR6xKwrNZ5XeRq8RgpX5AKt71VfRd6XMmMma/8HS9wCq
8IJFZogpWPO27X7seCb3WEsBRoUWP+hY+NVIxCmkBPQezphG0wfz6j9S9b9hB24=
=eBK+
-----END PGP SIGNATURE-----