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