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

Re: [Sshguard-users] compiler warnings -D_XOPEN_SOURCE

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

On 03/26/2015 17:31, James Harris wrote:
> If I remove AM_CFLAGS+= -D_XOPEN_SOURCE from the non Solaris case the
> warnings go. Another way to go is set AM_CFLAGS+= -D_XOPEN_SOURCE=600 as
> that will also remove the warning. In other words remove the conditional
> and the compile completes without issue.

Here's what the Open Group has to say [1]:

"An XSI-conforming application should ensure that the feature test macro
_XOPEN_SOURCE is defined with the value 600 before inclusion of any header."

> So what do we think is safer ? Remove _XOPEN_SOURCE or add  || LINUX to
> the solaris conditional?

I think the standard is pretty clear about unconditionally setting
_XOPEN_SOURCE to 600. I've attached a patch that does just that. If
there are no objections I'll commit it.

Note that this is the only source directory that sets _XOPEN_SOURCE;
should the others too?

Thanks,
Kevin Zheng

[1]
http://pubs.opengroup.org/onlinepubs/007904875/functions/xsh_chap02_02.html

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

Re: [Sshguard-users] compiler warnings -D_XOPEN_SOURCE

[mij <mi...@ss...>]

When running portability-related assessments, avoid “man” as the pest.
“man” is the most implementation-specific source of information you can find.
Run “man” on two different systems, get two different descriptions.

SSHGuard was written against POSIX, and that’s what enabled it to run on
such wide range of servers. Let’s try to maintain it at that level. Use the POSIX
reference from the OpenGroup.

cheers
michele


> On 26 Mar 2015, at 23:31, James Harris <jam...@gm...> wrote:
> 
> 
> I was looking at some of the compiler warnings I get while building trunk.
> 
> sshguard_options.c: In function ‘get_options_cmdline’:
> sshguard_options.c:148:21: warning: implicit declaration of function ‘setenv’ [-Wimplicit-function-declaration]
>                      setenv("SSHGUARD_EVENT_EXECUTE", optarg, 1);
> 
> 
> sshguard_logsuck.c: In function ‘read_from’:
> sshguard_logsuck.c:354:13: warning: implicit declaration of function ‘usleep’ [-Wimplicit-function-declaration]
>              usleep(20 * 1000);
> 
> 
> If I remove AM_CFLAGS+= -D_XOPEN_SOURCE from the non Solaris case the warnings go. Another way to go is set AM_CFLAGS+= -D_XOPEN_SOURCE=600 as that will also remove the warning. In other words remove the conditional and the compile completes without issue.
> 
> 
> My "man 3 usleep" has 
> 
>        usleep():
>            Since glibc 2.12:
>                _BSD_SOURCE ||
>                    (_XOPEN_SOURCE >= 500 ||
>                        _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED) &&
>                    !(_POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700)
>            Before glibc 2.12:
>                _BSD_SOURCE || _XOPEN_SOURCE >= 500 || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
> 
> and my "man 3 setenv" has
> 
>        setenv(), unsetenv():
>            _BSD_SOURCE || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600
> 
> 
> So what do we think is safer ? Remove _XOPEN_SOURCE or add  || LINUX to the solaris conditional?
> 
> -- 
> James Harris
> Software Engineer
> jam...@gm...
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/_______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] compiler warnings -D_XOPEN_SOURCE

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

I was looking at some of the compiler warnings I get while building trunk.

sshguard_options.c: In function ‘get_options_cmdline’:
sshguard_options.c:148:21: warning: implicit declaration of function
‘setenv’ [-Wimplicit-function-declaration]
                     setenv("SSHGUARD_EVENT_EXECUTE", optarg, 1);


sshguard_logsuck.c: In function ‘read_from’:
sshguard_logsuck.c:354:13: warning: implicit declaration of function
‘usleep’ [-Wimplicit-function-declaration]
             usleep(20 * 1000);


If I remove AM_CFLAGS+= -D_XOPEN_SOURCE from the non Solaris case the
warnings go. Another way to go is set AM_CFLAGS+= -D_XOPEN_SOURCE=600 as
that will also remove the warning. In other words remove the conditional
and the compile completes without issue.


My "man 3 usleep" has

       usleep():
           Since glibc 2.12:
               _BSD_SOURCE ||
                   (_XOPEN_SOURCE >= 500 ||
                       _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED) &&
                   !(_POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700)
           Before glibc 2.12:
               _BSD_SOURCE || _XOPEN_SOURCE >= 500 || _XOPEN_SOURCE &&
_XOPEN_SOURCE_EXTENDED

and my "man 3 setenv" has

       setenv(), unsetenv():
           _BSD_SOURCE || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600


So what do we think is safer ? Remove _XOPEN_SOURCE or add  || LINUX to the
solaris conditional?

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

Re: [Sshguard-users] xtables lock

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

On 03/25/2015 19:55, James Harris wrote:
> Since moving to a systemd based init exiting no longer feels like a huge
> problem. It can handle restarting if required but it also can handle
> exit codes which allow failures to escalate until resolved.  Spamming
> the log with a message every few minutes that something is holding the
> firewall lock doesn't feel like such a bad thing especially as new brute
> force attempts aren't being dealt with.

For now at least, I think spamming syslog is the better option.

> On a separate thought. Has anyone thought about being proactive with
> blocking? I have noticed attacks can come from IPs in the same class C
> address blocks in a small period of time. I was thinking of something
> like if X attacks come from an address block (or autonomous system?)  in
> a configured window add a temporary rule against that ip block.

It might be a little more complex than that. These days addresses are
allocated from arbitrary size subnets rather than A, B, and C blocks.

> One down side is blocked attacks wont generate a blacklist entry. If
> temporary rules were used I would want the option to log the number of
> hits to the rule at the point it was expired. 

If it's a small enough subnet, perhaps it's better to extend the amount
of time required to trigger a block. In a class C, it's probably true
that some addresses will repeat.

Thanks,
Kevin Zheng

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

Re: [Sshguard-users] xtables lock

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

Kevin,

Since moving to a systemd based init exiting no longer feels like a huge
problem. It can handle restarting if required but it also can handle exit
codes which allow failures to escalate until resolved.  Spamming the log
with a message every few minutes that something is holding the firewall
lock doesn't feel like such a bad thing especially as new brute force
attempts aren't being dealt with.

On a separate thought. Has anyone thought about being proactive with
blocking? I have noticed attacks can come from IPs in the same class C
address blocks in a small period of time. I was thinking of something like
if X attacks come from an address block (or autonomous system?)  in a
configured window add a temporary rule against that ip block.

One down side is blocked attacks wont generate a blacklist entry. If
temporary rules were used I would want the option to log the number of hits
to the rule at the point it was expired.

My guess is the attackers are finding open proxies in a given range and
then running across them to avoid blocking. Of course they could counter
with creating a large proxy list across a diverse range then choosing a
proxy at random but that might be another battle.


On Wed, Mar 25, 2015 at 5:21 PM, Kevin Zheng <kev...@gm...> wrote:

> Hi James,
>
> On 03/25/2015 19:08, James Harris wrote:
> > I created a pull request with the suggested changes. In addition to
> > waiting for the lock it includes improves start up time as it avoids
> > reverse dns lookup on all blocked ips. I have been running with these
> > changes for a while without issue.
>
> Thanks for the patch; it's been merged in b30e6a8.
>
> > I agree if the table is locked most likely any other operation sshguard
> > attempts will also fail. The question is should sshguard wait
> > indefinitely to acquire the lock?  I would suggest after a reasonably
> > long timeout it should log the failure and enter a failed state by
> > exiting. If sshguard was blocked for a significant period of time
> > without warning one might assume they are still being actively protected
> > when they are not.
>
> I'm not sure about exiting; this requires manual intervention to restart
> the daemon. I agree that it should indicate failure, perhaps by logging
> this to syslog and moving on. The flip side is that if the firewall is
> blocked indefinitely, you'll get a lot of messages.
>
> In any case, your fix is better than the status quo :)
>
> Thanks,
> Kevin Zheng
>
> --
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>



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

Re: [Sshguard-users] xtables lock

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

Hi James,

On 03/25/2015 19:08, James Harris wrote:
> I created a pull request with the suggested changes. In addition to
> waiting for the lock it includes improves start up time as it avoids
> reverse dns lookup on all blocked ips. I have been running with these
> changes for a while without issue.  

Thanks for the patch; it's been merged in b30e6a8.

> I agree if the table is locked most likely any other operation sshguard
> attempts will also fail. The question is should sshguard wait
> indefinitely to acquire the lock?  I would suggest after a reasonably
> long timeout it should log the failure and enter a failed state by
> exiting. If sshguard was blocked for a significant period of time
> without warning one might assume they are still being actively protected
> when they are not. 

I'm not sure about exiting; this requires manual intervention to restart
the daemon. I agree that it should indicate failure, perhaps by logging
this to syslog and moving on. The flip side is that if the firewall is
blocked indefinitely, you'll get a lot of messages.

In any case, your fix is better than the status quo :)

Thanks,
Kevin Zheng

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

Re: [Sshguard-users] xtables lock

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

I created a pull request with the suggested changes. In addition to waiting
for the lock it includes improves start up time as it avoids reverse dns
lookup on all blocked ips. I have been running with these changes for a
while without issue.

I agree if the table is locked most likely any other operation sshguard
attempts will also fail. The question is should sshguard wait indefinitely
to acquire the lock?  I would suggest after a reasonably long timeout it
should log the failure and enter a failed state by exiting. If sshguard was
blocked for a significant period of time without warning one might assume
they are still being actively protected when they are not.

On Tue, Mar 24, 2015 at 7:39 PM, Kevin Zheng <kev...@gm...> wrote:

> Hi James,
>
> Thanks for analyzing and reporting the issue.
>
> On 03/24/2015 16:19, James Harris wrote:
> > But it doesn't look like that is enough.  I suspect libvirtd has
> > 'finished' starting up but has not completed the iptable changes it
> > requires.  What about adding "-w" to the iptables firwall commands?  The
> > downside is the command could block for a while. Should run_command()
> > fork/exec and wait for a specific timeout before giving up on the
> > command? Is blocking indefinitely acceptable, or is this all on deck for
> > the libev rewrite?
>
> It doesn't sound like the xtables lock is held for a long time; if
> you're feeling adventurous you can try adding "-w" (I can give you a
> patch to test if you wish) and see what happens.
>
> If the firewall command blocks, SSHGuard will stop processing new log
> entries until system() returns. On a practical note, if xtables is
> really locked then returning immediately doesn't gain anything; the next
> attack cannot be blocked, so we might as well wait.
>
> This would not be fixed by the libev rewrite, although sometime in the
> distant future firewall commands may be executed in a separate process.
> However, even this does not solve the underlying issue; although
> SSHGuard will continue to run, nothing will be blocked.
>
> I'm not familiar with, nor do I run iptables, but it sounds like adding
> "-w" doesn't have huge issues and makes sense.
>
> Thanks,
> Kevin Zheng
>
> --
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>



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

Re: [Sshguard-users] xtables lock

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

Hi James,

Thanks for analyzing and reporting the issue.

On 03/24/2015 16:19, James Harris wrote:
> But it doesn't look like that is enough.  I suspect libvirtd has
> 'finished' starting up but has not completed the iptable changes it
> requires.  What about adding "-w" to the iptables firwall commands?  The
> downside is the command could block for a while. Should run_command()
> fork/exec and wait for a specific timeout before giving up on the
> command? Is blocking indefinitely acceptable, or is this all on deck for
> the libev rewrite?

It doesn't sound like the xtables lock is held for a long time; if
you're feeling adventurous you can try adding "-w" (I can give you a
patch to test if you wish) and see what happens.

If the firewall command blocks, SSHGuard will stop processing new log
entries until system() returns. On a practical note, if xtables is
really locked then returning immediately doesn't gain anything; the next
attack cannot be blocked, so we might as well wait.

This would not be fixed by the libev rewrite, although sometime in the
distant future firewall commands may be executed in a separate process.
However, even this does not solve the underlying issue; although
SSHGuard will continue to run, nothing will be blocked.

I'm not familiar with, nor do I run iptables, but it sounds like adding
"-w" doesn't have huge issues and makes sense.

Thanks,
Kevin Zheng

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

[Sshguard-users] xtables lock

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

Recently I have seen many of these messages during a boot on my FedoraCore
21 box.

"sshguard: Another app is currently holding the xtables lock. Perhaps you
want to use the -w option?"

It seems libvirtd is execing "/usr/sbin/iptables" after it starts up. I
have tweeked my sshguard.service file for systemd to have
After=sshd.service
After=syslog.target
After=iptables.target
After=ip6tables.target
After=libvirtd.service
After=firewalld.service

But it doesn't look like that is enough.  I suspect libvirtd has 'finished'
starting up but has not completed the iptable changes it requires.  What
about adding "-w" to the iptables firwall commands?  The downside is the
command could block for a while. Should run_command() fork/exec and wait
for a specific timeout before giving up on the command? Is blocking
indefinitely acceptable, or is this all on deck for the libev rewrite?

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

Re: [Sshguard-users] sshguard not working on OS X Yosemite

[Barry M. <bmu...@ga...>]

http://www.sshguard.net/docs/setup/

OS X uses the pf backend as of Yosemite

_-_-_-_-_-_-_-_-_-_-_-_-

Barry John Muldrey Jr.

Doctoral Student and Graduate Researcher,
Georgia Institute of Technology


www.barrymuldrey.com
+1 (504) 975-7971
689 Berne St SE, Apt C
Atlanta, GA 30312-3529
USA

On Thu, Mar 12, 2015 at 1:55 PM, Mike Laster <ml...@gm...> wrote:

> That is probably it.  I didn’t see anything in the FAQ on how to do that.
>
> > sudo pfctl -s rules
> No ALTQ support in kernel
> ALTQ related functions disabled
> scrub-anchor "com.apple/*" all fragment reassemble
> anchor "com.apple/*" all
>
> > On Mar 12, 2015, at 9:41 AM, Mark Felder <fe...@Fr...> wrote:
> >
> >
> >
> > On Thu, Mar 12, 2015, at 10:25, Mike Laster wrote:
> >> I have the latest source built (including the post 1.5 patch for the
> >> "via"
> >> problem.  Checked out from bcf98c7e4c24.  It appears that sshguard is
> >> parsing properly since when I repeatedly fail to login via ssh from
> >> another
> >> machine:
> >>
> >> 3/12/15 8:23:49.238 AM sshd[43878]: error: PAM: authentication error for
> >> root from 192.168.1.146 via 192.168.1.10
> >> 3/12/15 8:23:49.801 AM sshd[43878]: error: PAM: authentication error for
> >> root from 192.168.1.146 via 192.168.1.10
> >> 3/12/15 8:23:50.206 AM sshd[43878]: error: PAM: authentication error for
> >> root from 192.168.1.146 via 192.168.1.10
> >>
> >> and it seems to add it to pf:
> >>
> >>> sudo pfctl -T show -t sshguard
> >> No ALTQ support in kernel
> >> ALTQ related functions disabled
> >>   192.168.1.146
> >>
> >> However, my ssh sessions are not actually being blocked.  I can keep
> >> hitting ssh all day from 192.168.1.146 and no blocking seems to be going
> >> on.
> >>
> >> Is there something else I need to do to enable actual blocking?
> >>
> >
> > What is the output of
> >
> > pfctl -s rules
> >
> >
> > So we can see what rules are loaded. I suspect there's no actual block
> > rule for the sshguard table.
> >
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub
> for all
> > things parallel software development, from weekly thought leadership
> blogs to
> > news, videos, case studies, tutorials and more. Take a look and join the
> > conversation now. http://goparallel.sourceforge.net/
> > _______________________________________________
> > Sshguard-users mailing list
> > Ssh...@li...
> > https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

Re: [Sshguard-users] sshguard not working on OS X Yosemite

[Mike L. <ml...@gm...>]

That is probably it.  I didn’t see anything in the FAQ on how to do that.

> sudo pfctl -s rules
No ALTQ support in kernel
ALTQ related functions disabled
scrub-anchor "com.apple/*" all fragment reassemble
anchor "com.apple/*" all

> On Mar 12, 2015, at 9:41 AM, Mark Felder <fe...@Fr...> wrote:
> 
> 
> 
> On Thu, Mar 12, 2015, at 10:25, Mike Laster wrote:
>> I have the latest source built (including the post 1.5 patch for the
>> "via"
>> problem.  Checked out from bcf98c7e4c24.  It appears that sshguard is
>> parsing properly since when I repeatedly fail to login via ssh from
>> another
>> machine:
>> 
>> 3/12/15 8:23:49.238 AM sshd[43878]: error: PAM: authentication error for
>> root from 192.168.1.146 via 192.168.1.10
>> 3/12/15 8:23:49.801 AM sshd[43878]: error: PAM: authentication error for
>> root from 192.168.1.146 via 192.168.1.10
>> 3/12/15 8:23:50.206 AM sshd[43878]: error: PAM: authentication error for
>> root from 192.168.1.146 via 192.168.1.10
>> 
>> and it seems to add it to pf:
>> 
>>> sudo pfctl -T show -t sshguard
>> No ALTQ support in kernel
>> ALTQ related functions disabled
>>   192.168.1.146
>> 
>> However, my ssh sessions are not actually being blocked.  I can keep
>> hitting ssh all day from 192.168.1.146 and no blocking seems to be going
>> on.
>> 
>> Is there something else I need to do to enable actual blocking?
>> 
> 
> What is the output of
> 
> pfctl -s rules
> 
> 
> So we can see what rules are loaded. I suspect there's no actual block
> rule for the sshguard table.
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] sshguard not working on OS X Yosemite

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

On Thu, Mar 12, 2015, at 10:25, Mike Laster wrote:
> I have the latest source built (including the post 1.5 patch for the
> "via"
> problem.  Checked out from bcf98c7e4c24.  It appears that sshguard is
> parsing properly since when I repeatedly fail to login via ssh from
> another
> machine:
> 
> 3/12/15 8:23:49.238 AM sshd[43878]: error: PAM: authentication error for
> root from 192.168.1.146 via 192.168.1.10
> 3/12/15 8:23:49.801 AM sshd[43878]: error: PAM: authentication error for
> root from 192.168.1.146 via 192.168.1.10
> 3/12/15 8:23:50.206 AM sshd[43878]: error: PAM: authentication error for
> root from 192.168.1.146 via 192.168.1.10
> 
> and it seems to add it to pf:
> 
> > sudo pfctl -T show -t sshguard
> No ALTQ support in kernel
> ALTQ related functions disabled
>    192.168.1.146
> 
> However, my ssh sessions are not actually being blocked.  I can keep
> hitting ssh all day from 192.168.1.146 and no blocking seems to be going
> on.
> 
> Is there something else I need to do to enable actual blocking?
> 

What is the output of

pfctl -s rules


So we can see what rules are loaded. I suspect there's no actual block
rule for the sshguard table.

[Sshguard-users] sshguard not working on OS X Yosemite

[Mike L. <ml...@gm...>]

I have the latest source built (including the post 1.5 patch for the "via"
problem.  Checked out from bcf98c7e4c24.  It appears that sshguard is
parsing properly since when I repeatedly fail to login via ssh from another
machine:

3/12/15 8:23:49.238 AM sshd[43878]: error: PAM: authentication error for
root from 192.168.1.146 via 192.168.1.10
3/12/15 8:23:49.801 AM sshd[43878]: error: PAM: authentication error for
root from 192.168.1.146 via 192.168.1.10
3/12/15 8:23:50.206 AM sshd[43878]: error: PAM: authentication error for
root from 192.168.1.146 via 192.168.1.10

and it seems to add it to pf:

> sudo pfctl -T show -t sshguard
No ALTQ support in kernel
ALTQ related functions disabled
   192.168.1.146

However, my ssh sessions are not actually being blocked.  I can keep
hitting ssh all day from 192.168.1.146 and no blocking seems to be going on.

Is there something else I need to do to enable actual blocking?

Re: [Sshguard-users] Blacklist database corruption

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

On 03/05/2015 08:11, Mark Felder wrote:
> The blacklist database gets corrupted sometimes. I'm now the maintainer
> of sshguard on FreeBSD and I've seen several reports -- including
> encountering it myself a few times. The result is that sshguard will
> crash on start which is inconvenient to say the least.
> 
> The HardenedBSD folk have run into this too and Oliver Pinter wrote a
> shell script[1] to fix the sshguard blacklist database. Could this be
> converted into native code and handled at startup to sanitize the
> database before crashing?

The blacklist file for 1.6.0 (available now from Git) should now be
human-readable. I haven't been able to test this a whole lot, but I
don't think this should happen anymore.

Thanks,
Kevin Zheng

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

Re: [Sshguard-users] Upstreaming FreeBSD port patches

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

Hi Mark,

On 03/05/2015 08:19, Mark Felder wrote:
> FreeBSD has a few patches[1] for sshguard in the ports tree. Could
> someone review these and bring them upstream if applicable?

Most of these patches have already been committed to Bitbucket [1].
These changes will be available in the 1.6.0 release in a few weeks. I
don't think I've merged the Cyrus IMAP patch yet; I will be sure to do
this soon.

Meanwhile, thanks for maintaining the FreeBSD port. It's been quite some
time since the last release and patches have been accumulating.

You are welcome (and encouraged!) to check out the latest sources and
make sure everything works. I run FreeBSD as well, but it's been a while
since I've tested using syslog or rc.d.

Thanks,
Kevin Zheng

[1] https://bitbucket.org/sshguard/sshguard/

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

Re: [Sshguard-users] Blacklist database corruption

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

On Thu, Mar 5, 2015, at 08:11, Mark Felder wrote:
> 
> The HardenedBSD folk have run into this too and Oliver Pinter wrote a
> shell script[1] to fix the sshguard blacklist database. Could this be
> converted into native code and handled at startup to sanitize the
> database before crashing?
> 
> 

I suppose "fix" is a bit misleading. After coffee and further inspection
of the script, the "fix" is to extract the IP addresses from the
corrupted database file, add them to the firewall ruleset, and delete
the corrupted database.

That's not so helpful, unless sshguard can do the same -- manually
extract the IPs, delete the database file, and write them into a new
one. Detecting the corruption successfully is probably the hardest
part...

[Sshguard-users] Upstreaming FreeBSD port patches

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

Hello,

FreeBSD has a few patches[1] for sshguard in the ports tree. Could
someone review these and bring them upstream if applicable?


Thanks!


[1] https://svnweb.freebsd.org/ports/head/security/sshguard/files/

[Sshguard-users] Blacklist database corruption

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

The blacklist database gets corrupted sometimes. I'm now the maintainer
of sshguard on FreeBSD and I've seen several reports -- including
encountering it myself a few times. The result is that sshguard will
crash on start which is inconvenient to say the least.

The HardenedBSD folk have run into this too and Oliver Pinter wrote a
shell script[1] to fix the sshguard blacklist database. Could this be
converted into native code and handled at startup to sanitize the
database before crashing?


Thanks!


[1]
https://github.com/HardenedBSD/admin/blob/master/workaround_corrupt_sshguard_db.csh

[Sshguard-users] FreeBSD syslog debug level support

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

Hello,

A FreeBSD user submitted a patch[1] that adds support for matching
entries when syslog debugging is enabled.

Will this patch be accepted upstream? Are there any issues with this
method?


Thanks!

[1] https://bz-attachments.freebsd.org/attachment.cgi?id=153223

Re: [Sshguard-users] Spurious sshguard shutdowns at boot time with "sshguard[#]: Got exit signal" logged

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

On Sun, Feb 15, 2015 at 09:29:28PM -0600, Kevin Zheng wrote:
> Doesn't the default SIGHUP handler terminate the process?

Per signal(3) man page, the SIGHUP default when SIG_DFL is requested is
process termination.  My naive understanding is that SIG_DFL has to be
specifically requested in a signal() call, however.

Not specifying SIGHUP in any signal() call might as a side effect set the
signal mask to block SIGHUP.  But my experience here is way back in time,
so I'm not sure any more.

What I see in practice is SIGHUP having no effect (presumably at boot, but
very definitely when sent manually) after I remove the signal() call
setting its handler.

Hmm, for the nonce, it might be better to explicitly set the handler to
SIG_IGN than just leave it out.  I still want to understand why the SIGHUP
is being sent, and then perhaps see about not sending it if that makes
sense.


Richard

Re: [Sshguard-users] Spurious sshguard shutdowns at boot time with "sshguard[#]: Got exit signal" logged

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

Hi Richard,

Thanks for looking into this issue.

On 02/15/2015 20:12, Richard Johnson wrote:
> sshguard.c includes SIGHUP in its signals upon which to terminate.
> 
> The rc.d startup of sshguard at boot on OpenBSD (and FreeBSD) apparently
> comes with a HUP.  Sheer guessing here, but this may be because sshguard
> has the log file open at the time an initial newsyslog run occurs.

I'm running FreeBSD, but I don't start SSHGuard using 'rc.d' since I'm
starting a development version manually every boot.

I'm not sure why SIGHUP is being sent. I'll look around...

> Here's a quick workaround that'll hopefully hold me until there's more time
> for reading code and figuring out how to avoid HUPing sshguard at boot
> time.  It effectively ignores SIGHUP.  Confirmed that on OpenBSD 5.6 stable
> sshguard is still shut down cleanly at reboot time, as well as stops and
> starts fine via /etc/rc.d/sshguard stop|start|restart.
> 
> =======
> --- src/sshguard.c.orig	Wed Feb  9 05:01:47 2011
> +++ src/sshguard.c	Sun Feb 15 18:30:59 2015
> @@ -200,7 +200,6 @@
>  
>      /* termination signals */
>      signal(SIGTERM, sigfin_handler);
> -    signal(SIGHUP, sigfin_handler);
>      signal(SIGINT, sigfin_handler);
>  
>      /* load blacklisted addresses and block them (if requested) */

Doesn't the default SIGHUP handler terminate the process?

Thanks,
Kevin Zheng

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

Re: [Sshguard-users] Spurious sshguard shutdowns at boot time with "sshguard[#]: Got exit signal" logged

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

On Sun, Feb 15, 2015 at 05:19:51PM -0700, Richard Johnson wrote:
> On OpenBSD 5.6, I'm seeing sshguard 1.5.0 stopping nearly immediately upon
> start at boot time.  Typical log entries:
> 
> Feb 15 16:17:46 host sshguard[765]: Started successfully [(a,p,s)=(40, 420, 1200)], now ready to scan.
> Feb 15 16:17:47 host sshguard[765]: Got exit signal, flushing blocked addresses and exiting...
> 
> And sshguard is indeed no longer running.  A later manual start of sshguard
> succeeds.

sshguard.c includes SIGHUP in its signals upon which to terminate.

The rc.d startup of sshguard at boot on OpenBSD (and FreeBSD) apparently
comes with a HUP.  Sheer guessing here, but this may be because sshguard
has the log file open at the time an initial newsyslog run occurs.

Here's a quick workaround that'll hopefully hold me until there's more time
for reading code and figuring out how to avoid HUPing sshguard at boot
time.  It effectively ignores SIGHUP.  Confirmed that on OpenBSD 5.6 stable
sshguard is still shut down cleanly at reboot time, as well as stops and
starts fine via /etc/rc.d/sshguard stop|start|restart.

=======
--- src/sshguard.c.orig	Wed Feb  9 05:01:47 2011
+++ src/sshguard.c	Sun Feb 15 18:30:59 2015
@@ -200,7 +200,6 @@
 
     /* termination signals */
     signal(SIGTERM, sigfin_handler);
-    signal(SIGHUP, sigfin_handler);
     signal(SIGINT, sigfin_handler);
 
     /* load blacklisted addresses and block them (if requested) */

=======


Richard

[Sshguard-users] Spurious sshguard shutdowns at boot time with "sshguard[#]: Got exit signal" logged

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

On OpenBSD 5.6, I'm seeing sshguard 1.5.0 stopping nearly immediately upon
start at boot time.  Typical log entries:

Feb 15 16:17:46 host sshguard[765]: Started successfully [(a,p,s)=(40, 420, 1200)], now ready to scan.
Feb 15 16:17:47 host sshguard[765]: Got exit signal, flushing blocked addresses and exiting...

And sshguard is indeed no longer running.  A later manual start of sshguard
succeeds.

This matches with reported 2012 FreeBSD experience:
https://forums.freebsd.org/threads/at-boot-rc-script-runs-but-service-immediately-exits.29623/

However, in my case, even putting in a 60 second delay on the start of
sshguard is not enough for sshguard to remain running on the system I'm
using for testing.  The start is delayed, but then sshguard quits 1-2
seconds later with the 'Go exit signal' message showing in the log.

I do not know at present whether there's actually an exit signal
sent/received, or whether that message is triggered by something else.

Is this known and fixed yet in the dev repository, or has the cause not yet
been run down?


Richard

-------
/etc/rc.d/sshguard:
-------
#!/bin/sh
#
# $OpenBSD: sshguard.rc,v 1.1 2011/03/07 17:44:16 rpointel Exp $

daemon="/usr/local/sbin/sshguard"
daemon_flags="-l /var/log/authlog"

. /etc/rc.d/rc.subr

rc_bg=YES
rc_reload=NO

rc_cmd $1
-------

[Sshguard-users] OS X warnings

[LuKreme <kr...@kr...>]

com.apple.xpc.launchd[1] (org.macports.sshguard): The Debug key is no longer respected. Please remove it.
com.apple.xpc.launchd[1] (org.macports.sshguard): This service is defined to be constantly running and is inherently inefficient.

(OS X 10.10.2 and 10.10.3beta)

Anything to be concerned about?

-- 
Supposing there was justice for all, after all? For every unheeded
beggar, every harsh word, every neglected duty, every slight... every
choice... Because that was the point, wasn't it? You had to choose. You
might be right, you might be wrong, but you had to choose, knowing that
the rightness or wrongness might never be clear or even that you were
deciding between two sorts of wrong, that there was no right anywhere.
And always, always, you did it by yourself. You were the one there, on
the edge, watching and listening. Never any tears, never any apology,
never any regrets... You saved all that up in a way that could be used
when needed. --Carpe Jugulum

Re: [Sshguard-users] OSX - sshguard 1.5 not picking up all attack signatures

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

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

On 02/10/2015 19:23, Bradley Giesbrecht wrote:
> Done. MacPorts is now building with 95f80c8 from BitBucket.
> 
> http://trac.macports.org/changeset/132790

Fantastic, thanks! If you encounter any bugs or other suggestions,
please do report them here.

Best,
Kevin Zheng

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

iQEcBAEBCAAGBQJU29mOAAoJEOrPD3bCLhCQ6uQH+wfvNqMH1obzfkY7h84wG4Sj
JAsZ3QLD23PuNRlzhyNuwHNkdCzzplMB+tlnSLQDeWcIJXbDWcV7QuPkTiz5NbTH
oEa/bW4TqMUaroHmsYG9DguaiMsBq3xzzlEMlVHN+B3I0PvGYiSua3AnEenZc22r
yi3ffgUMfhzb8S2GhtWveADHEu4zpb21Eg1vQL7K8cPppZ0iZWyBURDPWUJXH5eR
hotYu2tnv7WEIEEVZes7qLyqaliR+eqyDnl4rHcbkl5YqMde8JWQeHd5UsdUvhVs
4i4KeXrqv5nfOxQS5Y2kuv6GnCm0R/fL65V7J3nfUdARYIFE+05bm1rF6XqU3S4=
=hKEw
-----END PGP SIGNATURE-----