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

[Sshguard-users] On initiating sshguard

[Rick H. <ri...@ta...>]

Hi list!

n00b question here.  I'm on FreeBSD 10.1 and running the ipfw firewall.  I
installed the sshguard-ipfw package; so I'm assuming that was the right
thing to do to start.

My confusion is that I seem to see two different ways to launch/run
sshguard.  One is from syslogd in syslog.conf, e.g.

auth.info;authpriv.info |/usr/local/sbin/sshguard [options here]

and another is to run sshguard as daemon from (the package installed)
/usr/local/etc/rc.d/sshguard script, which tells sshguard to read auth.log.
(And is a very nicely documented script to boot BTW.)

Both methods together *seem* redundant, but how should I be running
sshguard: both ways or only one way (i.e. but not the other)?

I RTFM but didn't notice this detail.  I apologize if I missed something in
the reading.

Thanks for your help, --Rick

Re: [Sshguard-users] fedora21 systemd and journalctl with sshguard

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

I use sshguard on FC 21. Below is the systemd unit file I use. You should
copy it to /etc/systemd/system/sshguard.service. Edit the ExecStart lineto
use the command line you want, be sure to use the correct path to sshguard,
yours might be /usr/local/sbin/sshguard
Then make sure the running systemd finds the new file ala "systemctl
daemon-reload'. You can start sshguard just once with 'systemctl start
sshguard' and use 'systemctl status sshguard' to verify it loaded without
problems. To have systemd start sshguard on boot use 'systemctl enable
sshguard'.

systemd is much more complicated than bsd init or sysv init, but it really
does have some useful features. As you can see this unit file will restart
the daemon should it exit or crash. Systemd is also integrated with
containers allowing it to easily start each daemon in an isolated
environment.


#
# sshguard systemd unit
#
#

[Unit]
Description=Ssh Guard dynamic firewall against brute force attempts
After=syslog.target
After=iptables.target
After=ip6tables.target
After=libvirtd.service
After=firewalld.service

[Service]
ExecStart=/usr/sbin/sshguard -w /etc/sshguard.whitelist -l /var/log/secure
-b 60:/var/db/sshguard/blacklist.db
Restart=always

[Install]
WantedBy=multi-user.target





On Tue, May 12, 2015 at 1:17 PM, Jason M <jk...@gm...> wrote:

> I upgraded fedora13 to fedora21 and am having a difficulty setting up the
> sshguard.  Unlike fedora13, fedora21 uses systemd and journalctl, and I
> need some guide how to set up the sshguard.  I downloded and compiled
> sshguard 1.5 version since I could not find the 64bit rpm version for
> fedora21.
>
> Thank you very much.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>


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

Re: [Sshguard-users] Subject: Re: Username Blacklisting

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

Many of the logs already parsed include usernames so it sounds like
adjusting the lexer/ parser expressions to pick out the name and include
them in the values passed back. Since we already have internet scales for
block and black list a simple integer multiplier should work for vouching
up the threat level.

I would suggest something like
Username:multiplier
Which keeps it paswd like. We could add more values in the future. In
addition to a multiplier I could see someone wanting to just set a value
instead of using multipliers.

Username:multiplier:setvalue

root::100
bob:2:

Setting any root attempt to 100 threat level and doubling the value Bob
would otherwise get.
On May 15, 2015 9:16 AM, "Kevin Zheng" <kev...@gm...> wrote:

> On 05/15/2015 10:58, Laurence Perkins (OE) wrote:
> > It would pretty well have to be added as a configuration at runtime
> > since the list of prohibited usernames would vary per system.
>
> Perhaps a flat text file, with one username per line?
>
> > My original thought was to have a list where even attempting to log in
> > with one of the names resulted in an immediate block.  E.g.: The root
> > account on my machine is disabled.  Anyone who even attempts to use it
> > is necessarily an unauthorized attacker and should be blocked
> > immediately.  There is no reason to wait for them to try more than once
> > (or even to let them finish the first attempt really).  Same thing goes
> > for various other account names that are commonly tested by attackers
> > and that don't even exist on my machine.  User accounts that do exist
> > where someone could legitimately be having trouble remembering their
> > password need to not lock the user out for fat-fingering their password
> > a couple of times though.
>
> Makes sense. Especially at the point which a user account (e.g. root) is
> disabled, any attempted login is certainly an attack.
>
> > If the list were implemented as a "danger multiplier" then it could be
> > calibrated so that root login attempts get blocked instantly, logins to
> > my account get blocked after just a couple of attempts, and logins to
> > some of my more absent-minded users get a little extra grace.  It's
> > probably not worth going to a lot of extra trouble to implement it this
> > way, but if username blacklisting is easiest to do by adjusting the
> > danger for listed accounts then reading a custom multiplier from the
> > account list for each account wouldn't take much more effort.  Just
> > being able to blacklist accounts, however, would eliminate the vast
> > majority of attackers as nearly all of them seem to hit the same list of
> > default usernames.
>
> Actually, most of the work is probably going to be extracting the
> username and passing it to the attack reporter. I'll start working on a
> proof-of-concept soon and keep you updated.
>
> Thanks,
> Kevin Zheng
>
> --
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

Re: [Sshguard-users] Subject: Re: Username Blacklisting

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

On 05/15/2015 10:58, Laurence Perkins (OE) wrote:
> It would pretty well have to be added as a configuration at runtime
> since the list of prohibited usernames would vary per system.

Perhaps a flat text file, with one username per line?

> My original thought was to have a list where even attempting to log in
> with one of the names resulted in an immediate block.  E.g.: The root
> account on my machine is disabled.  Anyone who even attempts to use it
> is necessarily an unauthorized attacker and should be blocked
> immediately.  There is no reason to wait for them to try more than once
> (or even to let them finish the first attempt really).  Same thing goes
> for various other account names that are commonly tested by attackers
> and that don't even exist on my machine.  User accounts that do exist
> where someone could legitimately be having trouble remembering their
> password need to not lock the user out for fat-fingering their password
> a couple of times though.

Makes sense. Especially at the point which a user account (e.g. root) is
disabled, any attempted login is certainly an attack.

> If the list were implemented as a "danger multiplier" then it could be
> calibrated so that root login attempts get blocked instantly, logins to
> my account get blocked after just a couple of attempts, and logins to
> some of my more absent-minded users get a little extra grace.  It's
> probably not worth going to a lot of extra trouble to implement it this
> way, but if username blacklisting is easiest to do by adjusting the
> danger for listed accounts then reading a custom multiplier from the
> account list for each account wouldn't take much more effort.  Just
> being able to blacklist accounts, however, would eliminate the vast
> majority of attackers as nearly all of them seem to hit the same list of
> default usernames.

Actually, most of the work is probably going to be extracting the
username and passing it to the attack reporter. I'll start working on a
proof-of-concept soon and keep you updated.

Thanks,
Kevin Zheng

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

[Sshguard-users] Subject: Re: Username Blacklisting

[Laurence P. (OE) <lpe...@op...>]

Message-ID: <555...@gm...>


> >> Having the option of scoring certain usernames as high danger
> attempts,
> >> or perhaps as danger 1+fractional multipliers, could be a clean way
> to
> >> implement such a feature.
> > 
> > I hadn't thought of doing it that way, but that would likely be more
> useful as you could
> > use it to set up multiple, different levels of paranoia for
> different users.  Especially
> > if you can use a fractional multiplier to effectively raise the
> threshold for guest accounts
> > and the like.
> 
> How would this work? Raise the danger of the attack so that two
> attempted logins with 'root' or similar usernames would be blocked?
> How
> would SSHGuard know which usernames to do this for? Would it be built
> into the binary, or added as a configuration at run-time?
> 
> (With your use case, why not just lower the blocking threshold?)
> 
> Thanks,
> Kevin Zheng

It would pretty well have to be added as a configuration at runtime
since the list of prohibited usernames would vary per system.

My original thought was to have a list where even attempting to log in
with one of the names resulted in an immediate block.  E.g.: The root
account on my machine is disabled.  Anyone who even attempts to use it
is necessarily an unauthorized attacker and should be blocked
immediately.  There is no reason to wait for them to try more than once
(or even to let them finish the first attempt really).  Same thing goes
for various other account names that are commonly tested by attackers
and that don't even exist on my machine.  User accounts that do exist
where someone could legitimately be having trouble remembering their
password need to not lock the user out for fat-fingering their password
a couple of times though.

If the list were implemented as a "danger multiplier" then it could be
calibrated so that root login attempts get blocked instantly, logins to
my account get blocked after just a couple of attempts, and logins to
some of my more absent-minded users get a little extra grace.  It's
probably not worth going to a lot of extra trouble to implement it this
way, but if username blacklisting is easiest to do by adjusting the
danger for listed accounts then reading a custom multiplier from the
account list for each account wouldn't take much more effort.  Just
being able to blacklist accounts, however, would eliminate the vast
majority of attackers as nearly all of them seem to hit the same list of
default usernames.


LMP

Re: [Sshguard-users] fedora21 systemd and journalctl with sshguard

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

On 05/12/2015 15:17, Jason M wrote:
> I upgraded fedora13 to fedora21 and am having a difficulty setting up
> the sshguard.  Unlike fedora13, fedora21 uses systemd and journalctl,
> and I need some guide how to set up the sshguard.  I downloded and
> compiled sshguard 1.5 version since I could not find the 64bit rpm
> version for fedora21.

Does Fedora ship with startup scripts for SSHGuard? If so, you're
probably better off using those.

If your logs go to files, this is what you can do:

# sshguard -l /var/log/auth.log -l /other/log/files

If not, I don't know enough about systemd and journalctl to help.

Best,
Kevin Zheng

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

Re: [Sshguard-users] Username Blacklisting

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

On 05/11/2015 12:06, Laurence Perkins (OE) wrote:
> The CPU penalty comes primarily from doing all the calculations to set up the 
> encrypted channel and secondarily from hashing the password for verification.  
> (The order of those two subject to change depending on encryption settings)
> Setting SSH to block certain usernames eliminates the latter, but you still have 
> the first one.  On my old C3 machine (roughly equivalent power to a Raspberry Pi) 
> setting up the encrypted channel took it about 2-3 seconds. (I like large keys)  
> I started using SSHguard because the rapid-fire login attempts were redlining my 
> CPU and making the machine more-or-less useless (except, maybe, as a toaster...)

Makes sense; this is one of the things SSHGuard was designed to prevent.

>> Having the option of scoring certain usernames as high danger attempts,
>> or perhaps as danger 1+fractional multipliers, could be a clean way to
>> implement such a feature.
> 
> I hadn't thought of doing it that way, but that would likely be more useful as you could
> use it to set up multiple, different levels of paranoia for different users.  Especially
> if you can use a fractional multiplier to effectively raise the threshold for guest accounts
> and the like.

How would this work? Raise the danger of the attack so that two
attempted logins with 'root' or similar usernames would be blocked? How
would SSHGuard know which usernames to do this for? Would it be built
into the binary, or added as a configuration at run-time?

(With your use case, why not just lower the blocking threshold?)

Thanks,
Kevin Zheng

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

[Sshguard-users] fedora21 systemd and journalctl with sshguard

[Jason M <jk...@gm...>]

I upgraded fedora13 to fedora21 and am having a difficulty setting up the
sshguard.  Unlike fedora13, fedora21 uses systemd and journalctl, and I
need some guide how to set up the sshguard.  I downloded and compiled
sshguard 1.5 version since I could not find the 64bit rpm version for
fedora21.

Thank you very much.

Re: [Sshguard-users] Username Blacklisting

[Laurence P. (OE) <lpe...@op...>]

Attempting two birds with one message...

>Date: Fri, 8 May 2015 11:46:15 -0600
>From: Richard Johnson <rjt...@sa...>
>Subject: Re: [Sshguard-users] Username Blacklisting
>To: ssh...@li...
>Message-ID: <201...@ri...>
>Content-Type: text/plain; charset=us-ascii>>

>On Fri, May 08, 2015 at 12:20:46PM -0500, Kevin Zheng wrote:
>> On 05/08/2015 11:51, Laurence Perkins (OE) wrote:
>> > While we're discussing potential new features, I've noticed that nearly
>> > all attackers hit the same list of default usernames (root, pi, ubuntu,
>> > etc.)

>> Sounds interesting, especially with the use case you describe (running
>> on a Raspberry Pi). Have you taken a look at OpenSSH settings like
>> AllowUsers or DenyUsers? Do those incur the same CPU penalty?

The CPU penalty comes primarily from doing all the calculations to set up the 
encrypted channel and secondarily from hashing the password for verification.  
(The order of those two subject to change depending on encryption settings)
Setting SSH to block certain usernames eliminates the latter, but you still have 
the first one.  On my old C3 machine (roughly equivalent power to a Raspberry Pi) 
setting up the encrypted channel took it about 2-3 seconds. (I like large keys)  
I started using SSHguard because the rapid-fire login attempts were redlining my 
CPU and making the machine more-or-less useless (except, maybe, as a toaster...)

>> 
>> This sounds useful; I'll start poking around soon.


>Having the option of scoring certain usernames as high danger attempts,
>or perhaps as danger 1+fractional multipliers, could be a clean way to
>implement such a feature.

I hadn't thought of doing it that way, but that would likely be more useful as you could
use it to set up multiple, different levels of paranoia for different users.  Especially
if you can use a fractional multiplier to effectively raise the threshold for guest accounts
and the like.



LMP

Re: [Sshguard-users] Username Blacklisting

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

That makes sense. So long as the whitelist is applied first. I can specify
the few machines I might rarely ssh in as root from all others would would
most likely be attacks.

How would this apply to other log scanning would there be other regex that
should increase the fractional attack value? For example are there http
paths that are common targets of exploit?
On May 8, 2015 11:03 AM, "Richard Johnson" <
rjt...@sa...> wrote:

> On Fri, May 08, 2015 at 12:20:46PM -0500, Kevin Zheng wrote:
> > On 05/08/2015 11:51, Laurence Perkins (OE) wrote:
> > > While we're discussing potential new features, I've noticed that nearly
> > > all attackers hit the same list of default usernames (root, pi, ubuntu,
> > > etc.)  It would be useful to be able to specify a list of usernames
> that
> > > result in an immediate block without waiting for the login to fail.
> > > (Processing the login attempt uses a not-insignificant amount of CPU on
> > > low-end machines like a Raspberry Pi.  Blocking the connection
> > > immediately would save quite a bit.)
> >
> > Sounds interesting, especially with the use case you describe (running
> > on a Raspberry Pi). Have you taken a look at OpenSSH settings like
> > AllowUsers or DenyUsers? Do those incur the same CPU penalty?
> >
> > This sounds useful; I'll start poking around soon.
>
>
> Having the option of scoring certain usernames as high danger attempts,
> or perhaps as danger 1+fractional multipliers, could be a clean way to
> implement such a feature.
>
>
> Richard
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

Re: [Sshguard-users] Username Blacklisting

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

On Fri, May 08, 2015 at 12:20:46PM -0500, Kevin Zheng wrote:
> On 05/08/2015 11:51, Laurence Perkins (OE) wrote:
> > While we're discussing potential new features, I've noticed that nearly
> > all attackers hit the same list of default usernames (root, pi, ubuntu,
> > etc.)  It would be useful to be able to specify a list of usernames that
> > result in an immediate block without waiting for the login to fail.
> > (Processing the login attempt uses a not-insignificant amount of CPU on
> > low-end machines like a Raspberry Pi.  Blocking the connection
> > immediately would save quite a bit.)
> 
> Sounds interesting, especially with the use case you describe (running
> on a Raspberry Pi). Have you taken a look at OpenSSH settings like
> AllowUsers or DenyUsers? Do those incur the same CPU penalty?
> 
> This sounds useful; I'll start poking around soon.


Having the option of scoring certain usernames as high danger attempts,
or perhaps as danger 1+fractional multipliers, could be a clean way to
implement such a feature.


Richard

Re: [Sshguard-users] Username Blacklisting

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

On 05/08/2015 11:51, Laurence Perkins (OE) wrote:
> While we're discussing potential new features, I've noticed that nearly
> all attackers hit the same list of default usernames (root, pi, ubuntu,
> etc.)  It would be useful to be able to specify a list of usernames that
> result in an immediate block without waiting for the login to fail.
> (Processing the login attempt uses a not-insignificant amount of CPU on
> low-end machines like a Raspberry Pi.  Blocking the connection
> immediately would save quite a bit.)

Sounds interesting, especially with the use case you describe (running
on a Raspberry Pi). Have you taken a look at OpenSSH settings like
AllowUsers or DenyUsers? Do those incur the same CPU penalty?

This sounds useful; I'll start poking around soon.

Best,
Kevin Zheng

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

Re: [Sshguard-users] Username Blacklisting

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

This feels like something that would be better handled with PAM.  Maybe it
would be enhanced by providing a flat file 'firewall' backend, something
like hosts.deny PAM could reference.
On May 8, 2015 10:06 AM, "Laurence Perkins (OE)" <lpe...@op...>
wrote:

> While we're discussing potential new features, I've noticed that nearly
> all attackers hit the same list of default usernames (root, pi, ubuntu,
> etc.)  It would be useful to be able to specify a list of usernames that
> result in an immediate block without waiting for the login to fail.
> (Processing the login attempt uses a not-insignificant amount of CPU on
> low-end machines like a Raspberry Pi.  Blocking the connection
> immediately would save quite a bit.)
>
> LMP
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

[Sshguard-users] Username Blacklisting

[Laurence P. (OE) <lpe...@op...>]

While we're discussing potential new features, I've noticed that nearly
all attackers hit the same list of default usernames (root, pi, ubuntu,
etc.)  It would be useful to be able to specify a list of usernames that
result in an immediate block without waiting for the login to fail.
(Processing the login attempt uses a not-insignificant amount of CPU on
low-end machines like a Raspberry Pi.  Blocking the connection
immediately would save quite a bit.)

LMP

Re: [Sshguard-users] init scripts, large blocks, hit counts

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

On 05/06/2015 15:46, James Harris wrote:
> I see the freebsd init script was removed from the repo. Was the script
> removed because it is broken or unwanted? I have a systmed unit file
> that I have been debating make a pull-up request for. I thought if at
> least an example unit file was included we might be able to encourage
> others to package sshguard for their preferred OS/distro.

Mostly because the FreeBSD startup script is being maintained outside of
the SSHGuard tree. What was left in the repository was a very old
version that once upon a time was in the FreeBSD ports tree. Since
startup scripts tend to be OS-specific, I decided to take it out.

I'm not sure what to feel about a systemd unit file. It sounds like it
could be useful for every Linux distribution that uses systemd, and
wouldn't hurt anyone else. Different OSes are probably going to make
distro specific changes, though.

Full disclosure: I'm a FreeBSD user, so I'm inherently biased against
systemd. I don't have any convincing arguments against it, though,
except that I *did* take out the FreeBSD startup script.

> On another topic. I have see my current loaded blacklist is up to about
> 1260 addresses. Out curiosity I started writing some scripts to do some
> analysis of the  IPs. My thought was maybe people that get issued a DHCP
> address from their provider start to reject addresses until till they
> get a new one that hasn't been blocked by their targets. I would guess
> those addresses are rather close to each other or at least issued to the
> same AS. If many attacks came from the same net block it would be faster
> to block a range of addresses. Fewer rules should make the firewall
> faster also it would be proactive blocking the other addresses they are
> likely to get. Sorting by AS I can see I have 39 hits from AS12876 from
> France which has 4 allocations but most of my hits are from only one.
> From AS4837 I have 38 blacklisted but they have several /16 or /15
> ranges and my hits come from across many of them.  From AS4134 I have 
> 452 black listed and they also also have 20some /15/ or /16 allocated
> blocks. I can provide the scripts if anyone is interested. I pulled the
> AS data from Team cymru via their dns
> gateway http://www.team-cymru.org/IP-ASN-mapping.html#dns.

This proposal sounds promising. The biggest hurdle was getting block
information from IP addresses (a WHOIS on every incoming attacker
doesn't sound like a good plan). With DNS this seems more feasible.

So would attacks be recorded on a per-address-block basis? What if an
attacker sitting on a huge public block (say, a university's class A)
gets the block blacklisted. Isn't this a denial of service?

> Finally I was looking over the iptables capabilities and it looks like
> it is possible to get hit count on rules.I would suspect most of the
> backend support this. Would there be interest in adding hit count thrush
> holds to the temporary blocks, black listing  promotions? So as the
> temporary rules continue to receive hits they should stay in place
> resetting the expire timer and given enough hits be promoted to a
> blacklist. Instead of waiting for several violations to occur only one
> may be needed. Then as the rule is continued to be triggered by likely
> attacks it can be extended or made permanent never opening the service
> back to the attacker.

Perhaps. Again, this circles back to the issue of blacklists. I tend to
not like permanent blacklisting because dynamic IPs can be recycled very
frequently. One could argue that instead of using SSHGuard, a
low-traffic host might be better off blocking IP blocks from (insert
your favorite botnet region here) on a firewall.

But again, I'm super biased and am aware that some features would be
useful to SSHGuard even though *I* don't use them. I'm really interested
in hearing opinions on this.

Thanks,
Kevin Zheng

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

[Sshguard-users] init scripts, large blocks, hit counts

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

I see the freebsd init script was removed from the repo. Was the script
removed because it is broken or unwanted? I have a systmed unit file that I
have been debating make a pull-up request for. I thought if at least an
example unit file was included we might be able to encourage others to
package sshguard for their preferred OS/distro.

On another topic. I have see my current loaded blacklist is up to about
1260 addresses. Out curiosity I started writing some scripts to do some
analysis of the  IPs. My thought was maybe people that get issued a DHCP
address from their provider start to reject addresses until till they get a
new one that hasn't been blocked by their targets. I would guess those
addresses are rather close to each other or at least issued to the same AS.
If many attacks came from the same net block it would be faster to block a
range of addresses. Fewer rules should make the firewall faster also it
would be proactive blocking the other addresses they are likely to get.
Sorting by AS I can see I have 39 hits from AS12876 from France which has 4
allocations but most of my hits are from only one. From AS4837 I have 38
blacklisted but they have several /16 or /15 ranges and my hits come from
across many of them.  From AS4134 I have
452 black listed and they also also have 20some /15/ or /16 allocated
blocks. I can provide the scripts if anyone is interested. I pulled the AS
data from Team cymru via their dns gateway
http://www.team-cymru.org/IP-ASN-mapping.html#dns.

Finally I was looking over the iptables capabilities and it looks like it
is possible to get hit count on rules.I would suspect most of the backend
support this. Would there be interest in adding hit count thrush holds to
the temporary blocks, black listing  promotions? So as the temporary rules
continue to receive hits they should stay in place resetting the expire
timer and given enough hits be promoted to a blacklist. Instead of waiting
for several violations to occur only one may be needed. Then as the rule is
continued to be triggered by likely attacks it can be extended or made
permanent never opening the service back to the attacker.









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

[Sshguard-users] Build fix for SSHGuard 1.6.0 using 'ipfw' and 'hosts' backends

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

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

This is an errata notice for the SSHGuard 1.6.0 release:

## Problem ##

SSHGuard supports one of several firewall backends; of these, the
'ipfw' and 'hosts' backends failed to build due to a missing header
file after some code reorganization prior to the 1.6.0 release.

There is no workaround available; however, users who are not using the
'ipfw' or 'hosts' backends are not affected.

## Solution ##

Those who are affected should apply the attached patch against the
1.6.0 release tarball, or track the 1.6 branch on Bitbucket.

## Credits ##

Thanks to Mark Felder <fe...@Fr...> for reporting this issue.

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

iQEcBAEBCAAGBQJVR+okAAoJEOrPD3bCLhCQlgQH+wUWoWLdBhzcppnc3CZ6eXol
CA+5uHa0+cuYdouTjqW5tayGOO8JT6Ng7ydw5tML6CjtBDRJ8aWIHeJcUI9l4yA3
htAD+CxhxJ4l2rWy0Upz1kLb0ylGkNfk8tE56oSwYlLCYptVGeIMw3OQhPI8gnpb
ZJt2YHpiS+Cf/qjhsmKQ6N9/8Tf7H8dZRXhUK5zhZ8LZ4ZQPJf2+1le3DMOy08P1
UjoQivl6Vh6m3ea3Cu9L3DLh2oqRfrh9ixYmkcPWIKKPO0Xnz1jPy8BF5NoTyGt2
KlsFKzbwKablGNOxUrEVaPEp48VP1heTVGsjHYfVK7CNp0yDtOvLBsvjAgWCORE=
=/iDp
-----END PGP SIGNATURE-----

Re: [Sshguard-users] SSHGuard 1.6.0 release announcement

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

On Sat, May 02, 2015 at 02:17:12PM -0500, Kevin Zheng wrote:
> 
> Greetings,
> 
> On behalf of the SSHGuard Team, it is my pleasure to announce the
> 1.6.0 release. This release is the first in the 1.6 branch and comes
> after more than four years of development.
> 

Fails to build with Clang due to missing include statement

hosts.c:47:15: error: use of undeclared identifier 'ADDRLEN'
    char addr[ADDRLEN];
              ^
hosts.c:234:22: error: use of undeclared identifier 'ADDRKIND_IPv4'
                case ADDRKIND_IPv4:
                     ^
hosts.c:238:22: error: use of undeclared identifier 'ADDRKIND_IPv6'
                case ADDRKIND_IPv6:
                     ^
3 errors generated.


See attached.


Thanks!

[Sshguard-users] SSHGuard 1.6.0 release announcement

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

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

Greetings,

On behalf of the SSHGuard Team, it is my pleasure to announce the
1.6.0 release. This release is the first in the 1.6 branch and comes
after more than four years of development.

This release is tagged as 'v1.6.0' 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 PGP
key as this announcement (0xC22E1090).

Notable changes in this release include:

- - Add rules for Postfix SASL login attempts
- - Add support for ISO 8601 timestamps (David Caldwell)
- - Add support for external commands run on firewall events (-e)
- - Blacklist file is now human-readable (Armando Miraglia)
- - Check tcpwrapper file permissions regardless of local umask
- - Detect additional pre-auth disconnects
- - Fix ipfw crash when loading an empty blacklist (Jin Choi)
- - Fix log parsing on days beginning with zero
- - Fix log polling on filesystems with many files (Johann H. Hauschild)
- - Fix matching for Cyrus IMAP login via SASL
- - Fix syslog format detection on hosts with undefined hostname
- - Match SSH login failures with "via" suffix
- - Remove broken kqueue(2) support
- - Tweak option names and help strings
- - Update SSH "Bad protocol" signature
- - Use case-insensitive "invalid user" signature
- - Wait for xtables lock when using iptables command (James Harris)

Please report any bugs, build failures, or OS-specific issues to the
mailing list or to the Bitbucket tracker [3].

Cheers,
Kevin Zheng

[1] https://bitbucket.org/sshguard/sshguard/commits/tag/v1.6.0
[2] https://sourceforge.net/projects/sshguard/files/sshguard/1.6.0/
[3] https://bitbucket.org/sshguard/sshguard/issues/

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

iQEcBAEBCAAGBQJVRSK1AAoJEOrPD3bCLhCQvjAIANAD/Pfs3Etf2dwiztfsDUOo
VLdReSUj8B1wdxo58joIDde7muhdnfmRnrx9dwFZ9FScrQCVoYJUuBKkwy9tRBAy
hYjO/Zu6jmFaUvYmnAa2Z7accHTJZpnztd9vEsHK/xV9/4wLbnJi+biUoz0PY2AH
4YNNWh4EHbkOd4o/ZkDbmxf9MjXkmraPKSIFcklkyUydqbDI4QGodLZ0ZkvwoJPc
fY0lJGd/FonlfJOFdHahTR6xKwrNZ5XeRq8RgpX5AKt71VfRd6XMmMma/8HS9wCq
8IJFZogpWPO27X7seCb3WEsBRoUWP+hY+NVIxCmkBPQezphG0wfz6j9S9b9hB24=
=eBK+
-----END PGP SIGNATURE-----

[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