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

[Sshguard-users] SSHGuard 1.6-rc1 release candidate announcement

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

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

Hi all,

It is my pleasure to announce the first release candidate for 1.6.
This release candidate is expected to become the 1.6.0 release.

This release candidate is tagged as 'v1.6-rc1' on Bitbucket [1] and
source tarballs are available from SourceForge [2]. Tarballs are
available in both `gzip` and `xz` formats. Checksums are signed with
the same key as this announcement (0xC22E1090).

For a list of user-visible changes, please see 'ChangeLog'.

Please report any bugs, build failures, or OS-specific issues to the
mailing list or to the Bitbucket tracker [3]. Unless critical issues
are uncovered, expect the 1.6.0 release within a week.

Thanks,
Kevin Zheng

[1] https://bitbucket.org/sshguard/sshguard/commits/tag/v1.6-rc1
[2] https://sourceforge.net/projects/sshguard/files/sshguard/1.6-rc1/
[3] https://bitbucket.org/sshguard/sshguard/issues/

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

iQEcBAEBCAAGBQJVO9KhAAoJEOrPD3bCLhCQu4gH/382KUIhPV6uooBlNNas/DgO
mW4HPgQrodsP8+rCivtrz8AgOoPVhGgftMN9Lyp1pMsFhZMAm9z828LYG7hpd9uS
vjr7Q74+y68veb/AhqKi2MLWmNcmQW2Spe0Q7HoLdlbx5ygeObrm1dr/ABLwCWnF
2znys8jX+i7iK5vmtLGzwhHhQQctoaPoHP5g7sDoggdZMv8FegkOKZFZCvJllNrE
YsF3w6y2TYu17+dLXbs+jwJmUIA7UNqNNnr8vEAjJkPOQTjHnp88TNeYSZYObfNj
DM+E2HGoAO+8NedOptwWOeot126jEf854gHYhiTVfhrHR04xyZEmKvbU+bOWto0=
=o574
-----END PGP SIGNATURE-----

Re: [Sshguard-users] welcome Kevin!

[Bradley G. <pi...@ma...>]

On Apr 20, 2015, at 10:52 PM, mij <mi...@ss...> wrote:

> Dear SSHGuard users,
> 
> The more attentive of you will have notice two changes recently:
> 
> 1. activity started on a separate codebase on BitBucket
> 2. most of this activity has been contributed by a “Kevin”, in code and ML
> 
> # BitBucket
> 
> We decided to switch to a distributed repo to make it easier to track
> user contribs. We have been trialling BB for the past 2 months with great results,
> and we’ll probably reflect it as official mainline in a matter of days now.
> 
> https://bitbucket.org/sshguard/sshguard
> 
> # Kevin
> 
> Kevin contacted the team a few months ago with some patches and kept
> up his contributions with consistency, competence, and friendliness.
> Since last week he’s member of the core team as kevin@ .
> 
> Welcome Kevin!

Fantastic, Bitbucket/Mercurial is great and welcome Kevin!

Regards,
Bradley Giesbrecht (pixilla)

[Sshguard-users] welcome Kevin!

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

Dear SSHGuard users,

The more attentive of you will have notice two changes recently:

1. activity started on a separate codebase on BitBucket
2. most of this activity has been contributed by a “Kevin”, in code and ML

# BitBucket

We decided to switch to a distributed repo to make it easier to track
user contribs. We have been trialling BB for the past 2 months with great results,
and we’ll probably reflect it as official mainline in a matter of days now.

https://bitbucket.org/sshguard/sshguard

# Kevin

Kevin contacted the team a few months ago with some patches and kept
up his contributions with consistency, competence, and friendliness.
Since last week he’s member of the core team as kevin@ .

Welcome Kevin!

cheers
michele

[Sshguard-users] SSHGuard 1.6 Roadmap

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

Hi all,

It's been four years since the 1.5 release. Since then, there have been
a series of bug fixes, improvements, and attack signature updates.

In the coming few days I would like to tag the 1.6 branch in preparation
for the 1.6.0 release. Until then, the 'master' branch on Bitbucket [1]
reflects what will be in the next release. I encourage everyone,
especially package maintainers, to clone or download a snapshot of the
repository and give it a whirl.

We've received a lot of patches and issue reports. These *are* being
taken care of, albeit a little slowly. If there are patches or bugs that
should really be fixed in 1.6.0, please feel free to submit them to the
mailing list or the Bitbucket issue tracker [2].

As always, feedback is immensely appreciated. Please send mail to the
users mailing list if you encounter crashes, bugs, or other issues.

Thanks,
Kevin Zheng

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

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

[Sshguard-users] Heads up: repository history changes

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

Hi all,

Two weeks ago I bungled two merges using the pull requests interface. I
made changes to commit messages but opted to merge the requests via the
web interface anyways. This has created redundant commits as well as
merges that confuse the history. I'm sorry.

To fix this I would like to rewrite history. The history up to and
including 'ca544f8' will not change. The two pull requests are still
there, only with slightly edited commit messages.

The next time you update your repository, do not pull. Instead:
$ git fetch; git rebase

Sorry for the pain and suffering caused. It will not happen again.

Thanks,
Kevin Zheng

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

Re: [Sshguard-users] compiler warnings -D_XOPEN_SOURCE

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

> 
> 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.

A radical change like switching feature test macros should be tested before
committing. It doesn’t always work as expected.


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

All should, but careful what Automake inherits.

-m

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