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

Re: [Sshguard-users] Can't compile sshguard 1.2

[David H. <dho...@gm...>]

On Wed, Sep 24, 2008 at 11:53 AM, Andy Berkvam <abe...@be...> wrote:
>   I just noticed that sshguard-1.2 was released.  I downloaded it and was
> unable to compile it.  The error is:
>
> aclocal.m4:17: error: this file was generated for autoconf 2.61.
> You have another version of autoconf.  If you want to use that,
> you should regenerate the build system entirely.

The error message should probably say something along the lines of:

this file was generated for autoconf 2.61.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'.


In other words, just run autoreconf (part of the gnu autoconf
utilities package), then you can re-run your ./configure and make as
you normally would.   You may want to ensure you have at LEAST version
2.61 or higher of autoconf installed (autoconf --version).  If not, it
is time to upgrade your gnu build tools.


FYI, here is the autoreconf-2.62(1) man page header:

NAME
       autoreconf - Update generated configuration files

SYNOPSIS
       autoreconf-2.62 [OPTION] ... [DIRECTORY] ...

DESCRIPTION
       Run `autoconf-2.62' (and `autoheader-2.62', `aclocal', `automake-2.62',
       `autopoint' (formerly `gettextize'), and `libtoolize'  where  appropri-
       ate)  repeatedly  to  remake  the  GNU  Build System files in specified
       DIRECTORIES and their subdirectories (defaulting to `.').

       By default, it only remakes those  files  that  are  older  than  their
       sources.   If you install new versions of the GNU Build System, you can
       make `autoreconf-2.62' remake  all  of  the  files  by  giving  it  the
       `--force' option.


Good Luck.

--_Dave H

>
>   Has anyone else been able to compile sshguard-1.2?
>
>   Below is the output when I try to compile.  I included a "make
> distclean" and the configure just for good measure.
>
> Thanks,
>
> Andy
>
> $ make distclean
> Making distclean in man
> make[1]: Entering directory `/usr/local/src/sshguard-1.2/man'
> make[2]: Entering directory `/usr/local/src/sshguard-1.2'
> make[2]: Leaving directory `/usr/local/src/sshguard-1.2'
> test -z "" || rm -f
> rm -f Makefile
> make[1]: Leaving directory `/usr/local/src/sshguard-1.2/man'
> Making distclean in src
> make[1]: Entering directory `/usr/local/src/sshguard-1.2/src'
> make[2]: Entering directory `/usr/local/src/sshguard-1.2'
> make[2]: Leaving directory `/usr/local/src/sshguard-1.2'
> Making distclean in fwalls
> make[2]: Entering directory `/usr/local/src/sshguard-1.2/src/fwalls'
> make[3]: Entering directory `/usr/local/src/sshguard-1.2'
> make[3]: Leaving directory `/usr/local/src/sshguard-1.2'
> test -z "libfwall.a" || rm -f libfwall.a
> rm -f *.o
> rm -f *.tab.c
> test -z "" || rm -f
> rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
> rm -rf ./.deps
> rm -f Makefile
> make[2]: Leaving directory `/usr/local/src/sshguard-1.2/src/fwalls'
> Making distclean in .
> make[2]: Entering directory `/usr/local/src/sshguard-1.2/src'
> make[3]: Entering directory `/usr/local/src/sshguard-1.2'
> make[3]: Leaving directory `/usr/local/src/sshguard-1.2'
> test -z "sshguard" || rm -f sshguard
> rm -f *.o
> rm -f *.tab.c
> test -z "" || rm -f
> rm -f config.h stamp-h1
> rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
> make[2]: Leaving directory `/usr/local/src/sshguard-1.2/src'
> rm -rf ./.deps
> rm -f Makefile
> make[1]: Leaving directory `/usr/local/src/sshguard-1.2/src'
> Making distclean in .
> make[1]: Entering directory `/usr/local/src/sshguard-1.2'
> test -z "" || rm -f
> rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
> make[1]: Leaving directory `/usr/local/src/sshguard-1.2'
> rm -f config.status config.cache config.log configure.lineno
> config.status.lineno
> rm -f Makefile
> aberkvam@noir:/usr/local/src/sshguard-1.2$ ./configure
> --with-firewall=hosts
> checking for a BSD-compatible install... /usr/bin/ginstall -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for style of include used by make... GNU
> checking dependency style of gcc... gcc3
> 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
> checking for pthread_create in -lpthread... yes
> checking how to run the C preprocessor... gcc -E
> checking for grep that handles long lines and -e... /usr/bin/grep
> checking for egrep... /usr/bin/grep -E
> checking for ANSI C header files... yes
> checking for sys/wait.h that is POSIX.1 compatible... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking arpa/inet.h usability... yes
> checking arpa/inet.h presence... yes
> checking for arpa/inet.h... yes
> checking malloc.h usability... yes
> checking malloc.h presence... yes
> checking for malloc.h... yes
> checking netdb.h usability... yes
> checking netdb.h presence... yes
> checking for netdb.h... yes
> checking netinet/in.h usability... yes
> checking netinet/in.h presence... yes
> checking for netinet/in.h... yes
> checking for stdlib.h... (cached) yes
> checking for string.h... (cached) yes
> checking sys/socket.h usability... yes
> checking sys/socket.h presence... yes
> checking for sys/socket.h... yes
> checking syslog.h usability... yes
> checking syslog.h presence... yes
> checking for syslog.h... yes
> checking for unistd.h... (cached) yes
> checking for an ANSI C-conforming const... yes
> checking for inline... inline
> checking for off_t... yes
> checking for pid_t... yes
> checking for size_t... yes
> checking vfork.h usability... no
> checking vfork.h presence... no
> checking for vfork.h... no
> checking for fork... yes
> checking for vfork... yes
> checking for working fork... yes
> checking for working vfork... (cached) yes
> checking for stdlib.h... (cached) yes
> checking for GNU libc compatible malloc... yes
> checking return type of signal handlers... void
> checking for gethostbyname... yes
> checking for inet_ntoa... yes
> checking for strerror... yes
> checking for strstr... yes
> checking for strtol... yes
> configure: Using /etc/hosts.allow as hosts.allow file
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating man/Makefile
> config.status: creating src/Makefile
> config.status: creating src/fwalls/Makefile
> config.status: creating src/config.h
> config.status: executing depfiles commands
> $ make
> Making all in src
> make[1]: Entering directory `/usr/local/src/sshguard-1.2/src'
> make[2]: Entering directory `/usr/local/src/sshguard-1.2'
> make[2]: Leaving directory `/usr/local/src/sshguard-1.2'
> cd .. && /bin/sh /usr/local/src/sshguard-1.2/missing --run autoheader
> aclocal.m4:17: error: this file was generated for autoconf 2.61.
> You have another version of autoconf.  If you want to use that,
> you should regenerate the build system entirely.
> aclocal.m4:17: the top level
> autom4te: /usr/bin/m4 failed with exit status: 63
> autoheader: /usr/bin/autom4te failed with exit status: 63
> make[1]: *** [config.h.in] Error 1
> make[1]: Leaving directory `/usr/local/src/sshguard-1.2/src'
> make: *** [all-recursive] Error 1
> $
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

[Sshguard-users] Can't compile sshguard 1.2

[Andy B. <abe...@be...>]

   I just noticed that sshguard-1.2 was released.  I downloaded it and was 
unable to compile it.  The error is:

aclocal.m4:17: error: this file was generated for autoconf 2.61.
You have another version of autoconf.  If you want to use that,
you should regenerate the build system entirely.

   Has anyone else been able to compile sshguard-1.2?

   Below is the output when I try to compile.  I included a "make 
distclean" and the configure just for good measure.

Thanks,

Andy

$ make distclean
Making distclean in man
make[1]: Entering directory `/usr/local/src/sshguard-1.2/man'
make[2]: Entering directory `/usr/local/src/sshguard-1.2'
make[2]: Leaving directory `/usr/local/src/sshguard-1.2'
test -z "" || rm -f
rm -f Makefile
make[1]: Leaving directory `/usr/local/src/sshguard-1.2/man'
Making distclean in src
make[1]: Entering directory `/usr/local/src/sshguard-1.2/src'
make[2]: Entering directory `/usr/local/src/sshguard-1.2'
make[2]: Leaving directory `/usr/local/src/sshguard-1.2'
Making distclean in fwalls
make[2]: Entering directory `/usr/local/src/sshguard-1.2/src/fwalls'
make[3]: Entering directory `/usr/local/src/sshguard-1.2'
make[3]: Leaving directory `/usr/local/src/sshguard-1.2'
test -z "libfwall.a" || rm -f libfwall.a
rm -f *.o
rm -f *.tab.c
test -z "" || rm -f
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -rf ./.deps
rm -f Makefile
make[2]: Leaving directory `/usr/local/src/sshguard-1.2/src/fwalls'
Making distclean in .
make[2]: Entering directory `/usr/local/src/sshguard-1.2/src'
make[3]: Entering directory `/usr/local/src/sshguard-1.2'
make[3]: Leaving directory `/usr/local/src/sshguard-1.2'
test -z "sshguard" || rm -f sshguard
rm -f *.o
rm -f *.tab.c
test -z "" || rm -f
rm -f config.h stamp-h1
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
make[2]: Leaving directory `/usr/local/src/sshguard-1.2/src'
rm -rf ./.deps
rm -f Makefile
make[1]: Leaving directory `/usr/local/src/sshguard-1.2/src'
Making distclean in .
make[1]: Entering directory `/usr/local/src/sshguard-1.2'
test -z "" || rm -f
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
make[1]: Leaving directory `/usr/local/src/sshguard-1.2'
rm -f config.status config.cache config.log configure.lineno 
config.status.lineno
rm -f Makefile
aberkvam@noir:/usr/local/src/sshguard-1.2$ ./configure 
--with-firewall=hosts
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
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
checking for pthread_create in -lpthread... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for unistd.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for off_t... yes
checking for pid_t... yes
checking for size_t... yes
checking vfork.h usability... no
checking vfork.h presence... no
checking for vfork.h... no
checking for fork... yes
checking for vfork... yes
checking for working fork... yes
checking for working vfork... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking return type of signal handlers... void
checking for gethostbyname... yes
checking for inet_ntoa... yes
checking for strerror... yes
checking for strstr... yes
checking for strtol... yes
configure: Using /etc/hosts.allow as hosts.allow file
configure: creating ./config.status
config.status: creating Makefile
config.status: creating man/Makefile
config.status: creating src/Makefile
config.status: creating src/fwalls/Makefile
config.status: creating src/config.h
config.status: executing depfiles commands
$ make
Making all in src
make[1]: Entering directory `/usr/local/src/sshguard-1.2/src'
make[2]: Entering directory `/usr/local/src/sshguard-1.2'
make[2]: Leaving directory `/usr/local/src/sshguard-1.2'
cd .. && /bin/sh /usr/local/src/sshguard-1.2/missing --run autoheader
aclocal.m4:17: error: this file was generated for autoconf 2.61.
You have another version of autoconf.  If you want to use that,
you should regenerate the build system entirely.
aclocal.m4:17: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
autoheader: /usr/bin/autom4te failed with exit status: 63
make[1]: *** [config.h.in] Error 1
make[1]: Leaving directory `/usr/local/src/sshguard-1.2/src'
make: *** [all-recursive] Error 1
$

[Sshguard-users] sshguard 1.1 with IPFW (FreeBSD 7)

[David H. <dho...@gm...>]

This is a little stale, but it just bounced (probably due to the
sourceforge changes to move mailing lists around.  If it bounces
again, I will open a ticket with sf.

On Fri, Sep 19, 2008 at 2:56 AM, David Horn <dho...@gm...> wrote:
> A few minor bugs with sshguard 1.1 on FreeBSD-7-RELEASE:
>
> 1)  When used with IPv6, the program "/sbin/ip6fw" no longer exists.
> The ip6fw(8) packet filter has been removed in FreeBSD 7. Since
> ipfw(4) has gained IPv6 support, it should be used instead. Please
> note that some rules might need to be adjusted. (as per 7.0 Release
> notes)
>
> Of course the fix is fairly simple (in src/fwalls/ipfw.c, update the
> appropriate lines to ipfw instead of ip6fw #ifdef'd as appropriate for
>>= FreeBSD 7)  Is this something that should/will be fixed in the base
> source, or should we just fix in the FreeBSD ports system ?
>

Unfortunately, it looks like this issue (in ipfw.c)  still exists in
sshguard 1.2, and in SVN source.

I have attached my proposed patch to ipfw.c and configure.ac (tested
on 1.1 and 1.2) I also fixed an issue of exceeding the command length
for ipfw (60 total bytes is not enough with IPv6, so I upped it to 90
since the IPv6 addr alone can be 39 bytes as a string)

patch <patch
autoconf
./configure -with-firewall=ipfw
make

configure will autodetect if ip6fw exists, and if it does not, will
use ipfw for IPv6 instead.


> 2)  When used with FreeBSD 7 OpenSSH (using both sshd base 4.5p1, and
> ports version of sshd 5.0p1 has same results), the syslog entries
> apparently confuse sshguard when a valid username (e.g. root), but
> invalid password is used.
>

I looked at the source for sshguard 1.2, and it looks like the fix for
this new sshd PAM string is there.  Thanks Hans for the pointer to
https://sourceforge.net/project/shownotes.php?release_id=627038

There is still however a bug related to using the new PAM string in
1.2, and IPv6 addresses (in other words, it works for IPv4, but not
for IPv6.)  I tried to find the problem, but so far no luck tracking
it down.  The string in question is as follows:

Sep 19 17:47:05 dhorn-bsd sshd[72678]: error: PAM: authentication
error for root from 2001:4830:1698:0:21d:6eff:fed5:8cfa


> Example Syslog entries:
>
> Sep 19 01:28:35 dhorn-bsd sshd[32346]: error: PAM: authentication
> error for root from 192.168.0.109
> Sep 19 01:28:35 dhorn-bsd last message repeated 2 times
> Sep 19 01:28:36 dhorn-bsd sshd[32351]: error: PAM: authentication
> error for root from 192.168.0.109
> Sep 19 01:28:37 dhorn-bsd last message repeated 2 times
> Sep 19 01:28:38 dhorn-bsd sshd[32356]: error: PAM: authentication
> error for root from 192.168.0.109
> Sep 19 01:28:38 dhorn-bsd last message repeated 2 times
> Sep 19 01:28:39 dhorn-bsd sshd[32361]: error: PAM: authentication
> error for root from 192.168.0.109
> Sep 19 01:28:40 dhorn-bsd last message repeated 2 times
> Sep 19 01:28:41 dhorn-bsd sshd[32366]: error: PAM: authentication
> error for root from 192.168.0.109
>
>
> This does NOT flag sshguard at all right now.  I am just assuming that
> it is the authentication error string portion that is probably causing
> the issue (not matching in attack_parser/attack_scanner)
>
> I hacked up a version that supports this new error string (and it
> works fine), but I may not have done it in the most efficient way.  In
> any case, I have already reported the authentication error strings to
> the web site:   http://sshguard.sourceforge.net/newattackpatt.php
>
> Anyone else seeing these issues ?
>
> Apologies if this has been covered in the mailing list before, but I
> could not find the archives for this listserv.
>
> --Thanks!
>
> --_Dave Horn
>

[Sshguard-users] adding new patterns

[Sergey M. <se...@ci...>]

Hi!

I start using sshguard. It works and looks good. But I'd like to add 
more patterns to block. But looks like it's not so easy to do (lex/yacc).

May be it will better if rules will be dynamical, not compiled in? May 
be as regexps? I think it would decrease code too.

Thanks for your work.
-- 
Sem.

Re: [Sshguard-users] sshguard 1.1 with IPFW (FreeBSD 7)

[Hans F. N. <Han...@hi...>]

Have you read
https://sourceforge.net/project/shownotes.php?release_id=627038

Hans - who normally don't top-post.

* David Horn <dho...@gm...> [2008-09-19]:
> A few minor bugs with sshguard 1.1 on FreeBSD-7-RELEASE:
> 
> 1)  When used with IPv6, the program "/sbin/ip6fw" no longer exists.
> The ip6fw(8) packet filter has been removed in FreeBSD 7. Since
> ipfw(4) has gained IPv6 support, it should be used instead. Please
> note that some rules might need to be adjusted. (as per 7.0 Release
> notes)
> 
> Of course the fix is fairly simple (in src/fwalls/ipfw.c, update the
> appropriate lines to ipfw instead of ip6fw #ifdef'd as appropriate for
> >= FreeBSD 7)  Is this something that should/will be fixed in the base
> source, or should we just fix in the FreeBSD ports system ?
> 
> 2)  When used with FreeBSD 7 OpenSSH (using both sshd base 4.5p1, and
> ports version of sshd 5.0p1 has same results), the syslog entries
> apparently confuse sshguard when a valid username (e.g. root), but
> invalid password is used.
> 
> Example Syslog entries:
> 
> Sep 19 01:28:35 dhorn-bsd sshd[32346]: error: PAM: authentication
> error for root from 192.168.0.109
> Sep 19 01:28:35 dhorn-bsd last message repeated 2 times
> Sep 19 01:28:36 dhorn-bsd sshd[32351]: error: PAM: authentication
> error for root from 192.168.0.109
> Sep 19 01:28:37 dhorn-bsd last message repeated 2 times
> Sep 19 01:28:38 dhorn-bsd sshd[32356]: error: PAM: authentication
> error for root from 192.168.0.109
> Sep 19 01:28:38 dhorn-bsd last message repeated 2 times
> Sep 19 01:28:39 dhorn-bsd sshd[32361]: error: PAM: authentication
> error for root from 192.168.0.109
> Sep 19 01:28:40 dhorn-bsd last message repeated 2 times
> Sep 19 01:28:41 dhorn-bsd sshd[32366]: error: PAM: authentication
> error for root from 192.168.0.109
> 
> 
> This does NOT flag sshguard at all right now.  I am just assuming that
> it is the authentication error string portion that is probably causing
> the issue (not matching in attack_parser/attack_scanner)
> 
> I hacked up a version that supports this new error string (and it
> works fine), but I may not have done it in the most efficient way.  In
> any case, I have already reported the authentication error strings to
> the web site:   http://sshguard.sourceforge.net/newattackpatt.php
> 
> Anyone else seeing these issues ?
> 
> Apologies if this has been covered in the mailing list before, but I
> could not find the archives for this listserv.
> 
> --Thanks!
> 
> --_Dave Horn

[Sshguard-users] sshguard 1.1 with IPFW (FreeBSD 7)

[David H. <dho...@gm...>]

A few minor bugs with sshguard 1.1 on FreeBSD-7-RELEASE:

1)  When used with IPv6, the program "/sbin/ip6fw" no longer exists.
The ip6fw(8) packet filter has been removed in FreeBSD 7. Since
ipfw(4) has gained IPv6 support, it should be used instead. Please
note that some rules might need to be adjusted. (as per 7.0 Release
notes)

Of course the fix is fairly simple (in src/fwalls/ipfw.c, update the
appropriate lines to ipfw instead of ip6fw #ifdef'd as appropriate for
>= FreeBSD 7)  Is this something that should/will be fixed in the base
source, or should we just fix in the FreeBSD ports system ?

2)  When used with FreeBSD 7 OpenSSH (using both sshd base 4.5p1, and
ports version of sshd 5.0p1 has same results), the syslog entries
apparently confuse sshguard when a valid username (e.g. root), but
invalid password is used.

Example Syslog entries:

Sep 19 01:28:35 dhorn-bsd sshd[32346]: error: PAM: authentication
error for root from 192.168.0.109
Sep 19 01:28:35 dhorn-bsd last message repeated 2 times
Sep 19 01:28:36 dhorn-bsd sshd[32351]: error: PAM: authentication
error for root from 192.168.0.109
Sep 19 01:28:37 dhorn-bsd last message repeated 2 times
Sep 19 01:28:38 dhorn-bsd sshd[32356]: error: PAM: authentication
error for root from 192.168.0.109
Sep 19 01:28:38 dhorn-bsd last message repeated 2 times
Sep 19 01:28:39 dhorn-bsd sshd[32361]: error: PAM: authentication
error for root from 192.168.0.109
Sep 19 01:28:40 dhorn-bsd last message repeated 2 times
Sep 19 01:28:41 dhorn-bsd sshd[32366]: error: PAM: authentication
error for root from 192.168.0.109


This does NOT flag sshguard at all right now.  I am just assuming that
it is the authentication error string portion that is probably causing
the issue (not matching in attack_parser/attack_scanner)

I hacked up a version that supports this new error string (and it
works fine), but I may not have done it in the most efficient way.  In
any case, I have already reported the authentication error strings to
the web site:   http://sshguard.sourceforge.net/newattackpatt.php

Anyone else seeing these issues ?

Apologies if this has been covered in the mailing list before, but I
could not find the archives for this listserv.

--Thanks!

--_Dave Horn

Re: [Sshguard-users] sshguard doesn't add to pf sshguard table?

[Mij <mi...@bi...>]

Hello Kacper,

if you see the blocking/releasing messages, then the problem to debug  
is restricted
to how the blocking goes. You can always use the -d flag to inspect  
this in detail. In
your case, do:
1) temporarily disable sshguard from the system: killall -STP sshguard
2) run a debugging sshguard instance: sshguard -d
3) paste a "suspicious" entry line in its standard input (+ enter) 4  
times

sshguard shows a "Matched IP address 101.102.103.104" message after  
each paste,
and concludes something like:
"Blocking 101.102.103.104: 4 failures over 5 seconds.
Setting environment: SSHG_ADDR=  
101.102.103.104;SSHG_ADDRKIND=4;SSHG_SERVICE=100.
<MESSAGE>
Blocking command failed. Exited: -1"

If you get a failure, <MESSAGE> should point out what's wrong. If you  
can't solve on your own, or
you think that is a bug, please report the whole blocking message so  
we can find out.


On 9 Sep 2008, at 05:59, Kacper Wysocki wrote:

> Hello all,
> I've setup sshguard-pf 1.1 to run through syslog as recommended:
>
> # pkg_info | grep sshguard
> sshguard-pf-1.1_1   Protect hosts from brute force attacks against  
> ssh and othe
>
> # cat /etc/syslog.conf | grep sshguard
> auth.info;authpriv.info          |exec /usr/local/sbin/sshguard
>
> and it reports that it runs fine:
> # cat /var/log/auth.log | grep sshguard
> Sep  8 12:00:00 interzone sshguard[35281]: Started successfully
> [(a,p,s)=(4, 420, 1200)], now ready to scan.
>                           x
> Sep  8 12:20:36 interzone sshguard[35281]: Blocking XX.XX.XX.XX: 4
> failures over 6 seconds.
> Sep  8 12:38:36 interzone sshguard[35281]: Releasing XX.XX.XX.XX after
> 445 seconds.
> (..output cropped for brevity..)
>
> my pf.conf is set up to work with sshguard:
> # cat /etc/pf.conf | grep sshguard
> table <sshguard> persist
> block in quick on $ext_if proto tcp from <sshguard> to any port 22
> label "ssh bruteforce"
>
> yet when I look at what pf is doing, I see no addresses added to the
> sshguard table, nor do I see any incoming packets blocked through
> pflog:
> # pfctl -t sshguard -vTshow
> No ALTQ support in kernel
> ALTQ related functions disabled
> # tcpdump -n -e -ttt -i pflog0
> listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture  
> size 96 bytes
> (nothing)
>
> Now, I'm sure I've fumbled something - why aren't sshguard blocked IPs
> being added to the pf table?
>
> TIA,
> Kacper Wysocki
> -- 
> http://kacper.doesntexist.org
> Employ no technique to gain supreme enlightment.
> - Mar pa Chos kyi blos gros
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] sshguard doesn't add to pf sshguard table?

[Kacper W. <ka...@on...>]

Hello all,
I've setup sshguard-pf 1.1 to run through syslog as recommended:

# pkg_info | grep sshguard
sshguard-pf-1.1_1   Protect hosts from brute force attacks against ssh and othe

# cat /etc/syslog.conf | grep sshguard
auth.info;authpriv.info          |exec /usr/local/sbin/sshguard

and it reports that it runs fine:
# cat /var/log/auth.log | grep sshguard
Sep  8 12:00:00 interzone sshguard[35281]: Started successfully
[(a,p,s)=(4, 420, 1200)], now ready to scan.
                           x
Sep  8 12:20:36 interzone sshguard[35281]: Blocking XX.XX.XX.XX: 4
failures over 6 seconds.
Sep  8 12:38:36 interzone sshguard[35281]: Releasing XX.XX.XX.XX after
445 seconds.
(..output cropped for brevity..)

my pf.conf is set up to work with sshguard:
# cat /etc/pf.conf | grep sshguard
table <sshguard> persist
block in quick on $ext_if proto tcp from <sshguard> to any port 22
label "ssh bruteforce"

yet when I look at what pf is doing, I see no addresses added to the
sshguard table, nor do I see any incoming packets blocked through
pflog:
# pfctl -t sshguard -vTshow
No ALTQ support in kernel
ALTQ related functions disabled
# tcpdump -n -e -ttt -i pflog0
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes
(nothing)

Now, I'm sure I've fumbled something - why aren't sshguard blocked IPs
being added to the pf table?

TIA,
 Kacper Wysocki
-- 
http://kacper.doesntexist.org
Employ no technique to gain supreme enlightment.
- Mar pa Chos kyi blos gros

Re: [Sshguard-users] correction to pf config page.

[Mij <mi...@bi...>]

Thanks for reporting, I've fixed it.

michele


On Aug 28, 2008, at 01:28 , jim feldman wrote:

> From a FreeBSD 6.3 install.
>
> the doc (http://sshguard.sourceforge.net/doc/setup/blockingpf.html)  
> has the following line:
>
> block in quick on $ext_if from <sshguard> to any port 22 label "ssh  
> bruteforce"
> This throws an error from the pf parser without specifying the  
> protocols
>
> block in quick on $ext_if proto { tcp, udp } from <sshguard> to any  
> port 22 label "ssh bruteforce"
>
> I'm not sure if it's the same on other platforms
>
> thx
> jim
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] correction to pf config page.

[jim f. <mtn...@gm...>]

>From a FreeBSD 6.3 install.

the doc (http://sshguard.sourceforge.net/doc/setup/blockingpf.html) has the
following line:

block in quick on $ext_if from <sshguard> to any port 22 label "ssh bruteforce"

This throws an error from the pf parser without specifying the protocols

block in quick on $ext_if proto { tcp, udp } from <sshguard> to any port 22
label "ssh bruteforce"

I'm not sure if it's the same on other platforms

thx
jim

Re: [Sshguard-users] Help forwarding dovecot login failures to sshguard

[Mij <mi...@bi...>]

Hello Ron,

this pattern is not recognized by sshguard, thanks for reporting this.

In general, this is a trick for tracing these problems: to the question

1) "is sshguard receiving those log entries?" you can answer by
using tee: in syslog.conf, use something like

auth.info;authpriv.info;local0.info     |tee -a /tmp/mylogsniff | /usr/ 
local/sbin/sshguard

this logs everything will arrive to sshguard in /tmp/mylogsniff .

2) "does sshguard recognize pattern X?" you answer by running sshguard  
in debug mode
and pasting the line in its standard input. This is an example with  
the "null" backend firewall
(always executes "true").

$ sshguard -d
Run command "true": exited 0.
Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan.
(sshguard is now waiting for your input, paste here and enter)

if after the parsing dump you get "Matched IP address 1.2.3.4" then  
the entry matched, if
the entry is not recognized it does not appear.

In your case, I'd ask you to submit your pattern on

http://sshguard.sourceforge.net/newattackpatt.php

at a quick look, the reason for the dovecot entry not being spotted on  
your system is that
it's prepended by some PAM stuff.

michele


On Aug 8, 2008, at 03:40 , Ron Wilhoite wrote:

> I have sshguard installed on a freebsd server, and it is catching  
> failed
> ssh login attempts and working exactly as it should.
>
> Aug  7 21:16:18 bal sshguard[83262]: Started successfully [(a,p,s)=(4,
> 300, 1200)], now ready to scan.
> Aug  7 21:22:35 bal sshd[83361]: Invalid user bub from 72.185.201.149
> Aug  7 21:22:35 bal sshguard[83262]: Matched IP address 72.185.201.149
> Aug  7 21:22:39 bal sshd[83361]: error: PAM: authentication error for
> illegal user bub from cpe-72-185-201-149.tampabay.res.rr.com
> Aug  7 21:22:39 bal sshd[83361]: Failed keyboard-interactive/pam for
> invalid user bub from 72.185.201.149 port 60091 ssh2
> Aug  7 21:22:39 bal sshguard[83262]: Matched IP address 72.185.201.149
>
> But I can't seem to get failed pop and imap logins from dovecot
> forwarded to sshguard.
>
> From dovecot.conf:
> # Syslog facility to use if you're logging to syslog. Usually if you  
> don't
> # want to use "mail", you'll use local0..local7. Also other standard
> # facilities are supported.
> syslog_facility = local0
>
> From syslog.conf:
> auth.info;authpriv.info;local0.info     |exec /usr/local/sbin/sshguard
> -p 300
> local0.info		/var/log/dovecot.log
>
> The failed login attempts look like this from dovecot.log:
> Aug  7 21:17:14 bal dovecot: auth-worker(default):
> pam(bub,72.185.201.149): pam_authenticate() failed: authentication  
> error
> Aug  7 21:17:28 bal dovecot: pop3-login: Aborted login (auth failed, 1
> attempts): user=<bub>, method=PLAIN, rip=72.185.201.149,  
> lip=192.168.0.2
> Aug  7 21:19:01 bal dovecot: auth-worker(default):
> pam(bubble,127.0.0.1): pam_authenticate() failed: authentication error
> Aug  7 21:19:03 bal dovecot: imap-login: Aborted login (auth failed, 1
> attempts): user=<bubble>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1,
> secured
> Aug  7 21:19:49 bal dovecot: imap-login: Disconnected (auth failed, 0
> attempts): rip=72.185.201.149, lip=192.168.0.2
>
> Any suggestions on what to change or how to figure out why sshguard
> either isn't getting the dovecot information or isn't understanding  
> it?
>
> Thanks.
>
> Ron Wilhoite
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] Help forwarding dovecot login failures to sshguard

[Ron W. <ro...@ba...>]

I have sshguard installed on a freebsd server, and it is catching failed 
ssh login attempts and working exactly as it should.

Aug  7 21:16:18 bal sshguard[83262]: Started successfully [(a,p,s)=(4, 
300, 1200)], now ready to scan.
Aug  7 21:22:35 bal sshd[83361]: Invalid user bub from 72.185.201.149
Aug  7 21:22:35 bal sshguard[83262]: Matched IP address 72.185.201.149
Aug  7 21:22:39 bal sshd[83361]: error: PAM: authentication error for 
illegal user bub from cpe-72-185-201-149.tampabay.res.rr.com
Aug  7 21:22:39 bal sshd[83361]: Failed keyboard-interactive/pam for 
invalid user bub from 72.185.201.149 port 60091 ssh2
Aug  7 21:22:39 bal sshguard[83262]: Matched IP address 72.185.201.149

But I can't seem to get failed pop and imap logins from dovecot 
forwarded to sshguard.

 From dovecot.conf:
# Syslog facility to use if you're logging to syslog. Usually if you don't
# want to use "mail", you'll use local0..local7. Also other standard
# facilities are supported.
syslog_facility = local0

 From syslog.conf:
auth.info;authpriv.info;local0.info     |exec /usr/local/sbin/sshguard 
-p 300
local0.info		/var/log/dovecot.log

The failed login attempts look like this from dovecot.log:
Aug  7 21:17:14 bal dovecot: auth-worker(default): 
pam(bub,72.185.201.149): pam_authenticate() failed: authentication error
Aug  7 21:17:28 bal dovecot: pop3-login: Aborted login (auth failed, 1 
attempts): user=<bub>, method=PLAIN, rip=72.185.201.149, lip=192.168.0.2
Aug  7 21:19:01 bal dovecot: auth-worker(default): 
pam(bubble,127.0.0.1): pam_authenticate() failed: authentication error
Aug  7 21:19:03 bal dovecot: imap-login: Aborted login (auth failed, 1 
attempts): user=<bubble>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, 
secured
Aug  7 21:19:49 bal dovecot: imap-login: Disconnected (auth failed, 0 
attempts): rip=72.185.201.149, lip=192.168.0.2

Any suggestions on what to change or how to figure out why sshguard 
either isn't getting the dovecot information or isn't understanding it?

Thanks.

Ron Wilhoite

[Sshguard-users] sshguard 1.1

[Mij <mi...@bi...>]

Dear users,

sshguard version 1.1 has been released few days ago.

See
http://sshguard.sourceforge.net/
and
http://freshmeat.net/projects/sshguard/

michele

Re: [Sshguard-users] How do I use a custom backend .h, and other newbie Qs

[Mike B. <mi...@sk...>]

Yves Gu￿in wrote:
> Hello,
> 
> I read those articles, they are very interesting and there is a restriction about -blackhole (see man 8 route)
> 
>  Currently, routes with the RTF_BLACKHOLE flag set need to have the gate-
>      way set to an instance of the lo(4) driver, using the -iface option, for
>      the flag to have any effect; unless IP fast forwarding is enabled, in
>      which case the meaning of the flag will always be honored.
> 
> so may be you need the discard divice interface or the net.inet.ip.fastforwarding set to 1.

Not exactly; it just means that as of when that man page was written (in 
2005), there was a requirement that you do this:

'route add <destinationIP> <gatewayIP> -blackhole -iface'

rather than this:

'route add <destinationIP> <gatewayIP> -blackhole'

and you had to make sure gatewayIP was one assigned to a loopback interface.
By default, FreeBSD systems will have loopback interface device lo0 running 
and assigned to 127.0.0.1 / ::1.  So 127.0.0.1 is generally safe to use as the 
gateway IP.

The only question, then, is whether -iface (or -interface, same thing) is 
still required. It doesn't seem to be; I've been getting along fine without 
it, so I assume the bug is fixed.

Mike

Re: [Sshguard-users] How do I use a custom backend .h, and other newbie Qs

[Yves G. <yve...@ya...>]

Hello,

I read those articles, they are very interesting and there is a restriction about -blackhole (see man 8 route)

 Currently, routes with the RTF_BLACKHOLE flag set need to have the gate-
     way set to an instance of the lo(4) driver, using the -iface option, for
     the flag to have any effect; unless IP fast forwarding is enabled, in
     which case the meaning of the flag will always be honored.

so may be you need the discard divice interface or the net.inet.ip.fastforwarding set to 1.

Yves Guerin


--- En date de : Lun 7.7.08, Mike Brown <mi...@sk...> a écrit :
De: Mike Brown <mi...@sk...>
Objet: Re: [Sshguard-users] How do I use a custom backend .h, and other newbie Qs
À: ssh...@li...
Date: Lundi 7 Juillet 2008, 23h03

Mij wrote:
> > On my FreeBSD system, I've been using route(4) to manually
manipulate my 
> > routing tables, setting up blackhole routes for IPs from which
attacks 
> > originate. This works much more efficiently than ipfw, and very
thoroughly 
> > blocks all communication with the compromised hosts.
> 
> thanks, in general I appreciate contributions and customization so I look 
> fwd to include this into the trunk as soon as it becomes a convenient 
> solution.
> 
> In which circumstances does this work more efficiently than ipfw or
another 
> firewall? I consider quite negligible the load of rejecting connections: 
> what is the load at which you see this improvement?

Thanks for replying. You ask good questions.

I must admit, I've done no research of my own into this; I'm just
relying 
entirely on the info in this message:

http://lists.freebsd.org/pipermail/freebsd-questions/2005-July/092090.html

(quoting the OP): "This is executed in the IP stack and is faster than in
the 
firewall when you have over 20 of those special 'deny this IP address'
rules 
in the firewall."


A little Googling shows that someone else asked about the technique here (a 
couple years earlier):

http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00168.html

Opinions on efficiency differed but were inconclusive.
This reply offered another route-based approach: 
http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00225.html
(rather than routing to localhost with the 'blackhole' option, route to
a 
specially configured pseudo-device with the same functionality)

> A benefit that I see is that there is no dependency on specific firewalls 
> anymore. A drawback is that routing tables are not meant for this, so it 
> might be tricky to manage sshguard rules and avoid messing up with
"manual" 
> ones. If you're interested in contributing this, please have a look at
the 
> question of the portability across systems different from linux.

The solution seems to rely on features/efficiencies of FreeBSD, but I don't

know anything about Linux's TCP/IP stack, so maybe the situation there is 
similar. I'm not qualified to judge.

(I'll respond to the rest later)

Thanks again,
-Mike

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users


      _____________________________________________________________________________ 
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr

Re: [Sshguard-users] How do I use a custom backend .h, and other newbie Qs

[Mij <mi...@bi...>]

Mike's idea to use route may also be combined with the discard  
interface. This case distinguishes
for connections not to be reset back to the attacker (anything else?),  
although it is only available
in FreeBSD I guess.
Again, portability is a huge benefit as it abstracts away all the  
problems of dealing with different
distributions for different operating systems. This doesn't forbid to  
create a repository on the website
for collecting all the scripts contributed by the users and permit to  
possibly flag them by operating system.


On Jul 8, 2008, at 14:46 , Yves Guérin wrote:

> Hello,
>
> I use freebsd and ipfw, are we able to do the same thing with ipfw ?  
> I read the following articles as mention in the last e-mail (http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00225.html 
> )
>
> or may be just develop a custom bash script to do the same thing via  
> the syslogd facilities  (may I will try this way, stay tune)?
>
>
> Regards,
>
> Yves
> --- En date de : Mar 17.6.08, Mij <mi...@bi...> a écrit :
> De: Mij <mi...@bi...>
> Objet: Re: [Sshguard-users] How do I use a custom backend .h, and  
> other newbie Qs
> À: ssh...@li...
> Date: Mardi 17 Juin 2008, 1h46
>
> Hello Mike
>
> thanks for your post, please find the comments throughout your text
>
>
> On
>  Jun 12, 2008, at 7:32 AM, Mike Brown wrote:
>
> > On my FreeBSD system, I've been using route(4) to manually
> > manipulate my
> > routing tables, setting up blackhole routes for IPs from which  
> attacks
> > originate. This works much more efficiently than ipfw, and very
> > thoroughly
> > blocks all communication with the compromised hosts.
>
> thanks, in general I appreciate contributions and customization so I
> look fwd to
> include this into the trunk as soon as it becomes a convenient  
> solution.
>
> In which circumstances does this work more efficiently than ipfw or
> another firewall?
> I consider quite negligible the load of rejecting connections: what is
> the load at which
> you see this improvement?
>
> A benefit that I see is that there is no dependency on specific
> firewalls anymore. A
> drawback is that routing tables are not meant for this, so it might be
> tricky to
>  manage
> sshguard rules and avoid messing up with "manual" ones. If you're
>
> interested in
> contributing this, please have a look at the question of the
> portability across systems
> different from linux.
>
>
> > Rather than using my own custom, buggy script, I thought I'd try
> > sshguard with
> > a custom backend. I used sshguard_backendgen.sh to generate a .h  
> file.
> > I used the commands below for the block, release, and flush, and
> > left the
> > init and finalize commands empty:
> >
> > /sbin/route -q add $SSHG_ADDR 127.0.0.1 -blackhole
> > /sbin/route -q delete $SSHG_ADDR 127.0.0.1
> > netstat -r -n -W | head | tr -s ' ' '\t' | cut -f 3,1
> | rev | grep
> > '^B' | cut -f 2 | rev | xargs -n 1 -J % /sbin/route -q delete %
> > 127.0.0.1
> >
> > The flush command is a bit kludgy, obviously, and I haven't tested
> > it, but the
> > idea is to avoid using
>  'route flush', which is generally a bad
> idea,
> > and
> > rather just flush the blackholed routes. Unfortunately, the way I
> > have it, it
> > will flush _all_ blackholed routes, not just the ones sshguard
> > blocked. Is
> > there a way to get just the ones sshguard did? It'd be nice if it
> > could write
> > a single log somewhere, other than what shows up in my auth.log
> > (which gets
> > rotated).
>
> you're perfectly able to do it, just compose the "add" script
> with a
> further logging piece, eg (just guessing)
>
> /sbin/route -q add $SSHG_ADDR 127.0.0.1 -blackhole && echo $SSHG_ADDR
>  >> /var/db/sshguard-blocked.log
>
> then flush with
>
> cat /var/db/sshguard-blocked.log | while read $blocked ; do /sbin/
> route -q delete $blocked 127.0.0.1 ; done
>
>
> > Anyway, my main problem is that I don't know what to do with that .h
> > file
>  now.
> > How do I tell sshguard to use it? Sorry if this is a dumb question.
> > I couldn't
> > find the answer in the docs.
>
> This is not a dumb question :)
> the thing was meant to provide 90% of the work with 10% of the effort,
> so it works like this:
>
> 1) you generate your .h file
> 2) you ./configure --with-firewall=pf
> 	the script copies src/fwalls/command_pf.h to src/fwalls/command.h
> 	command.h is the file containing the commands of the backend
> 3) you just replace src/fwalls/command.h with your generated .h file
> 4) you proceed to compiling & installing
>
>
> > Also, a third question: do I put the -w option (for whitelisting) in
> > my
> > syslog.conf? That part wasn't clear either.
>
> -w and the other options of whitelisting
> ( http://sshguard.sourceforge.net/doc/usage/whitelisting.html ) are
> command line options
> that can be passed to the sshguard process no matter where
>  it is
> started from. Syslog is also fine,
> eg this line is fine:
>      auth.info;authpriv.info    |/usr/local/sbin/sshguard -w 1.2.3.4 -
> w 5.6.7.0/24
>
> bye
>
>
> >
> >
> > Thanks,
> > Mike
> >
> >  
> -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > Sshguard-users mailing list
> > Ssh...@li...
> > https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open
>  Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
> Envoyé avec Yahoo! Mail.
> Une boite mail plus intelligente.  
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08_______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] How do I use a custom backend .h, and other newbie Qs

[Mij <mi...@bi...>]

we can include this in sshguard, sure. I don't see any quantification  
of the gains though,
and all the statements of preferability lack a justification, as you  
report. Especially for this
scope, where the number of addresses that being blocked at any time is  
very low (5 to 10)
I think any weak performance improvement in the blocking backend  
transforms into an
invisible overall one. Keeping in mind the 80-20 rule, the 80% part is  
the parser in sshguard,
-- as it has to eat all the auth logging, while blockings are  
incidental -- and that is already
very fast.

As a general rule, if there is no significant performance improvement  
I prefer simplicity
of the code and ease of use to performance. Still, the ability not to  
depend on a firewall
(route is always present, the firewall is not) is attractive, so I  
think this can be an interesting
component provided that "route" is used in a syntax which is portable  
enough.


On Jul 7, 2008, at 20:03 , Mike Brown wrote:

> Mij wrote:
>>> On my FreeBSD system, I've been using route(4) to manually  
>>> manipulate my
>>> routing tables, setting up blackhole routes for IPs from which  
>>> attacks
>>> originate. This works much more efficiently than ipfw, and very  
>>> thoroughly
>>> blocks all communication with the compromised hosts.
>>
>> thanks, in general I appreciate contributions and customization so  
>> I look
>> fwd to include this into the trunk as soon as it becomes a convenient
>> solution.
>>
>> In which circumstances does this work more efficiently than ipfw or  
>> another
>> firewall? I consider quite negligible the load of rejecting  
>> connections:
>> what is the load at which you see this improvement?
>
> Thanks for replying. You ask good questions.
>
> I must admit, I've done no research of my own into this; I'm just  
> relying
> entirely on the info in this message:
>
> http://lists.freebsd.org/pipermail/freebsd-questions/2005-July/092090.html
>
> (quoting the OP): "This is executed in the IP stack and is faster  
> than in the
> firewall when you have over 20 of those special 'deny this IP  
> address' rules
> in the firewall."
>
>
> A little Googling shows that someone else asked about the technique  
> here (a
> couple years earlier):
>
> http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00168.html
>
> Opinions on efficiency differed but were inconclusive.
> This reply offered another route-based approach:
> http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00225.html
> (rather than routing to localhost with the 'blackhole' option, route  
> to a
> specially configured pseudo-device with the same functionality)
>
>> A benefit that I see is that there is no dependency on specific  
>> firewalls
>> anymore. A drawback is that routing tables are not meant for this,  
>> so it
>> might be tricky to manage sshguard rules and avoid messing up with  
>> "manual"
>> ones. If you're interested in contributing this, please have a look  
>> at the
>> question of the portability across systems different from linux.
>
> The solution seems to rely on features/efficiencies of FreeBSD, but  
> I don't
> know anything about Linux's TCP/IP stack, so maybe the situation  
> there is
> similar. I'm not qualified to judge.
>
> (I'll respond to the rest later)
>
> Thanks again,
> -Mike
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] possible bug

[Mij <mi...@bi...>]

Rob,

this behaviour is curious. Do you have iptables installed
debugging under version 1.0 is not trivial as in version 1.1:
you may want to try compiling v1.1beta4 (installing is not needed)
and then:

1) run it as
./sshguard -d

2) paste in its standard input the "Invalid user..." line

3) see what command is executed and derive why the shell returns that  
error



On Jul 3, 2008, at 21:07 , Rob Snyder wrote:

> using all the standard ubuntu 8.04 stuff
>
> i started with the syslog approach. it didnt work. then for  
> simplicity I tried the tail method and get the following:
> snyderra@rewop:~$ tail -n0 -F /var/log/auth.log |  /usr/sbin/ 
> sshguard /usr/sbin/sshguard: line 1: syntax error near unexpected  
> token `('
> /usr/sbin/sshguard: line 1: `Jul  3 14:32:43 rewop sshd[7376]:  
> pam_unix(sshd:session): session closed for user snyderra'
>
> here is a tail of /var/log/auth.log
>
> Jul  3 14:47:35 rewop sudo: pam_unix(sudo:session): session opened  
> for user root by snyderra(uid=0)
> Jul  3 14:47:35 rewop sudo: pam_unix(sudo:session): session closed  
> for user root
> Jul  3 14:48:00 rewop sshd[8127]: Invalid user bob from  
> 111.111.111.111
> Jul  3 14:48:41 rewop sudo: snyderra : TTY=pts/0 ; PWD=/home/ 
> snyderra ; USER=root ; COMMAND=/usr/bin/nano /etc/syslog.conf
> Jul  3 14:48:41 rewop sudo: pam_unix(sudo:session): session opened  
> for user root by snyderra(uid=0)
> Jul  3 14:48:41 rewop sudo: pam_unix(sudo:session): session closed  
> for user root
> Jul  3 14:53:40 rewop sudo: pam_smbpass(sudo:auth): unrecognized  
> option [missingok]
> Jul  3 14:53:40 rewop sudo: snyderra : TTY=pts/1 ; PWD=/home/ 
> snyderra ; USER=root ; COMMAND=/usr/bin/aptitude
> Jul  3 14:53:40 rewop sudo: pam_unix(sudo:session): session opened  
> for user root by snyderra(uid=0)
>
>
>
> any ideas? am i doing something wrong?
>
>
> thanks.
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08_______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] How do I use a custom backend .h, and other newbie Qs

[Mike B. <mi...@sk...>]

Yves Gu￿in wrote:
> I use freebsd and ipfw, are we able to do the same thing with ipfw ? 

ipfw is already supported by sshguard. Just install sshguard from the Ports 
Collection. When building the port, either set environment variable 
SSHGUARDFW=ipfw before running 'make', or do it on the command line like 'make 
SSHGUARDFW=ipfw'. This will cause --with-firewall=ipfw to be added to the 
configure arguments.

Re: [Sshguard-users] How do I use a custom backend .h, and other newbie Qs

[Yves G. <yve...@ya...>]

Hello,

I use freebsd and ipfw, are we able to do the same thing with ipfw ? I read the following articles as mention in the last e-mail (http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00225.html)

or may be just develop a custom bash script to do the same thing via the syslogd facilities  (may I will try this way, stay tune)?


Regards,

Yves
--- En date de : Mar 17.6.08, Mij <mi...@bi...> a écrit :
De: Mij <mi...@bi...>
Objet: Re: [Sshguard-users] How do I use a custom backend .h, and other newbie Qs
À: ssh...@li...
Date: Mardi 17 Juin 2008, 1h46

Hello Mike

thanks for your post, please find the comments throughout your text


On Jun 12, 2008, at 7:32 AM, Mike Brown wrote:

> On my FreeBSD system, I've been using route(4) to manually  
> manipulate my
> routing tables, setting up blackhole routes for IPs from which attacks
> originate. This works much more efficiently than ipfw, and very  
> thoroughly
> blocks all communication with the compromised hosts.

thanks, in general I appreciate contributions and customization so I  
look fwd to
include this into the trunk as soon as it becomes a convenient solution.

In which circumstances does this work more efficiently than ipfw or  
another firewall?
I consider quite negligible the load of rejecting connections: what is  
the load at which
you see this improvement?

A benefit that I see is that there is no dependency on specific  
firewalls anymore. A
drawback is that routing tables are not meant for this, so it might be  
tricky to manage
sshguard rules and avoid messing up with "manual" ones. If you're
 
interested in
contributing this, please have a look at the question of the  
portability across systems
different from linux.


> Rather than using my own custom, buggy script, I thought I'd try  
> sshguard with
> a custom backend. I used sshguard_backendgen.sh to generate a .h file.
> I used the commands below for the block, release, and flush, and  
> left the
> init and finalize commands empty:
>
> /sbin/route -q add $SSHG_ADDR 127.0.0.1 -blackhole
> /sbin/route -q delete $SSHG_ADDR 127.0.0.1
> netstat -r -n -W | head | tr -s ' ' '\t' | cut -f 3,1
| rev | grep  
> '^B' | cut -f 2 | rev | xargs -n 1 -J % /sbin/route -q delete %  
> 127.0.0.1
>
> The flush command is a bit kludgy, obviously, and I haven't tested  
> it, but the
> idea is to avoid using 'route flush', which is generally a bad
idea,  
> and
> rather just flush the blackholed routes. Unfortunately, the way I  
> have it, it
> will flush _all_ blackholed routes, not just the ones sshguard  
> blocked. Is
> there a way to get just the ones sshguard did? It'd be nice if it  
> could write
> a single log somewhere, other than what shows up in my auth.log  
> (which gets
> rotated).

you're perfectly able to do it, just compose the "add" script
with a  
further logging piece, eg (just guessing)

/sbin/route -q add $SSHG_ADDR 127.0.0.1 -blackhole && echo $SSHG_ADDR  
 >> /var/db/sshguard-blocked.log

then flush with

cat /var/db/sshguard-blocked.log | while read $blocked ; do /sbin/ 
route -q delete $blocked 127.0.0.1 ; done


> Anyway, my main problem is that I don't know what to do with that .h  
> file now.
> How do I tell sshguard to use it? Sorry if this is a dumb question.  
> I couldn't
> find the answer in the docs.

This is not a dumb question :)
the thing was meant to provide 90% of the work with 10% of the effort,  
so it works like this:

1) you generate your .h file
2) you ./configure --with-firewall=pf
	the script copies src/fwalls/command_pf.h to src/fwalls/command.h
	command.h is the file containing the commands of the backend
3) you just replace src/fwalls/command.h with your generated .h file
4) you proceed to compiling & installing


> Also, a third question: do I put the -w option (for whitelisting) in  
> my
> syslog.conf? That part wasn't clear either.

-w and the other options of whitelisting
( http://sshguard.sourceforge.net/doc/usage/whitelisting.html ) are  
command line options
that can be passed to the sshguard process no matter where it is  
started from. Syslog is also fine,
eg this line is fine:
     auth.info;authpriv.info    |/usr/local/sbin/sshguard -w 1.2.3.4 - 
w 5.6.7.0/24

bye


>
>
> Thanks,
> Mike
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users


      _____________________________________________________________________________ 
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr

Re: [Sshguard-users] How do I use a custom backend .h, and other newbie Qs

[Mike B. <mi...@sk...>]

Mij wrote:
> > On my FreeBSD system, I've been using route(4) to manually manipulate my 
> > routing tables, setting up blackhole routes for IPs from which attacks 
> > originate. This works much more efficiently than ipfw, and very thoroughly 
> > blocks all communication with the compromised hosts.
> 
> thanks, in general I appreciate contributions and customization so I look 
> fwd to include this into the trunk as soon as it becomes a convenient 
> solution.
> 
> In which circumstances does this work more efficiently than ipfw or another 
> firewall? I consider quite negligible the load of rejecting connections: 
> what is the load at which you see this improvement?

Thanks for replying. You ask good questions.

I must admit, I've done no research of my own into this; I'm just relying 
entirely on the info in this message:

http://lists.freebsd.org/pipermail/freebsd-questions/2005-July/092090.html

(quoting the OP): "This is executed in the IP stack and is faster than in the 
firewall when you have over 20 of those special 'deny this IP address' rules 
in the firewall."


A little Googling shows that someone else asked about the technique here (a 
couple years earlier):

http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00168.html

Opinions on efficiency differed but were inconclusive.
This reply offered another route-based approach: 
http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00225.html
(rather than routing to localhost with the 'blackhole' option, route to a 
specially configured pseudo-device with the same functionality)

> A benefit that I see is that there is no dependency on specific firewalls 
> anymore. A drawback is that routing tables are not meant for this, so it 
> might be tricky to manage sshguard rules and avoid messing up with "manual" 
> ones. If you're interested in contributing this, please have a look at the 
> question of the portability across systems different from linux.

The solution seems to rely on features/efficiencies of FreeBSD, but I don't 
know anything about Linux's TCP/IP stack, so maybe the situation there is 
similar. I'm not qualified to judge.

(I'll respond to the rest later)

Thanks again,
-Mike

[Sshguard-users] possible bug

[Rob S. <sny...@gm...>]

using all the standard ubuntu 8.04 stuff

i started with the syslog approach. it didnt work. then for simplicity I
tried the tail method and get the following:
snyderra@rewop:~$ tail -n0 -F /var/log/auth.log |  /usr/sbin/sshguard
/usr/sbin/sshguard: line 1: syntax error near unexpected token `('
/usr/sbin/sshguard: line 1: `Jul  3 14:32:43 rewop sshd[7376]:
pam_unix(sshd:session): session closed for user snyderra'

here is a tail of /var/log/auth.log

Jul  3 14:47:35 rewop sudo: pam_unix(sudo:session): session opened for user
root by snyderra(uid=0)
Jul  3 14:47:35 rewop sudo: pam_unix(sudo:session): session closed for user
root
Jul  3 14:48:00 rewop sshd[8127]: Invalid user bob from 111.111.111.111
Jul  3 14:48:41 rewop sudo: snyderra : TTY=pts/0 ; PWD=/home/snyderra ;
USER=root ; COMMAND=/usr/bin/nano /etc/syslog.conf
Jul  3 14:48:41 rewop sudo: pam_unix(sudo:session): session opened for user
root by snyderra(uid=0)
Jul  3 14:48:41 rewop sudo: pam_unix(sudo:session): session closed for user
root
Jul  3 14:53:40 rewop sudo: pam_smbpass(sudo:auth): unrecognized option
[missingok]
Jul  3 14:53:40 rewop sudo: snyderra : TTY=pts/1 ; PWD=/home/snyderra ;
USER=root ; COMMAND=/usr/bin/aptitude
Jul  3 14:53:40 rewop sudo: pam_unix(sudo:session): session opened for user
root by snyderra(uid=0)



any ideas? am i doing something wrong?


thanks.

Re: [Sshguard-users] Add a new custom rule

[Mij <mi...@bi...>]

Hello Colin,

thanks for being precise in this report. Please submit the same data  
as an
attack pattern proposal here

http://sshguard.sourceforge.net/newattackpatt.php

there is a chance that I will integrate support for this in the  
upcoming 1.1 stable.


On Jun 28, 2008, at 3:53 PM, Colin wrote:

> Hello,
> I am successfully using sshguard 1.0 on FreeBSD (6.x and 7.0) with  
> ipfw to
> block ssh attacks. On my setup sshguard parses the /var/log/auth.log
> messages which also logs failed FTP and POP attempts. Thus I would  
> like to
> use sshguard to block those attacks too (instead of using a new filter
> program). However I am not sure how to tackle this, could someone  
> point me
> to the necessary modifications or files to change? I suppose
> src/attack_scanner.l is a good start, but is it the only one? A simple
> working rule would be enough for my liking :o).
>
> Thanks,
> Cheers,
> Colin
>
> Typical POP attack:
>
> Jun 26 11:51:17 sleepyowl ipop3d[75832]: Login failed user=dave  
> auth=dave
> host=210.0.95.29.static.nexnet.net.au [210.0.95.29]
> Jun 26 11:51:17 sleepyowl ipop3d[75834]: Login failed user=data  
> auth=data
> host=210.0.95.29.static.nexnet.net.au [210.0.95.29]
> Jun 26 11:51:19 sleepyowl ipop3d[75836]: Login failed user=daustin
> auth=daustin host=210.0.95.29.static.nexnet.net.au [210.0.95.29]
>
>
> Typical FTP attack:
>
> Jun 26 14:04:15 sleepyowl ftpd[79060]: FTP LOGIN FAILED FROM
> 211.151.240.50, anne
> Jun 26 14:04:34 sleepyowl ftpd[79067]: FTP LOGIN FAILED FROM
> 211.151.240.50, anne
> Jun 26 14:04:53 sleepyowl ftpd[79069]: FTP LOGIN FAILED FROM
> 211.151.240.50, anne
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] Add a new custom rule

[Colin <in...@sl...>]

Hello,
I am successfully using sshguard 1.0 on FreeBSD (6.x and 7.0) with ipfw to
block ssh attacks. On my setup sshguard parses the /var/log/auth.log
messages which also logs failed FTP and POP attempts. Thus I would like to
use sshguard to block those attacks too (instead of using a new filter
program). However I am not sure how to tackle this, could someone point me
to the necessary modifications or files to change? I suppose
src/attack_scanner.l is a good start, but is it the only one? A simple
working rule would be enough for my liking :o).

Thanks,
Cheers,
Colin

Typical POP attack:

Jun 26 11:51:17 sleepyowl ipop3d[75832]: Login failed user=dave auth=dave
host=210.0.95.29.static.nexnet.net.au [210.0.95.29]
Jun 26 11:51:17 sleepyowl ipop3d[75834]: Login failed user=data auth=data
host=210.0.95.29.static.nexnet.net.au [210.0.95.29]
Jun 26 11:51:19 sleepyowl ipop3d[75836]: Login failed user=daustin
auth=daustin host=210.0.95.29.static.nexnet.net.au [210.0.95.29]


Typical FTP attack:

Jun 26 14:04:15 sleepyowl ftpd[79060]: FTP LOGIN FAILED FROM
211.151.240.50, anne
Jun 26 14:04:34 sleepyowl ftpd[79067]: FTP LOGIN FAILED FROM
211.151.240.50, anne
Jun 26 14:04:53 sleepyowl ftpd[79069]: FTP LOGIN FAILED FROM
211.151.240.50, anne

Re: [Sshguard-users] Waiting for sshguard 1.1 ...

[Hans F. N. <Han...@hi...>]

* Mij <mi...@bi...> [2008-06-21]:
> Hello Hans
> 
> great to hear such a proactive availability. I already have an
> about- to-be-released version of 1.1. It already fixes both
> problems, and several reports  and patches I had from users. I
> usually leave the code running for 3 weeks on a  production server
> before releasing, although I recently had two further submissions
> that  I still need to integrate.
> 
> The only item that I won't be able to take out of my todo list is a
> report from beginning of march. It is related to the IPF backend, I
> don't use it and I won't  have time to setup a test machine for
> that. If this may interest you, contribution for  that would be
> highly welcome (and of course properly reported).
> 
> In the next few weeks I'm going to release 1.1 anyway, don't despair :)

This is indeed great news - thank you very much. I'm sorry to say that
I can't help you with any IPF backend issues. (On my private servers I
use PF (FreeBSD) and at work we use iptables (CentOS).)

Hans

> On Jun 20, 2008, at 4:32 PM, Hans F. Nordhaug wrote:
> 
> > I would really like a release of 1.1. AFAIK there are at least two
> > problems with 1.0 - not blocking root and single letter usernames.
> > Are there any issues we can help with so 1.1 can be released?
> >
> > Regards,
> > Hans