Menu
▾
▴
sshguard-users
|
From: Kevin Z. <kev...@gm...> - 2016-08-08 17:23:32
Attachments:
signature.asc
|
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-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-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: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: 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: 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: 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: 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... |
Thanks for helping keep SourceForge clean.
X