You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
(9) |
Apr
(2) |
May
(3) |
Jun
(15) |
Jul
(1) |
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(4) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2016 |
Jan
(10) |
Feb
|
Mar
|
Apr
(2) |
May
(3) |
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2017 |
Jan
(6) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
|
Feb
|
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Kevin Z. <kev...@gm...> - 2017-01-19 16:44:49
|
On 01/19/17 07:03, William Woodruff wrote: > I'm a maintainer with Homebrew, and I have some questions about the > upcoming 2.0 release: > > * Will `sshguard-setup` be installed with `sshguard`? No. It was originally planned but wasn't going to make 2.0.0. The error message no longer mentions 'sshguard-setup'. > * Will a default configuration akin to 1.7.1's functionality be > available? Not decided. Currently, all backends are built and installed and the backend is selected at runtime using the configuration file (the BACKEND variable, a path to a sshg-fw executable). One idea would be for packagers to ship the default configuration file with the BACKEND and other defaults set appropriately (e.g. LOGREADER on macOS 10.12). But I want to hear suggestions from package maintainers. > We accidentally packaged your (experimental) 1.99 release a while ago, > but came across these issues and have since reverted back to 1.7.1: > > https://github.com/Homebrew/homebrew-core/issues/8657 Sorry. I didn't make it explicit that it was a preview beta release. I usually don't publish betas, but I thought it might be useful for people who don't want to check out from Git and install developer tools. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: William W. <wi...@tu...> - 2017-01-19 15:10:30
|
Hi all, I'm a maintainer with Homebrew, and I have some questions about the upcoming 2.0 release: * Will `sshguard-setup` be installed with `sshguard`? * Will a default configuration akin to 1.7.1's functionality be available? We accidentally packaged your (experimental) 1.99 release a while ago, but came across these issues and have since reverted back to 1.7.1: https://github.com/Homebrew/homebrew-core/issues/8657 I'd appreciate any clarification you could give on those two questions. Best, William Woodruff wi...@tu... |
From: jungle B. <jun...@gm...> - 2017-01-03 02:41:27
|
Hi Kevin, On Jan 2, 2017 2:19 PM, "Kevin Zheng" <kev...@gm...> wrote: > > Hi there, > > A lot of work to get SSHGuard working with new log sources (journalctl, > macOS log) and backends (firewalld, ipset) has happened in 2.0. > > The new version also uses a configuration file. > > Some deprecated backends have been resurrected (hosts, ipfilter). > > Most importantly, SSHGuard has been split into several processes piped > into one another (sshg-logmon | sshg-parser | sshg-blocker | sshg-fw). > sshg-parser can run with capsicum(4) and pledge(2). sshg-blocker can be > sandboxed in its default configuration (without pid file, whitelist, > blacklisting) and has not been tested sandboxed in other configurations. > I'm going to give this a shot on that one host that had a problem. The OS has been reinstalled so I'm hoping it will make a difference this time around. Can you point us to the latest documentation? Thanks for your efforts, IMO, to make sshguard easier to use. > > The experimental code is available on SourceForge as 1.99.0 [1]. > > Thanks, > Kevin > > [1] https://sourceforge.net/projects/sshguard/files/sshguard/1.99.0/ > > -- > Kevin Zheng > kev...@gm... | ke...@be... | PGP: 0xC22E1090 > > |
From: Kevin Z. <kev...@gm...> - 2017-01-02 22:19:33
|
Hi there, A lot of work to get SSHGuard working with new log sources (journalctl, macOS log) and backends (firewalld, ipset) has happened in 2.0. The new version also uses a configuration file. Some deprecated backends have been resurrected (hosts, ipfilter). Most importantly, SSHGuard has been split into several processes piped into one another (sshg-logmon | sshg-parser | sshg-blocker | sshg-fw). sshg-parser can run with capsicum(4) and pledge(2). sshg-blocker can be sandboxed in its default configuration (without pid file, whitelist, blacklisting) and has not been tested sandboxed in other configurations. The sshguard program is now a driver script that glues everything together. It's probably still a little fragile. Some cleanup work remains. Documentation is also being updated. I encourage package maintainers and people with suitable test environments to give the new code a shot and provide feedback. The experimental code is available on SourceForge as 1.99.0 [1]. Thanks, Kevin [1] https://sourceforge.net/projects/sshguard/files/sshguard/1.99.0/ -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: Kevin Z. <kev...@gm...> - 2016-10-25 21:34:15
|
Hi there, SSHGuard 1.7.1 is available. Added - Add sample Mac OS X 10.12 style launchd.plist Changed - Allow multiple forward slashes in process name - Log released addresses only when debugging Deprecated - Process validation (``-f`` option) is deprecated Fixed - Adjust TIMESTAMP_ISO8601 for Mac OS X 10.12 - Fix build error in hosts backend - Fix empty functions in firewall scripts causing errors with Bash - Flush stdout after every line in sshg-parser Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: Mark F. <fe...@Fr...> - 2016-08-29 18:04:26
|
> On Aug 29, 2016, at 13:02, Kevin Zheng <kev...@gm...> wrote: > > On 08/29/2016 10:47, Mark Felder wrote: >> Not sure. I was just looking for an easy hack for users of the hosts >> backend. > > If that's something people are interested in it would just involve > translating the original hosts.c into a new sshg-fw backend. > > It's only deprecated because not many people said they were using it on > the survey, and I wasn't going to rewrite if not many were using it. > > It would be trivial to implement if we assume the whole hosts.deny is > controlled by SSHGuard. The original implementation used comment blocks > to separate the SSHGuard-controlled parts from the rest. Do you know how > people are usually using the hosts backend? > Not sure. I've only seen one person that was using hosts file backend and noticed it is not available anymore. -- Mark Felder ports-secteam member fe...@Fr... |
From: Kevin Z. <kev...@gm...> - 2016-08-29 18:03:05
|
On 08/29/2016 10:47, Mark Felder wrote: > Not sure. I was just looking for an easy hack for users of the hosts > backend. If that's something people are interested in it would just involve translating the original hosts.c into a new sshg-fw backend. It's only deprecated because not many people said they were using it on the survey, and I wasn't going to rewrite if not many were using it. It would be trivial to implement if we assume the whole hosts.deny is controlled by SSHGuard. The original implementation used comment blocks to separate the SSHGuard-controlled parts from the rest. Do you know how people are usually using the hosts backend? -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: Kevin Z. <kev...@gm...> - 2016-08-29 17:56:02
|
On 08/29/2016 10:49, Mark Felder wrote: > On Mon, Aug 8, 2016, at 12:23, Kevin Zheng wrote: >> >> Logsuck (-l option) is deprecated, use sshg-logtail instead > > The problem I have with this is that now I have to provide a new rc > script for users to have logtail, and users have to remember to start > it. Would it be reasonable to just accept the -l option but internally > fork off the sshg-logtail as a child process? Yes, that's what's planned for the next version. Tentatively, the '-l' flag will go away (replaced with positional arguments). Positional arguments will be passed to a forked off sshg-logtail, and the regular arguments will go to SSHGuard. You can stick to '-l' if you haven't been having problems with it. It's being taken out because it's had lots of bugs, from broken kqueue a while ago to using uninitialized memory to infinite looping on systems without a separate debug.log. -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: Mark F. <fe...@Fr...> - 2016-08-29 17:49:49
|
On Mon, Aug 8, 2016, at 12:23, Kevin Zheng wrote: > > Logsuck (-l option) is deprecated, use sshg-logtail instead The problem I have with this is that now I have to provide a new rc script for users to have logtail, and users have to remember to start it. Would it be reasonable to just accept the -l option but internally fork off the sshg-logtail as a child process? -- Mark Felder ports-secteam member fe...@Fr... |
From: Mark F. <fe...@Fr...> - 2016-08-29 17:47:31
|
On Mon, Aug 29, 2016, at 12:30, Kevin Zheng wrote: > On 08/29/2016 10:18, Mark Felder wrote: > >> Removed > >> Remove external hooks (-e option) > > > > How does the Null backend work now? > > The 'configure' script generates a sshg-fw that reads commands like > 'block 1.2.3.4' but just prints the action instead of doing anything. > > Instead of writing hooks, you can edit the sshg-fw script directly. In > future versions the user should be able to provide a path to sshg-fw; > right now the path is provided from the 'configure' script. > > The situation now is kind of ugly (compile in a new path or edit the > installed sshg-fw script). Suggestions? > Not sure. I was just looking for an easy hack for users of the hosts backend. -- Mark Felder ports-secteam member fe...@Fr... |
From: Kevin Z. <kev...@gm...> - 2016-08-29 17:30:41
|
On 08/29/2016 10:18, Mark Felder wrote: >> Removed >> Remove external hooks (-e option) > > How does the Null backend work now? The 'configure' script generates a sshg-fw that reads commands like 'block 1.2.3.4' but just prints the action instead of doing anything. Instead of writing hooks, you can edit the sshg-fw script directly. In future versions the user should be able to provide a path to sshg-fw; right now the path is provided from the 'configure' script. The situation now is kind of ugly (compile in a new path or edit the installed sshg-fw script). Suggestions? -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: Mark F. <fe...@Fr...> - 2016-08-29 17:18:28
|
On Mon, Aug 8, 2016, at 12:23, Kevin Zheng wrote: > Greetings, > > SSHGuard 1.7.0 is available: > https://sourceforge.net/projects/sshguard/files/sshguard/1.7.0/ > > > Removed > Remove external hooks (-e option) How does the Null backend work now? -- Mark Felder ports-secteam member fe...@Fr... |
From: Kevin Z. <kev...@gm...> - 2016-08-08 17:23:32
|
Greetings, SSHGuard 1.7.0 is available: https://sourceforge.net/projects/sshguard/files/sshguard/1.7.0/ Added Add sshg-logtail Add sshg-parser Control firewall using sshg-fw Match "no matching key exchange method" for SSH Deprecated Hosts backend is deprecated Logsuck (-l option) is deprecated, use sshg-logtail instead Process validation (-f option) is deprecated Removed Remove external hooks (-e option) Remove support for genfilt and ipfilter backends Fixed Accept socklog messages without a timestamp Fix excessive logging causing endless looping in logsuck Fix undefined assignment of initial inode number Note on deprecation: Deprecated features will be removed in the next non-bugfix release. If you would like to nominate a feature to be un-deprecated, contact the project mailing list. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: Mark F. <fe...@Fr...> - 2016-05-02 16:44:07
|
On Mon, May 2, 2016, at 11:42, Kevin Zheng wrote: > On 05/02/2016 08:56, Mark Felder wrote: > >> Most notably, some default options have changed. The abuse threshold has > >> been reduced to 30 (3 attacks) and the initial block time has been > >> lowered to 2 minutes (from 7). These settings can be overridden from the > >> command line. Package maintainers should check their scripts. > >> > > > > The man page has not been updated to reflect these changes. > > Oops, thanks for catching the issue. An updated man page has been > committed, and the diff between 1.6.4 is attached. > This was not noted in the release notes, but I will make sure this is reflected in the FreeBSD port +.B \fB\-s\fP \fIinterval\fP (default 1800 secs, or 30 minutes) -- Mark Felder ports-secteam member fe...@Fr... |
From: Kevin Z. <kev...@gm...> - 2016-05-02 16:42:38
|
On 05/02/2016 08:56, Mark Felder wrote: >> Most notably, some default options have changed. The abuse threshold has >> been reduced to 30 (3 attacks) and the initial block time has been >> lowered to 2 minutes (from 7). These settings can be overridden from the >> command line. Package maintainers should check their scripts. >> > > The man page has not been updated to reflect these changes. Oops, thanks for catching the issue. An updated man page has been committed, and the diff between 1.6.4 is attached. Thanks, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: Mark F. <fe...@Fr...> - 2016-05-02 16:11:51
|
On Thu, Apr 28, 2016, at 20:24, Kevin Zheng wrote: > > Most notably, some default options have changed. The abuse threshold has > been reduced to 30 (3 attacks) and the initial block time has been > lowered to 2 minutes (from 7). These settings can be overridden from the > command line. Package maintainers should check their scripts. > The man page has not been updated to reflect these changes. -- Mark Felder ports-secteam member fe...@Fr... |
From: Kevin Z. <kev...@gm...> - 2016-04-29 01:24:58
|
Greetings, I am pleased to announce the release of SSHGuard 1.6.4 [1]. This release brings updated signatures, usability improvements, and bug fixes. Highlights in this release include: - Match Postfix pre-authentication disconnects - Fix bashisms in iptables backend - Fix size argument in inet_ntop() call - Remove excessive logging when polling from files - Keep looking for unreadable files while polling - Update Dovecot signature for POP3 - Match "Connection reset" message for SSH - Resurrect PID file option by popular demand - Adjust default abuse threshold Most notably, some default options have changed. The abuse threshold has been reduced to 30 (3 attacks) and the initial block time has been lowered to 2 minutes (from 7). These settings can be overridden from the command line. Package maintainers should check their scripts. The PID file option (-p) has been resurrected. As usual, please report any bugs, build failures, or other issues to the mailing list or the Bitbucket tracker [2]. If you haven't already, please take 2-3 minutes to complete a survey about how you use SSHGuard: https://docs.google.com/forms/d/1UQHrtq7uhpopWDsNmvYyVbwKpupkgHAwcd3SwmTMaNc/viewform?usp=send_form Best, Kevin [1] https://sourceforge.net/projects/sshguard/files/sshguard/1.6.4/ [2] https://bitbucket.org/sshguard/sshguard/issues/ -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: Kevin Z. <kev...@gm...> - 2016-04-24 05:00:03
|
Greetings, SSHGuard 1.6.4 is just around the corner, bringing these changes: - Match Postfix pre-authentication disconnects - Fix bashisms in iptables backend - Fix size argument in inet_ntop() call - Remove excessive logging when polling from files - Keep looking for unreadable files while polling - Update Dovecot signature for POP3 - Match "Connection reset" message for SSH - Resurrect PID file option by popular demand - Adjust default abuse threshold Most notably, some default options have changed. The abuse threshold has been reduced to 30 (3 attacks) and the initial block time has been lowered to 2 minutes (from 7). These settings can be overridden from the command line. Package maintainers should check their scripts. The PID file option (-p) has been resurrected. If no major issues come up, the 1.6.4 tarball will be released in the coming week. You can test-drive this release by cloning from the 'master' branch in the Bitbucket repository. Cheers, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
From: <li...@la...> - 2016-01-29 02:13:26
|
I'll admit ignorance here. What is process validation I get too many hits from Google, and don't know enough to narrow the search. Otherwise the survey was a snap. Original Message From: Kevin Zheng Sent: Thursday, January 28, 2016 3:37 PM To: ssh...@li...; ssh...@li... Reply To: ssh...@li... Subject: [Sshguard-users] SSHGuard user survey Dear SSHGuard users, I've created a short survey to help understand how people use SSHGuard. Among other things, I'm interested in which features, operating systems, architectures, and services people use with SSHGuard. Please take 2-3 minutes to take the survey here: https://docs.google.com/forms/d/1UQHrtq7uhpopWDsNmvYyVbwKpupkgHAwcd3SwmTMaNc/viewform?usp=send_form Summary results are available once you submit; however, they are probably not very meaningful since at the time of writing only one person (me) has taken it. If there are glaring errors or omissions please report them here on the mailing list or to me directly. Thanks, Kevin -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Sshguard-users mailing list Ssh...@li... https://lists.sourceforge.net/lists/listinfo/sshguard-users |
From: Kevin Z. <kev...@gm...> - 2016-01-28 23:37:35
|
Dear SSHGuard users, I've created a short survey to help understand how people use SSHGuard. Among other things, I'm interested in which features, operating systems, architectures, and services people use with SSHGuard. Please take 2-3 minutes to take the survey here: https://docs.google.com/forms/d/1UQHrtq7uhpopWDsNmvYyVbwKpupkgHAwcd3SwmTMaNc/viewform?usp=send_form Summary results are available once you submit; however, they are probably not very meaningful since at the time of writing only one person (me) has taken it. If there are glaring errors or omissions please report them here on the mailing list or to me directly. Thanks, Kevin -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
From: Willem J. W. <wj...@di...> - 2016-01-08 08:18:59
|
On 8-1-2016 03:42, Kevin Zheng wrote: > On 01/05/2016 03:02, Willem Jan Withagen wrote: >> I cannot speak for everybody, but it would allow for sshguard to get the >> "standard" rc.d script treatment. Which is well known, and straight forward. >> Going thru deamon just is a bit more convoluted and uses more resources. >> >> So if it is not a great pain, I think it is appreciated. > > This option was resurrected in 9b94e0f and is available from 'master'. > Note that this option functions as it did before; it does not use > pidfile(3) and therefore doesn't check the PID file before starting. > > Sorry for the trouble of taking it out in the first place. Thanx Kevin. And just in case nobody else said it: I really appreciate the work you are doing for this project. --WjW |
From: Kevin Z. <kev...@gm...> - 2016-01-08 02:43:03
|
On 01/05/2016 03:02, Willem Jan Withagen wrote: > I cannot speak for everybody, but it would allow for sshguard to get the > "standard" rc.d script treatment. Which is well known, and straight forward. > Going thru deamon just is a bit more convoluted and uses more resources. > > So if it is not a great pain, I think it is appreciated. This option was resurrected in 9b94e0f and is available from 'master'. Note that this option functions as it did before; it does not use pidfile(3) and therefore doesn't check the PID file before starting. Sorry for the trouble of taking it out in the first place. Thanks, Kevin -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
From: Willem J. W. <wj...@di...> - 2016-01-05 09:02:58
|
On 5-1-2016 00:00, Kevin Zheng wrote: > On 01/04/2016 16:19, Willem Jan Withagen wrote: >> I did not have time to react to the release notes before, but I have to >> concur with Mark that it is a pitty that this feature was removed. >> Does not make FreeBSD life much easier. >> >> And I'm not sure that the PIDfile needs to be locked. >> Why should it be? > > To prevent a second process from starting if one is already running. I > believe daemon(8) accomplishes this using pidfile(3). > > Granted, the '-i' option is probably only used by init daemons, in which > case the existence of the file is checked before anything is started, so > this is really a non-issue. > > If this option makes things substantially easier, I can resurrect it. I cannot speak for everybody, but it would allow for sshguard to get the "standard" rc.d script treatment. Which is well known, and straight forward. Going thru deamon just is a bit more convoluted and uses more resources. So if it is not a great pain, I think it is appreciated. --WjW |
From: Kevin Z. <kev...@gm...> - 2016-01-04 23:00:59
|
On 01/04/2016 16:19, Willem Jan Withagen wrote: > I did not have time to react to the release notes before, but I have to > concur with Mark that it is a pitty that this feature was removed. > Does not make FreeBSD life much easier. > > And I'm not sure that the PIDfile needs to be locked. > Why should it be? To prevent a second process from starting if one is already running. I believe daemon(8) accomplishes this using pidfile(3). Granted, the '-i' option is probably only used by init daemons, in which case the existence of the file is checked before anything is started, so this is really a non-issue. If this option makes things substantially easier, I can resurrect it. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
From: Willem J. W. <wj...@di...> - 2016-01-04 22:36:29
|
On 01/04/2016 12:13, Mark Felder wrote: On 4-1-2016 21:33, Kevin Zheng wrote: >>> - Remove PID file option >> >> ... Why? The rc scripts on FreeBSD heavily rely on pidfiles. It ensures >> that the process name and pidfile contents match what it finds in the >> process list to be sure it's not going to kill the wrong process. I can >> alter sshguard's rc script to launch via daemon(8) so I can get a >> pidfile again, but that seems silly. > > I removed it thinking that I was duplicating what daemon(8) does. The > original PID file code did not properly lock the PID file, so I thought > to delegate to daemon(8) instead of rolling my own pidfile(3). I did not have time to react to the release notes before, but I have to concur with Mark that it is a pitty that this feature was removed. Does not make FreeBSD life much easier. And I'm not sure that the PIDfile needs to be locked. Why should it be? --WjW |