Menu
▾
▴
sshguard-users — User questions and answers, bugs, and general support
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
(10) |
Apr
(7) |
May
(6) |
Jun
(13) |
Jul
(4) |
Aug
|
Sep
|
Oct
(17) |
Nov
(5) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
(7) |
Jul
(10) |
Aug
(4) |
Sep
(14) |
Oct
|
Nov
(1) |
Dec
(7) |
| 2009 |
Jan
(17) |
Feb
(20) |
Mar
(11) |
Apr
(14) |
May
(8) |
Jun
(3) |
Jul
(22) |
Aug
(9) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
(8) |
| 2010 |
Jan
(17) |
Feb
(9) |
Mar
(15) |
Apr
(24) |
May
(14) |
Jun
(1) |
Jul
(21) |
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
(6) |
Dec
(9) |
| 2011 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(4) |
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(2) |
Oct
(29) |
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(13) |
May
(4) |
Jun
(9) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(11) |
Dec
(4) |
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
(4) |
Apr
(13) |
May
(4) |
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
(3) |
Nov
(1) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(6) |
May
(8) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(14) |
Dec
(8) |
| 2015 |
Jan
(16) |
Feb
(30) |
Mar
(20) |
Apr
(5) |
May
(33) |
Jun
(11) |
Jul
(15) |
Aug
(91) |
Sep
(23) |
Oct
(10) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(22) |
Feb
(8) |
Mar
(6) |
Apr
(23) |
May
(38) |
Jun
(29) |
Jul
(43) |
Aug
(43) |
Sep
(18) |
Oct
(8) |
Nov
(2) |
Dec
(25) |
| 2017 |
Jan
(38) |
Feb
(3) |
Mar
(1) |
Apr
|
May
(18) |
Jun
(2) |
Jul
(16) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(14) |
| 2018 |
Jan
(15) |
Feb
(2) |
Mar
(3) |
Apr
(5) |
May
(8) |
Jun
(12) |
Jul
(19) |
Aug
(16) |
Sep
(8) |
Oct
(13) |
Nov
(15) |
Dec
(10) |
| 2019 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(5) |
Sep
(5) |
Oct
(12) |
Nov
(4) |
Dec
|
| 2020 |
Jan
(2) |
Feb
(6) |
Mar
|
Apr
|
May
(11) |
Jun
(1) |
Jul
(3) |
Aug
(22) |
Sep
(8) |
Oct
|
Nov
(2) |
Dec
|
| 2021 |
Jan
(7) |
Feb
|
Mar
(19) |
Apr
|
May
(10) |
Jun
(5) |
Jul
(7) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(10) |
Dec
(4) |
| 2022 |
Jan
(17) |
Feb
|
Mar
(7) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
(15) |
Apr
(8) |
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Willem J. W. <wj...@di...> - 2015-08-10 18:33:15
|
On 10-8-2015 20:28, Mark Felder wrote: > > > On Mon, Aug 10, 2015, at 12:05, Kevin Zheng wrote: >> Hi Mark, >> >> On 08/10/2015 11:11, Mark Felder wrote: >>> Kevin, is this the patch in question? >>> >>> https://bitbucket.org/sshguard/sshguard/commits/da561435cc29c22ee3b545b61e76aa318ec8fd0f/raw/ >> >> I've attached the patch that fixes 'ipfw' support. You can generate this >> yourself by running: >> >> $ git diff v1.6.1 origin/1.6 >> >> Most of this diff consists of deletions. You can safely ignore the hunk >> that deletes 'src/fwalls/ipfw.c' if you're putting this in ports. >> > > Do I understand the important parts of the patch correctly? > > 1) configure.ac copying command_ipfw.h to command.h > 2) creation of src/fwalls/command_ipfw.h > > > If so, I can easily fix the FreeBSD port if ipfw support is broken. One of the things I was looking at, is check if the type selection could be done thru 'make config'. That would make it just one port with many faces... Haven't gotten around to it, but I expect it not to be rocket science. --WjW |
|
From: Kevin Z. <kev...@gm...> - 2015-08-10 18:31:34
|
On 08/10/2015 13:28, Mark Felder wrote: > Do I understand the important parts of the patch correctly? > > 1) configure.ac copying command_ipfw.h to command.h > 2) creation of src/fwalls/command_ipfw.h Yes, that's all there is to it. Also note the change in Makefile.am that builds 'command.c' instead of 'ipfw.c'. Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: Mark F. <fe...@Fr...> - 2015-08-10 18:28:39
|
On Mon, Aug 10, 2015, at 12:05, Kevin Zheng wrote: > Hi Mark, > > On 08/10/2015 11:11, Mark Felder wrote: > > Kevin, is this the patch in question? > > > > https://bitbucket.org/sshguard/sshguard/commits/da561435cc29c22ee3b545b61e76aa318ec8fd0f/raw/ > > I've attached the patch that fixes 'ipfw' support. You can generate this > yourself by running: > > $ git diff v1.6.1 origin/1.6 > > Most of this diff consists of deletions. You can safely ignore the hunk > that deletes 'src/fwalls/ipfw.c' if you're putting this in ports. > Do I understand the important parts of the patch correctly? 1) configure.ac copying command_ipfw.h to command.h 2) creation of src/fwalls/command_ipfw.h If so, I can easily fix the FreeBSD port if ipfw support is broken. |
|
From: Kevin Z. <kev...@gm...> - 2015-08-10 18:27:25
|
On 08/10/2015 13:04, Willem Jan Withagen wrote: > 50000 is a very high number, while you would like to lock out bad guys > as early as possible.... > For me it is like the 6th or 7th rule in the firewall Right, the intention is to use a high number so that the rules set by SSHGuard do not override the users' own rules. > I would consider that a real bad design.... > IMHO Stuffing automagical things in a firewall is asking for a lot of > unexpected trouble... I share your concern, but it is partially mitigated by the fact that the rule number is so high; more likely than not it will not trample on the users' own rules. There is also precedent: since the 'ipfw' backend was conceived it has always added firewall rules automatically. But I'm open to suggestions on how I can do better. Thanks, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: Willem J. W. <wj...@di...> - 2015-08-10 18:05:36
|
On 10-8-2015 19:05, Kevin Zheng wrote: > Hi Mark, > > On 08/10/2015 11:11, Mark Felder wrote: >> Kevin, is this the patch in question? >> >> https://bitbucket.org/sshguard/sshguard/commits/da561435cc29c22ee3b545b61e76aa318ec8fd0f/raw/ > > I've attached the patch that fixes 'ipfw' support. You can generate this > yourself by running: > > $ git diff v1.6.1 origin/1.6 > > Most of this diff consists of deletions. You can safely ignore the hunk > that deletes 'src/fwalls/ipfw.c' if you're putting this in ports. > > Keep in mind that in order to use this, users will have to add a rule to > their 'ipfw' ruleset that blocks addresses from table 22: > > # ipfw add 50000 deny ip from table\(22\) to me 50000 is a very high number, while you would like to lock out bad guys as early as possible.... For me it is like the 6th or 7th rule in the firewall > This will likely change in 1.7, where I think I'll have sshguard insert > this rule automatically. I would consider that a real bad design.... IMHO Stuffing automagical things in a firewall is asking for a lot of unexpected trouble... --WjW |
|
From: Kevin Z. <kev...@gm...> - 2015-08-10 17:05:39
|
Hi Mark, On 08/10/2015 11:11, Mark Felder wrote: > Kevin, is this the patch in question? > > https://bitbucket.org/sshguard/sshguard/commits/da561435cc29c22ee3b545b61e76aa318ec8fd0f/raw/ I've attached the patch that fixes 'ipfw' support. You can generate this yourself by running: $ git diff v1.6.1 origin/1.6 Most of this diff consists of deletions. You can safely ignore the hunk that deletes 'src/fwalls/ipfw.c' if you're putting this in ports. Keep in mind that in order to use this, users will have to add a rule to their 'ipfw' ruleset that blocks addresses from table 22: # ipfw add 50000 deny ip from table\(22\) to me This will likely change in 1.7, where I think I'll have sshguard insert this rule automatically. Apologies for the trouble here. I don't think the release plan of backporting bug fixes is working too well; I'm thinking about making releases at regular intervals from 'master' instead. But that's a whole different topic. Thanks, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: Mark F. <fe...@Fr...> - 2015-08-10 16:27:40
|
On Tue, Aug 4, 2015, at 16:53, Kevin Zheng wrote: > On 08/04/2015 16:11, li...@la... wrote: > > I upgraded to 1.6.1. > > Looks like it crashes. > > This is a known issue that has been fixed in the development version, > but did not make it back to the 1.6 branch for the 1.6.1 release. > > If it's an option, consider compiling and running the development > version on Bitbucket (it's the version I run). Alternatively, I can > provide a patch against 1.6.1 that fixes the ipfw crash. > > (Since you're running FreeBSD, you might feel adventurous enough to try > out the shiny new Capsicum support!) > > Best, > Kevin Zheng > Kevin, is this the patch in question? https://bitbucket.org/sshguard/sshguard/commits/da561435cc29c22ee3b545b61e76aa318ec8fd0f/raw/ Thanks |
|
From: Kevin Z. <kev...@gm...> - 2015-08-06 21:46:50
|
On 08/06/2015 16:34, li...@la... wrote: > Compiled, installed, and banning bad boys. Well maybe.... > > This user was banned, but not for long: You probably didn't set up the firewall correctly. In the development version, you need to add a rule to block address from table '22'. I will document this soon, I promise. Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: <li...@la...> - 2015-08-06 21:35:08
|
Compiled, installed, and banning bad boys. Well maybe.... This user was banned, but not for long: Aug 6 21:20:24 theranch sshd[1494]: reverse mapping checking getaddrinfo for sianet.static.gvt.net.br [179.185.39.196] failed - POSSIBLE BREAK-IN ATTEMPT! Aug 6 21:20:24 theranch sshd[1494]: Invalid user testuser from 179.185.39.196 Aug 6 21:20:24 theranch sshd[1494]: input_userauth_request: invalid user testuser [preauth] Aug 6 21:20:25 theranch sshd[1494]: Received disconnect from 179.185.39.196: 11: Bye Bye [preauth] Aug 6 21:20:25 theranch sshguard[755]: blacklist: added 179.185.39.196 Aug 6 21:20:25 theranch sshguard[755]: Blocking 179.185.39.196:4 for >0secs: 40 danger in 4 attacks over 261 seconds (all: 40d in 1 abuses over 261s). Aug 6 21:24:42 theranch sshd[1504]: reverse mapping checking getaddrinfo for sianet.static.gvt.net.br [179.185.39.196] failed - POSSIBLE BREAK-IN ATTEMPT! Aug 6 21:24:42 theranch sshd[1504]: Invalid user students from 179.185.39.196 Aug 6 21:24:42 theranch sshd[1504]: input_userauth_request: invalid user students [preauth] Aug 6 21:24:42 theranch sshd[1504]: Received disconnect from 179.185.39.196: 11: Bye Bye [preauth] Aug 6 21:28:59 theranch sshd[1508]: reverse mapping checking getaddrinfo for sianet.static.gvt.net.br [179.185.39.196] failed - POSSIBLE BREAK-IN ATTEMPT! Aug 6 21:28:59 theranch sshd[1508]: Invalid user test from 179.185.39.196 Aug 6 21:28:59 theranch sshd[1508]: input_userauth_request: invalid user test [preauth] Aug 6 21:28:59 theranch sshd[1508]: Received disconnect from 179.185.39.196: 11: Bye Bye [preauth] Original Message From: Kevin Zheng Sent: Thursday, August 6, 2015 5:49 AM To: ssh...@li... Reply To: ssh...@li... Subject: Re: [Sshguard-users] Is sshguard working? On 08/06/2015 01:13, li...@la... wrote: > Ya know, there is much confusion on the interwebs regarding autotools: > > http://stackoverflow.com/questions/19263899/why-is-autoreconf-not-used-often > > So some things aren't so obvious. ;-) > > Easily over 95% of what I have compiled from source is simply > ./configure > make > make install So are the SSHGuard source distributions (tarballs). But since autotools are automatically generated, they don't belong in Git. You're expected to generate them yourself with `autoreconf -i`. Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 ------------------------------------------------------------------------------ _______________________________________________ Sshguard-users mailing list Ssh...@li... https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Kevin Z. <kev...@gm...> - 2015-08-06 12:49:34
|
On 08/06/2015 01:13, li...@la... wrote: > Ya know, there is much confusion on the interwebs regarding autotools: > > http://stackoverflow.com/questions/19263899/why-is-autoreconf-not-used-often > > So some things aren't so obvious. ;-) > > Easily over 95% of what I have compiled from source is simply > ./configure > make > make install So are the SSHGuard source distributions (tarballs). But since autotools are automatically generated, they don't belong in Git. You're expected to generate them yourself with `autoreconf -i`. Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: <li...@la...> - 2015-08-06 06:14:09
|
Ya know, there is much confusion on the interwebs regarding autotools: http://stackoverflow.com/questions/19263899/why-is-autoreconf-not-used-often So some things aren't so obvious. ;-) Easily over 95% of what I have compiled from source is simply ./configure make make install Original Message From: Kevin Zheng Sent: Wednesday, August 5, 2015 6:35 PM To: ssh...@li... Reply To: ssh...@li... Subject: Re: [Sshguard-users] Is sshguard working? On 08/05/2015 20:30, James Harris wrote: > It seems like build documentation is a place where we are lacking. Until > sshguard get picked up into distros that provide packaging I think we > need to see most will install from source. I have my own shell scripts > that build under fedora. Maybe we should be checking these scripts in? Documentation in general is a bit lacking -- sorry. I assume some things are obvious (e.g. 'autoreconf -i', running 'configure'), but it turns out that they aren't. The man page is up to date (yay!), but installation instructions in general (compiling, setting up the firewall) isn't. I also have to figure out how to ship it with the source distribution while keeping the website (even more out of date) up to date. Suggestions are welcome! Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 ------------------------------------------------------------------------------ _______________________________________________ Sshguard-users mailing list Ssh...@li... https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: James H. <jam...@gm...> - 2015-08-06 01:42:05
|
The updated man pages are great. Your doing a great job Kevin. Documentation is often a good entry point to start contributing to a project. So really this is for everyone else that uses sshguard. If you have figured out how to install and configure. Think about writing it up. On Aug 5, 2015 6:36 PM, "Kevin Zheng" <kev...@gm...> wrote: > On 08/05/2015 20:30, James Harris wrote: > > It seems like build documentation is a place where we are lacking. Until > > sshguard get picked up into distros that provide packaging I think we > > need to see most will install from source. I have my own shell scripts > > that build under fedora. Maybe we should be checking these scripts in? > > Documentation in general is a bit lacking -- sorry. I assume some things > are obvious (e.g. 'autoreconf -i', running 'configure'), but it turns > out that they aren't. > > The man page is up to date (yay!), but installation instructions in > general (compiling, setting up the firewall) isn't. I also have to > figure out how to ship it with the source distribution while keeping the > website (even more out of date) up to date. > > Suggestions are welcome! > > Best, > Kevin Zheng > > -- > Kevin Zheng > kev...@gm... | ke...@kd... | PGP: 0xC22E1090 > > > ------------------------------------------------------------------------------ > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users > |
|
From: Kevin Z. <kev...@gm...> - 2015-08-06 01:35:42
|
On 08/05/2015 20:30, James Harris wrote: > It seems like build documentation is a place where we are lacking. Until > sshguard get picked up into distros that provide packaging I think we > need to see most will install from source. I have my own shell scripts > that build under fedora. Maybe we should be checking these scripts in? Documentation in general is a bit lacking -- sorry. I assume some things are obvious (e.g. 'autoreconf -i', running 'configure'), but it turns out that they aren't. The man page is up to date (yay!), but installation instructions in general (compiling, setting up the firewall) isn't. I also have to figure out how to ship it with the source distribution while keeping the website (even more out of date) up to date. Suggestions are welcome! Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: James H. <jam...@gm...> - 2015-08-06 01:30:49
|
It seems like build documentation is a place where we are lacking. Until sshguard get picked up into distros that provide packaging I think we need to see most will install from source. I have my own shell scripts that build under fedora. Maybe we should be checking these scripts in? On Aug 5, 2015 6:18 PM, "Kevin Zheng" <kev...@gm...> wrote: > On 08/05/2015 19:39, li...@la... wrote: > > > > # cd sshguard-sshguard-3216aaa2ba58/ > > # aclocal > > # autoconf > > # automake -a > > configure.ac:129: installing './compile' > > configure.ac:6: installing './install-sh' > > configure.ac:6: installing './missing' > > configure.ac:5: error: required file 'src/config.h.in' not found > > Try `autoreconf -i`. It's one command that'll do it all (correctly). > > Best, > Kevin Zheng > > -- > Kevin Zheng > kev...@gm... | ke...@kd... | PGP: 0xC22E1090 > > > ------------------------------------------------------------------------------ > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users > |
|
From: Kevin Z. <kev...@gm...> - 2015-08-06 01:17:40
|
On 08/05/2015 19:39, li...@la... wrote: > > # cd sshguard-sshguard-3216aaa2ba58/ > # aclocal > # autoconf > # automake -a > configure.ac:129: installing './compile' > configure.ac:6: installing './install-sh' > configure.ac:6: installing './missing' > configure.ac:5: error: required file 'src/config.h.in' not found Try `autoreconf -i`. It's one command that'll do it all (correctly). Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: <li...@la...> - 2015-08-06 00:42:41
|
Sorry my reply escaped before I could add comments. Is my use of auto tools correct? It has one error. |
|
From: <li...@la...> - 2015-08-06 00:39:37
|
# cd sshguard-sshguard-3216aaa2ba58/ # aclocal # autoconf # automake -a configure.ac:129: installing './compile' configure.ac:6: installing './install-sh' configure.ac:6: installing './missing' configure.ac:5: error: required file 'src/config.h.in' not found # ./configure --with-firewall=ipfw checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking for ipfw... no configure: WARNING: ipfw program not in path! Using /sbin as default unless --with-ipfw specified ## -------------- ## ## Program Checks ## ## -------------- ## checking for gawk... (cached) nawk checking for gcc... no checking for cc... 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... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ranlib... ranlib checking for bison... no checking for byacc... byacc 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... cc -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... no checking malloc.h presence... no checking for malloc.h... no 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 getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking for off_t... yes checking for pid_t... yes checking for size_t... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for C/C++ restrict keyword... __restrict checking whether __SUNPRO_C is declared... no ## ----------------- ## ## Library Functions ## ## ----------------- ## 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 for gethostbyname... yes checking for inet_ntoa... yes checking for strerror... yes checking for strstr... yes checking for strtol... yes checking for library containing socket... none required checking for library containing gethostbyname... none required checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating man/Makefile config.status: error: cannot find input file: `src/Makefile.in' Original Message From: Kevin Zheng Sent: Tuesday, August 4, 2015 2:53 PM To: ssh...@li... Reply To: ssh...@li... Subject: Re: [Sshguard-users] Is sshguard working? On 08/04/2015 16:11, li...@la... wrote: > I upgraded to 1.6.1. > Looks like it crashes. This is a known issue that has been fixed in the development version, but did not make it back to the 1.6 branch for the 1.6.1 release. If it's an option, consider compiling and running the development version on Bitbucket (it's the version I run). Alternatively, I can provide a patch against 1.6.1 that fixes the ipfw crash. (Since you're running FreeBSD, you might feel adventurous enough to try out the shiny new Capsicum support!) Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 ------------------------------------------------------------------------------ _______________________________________________ Sshguard-users mailing list Ssh...@li... https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Willem J. W. <wj...@di...> - 2015-08-05 15:46:42
|
On 5-8-2015 15:16, Alastair Hogge wrote: > On 2015-08-02 Sun 13:36:37 -0500 Gregory Putrich, wrote: >> For IPFW, did the change to use a table instead of individual rules make >> it in? I’ve installed 1.6.1 on FreeBSD from the ports (sshguard-ipfw) and >> its still creating individual rules, and also it crashes on start if the >> blacklist is larger than 4 lines or so. > > If you want to make use of a table id in ifpw follow these steps below: > > # pkg install security/sshguard-null > # sysrc sshguard_flags="-e /usr/local/sbin/sshguard-null" > > $ cat /usr/local/sbin/sshguard-null > > #!/bin/sh > # Source: > # http://sourceforge.net/p/sshguard/mailman/message/34151601/ > > fwcmd="/sbin/ipfw" > table_id="sshguard" > print_debug="0" > > fwcmd_debug() { > if [ ${print_debug} -gt 0 ]; then > /usr/bin/logger -i -p local0.notice -t sshguard-null ${@} > fi > } > > fwcmd_debug "${0}: Incoming sshguard(8) action" > > case ${SSHG_ACTION} in > init) > # create table? > fwcmd_debug "${SSHG_ACTION}" > ;; > fin) > fwcmd_debug "${fwcmd} table ${table_id} flush" > ${fwcmd} table ${table_id} flush > ;; > block) > fwcmd_debug "${fwcmd} table ${table_id} add ${SSHG_ADDR}" > ${fwcmd} table ${table_id} add ${SSHG_ADDR} > ;; > block_list) > for a in `echo ${SSHG_ADDR} | sed 's/,/ /g'` ; do > fwcmd_debug "${fwcmd} table ${table_id} add ${a}" > ${fwcmd} table ${table_id} add ${a} > done > ;; > release) > fwcmd_debug "${fwcmd} table ${table_id} delete ${SSHG_ADDR}" > ${fwcmd} table ${table_id} delete ${SSHG_ADDR} > ;; > flush) > fwcmd_debug "${fwcmd} table ${table_id} flush" > ${fwcmd} table ${table_id} flush > ;; > *) > fwcmd_debug "${SSHG_ACTION} unsupported" > ;; > esac > > exit 0 > > I have been using this method on FreeBSD-11-CURRENT for >3 weeks now & have > not observed any crashes. sshguard & ipfw continue to function as expected. Right, Haven't looked into the new stuff due to $work, but that is the way I'm still doing it. More or less based on KISS. (and I think shell-scripts are KISS :) Funny thing I see in your script is that your table ID is: sshguard. So you are already using one of the features I saw that was in the new IPFW code: IDs don't have to be numbers any longer. Now the fun part is that you can reload your firewall without erasing the tables... So the blacklisting is kept in order. If you'd want to remove all blacklisting for testing purposes: ipfw table all flush is your friend. Need to know if a customer landed himself in the blacklist: ipfw table all list | grep ip-nr and so on, and so on. And with alphanumeric table names things get even more fun... I also load table from: swatch for watching httpd/mail/... log files for scriptkidies portsentry for catching people trying portscanning etc... Everything could be improved upon al lot, but it gets most obnoxous tries down. So otehr things have a bigger chance of standing out. --WjW Now for the counterpart: Here is the top part of my ipfw config.... ---- 01000 count ip from any to any # delete (by hand) major blocks that are harasing me # They could also go into a table... 01010 deny ip from 82.75.147.236,77.249.92.231,178.170.161.34,60.208.0.0/13,61.182.0.0/15,116.224.0.0/12,218.108.0.0/15,1.93.0.0/16,222.186.0.0/16,222.240.128.0/17,46.105.102.221 to any 01020 deny ip from any to 82.75.147.236,77.249.92.231,178.170.161.34,60.208.0.0/13,61.182.0.0/15,116.224.0.0/12,218.108.0.0/15,1.93.0.0/16,222.186.0.0/16,222.240.128.0/17,46.105.102.221 # skip over the blocking rules for hackers/spammers for my trusted # IPs.... could also go into a table .... 01030 skipto 2000 ip from ${trustedipnrs} to any 01040 deny ip from table(10) to any 01050 deny ip from table(21) to any 01060 deny ip from table(22) to any 01070 deny ip from table(25) to any 01080 deny ip from table(26) to any 01090 deny ip from table(40) to any 01100 deny ip from table(41) to any 01110 deny ip from table(42) to any 01120 deny ip from table(43) to any 01130 deny ip from table(50) to any 01140 deny ip from table(53) to any 01150 deny ip from table(54) to any 01160 deny ip from table(55) to any 01170 deny ip from table(56) to any 01180 deny ip from table(57) to any 01190 deny ip from table(58) to any 01200 deny ip from table(59) to any 01210 deny ip from table(60) to any 01220 deny ip from table(70) to any 01230 deny ip from table(75) to any 01240 deny ip from table(80) to any 01250 deny ip from table(81) to any 01260 deny ip from table(86) to any # landingpoint if not on the spammerlists 02000 count ip from any to any ------ |
|
From: Greg P. <gr...@n0...> - 2015-08-05 13:30:40
|
Alastair Hogge said: > On 2015-08-02 Sun 13:36:37 -0500 Gregory Putrich, wrote: > > For IPFW, did the change to use a table instead of individual rules make > > it in? I???ve installed 1.6.1 on FreeBSD from the ports (sshguard-ipfw) and > > its still creating individual rules, and also it crashes on start if the > > blacklist is larger than 4 lines or so. > > If you want to make use of a table id in ifpw follow these steps below: > <snip> > > I have been using this method on FreeBSD-11-CURRENT for >3 weeks now & have > not observed any crashes. sshguard & ipfw continue to function as expected. Thanks. I had sent this email from the wrong address and thought it got funnelled off to oblivion since the addr isn't subscribed to the mailing list. Sent another email from the correct address and Kevin answered it (will be coming in 1.6.2). Was a bit surprised when I saw this one show up... Oops. Back in June (?) I had compiled it from his branch and it worked absolutely great. No crashes and kept things tidy. Kept it running until I upgraded to 1.6.1 last weekend. I could do that again, but may just wait until 1.6.2 comes out, if it won't be in the distant future. It is blocking fine, just a matter of tidiness & restartability. Now that I think about it, I just may install it again on one of my servers. Greg |
|
From: Alastair H. <ag...@fa...> - 2015-08-05 13:16:31
|
On 2015-08-02 Sun 13:36:37 -0500 Gregory Putrich, wrote: > For IPFW, did the change to use a table instead of individual rules make > it in? I’ve installed 1.6.1 on FreeBSD from the ports (sshguard-ipfw) and > its still creating individual rules, and also it crashes on start if the > blacklist is larger than 4 lines or so. If you want to make use of a table id in ifpw follow these steps below: # pkg install security/sshguard-null # sysrc sshguard_flags="-e /usr/local/sbin/sshguard-null" $ cat /usr/local/sbin/sshguard-null #!/bin/sh # Source: # http://sourceforge.net/p/sshguard/mailman/message/34151601/ fwcmd="/sbin/ipfw" table_id="sshguard" print_debug="0" fwcmd_debug() { if [ ${print_debug} -gt 0 ]; then /usr/bin/logger -i -p local0.notice -t sshguard-null ${@} fi } fwcmd_debug "${0}: Incoming sshguard(8) action" case ${SSHG_ACTION} in init) # create table? fwcmd_debug "${SSHG_ACTION}" ;; fin) fwcmd_debug "${fwcmd} table ${table_id} flush" ${fwcmd} table ${table_id} flush ;; block) fwcmd_debug "${fwcmd} table ${table_id} add ${SSHG_ADDR}" ${fwcmd} table ${table_id} add ${SSHG_ADDR} ;; block_list) for a in `echo ${SSHG_ADDR} | sed 's/,/ /g'` ; do fwcmd_debug "${fwcmd} table ${table_id} add ${a}" ${fwcmd} table ${table_id} add ${a} done ;; release) fwcmd_debug "${fwcmd} table ${table_id} delete ${SSHG_ADDR}" ${fwcmd} table ${table_id} delete ${SSHG_ADDR} ;; flush) fwcmd_debug "${fwcmd} table ${table_id} flush" ${fwcmd} table ${table_id} flush ;; *) fwcmd_debug "${SSHG_ACTION} unsupported" ;; esac exit 0 I have been using this method on FreeBSD-11-CURRENT for >3 weeks now & have not observed any crashes. sshguard & ipfw continue to function as expected. > Thanks, > Greg > > On Jul 31, 2015, at 20:07 , Kevin Zheng <kev...@gm...> wrote: > > > > Signed PGP part > > Greetings, > > > > I am pleased to announce the release of SSHGuard 1.6.1 [1]. This > > release is primarily a bugfix release that fixes a few late-breaking > > issues from 1.6.0 while incorporating a few feature improvements. This > > release was slightly delayed by a recent SourceForge outage. > > > > Changes in this release include: > > > > - Accept "Received disconnect" with optional prefix > > - Add support for socklog entries > > - Fix 'ipfw-rules-range' option in configure script > > - Fix build for 'ipfw' and 'hosts' backends > > - Fix integer comparisons of different types > > - Match attacks when syslog debugging is enabled > > > > Many thanks to the contributors who reported issues or sent in patches > > to fix them. Special thanks to the FreeBSD community for reporting and > > fixing a number of problems amended in this release. > > > > As usual, please report any bugs, build failures, or other issues to > > the mailing list or the Bitbucket tracker [2]. > > > > Very best, > > Kevin Zheng > > > > [1] https://sourceforge.net/projects/sshguard/files/sshguard/1.6.1/ > > [2] https://bitbucket.org/sshguard/sshguard/issues/ > > > > -- > > Kevin Zheng > > kev...@gm... | ke...@kd... | PGP: 0xC22E1090 > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Sshguard-users mailing list > > Ssh...@li... > > https://lists.sourceforge.net/lists/listinfo/sshguard-users > > ------------------------------------------------------------------------------ > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users -- What good is having someone who can walk on water if you don't follow in his footsteps? |
|
From: Kevin Z. <kev...@gm...> - 2015-08-04 21:53:36
|
On 08/04/2015 16:11, li...@la... wrote: > I upgraded to 1.6.1. > Looks like it crashes. This is a known issue that has been fixed in the development version, but did not make it back to the 1.6 branch for the 1.6.1 release. If it's an option, consider compiling and running the development version on Bitbucket (it's the version I run). Alternatively, I can provide a patch against 1.6.1 that fixes the ipfw crash. (Since you're running FreeBSD, you might feel adventurous enough to try out the shiny new Capsicum support!) Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: <li...@la...> - 2015-08-04 21:11:26
|
I upgraded to 1.6.1. Looks like it crashes. Aug 4 20:54:13 theranch pkg: sshguard-ipfw upgraded: 1.6.0_1 -> 1.6.1 Aug 4 19:41:03 theranch sshguard[18636]: Started with danger threshold=40 ; minimum block=420 seconds Aug 4 19:41:12 theranch sshguard[18636]: Got exit signal, flushing blocked addresses and exiting... Original Message From: Kevin Zheng Sent: Monday, August 3, 2015 6:25 PM To: ssh...@li... Reply To: ssh...@li... Subject: Re: [Sshguard-users] Is sshguard working? On 08/03/2015 19:41, James Harris wrote: > If sshguard is running on this system shouldn't we see the block rules > in this list ? To have them actually block the allow port 22 rule (and > maybe the other allow rules) need to move but shouldn't we see the rules > that have been added? Yes, we *should* see the block rules around rule 55000. Any idea what version of SSHGuard is being used? The one from FreeBSD ports? Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 ------------------------------------------------------------------------------ _______________________________________________ Sshguard-users mailing list Ssh...@li... https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: <li...@la...> - 2015-08-04 19:44:24
|
Sshguard -v indicates 1.6.0 I used the version with the suffix -ipfw. Original Message From: Kevin Zheng Sent: Monday, August 3, 2015 6:25 PM To: ssh...@li... Reply To: ssh...@li... Subject: Re: [Sshguard-users] Is sshguard working? On 08/03/2015 19:41, James Harris wrote: > If sshguard is running on this system shouldn't we see the block rules > in this list ? To have them actually block the allow port 22 rule (and > maybe the other allow rules) need to move but shouldn't we see the rules > that have been added? Yes, we *should* see the block rules around rule 55000. Any idea what version of SSHGuard is being used? The one from FreeBSD ports? Best, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 ------------------------------------------------------------------------------ _______________________________________________ Sshguard-users mailing list Ssh...@li... https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Willem J. W. <wj...@di...> - 2015-08-04 12:04:35
|
On 4-8-2015 03:31, Kevin Zheng wrote: > On 08/03/2015 03:36, Willem Jan Withagen wrote: >> I added some code on FreeBSD to libssh to make some errors actually log >> the the ip-number, because this is usualy abuse as well.... >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202055 >> >> And it changes the log like: >> fatal: Read from socket failed: Connection reset by peer [preauth] >> >> Which is rather useless for tools like sshguard and/or fail2ban >> >> But this patch changes this info to: >> Aug 2 19:37:32 zfs sshd[19444]: Read from socket failed: 218.2.22.36 >> [preauth] >> Aug 2 19:37:32 zfs sshd[19444]:fatal: Read from socket failed: >> Connection reset by peer [preauth] > > This looks like a patch against OpenSSH. > >> But then again this needs to be picked upt by sshguard with an extra >> parser rule... > > It'll be a while before this change makes it upstream, and it might > change before it gets there, so I'll hold off on this change. I checked the upstream and what I see there is a completely new setup at least with regards to logging. So you actually need to install and run it to get a grip for how things are going to look in the upcoming releases.... I'm going to install openssh-portable-devel on one of my servers, and see what is going on there.... --WjW |
|
From: Willem J. W. <wj...@di...> - 2015-08-04 10:22:08
|
On 4-8-2015 03:31, Kevin Zheng wrote: > On 08/03/2015 03:36, Willem Jan Withagen wrote: >> I added some code on FreeBSD to libssh to make some errors actually log >> the the ip-number, because this is usualy abuse as well.... >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202055 >> >> And it changes the log like: >> fatal: Read from socket failed: Connection reset by peer [preauth] >> >> Which is rather useless for tools like sshguard and/or fail2ban >> >> But this patch changes this info to: >> Aug 2 19:37:32 zfs sshd[19444]: Read from socket failed: 218.2.22.36 >> [preauth] >> Aug 2 19:37:32 zfs sshd[19444]:fatal: Read from socket failed: >> Connection reset by peer [preauth] > > This looks like a patch against OpenSSH. Eh, if that is what FreeBSD uses, then yes. > >> But then again this needs to be picked upt by sshguard with an extra >> parser rule... > > It'll be a while before this change makes it upstream, and it might > change before it gets there, so I'll hold off on this change. I understand.... But it is one of the remaining messages where info is missed to act upon. I have not yet received message from the bugs maintainer. --WjW |
2 messages has been excluded from this view by a project administrator.
