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

Re: [Sshguard-users] configuration options

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

On 02/14/2016 10:14, dt...@gm... wrote:
>    (1) config file used to input/add to/change the regular expressions used to
>        trigger blocks

This would be a pretty significant change since most of SSHGuard's
functionality is compiled into the binary. I'll keep this in mind,
though; it needs to be a lot easier to add more attack signatures.

If this is something people are interested in, please comment!

>    (2) A good number of attackers figure out the blocking parameters and then
>        make a large number of requests at a rate that does not trigger
>        blocking. I use sshguard on closed systems (no external users) and open
>        systems, so my setting are very different as must (of my) users do not
>        use keys and mistype their passwords.

Yes, there needs to be a better way to classify attackers.

>        A nice addition would be a trigger that more than <n> failures per day
>        would trigger a block. The duration should also be optional but at
>        least a day. It could be <n> attempts on more than <m> users.
> 
> And on a much lower priority: a utility to prune the black list. Now I use the 
> blacklist only on closed systems.

My thinking right now is to remove "blacklisting" as a special case and
simply treating them as a really like (say, 24 hour block). The
blacklist file could be replaced with a "SSHGuard state" file that saves
all current blocks so they can be reloaded if SSHGuard restarts.

Best,
Kevin

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

[Sshguard-users] configuration options

[<dt...@gm...>]

I just filled out the survey. Some things I did not see and would really find 
helpful:

   (1) config file used to input/add to/change the regular expressions used to
       trigger blocks

   (2) A good number of attackers figure out the blocking parameters and then
       make a large number of requests at a rate that does not trigger
       blocking. I use sshguard on closed systems (no external users) and open
       systems, so my setting are very different as must (of my) users do not
       use keys and mistype their passwords.

       A nice addition would be a trigger that more than <n> failures per day
       would trigger a block. The duration should also be optional but at
       least a day. It could be <n> attempts on more than <m> users.

And on a much lower priority: a utility to prune the black list. Now I use the 
blacklist only on closed systems.

I have a system sorely in need of updating because of access limitations. On 
that system I have some scripts to sorta do what sshguard does. That system
gets an order (or more) in magnitude more attacks. I look forward to getting 
there and updating that system.


_____
Douglas Denault
http://www.safeport.com
do...@sa...
Voice: 301-217-9220
   Fax: 301-217-9277

Re: [Sshguard-users] Support for Postfix ?

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

On 02/02/2016 06:11, Christophe Meessen wrote:
> I currently have some people trying to authenticate throuqh the port 25. 
> I suppose they try out default passwords.
> I get up to 100 attempts in a few tens of seconds and they retry every 
> hour. Fai2ban fails to detect and block them.
> There are also the ports 465 (SMTPS) and 587 with SASL authentication 
> which may fail. I currently don't have any failed connection attempts on 
> these ports, but this is just a matter of time.
> 
> I'm ready to switch from fail2ban to sshguard, but your web site doesn't 
> report a support of Postfix. This is a bit surprizing since many people 
> use Postfix. So my question is if sshguard supports Postfix protection.

At the moment, tentatively. SSHGuard only recognizes this SASL
authentication failure as an attack:

warning: unknown[1.2.3.4]: SASL LOGIN authentication failed:

If this is the one you're seeing SSHGuard should work fine. Just make
sure to feed it the appropriate log files.

Best,
Kevin

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

[Sshguard-users] Support for Postfix ?

[Christophe M. <chr...@me...>]

Hello,

I currently have some people trying to authenticate throuqh the port 25. 
I suppose they try out default passwords.
I get up to 100 attempts in a few tens of seconds and they retry every 
hour. Fai2ban fails to detect and block them.
There are also the ports 465 (SMTPS) and 587 with SASL authentication 
which may fail. I currently don't have any failed connection attempts on 
these ports, but this is just a matter of time.

I'm ready to switch from fail2ban to sshguard, but your web site doesn't 
report a support of Postfix. This is a bit surprizing since many people 
use Postfix. So my question is if sshguard supports Postfix protection.

-- 
Bien cordialement,

Ch.Meessen

Re: [Sshguard-users] SSHGuard user survey

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

On 01/28/2016 17:33, li...@la... wrote:
> I'll admit ignorance here. What is process validation I get too many
> hits from Google, and don't know enough to narrow the search.

You pass a list of files containing PIDs of "authoritative" processes.
SSHGuard then only acts on logs from those PIDs. This prevents sneaky
local users from being able to make SSHGuard block addresses.

> Otherwise the survey was a snap.

Thanks!

Best,
Kevin

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

Re: [Sshguard-users] SSHGuard user survey

[<li...@la...>]

I'll admit ignorance here. What is process validation I get too many hits from Google, and don't know enough to narrow the search. 

Otherwise the survey was a snap.


  Original Message  
From: Kevin Zheng
Sent: Thursday, January 28, 2016 3:37 PM
To: ssh...@li...; ssh...@li...
Reply To: ssh...@li...
Subject: [Sshguard-users] SSHGuard user survey

Dear SSHGuard users,

I've created a short survey to help understand how people use
SSHGuard. Among other things, I'm interested in which features,
operating systems, architectures, and services people use with SSHGuard.

Please take 2-3 minutes to take the survey here:

https://docs.google.com/forms/d/1UQHrtq7uhpopWDsNmvYyVbwKpupkgHAwcd3SwmTMaNc/viewform?usp=send_form

Summary results are available once you submit; however, they are
probably not very meaningful since at the time of writing only one
person (me) has taken it. If there are glaring errors or omissions
please report them here on the mailing list or to me directly.

Thanks,
Kevin

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

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users

[Sshguard-users] SSHGuard user survey

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

Dear SSHGuard users,

I've created a short survey to help understand how people use
SSHGuard. Among other things, I'm interested in which features,
operating systems, architectures, and services people use with SSHGuard.

Please take 2-3 minutes to take the survey here:

https://docs.google.com/forms/d/1UQHrtq7uhpopWDsNmvYyVbwKpupkgHAwcd3SwmTMaNc/viewform?usp=send_form

Summary results are available once you submit; however, they are
probably not very meaningful since at the time of writing only one
person (me) has taken it. If there are glaring errors or omissions
please report them here on the mailing list or to me directly.

Thanks,
Kevin

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

Re: [Sshguard-users] Dynamic hostnames in the whitelist

[Willem J. W. <wj...@di...>]

On 26-1-2016 04:49, Kevin Zheng wrote:
> On 01/25/2016 18:15, Don Coleman wrote:
>> Hm... never thought I'd need to defend the basic feature I was trying to 
>> improve -- I'd sort of figured that argument had already occurred and 
>> thus was moot.
> 
> Yeah, sorry about that. It's important to reevaluate once in a while.
> 
>> I understand your perspective on self-lockout and maybe just waiting a 
>> bit isn't such a bad solution -- though as I also use black listing, I'm 
>> a bit paranoid of being on a bad keyboard or ham fingered or something 
>> and getting black listed.   And my main server is in Berkeley and I'm in 
>> Barcelona... a more flexible or adaptable implementation of blocking 
>> could mitigate the need for black listing and the fear of lock-outs ... 
>> but is that really going to happen?
> 
> Ideally, there would be a blocking strategy that would obsolete both
> whitelisting and blacklisting. There shouldn't be literal blacklisting,
> either, just blocks with very long timeouts (e.g. 24 hours).
> 
> Just curious, why did you decide on blacklisting?
> 
>> A for doing it in the firewall ... well, a firewall is dealing with all 
>> sorts of traffic -- it needs a super fast response time and a very small 
>> foot print, and they're just *not* ever going to be doing a DNS query, 
>> so supporting directly dynamic ip addresses there is a non-starter.  
>> Protecting a service is something very different -- they're already 
>> heavy weight, and thus you can be relatively slow in responding.
> 
> Good point. DNS queries in a firewall is unthinkable.
> 
>> My plan would be to check/refresh the whitelist just before actually 
>> blocking something.  In the typical expected case, a dynamic name would 
>> always be expired and a static one wouldn't be -- the only reason really 
>> to pay attention to the TTL at all (one could just do a gethostbyname() 
>> every time), is to not increase measurably sshguard's load on a system 
>> when under a denial of service attack.
> 
> This seems reasonable. If you're interested, and you can compile from
> source, I can give you a patch to test.
> 
>> As for my particular usage, yes, I use both white and black listing.  I 
>> personally am not really concerned with ssh probes actually logging into 
>> my system (I have very good passwords)... I just want log files that are 
>> clean and only show me actual problems I need to pay attention to.  I 
>> already run sshd on a non-standard port.  My sshguard configuration is 
>> both slower to block something, and has a longer memory to decide to 
>> block (I find probers on non-standard ports are more sophisticated).
> 
> How often do these probes try to log in?
> 
>> My syslogd.conf conf pipe line is:
>>
>> |/usr/bin/grep -Fv --line-buffered $'Connection closed by\n for don from 
>> ' | /usr/local/sbin/sshguard -i /var/run/sshguard.pid -p 840 -s 3600 -w 
>> /usr/local/etc/sshguard.whitelist -b 160:/var/db/sshguard/blacklist.db
>>
>> The grep line keeps any aborted login attempts (no password ever 
>> provided) and any login attempts by don (me) from counting.
> 
> Ahh, you want to ignore aborted login attempts. I block aborted login
> attempts because my server only allows key logins, and so log noise for
> me are those aborted login attempts.
> 
>> 1) allow blocking state to be reset to zero on a successful login from a 
>> host.
> 
> I'll keep this in mind.
> 
>> 2) I've also thought about region based weighting of blocking -- probes 
>> from strange countries could be treated harshly...
> 
> Perhaps, but to me this seems somewhat out of scope for SSHGuard.
> 
>> I've only been using sshguard for a week, so I'm still learning... 
>> (though I've been using tcp/ip for decades ... and I'm still learning ;->).
> 
> Thanks for your comments and suggestions. They're definitely helpful.

I've had a previous discussion with Kevin before on semantics...
And the fact that sshguard calls them white/blacklist does not mean that
they are per default what they say they are....

The whitelist specifies the list of adresses that will not be entered
into the blocking strategy whatever they do. However that does not
warrant whitelisting in the classical sense. IF you want that, then you
actually have to implement a whitelist strategy in your firewall and add
whitelisted hosts there.
For example if you also run fail2ban, then fail2ban might detect a
violation and add the host. So now you have 2 places to keep whitelists
if used as such. Add some of the detecting tools from Wordpress and you
have one more list to maintain.
I would use the firewall(-config) for that.

The blacklist is a different baby here. It is the list with addresses
that have not yet expired they punishment term. And upon reloading
sshguard it reinstalls this list. I guess that you can abuse this and
manually add to this list as well.
But then again, that is actually to work that out with the firewall-config.

Sshguard is in essence an intrussion detection tool, and has been
elaborated with the possibility to interact with the firewall.
That does not forgo the fact that you will need a decent strategy in
your firewall on what to do with "the good, bad and the ugly"....

If you start mixing this, you could end up with a situation where you
are doing the right thing at the wrong place.

And IMHO you need to hardcode whitelisted hosts that need 100% always
access right in the first few lines of the firewall to prevent any
lockout. Now if those hosts have dynamic IPnrs, then you have to make
something to watch this and accordingly update the firewall rules.

FreeBSD has firewall tables, and I have reserved one of the tables to
contain host ipnrs that are host I personly administer, and thus trust a
little bit more than others. Thos I do not lookout in the firewall EVER.

--WjW

Re: [Sshguard-users] Dynamic hostnames in the whitelist

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

On 01/25/2016 18:15, Don Coleman wrote:
> Hm... never thought I'd need to defend the basic feature I was trying to 
> improve -- I'd sort of figured that argument had already occurred and 
> thus was moot.

Yeah, sorry about that. It's important to reevaluate once in a while.

> I understand your perspective on self-lockout and maybe just waiting a 
> bit isn't such a bad solution -- though as I also use black listing, I'm 
> a bit paranoid of being on a bad keyboard or ham fingered or something 
> and getting black listed.   And my main server is in Berkeley and I'm in 
> Barcelona... a more flexible or adaptable implementation of blocking 
> could mitigate the need for black listing and the fear of lock-outs ... 
> but is that really going to happen?

Ideally, there would be a blocking strategy that would obsolete both
whitelisting and blacklisting. There shouldn't be literal blacklisting,
either, just blocks with very long timeouts (e.g. 24 hours).

Just curious, why did you decide on blacklisting?

> A for doing it in the firewall ... well, a firewall is dealing with all 
> sorts of traffic -- it needs a super fast response time and a very small 
> foot print, and they're just *not* ever going to be doing a DNS query, 
> so supporting directly dynamic ip addresses there is a non-starter.  
> Protecting a service is something very different -- they're already 
> heavy weight, and thus you can be relatively slow in responding.

Good point. DNS queries in a firewall is unthinkable.

> My plan would be to check/refresh the whitelist just before actually 
> blocking something.  In the typical expected case, a dynamic name would 
> always be expired and a static one wouldn't be -- the only reason really 
> to pay attention to the TTL at all (one could just do a gethostbyname() 
> every time), is to not increase measurably sshguard's load on a system 
> when under a denial of service attack.

This seems reasonable. If you're interested, and you can compile from
source, I can give you a patch to test.

> As for my particular usage, yes, I use both white and black listing.  I 
> personally am not really concerned with ssh probes actually logging into 
> my system (I have very good passwords)... I just want log files that are 
> clean and only show me actual problems I need to pay attention to.  I 
> already run sshd on a non-standard port.  My sshguard configuration is 
> both slower to block something, and has a longer memory to decide to 
> block (I find probers on non-standard ports are more sophisticated).

How often do these probes try to log in?

> My syslogd.conf conf pipe line is:
> 
> |/usr/bin/grep -Fv --line-buffered $'Connection closed by\n for don from 
> ' | /usr/local/sbin/sshguard -i /var/run/sshguard.pid -p 840 -s 3600 -w 
> /usr/local/etc/sshguard.whitelist -b 160:/var/db/sshguard/blacklist.db
> 
> The grep line keeps any aborted login attempts (no password ever 
> provided) and any login attempts by don (me) from counting.

Ahh, you want to ignore aborted login attempts. I block aborted login
attempts because my server only allows key logins, and so log noise for
me are those aborted login attempts.

> 1) allow blocking state to be reset to zero on a successful login from a 
> host.

I'll keep this in mind.

> 2) I've also thought about region based weighting of blocking -- probes 
> from strange countries could be treated harshly...

Perhaps, but to me this seems somewhat out of scope for SSHGuard.

> I've only been using sshguard for a week, so I'm still learning... 
> (though I've been using tcp/ip for decades ... and I'm still learning ;->).

Thanks for your comments and suggestions. They're definitely helpful.

Best,
Kevin

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

Re: [Sshguard-users] Dynamic hostnames in the whitelist

[Don C. <do...@co...>]

Hm... never thought I'd need to defend the basic feature I was trying to 
improve -- I'd sort of figured that argument had already occurred and 
thus was moot.

I understand your perspective on self-lockout and maybe just waiting a 
bit isn't such a bad solution -- though as I also use black listing, I'm 
a bit paranoid of being on a bad keyboard or ham fingered or something 
and getting black listed.   And my main server is in Berkeley and I'm in 
Barcelona... a more flexible or adaptable implementation of blocking 
could mitigate the need for black listing and the fear of lock-outs ... 
but is that really going to happen?

A for doing it in the firewall ... well, a firewall is dealing with all 
sorts of traffic -- it needs a super fast response time and a very small 
foot print, and they're just *not* ever going to be doing a DNS query, 
so supporting directly dynamic ip addresses there is a non-starter.  
Protecting a service is something very different -- they're already 
heavy weight, and thus you can be relatively slow in responding.

sshguard can be much more relaxed ...  that's why it can use the whole 
sshd/syslogd/sshguard path, and still be useful.

My plan would be to check/refresh the whitelist just before actually 
blocking something.  In the typical expected case, a dynamic name would 
always be expired and a static one wouldn't be -- the only reason really 
to pay attention to the TTL at all (one could just do a gethostbyname() 
every time), is to not increase measurably sshguard's load on a system 
when under a denial of service attack.

As for my particular usage, yes, I use both white and black listing.  I 
personally am not really concerned with ssh probes actually logging into 
my system (I have very good passwords)... I just want log files that are 
clean and only show me actual problems I need to pay attention to.  I 
already run sshd on a non-standard port.  My sshguard configuration is 
both slower to block something, and has a longer memory to decide to 
block (I find probers on non-standard ports are more sophisticated).


My syslogd.conf conf pipe line is:

|/usr/bin/grep -Fv --line-buffered $'Connection closed by\n for don from 
' | /usr/local/sbin/sshguard -i /var/run/sshguard.pid -p 840 -s 3600 -w 
/usr/local/etc/sshguard.whitelist -b 160:/var/db/sshguard/blacklist.db

The grep line keeps any aborted login attempts (no password ever 
provided) and any login attempts by don (me) from counting.

Since you asked about general usage stuff -- Two other features I'd like 
are :

1) allow blocking state to be reset to zero on a successful login from a 
host.
2) I've also thought about region based weighting of blocking -- probes 
from strange countries could be treated harshly...

I've only been using sshguard for a week, so I'm still learning... 
(though I've been using tcp/ip for decades ... and I'm still learning ;->).

Don



On 01/25/16 16:33, Kevin Zheng wrote:
> On 01/24/2016 09:40, Don Coleman wrote:
>> sshguard (as of 1.6.2) operates internally on ip addresses.   It maps
>> hostnames to ip addresses only at startup time, and this is
>> fundamentally flawed, as hostname to ip addresses mappings change over time.
> The whitelisting feature itself might be fundamentally flawed. I believe
> the original intent was to prevent self-lockouts. However, SSHGuard is
> designed to mitigate brute-force attacks, so if SSHGuard was designed
> perfectly (which it isn't) and you aren't brute-forcing yourself, then
> you shouldn't need whitelisting.
>
> If you want to prevent self-lockouts, the best thing to do is add a
> firewall rule that unconditionally allows your traffic. But if you can
> do that, why not deny all traffic except for your own?
>
> If you use blacklisting, whitelisting is potentially useful. Otherwise,
> SSHGuard will always unblock your address after a certain amount of
> time. It shouldn't be too long since you're not brute-forcing yourself.
>
> I'd like to hear more from people who use some combination of
> whitelisting and blacklisting: what do you use it for? I (personally)
> don't use either and find it difficult to justify a correct but somewhat
> complex feature as keeping hostnames updated.
>
> (I believe ntimed has a good solution for the "hostnames changing from
> underneath you" issue. It was designed for addresses that come and go,
> such as pool.ntp.org, but sounds like it could be used here.)
>
> Best,
> Kevin
>

Re: [Sshguard-users] Dynamic hostnames in the whitelist

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

Personally I whitelist the rfc1918 address space mostly because I'm
paranoid and never want to be forced to find the monitor cable for my
machines in the closet. Further since I am paranoid I also setup high
priority firewall rules to always pass the rfc1918 addresses. When
connecting from outside my local network I can unpredictable addresses. So
white listing those isn't possible. While I could blacklist all of China,
Russia, and several other places that attacks seem to originate doing so
would be a bit of a work to find all those networks and could possibly grow
my firewall tables to an unmanageable size.  I use sshguard to react to
attacks in real time. Mostly I want to shut down all further access once I
start to see ssh brute forcing. My main concern is they move from ssh brute
forcing to some other protocol that isn't as well protected.  I also use
google authenticator (https://github.com/google/google-authenticator) to
apply two factor authentication to ssh logons when coming from an outside
network.

On Mon, Jan 25, 2016 at 4:33 PM, Kevin Zheng <kev...@gm...> wrote:

> On 01/24/2016 09:40, Don Coleman wrote:
> > sshguard (as of 1.6.2) operates internally on ip addresses.   It maps
> > hostnames to ip addresses only at startup time, and this is
> > fundamentally flawed, as hostname to ip addresses mappings change over
> time.
>
> The whitelisting feature itself might be fundamentally flawed. I believe
> the original intent was to prevent self-lockouts. However, SSHGuard is
> designed to mitigate brute-force attacks, so if SSHGuard was designed
> perfectly (which it isn't) and you aren't brute-forcing yourself, then
> you shouldn't need whitelisting.
>
> If you want to prevent self-lockouts, the best thing to do is add a
> firewall rule that unconditionally allows your traffic. But if you can
> do that, why not deny all traffic except for your own?
>
> If you use blacklisting, whitelisting is potentially useful. Otherwise,
> SSHGuard will always unblock your address after a certain amount of
> time. It shouldn't be too long since you're not brute-forcing yourself.
>
> I'd like to hear more from people who use some combination of
> whitelisting and blacklisting: what do you use it for? I (personally)
> don't use either and find it difficult to justify a correct but somewhat
> complex feature as keeping hostnames updated.
>
> (I believe ntimed has a good solution for the "hostnames changing from
> underneath you" issue. It was designed for addresses that come and go,
> such as pool.ntp.org, but sounds like it could be used here.)
>
> Best,
> Kevin
>
> --
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>



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

Re: [Sshguard-users] Dynamic hostnames in the whitelist

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

On 01/24/2016 09:40, Don Coleman wrote:
> sshguard (as of 1.6.2) operates internally on ip addresses.   It maps 
> hostnames to ip addresses only at startup time, and this is 
> fundamentally flawed, as hostname to ip addresses mappings change over time.

The whitelisting feature itself might be fundamentally flawed. I believe
the original intent was to prevent self-lockouts. However, SSHGuard is
designed to mitigate brute-force attacks, so if SSHGuard was designed
perfectly (which it isn't) and you aren't brute-forcing yourself, then
you shouldn't need whitelisting.

If you want to prevent self-lockouts, the best thing to do is add a
firewall rule that unconditionally allows your traffic. But if you can
do that, why not deny all traffic except for your own?

If you use blacklisting, whitelisting is potentially useful. Otherwise,
SSHGuard will always unblock your address after a certain amount of
time. It shouldn't be too long since you're not brute-forcing yourself.

I'd like to hear more from people who use some combination of
whitelisting and blacklisting: what do you use it for? I (personally)
don't use either and find it difficult to justify a correct but somewhat
complex feature as keeping hostnames updated.

(I believe ntimed has a good solution for the "hostnames changing from
underneath you" issue. It was designed for addresses that come and go,
such as pool.ntp.org, but sounds like it could be used here.)

Best,
Kevin

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

Re: [Sshguard-users] Dynamic hostnames in the whitelist

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

It sounds like an interesting patch. Going by the TTL is a good hint for
how long to track the resolution. I would also suggest parameters for
minimum and maximum TTLs to honor. I use a dynamic updated name hosted at
google domains. It uses a ridiculously short TTL. I could see others in a
similar situation wanting to reduce DNS calls or avoid annoying a provider.

On Sun, Jan 24, 2016 at 9:40 AM, Don Coleman <do...@co...> wrote:

>
> sshguard (as of 1.6.2) operates internally on ip addresses.   It maps
> hostnames to ip addresses only at startup time, and this is
> fundamentally flawed, as hostname to ip addresses mappings change over
> time.
>
> I'm currently working around this by restarting it once a day. This is
> effective, but kludgy..
>
> I searched the archives for this list, and didn't see any mention of
> this issue, so I presume most people aren't concerned with white listing
> dynamic hostnames.
>
> sshguard uses getaddrinfo() to map hostnames to ip addresses.  This is
> not the proper interface for long-running daemons to be using.
>
> It probably should be using the res_* functions.   It should track the
> ttl of hostname mappings in it's whitelist, and re-map them once the ttl
> expires.  If the remap fails or takes too long, it should probably
> continue using the old value for a short additional time, say 5 to 10
> minutes, before trying again (as sshd is already mapping the name to IP
> address on each request, a valid mapping should already be in a nearby
> dns cache).
>
> Any interest in this?
>
> Thanks,
> Don
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>



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

[Sshguard-users] Dynamic hostnames in the whitelist

[Don C. <do...@co...>]

sshguard (as of 1.6.2) operates internally on ip addresses.   It maps 
hostnames to ip addresses only at startup time, and this is 
fundamentally flawed, as hostname to ip addresses mappings change over time.

I'm currently working around this by restarting it once a day. This is 
effective, but kludgy..

I searched the archives for this list, and didn't see any mention of 
this issue, so I presume most people aren't concerned with white listing 
dynamic hostnames.

sshguard uses getaddrinfo() to map hostnames to ip addresses.  This is 
not the proper interface for long-running daemons to be using.

It probably should be using the res_* functions.   It should track the 
ttl of hostname mappings in it's whitelist, and re-map them once the ttl 
expires.  If the remap fails or takes too long, it should probably 
continue using the old value for a short additional time, say 5 to 10 
minutes, before trying again (as sshd is already mapping the name to IP 
address on each request, a valid mapping should already be in a nearby 
dns cache).

Any interest in this?

Thanks,
Don

Re: [Sshguard-users] confused about what to expect

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

Or worse you might be able to parse the logs but the method to update the
firewall changes and you are still left unprotected and possibly loose all
your previous protection after a reboot.  I would suggest monitoring the
firewall rules that get added, not just log messages from sshguard.

On Thu, Jan 21, 2016 at 2:48 PM, Emmanuel <el...@ms...> wrote:

> ok i get it...
>
> Is there a 'minimal' message type that is recognized, I mean 'Failed
> password for root from IP...' seems like pretty basic
>
> I'll try to strip everything else but I'm using CoreOS as you noticed,
> and things change a lot and quickly with those guys, so I dont' feel very
> confident this is a very robust solution: if i upgrade CoreOS to a new
> version i may end up with a non-parsable log and no protection... not good.
>
> Thanks for help
>
>
> > To: ssh...@li...
> > From: kev...@gm...
> > Date: Thu, 21 Jan 2016 14:24:33 -0800
> > Subject: Re: [Sshguard-users] confused about what to expect
> >
> > On 01/21/2016 14:15, Emmanuel wrote:
> > > i am running 1.6.0
> >
> > 1.6.3 recognizes most of your log messages as attacks. I haven't tested
> > 1.6.0; you should consider upgrading to 1.6.3.
> >
> > > I am trying to understand what sshguard does under the hood.
> >
> > Briefly, a lexer splits up each line into tokens (like
> > TIMESTAMP_SYSLOG). A parser looks at each token and processes it if the
> > tokens match a known attack pattern.
> >
> > You can try using sed to get rid of everything but the log message, i.e.
> > the "Failed password for root from 183.3.202.107 port 15012 ssh2". If it
> > still doesn't recognize the attack, it's probably because 1.6.0 doesn't
> > have that particular attack yet.
> >
> > > what do you mean by not recognizing the syslog prefix?
> > > I can sed or transform the stream if I have to to make it work, I just
> > > want to understand what format is expected and what make break it.
> > > I'm not big in to C, so I'd rather not dig into the code.
> > > is there some doc somewhere about this?
> >
> > The lexer/parser is ugly even if you know C. Something is being done
> > about this, but I'm not sure how long it'll take.
> >
> > Best,
> > Kevin
> >
> > --
> > Kevin Zheng
> > kev...@gm... | ke...@kd... | PGP: 0xC22E1090
> >
> >
> ------------------------------------------------------------------------------
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > Monitor end-to-end web transactions and take corrective actions now
> > Troubleshoot faster and improve end-user experience. Signup Now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> > _______________________________________________
> > Sshguard-users mailing list
> > Ssh...@li...
> > https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>


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

Re: [Sshguard-users] confused about what to expect

[Emmanuel <el...@ms...>]

ok i get it...
Is there a 'minimal' message type that is recognized, I mean 'Failed password for root from IP...' seems like pretty basic
I'll try to strip everything else but I'm using CoreOS as you noticed, and things change a lot and quickly with those guys, so I dont' feel very confident this is a very robust solution: if i upgrade CoreOS to a new version i may end up with a non-parsable log and no protection... not good.
Thanks for help

> To: ssh...@li...
> From: kev...@gm...
> Date: Thu, 21 Jan 2016 14:24:33 -0800
> Subject: Re: [Sshguard-users] confused about what to expect
> 
> On 01/21/2016 14:15, Emmanuel wrote:
> > i am running 1.6.0
> 
> 1.6.3 recognizes most of your log messages as attacks. I haven't tested
> 1.6.0; you should consider upgrading to 1.6.3.
> 
> > I am trying to understand what sshguard does under the hood.
> 
> Briefly, a lexer splits up each line into tokens (like
> TIMESTAMP_SYSLOG). A parser looks at each token and processes it if the
> tokens match a known attack pattern.
> 
> You can try using sed to get rid of everything but the log message, i.e.
> the "Failed password for root from 183.3.202.107 port 15012 ssh2". If it
> still doesn't recognize the attack, it's probably because 1.6.0 doesn't
> have that particular attack yet.
> 
> > what do you mean by not recognizing the syslog prefix?
> > I can sed or transform the stream if I have to to make it work, I just
> > want to understand what format is expected and what make break it.
> > I'm not big in to C, so I'd rather not dig into the code.
> > is there some doc somewhere about this?
> 
> The lexer/parser is ugly even if you know C. Something is being done
> about this, but I'm not sure how long it'll take.
> 
> Best,
> Kevin
> 
> -- 
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
 		 	   		  

Re: [Sshguard-users] confused about what to expect

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

On 01/21/2016 14:15, Emmanuel wrote:
> i am running 1.6.0

1.6.3 recognizes most of your log messages as attacks. I haven't tested
1.6.0; you should consider upgrading to 1.6.3.

> I am trying to understand what sshguard does under the hood.

Briefly, a lexer splits up each line into tokens (like
TIMESTAMP_SYSLOG). A parser looks at each token and processes it if the
tokens match a known attack pattern.

You can try using sed to get rid of everything but the log message, i.e.
the "Failed password for root from 183.3.202.107 port 15012 ssh2". If it
still doesn't recognize the attack, it's probably because 1.6.0 doesn't
have that particular attack yet.

> what do you mean by not recognizing the syslog prefix?
> I can sed or transform the stream if I have to to make it work, I just
> want to understand what format is expected and what make break it.
> I'm not big in to C, so I'd rather not dig into the code.
> is there some doc somewhere about this?

The lexer/parser is ugly even if you know C. Something is being done
about this, but I'm not sure how long it'll take.

Best,
Kevin

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

Re: [Sshguard-users] confused about what to expect

[Emmanuel <el...@ms...>]

i am running 1.6.0
I am trying to understand what sshguard does under the hood.
what do you mean by not recognizing the syslog prefix?I can sed or transform the stream if I have to to make it work, I just want to understand what format is expected and what make break it.I'm not big in to C, so I'd rather not dig into the code.is there some doc somewhere about this?


> To: ssh...@li...
> From: kev...@gm...
> Date: Thu, 21 Jan 2016 13:49:00 -0800
> Subject: Re: [Sshguard-users] confused about what to expect
> 
> On 01/21/2016 13:16, Emmanuel wrote:
> > So what exactly is happening here?
> 
> It sounds like SSHGuard isn't recognizing the syslog prefix. Have you
> tried running 1.6.3 or the development version in Git?
> 
> Thanks,
> Kevin
> 
> -- 
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
 		 	   		  

Re: [Sshguard-users] confused about what to expect

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

On 01/21/2016 13:16, Emmanuel wrote:
> So what exactly is happening here?

It sounds like SSHGuard isn't recognizing the syslog prefix. Have you
tried running 1.6.3 or the development version in Git?

Thanks,
Kevin

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

Re: [Sshguard-users] confused about what to expect

[Emmanuel <el...@ms...>]

When I run the log I sent through sshguard with the SSHGUARD_DEBUG=yes flag on I get this:
from this log:
Jan 21 20:42:38 coreos sshd: Failed password for root from 183.3.202.107 port 15012 ssh2Jan 21 20:42:39 coreos sshd: Failed password for root from 183.3.202.107 port 15012 ssh2Jan 21 20:42:39 coreos sshd: Failed password for root from 183.3.202.107 port 15012 ssh2Jan 21 20:42:40 coreos sshd: Received disconnect from 183.3.202.107: 11:  [preauth]Jan 21 20:42:40 coreos sshd: Disconnected from 183.3.202.107 [preauth]Jan 21 20:42:48 coreos sshd: Failed password for root from 183.3.202.107 port 63755 ssh2Jan 21 20:42:49 coreos sshd: Failed password for root from 183.3.202.107 port 63755 ssh2Jan 21 20:42:49 coreos sshd: Failed password for root from 183.3.202.107 port 63755 ssh2Jan 21 20:42:50 coreos sshd: Received disconnect from 183.3.202.107: 11:  [preauth]Jan 21 20:42:50 coreos sshd: Disconnected from 183.3.202.107 [preauth]
I get this output:
Run command "iptables -w -L -n": exited 0.Started with danger threshold=40 ; minimum block=420 secondsStarting parseEntering state 0Reading a token: --accepting rule at line 201 ("Jan 21 20:42:38")Next token is token TIMESTAMP_SYSLOG ()Cleanup: discarding lookahead token TIMESTAMP_SYSLOG ()Stack now 0Starting parseEntering state 0Reading a token: --accepting rule at line 201 ("Jan 21 20:42:39")Next token is token TIMESTAMP_SYSLOG ()Cleanup: discarding lookahead token TIMESTAMP_SYSLOG ()Stack now 0Starting parseEntering state 0Reading a token: --accepting rule at line 201 ("Jan 21 20:42:39")Next token is token TIMESTAMP_SYSLOG ()Cleanup: discarding lookahead token TIMESTAMP_SYSLOG ()Stack now 0Starting parseEntering state 0Reading a token: --accepting rule at line 201 ("Jan 21 20:42:40")Next token is token TIMESTAMP_SYSLOG ()Cleanup: discarding lookahead token TIMESTAMP_SYSLOG ()Stack now 0Starting parseEntering state 0Reading a token: --accepting rule at line 201 ("Jan 21 20:42:40")Next token is token TIMESTAMP_SYSLOG ()Cleanup: discarding lookahead token TIMESTAMP_SYSLOG ()Stack now 0Starting parseEntering state 0Reading a token: --accepting rule at line 201 ("Jan 21 20:42:48")Next token is token TIMESTAMP_SYSLOG ()Cleanup: discarding lookahead token TIMESTAMP_SYSLOG ()Stack now 0Starting parseEntering state 0Reading a token: --accepting rule at line 201 ("Jan 21 20:42:49")Next token is token TIMESTAMP_SYSLOG ()Cleanup: discarding lookahead token TIMESTAMP_SYSLOG ()Stack now 0Starting parseEntering state 0Reading a token: --accepting rule at line 201 ("Jan 21 20:42:49")Next token is token TIMESTAMP_SYSLOG ()Cleanup: discarding lookahead token TIMESTAMP_SYSLOG ()Stack now 0Starting parseEntering state 0Reading a token: --accepting rule at line 201 ("Jan 21 20:42:50")Next token is token TIMESTAMP_SYSLOG ()Cleanup: discarding lookahead token TIMESTAMP_SYSLOG ()Stack now 0Starting parseEntering state 0Reading a token: --accepting rule at line 201 ("Jan 21 20:42:50")Next token is token TIMESTAMP_SYSLOG ()Cleanup: discarding lookahead token TIMESTAMP_SYSLOG ()Stack now 0

So what exactly is happening here?
Thanks


> To: ssh...@li...
> From: kev...@gm...
> Date: Thu, 21 Jan 2016 11:49:55 -0800
> Subject: Re: [Sshguard-users] confused about what to expect
> 
> On 01/21/2016 11:46, Emmanuel wrote:
> > *Is there any way to redirect this to stdout for example?*
> 
> Yes, set SSHGUARD_DEBUG=yes in your environment.
> 
> Best,
> Kevin
> 
> -- 
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
 		 	   		  

Re: [Sshguard-users] confused about what to expect

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

On 01/21/2016 11:46, Emmanuel wrote:
> *Is there any way to redirect this to stdout for example?*

Yes, set SSHGUARD_DEBUG=yes in your environment.

Best,
Kevin

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

Re: [Sshguard-users] confused about what to expect

[Emmanuel <el...@ms...>]

> To: ssh...@li...
> From: kev...@gm...
> Date: Thu, 21 Jan 2016 11:38:52 -0800
> Subject: Re: [Sshguard-users] confused about what to expect
> 
> On 01/21/2016 10:51, Emmanuel wrote:
> > I run sshguard without any flags so far. sending journalctl data to it with 
> > 
> > /bin/sh -c 'journalctl --no-pager -q -f -t sshd | sed -u
> > "s/\\[[0-9]*\\]//" | docker run -i --name sshguard --rm --net=host
> > --privileged mischief/sshguard:1.6.0'
> > 
> > the 'sed' part is meant to strip the PID info as I understand sshguard
> > tries to match PIDs but CoreOS uses inetd sshd and sshguard would reject
> > that
> 
> I've never run SSHGuard using systemd(8) before, so I won't be much help
> there. You've made sure that the logs are coming out of the pipe?

Out of the Pipe to SSHGUARD, YES!Then I'm not sure how I can check what sshguard does or gets
> > Prior I have set: 
> > /usr/sbin/iptables -D INPUT -j sshguard
> > /usr/sbin/ip6tables -D INPUT -j sshguard
> > /usr/sbin/iptables -A INPUT -j sshguard
> > /usr/sbin/ip6tables -A INPUT -j sshguard
> > 
> > I would expect sshguard to create iptables rules, but I don't see any
> > even though my journalctl logs show attacks happening.
> > I would like to know:
> > 
> > *1) what should the rules look like?*
> 
> Not sure (as I don't run iptables). I'm sure someone on this list knows.
> 
> > *2) How is the 'score' calculated? I see the default is 40, but what
> > does 40 equate to in terms of number of attempts etc?*
> 
> Each attempt (currently) adds a score of 10. The default is to block an
> address when the score reaches 40 (4 attacks).OK thanks!
> 
> > *3) Does sshguard logs banned addresses somewhere?*
> 
> SSHGuard logs what it does to syslog.
Is there any way to redirect this to stdout for example?
> 
> Best,
> Kevin
> 
> -- 
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
 		 	   		  

Re: [Sshguard-users] confused about what to expect

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

On 01/21/2016 10:51, Emmanuel wrote:
> I run sshguard without any flags so far. sending journalctl data to it with 
> 
> /bin/sh -c 'journalctl --no-pager -q -f -t sshd | sed -u
> "s/\\[[0-9]*\\]//" | docker run -i --name sshguard --rm --net=host
> --privileged mischief/sshguard:1.6.0'
> 
> the 'sed' part is meant to strip the PID info as I understand sshguard
> tries to match PIDs but CoreOS uses inetd sshd and sshguard would reject
> that

I've never run SSHGuard using systemd(8) before, so I won't be much help
there. You've made sure that the logs are coming out of the pipe?

> Prior I have set: 
> /usr/sbin/iptables -D INPUT -j sshguard
> /usr/sbin/ip6tables -D INPUT -j sshguard
> /usr/sbin/iptables -A INPUT -j sshguard
> /usr/sbin/ip6tables -A INPUT -j sshguard
> 
> I would expect sshguard to create iptables rules, but I don't see any
> even though my journalctl logs show attacks happening.
> I would like to know:
> 
> *1) what should the rules look like?*

Not sure (as I don't run iptables). I'm sure someone on this list knows.

> *2) How is the 'score' calculated? I see the default is 40, but what
> does 40 equate to in terms of number of attempts etc?*

Each attempt (currently) adds a score of 10. The default is to block an
address when the score reaches 40 (4 attacks).

> *3) Does sshguard logs banned addresses somewhere?*

SSHGuard logs what it does to syslog.

Best,
Kevin

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

[Sshguard-users] confused about what to expect

[Emmanuel <el...@ms...>]

Hello,
I'm trying to use sshguard in docker on a Kubernetes cluster.
I have used blackhole script so far and it looks like sshguard is more advanced, but I can't seem to see it's effect:
I have it running right now on my cluster, with the docker flag for the container to be privileged. 
I run sshguard without any flags so far. sending journalctl data to it with 
/bin/sh -c 'journalctl --no-pager -q -f -t sshd | sed -u "s/\\[[0-9]*\\]//" | docker run -i --name sshguard --rm --net=host --privileged mischief/sshguard:1.6.0'
the 'sed' part is meant to strip the PID info as I understand sshguard tries to match PIDs but CoreOS uses inetd sshd and sshguard would reject that
Prior I have set: /usr/sbin/iptables -D INPUT -j sshguard/usr/sbin/ip6tables -D INPUT -j sshguard/usr/sbin/iptables -A INPUT -j sshguard/usr/sbin/ip6tables -A INPUT -j sshguard
I would expect sshguard to create iptables rules, but I don't see any even though my journalctl logs show attacks happening.I would like to know:
1) what should the rules look like?
I see:
$ iptables --listChain INPUT (policy ACCEPT)target     prot opt source               destinationsshguard   all  --  anywhere             anywhere
Chain FORWARD (policy ACCEPT)target     prot opt source               destinationDOCKER     all  --  anywhere             anywhereACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHEDACCEPT     all  --  anywhere             anywhereACCEPT     all  --  anywhere             anywhere
Chain OUTPUT (policy ACCEPT)target     prot opt source               destination
Chain DOCKER (1 references)target     prot opt source               destination
Chain sshguard (1 references)target     prot opt source               destination

$ iptables --list-rules-P INPUT ACCEPT-P FORWARD ACCEPT-P OUTPUT ACCEPT-N DOCKER-N sshguard-A INPUT -j sshguard-A FORWARD -o docker0 -j DOCKER-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT-A FORWARD -i docker0 ! -o docker0 -j ACCEPT-A FORWARD -i docker0 -o docker0 -j ACCEPT

in journalctl I get a lot of attempts to ssh onto my server, for example:
Jan 21 04:57:21 coreos systemd[1]: Started OpenSSH per-connection server daemon (183.3.202.107:63369).Jan 21 04:57:23 coreos sshd[7899]: Failed password for root from 183.3.202.107 port 63369 ssh2Jan 21 04:57:23 coreos sshd[7899]: Failed password for root from 183.3.202.107 port 63369 ssh2Jan 21 04:57:23 coreos sshd[7899]: Failed password for root from 183.3.202.107 port 63369 ssh2Jan 21 04:57:24 coreos sshd[7899]: Received disconnect from 183.3.202.107: 11:  [preauth]Jan 21 04:57:24 coreos sshd[7899]: Disconnected from 183.3.202.107 [preauth]Jan 21 04:57:24 coreos systemd[1]: Started OpenSSH per-connection server daemon (183.3.202.107:24051).Jan 21 04:57:26 coreos sshd[7903]: Failed password for root from 183.3.202.107 port 24051 ssh2Jan 21 04:57:26 coreos sshd[7903]: Failed password for root from 183.3.202.107 port 24051 ssh2Jan 21 04:57:27 coreos sshd[7903]: Failed password for root from 183.3.202.107 port 24051 ssh2Jan 21 04:57:27 coreos sshd[7903]: Received disconnect from 183.3.202.107: 11:  [preauth]Jan 21 04:57:27 coreos sshd[7903]: Disconnected from 183.3.202.107 [preauth]Jan 21 04:57:27 coreos systemd[1]: Started OpenSSH per-connection server daemon (183.3.202.107:38955).Jan 21 04:57:30 coreos sshd[7960]: Failed password for root from 183.3.202.107 port 38955 ssh2Jan 21 04:57:30 coreos sshd[7960]: Failed password for root from 183.3.202.107 port 38955 ssh2Jan 21 04:57:31 coreos sshd[7960]: Failed password for root from 183.3.202.107 port 38955 ssh2Jan 21 04:57:31 coreos sshd[7960]: Received disconnect from 183.3.202.107: 11:  [preauth]Jan 21 04:57:31 coreos sshd[7960]: Disconnected from 183.3.202.107 [preauth]Jan 21 04:57:31 coreos systemd[1]: Started OpenSSH per-connection server daemon (183.3.202.107:57043).Jan 21 04:57:33 coreos sshd[8004]: Failed password for root from 183.3.202.107 port 57043 ssh2Jan 21 04:57:34 coreos sshd[8004]: Failed password for root from 183.3.202.107 port 57043 ssh2Jan 21 04:57:35 coreos sshd[8004]: Failed password for root from 183.3.202.107 port 57043 ssh2Jan 21 04:57:35 coreos sshd[8004]: Received disconnect from 183.3.202.107: 11:  [preauth]Jan 21 04:57:35 coreos sshd[8004]: Disconnected from 183.3.202.107 [preauth]Jan 21 04:57:35 coreos systemd[1]: Started OpenSSH per-connection server daemon (183.3.202.107:21575).Jan 21 04:57:38 coreos sshd[8008]: Failed password for root from 183.3.202.107 port 21575 ssh2Jan 21 04:57:38 coreos sshd[8008]: Failed password for root from 183.3.202.107 port 21575 ssh2Jan 21 04:57:39 coreos sshd[8008]: Failed password for root from 183.3.202.107 port 21575 ssh2Jan 21 04:57:39 coreos sshd[8008]: Received disconnect from 183.3.202.107: 11:  [preauth]Jan 21 04:57:39 coreos sshd[8008]: Disconnected from 183.3.202.107 [preauth]Jan 21 04:57:40 coreos systemd[1]: Started OpenSSH per-connection server daemon (183.3.202.107:42026).Jan 21 04:57:41 coreos sshd[8012]: Failed password for root from 183.3.202.107 port 42026 ssh2Jan 21 04:57:42 coreos sshd[8012]: Failed password for root from 183.3.202.107 port 42026 ssh2Jan 21 04:57:43 coreos sshd[8012]: Failed password for root from 183.3.202.107 port 42026 ssh2Jan 21 04:57:43 coreos sshd[8012]: Received disconnect from 183.3.202.107: 11:  [preauth]Jan 21 04:57:43 coreos sshd[8012]: Disconnected from 183.3.202.107 [preauth]Jan 21 04:57:43 coreos systemd[1]: Started OpenSSH per-connection server daemon (183.3.202.107:58053).Jan 21 04:57:46 coreos sshd[8017]: Failed password for root from 183.3.202.107 port 58053 ssh2Jan 21 04:57:47 coreos sshd[8017]: Failed password for root from 183.3.202.107 port 58053 ssh2Jan 21 04:57:47 coreos sshd[8017]: Failed password for root from 183.3.202.107 port 58053 ssh2Jan 21 04:57:47 coreos sshd[8017]: Received disconnect from 183.3.202.107: 11:  [preauth]Jan 21 04:57:47 coreos sshd[8017]: Disconnected from 183.3.202.107 [preauth]

2) How is the 'score' calculated? I see the default is 40, but what does 40 equate to in terms of number of attempts etc?
3) Does sshguard logs banned addresses somewhere?

I would like to make sure it is working as expected!
Thanks for clarifying these points.
 		 	   		  

Re: [Sshguard-users] SSHGuard 1.6.3 release announcement

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

On Fri, Jan 1, 2016, at 19:36, Kevin Zheng wrote:
>
>     - Fix `pfctl` command syntax with OpenBSD 5.8

Does this in any way affect pf on FreeBSD?

>     - Remove PID file option

... Why? The rc scripts on FreeBSD heavily rely on pidfiles. It ensures
that the process name and pidfile contents match what it finds in the
process list to be sure it's not going to kill the wrong process. I can
alter sshguard's rc script to launch via daemon(8) so I can get a
pidfile again, but that seems silly.

-- 
  Mark Felder
  ports-secteam member
  fe...@Fr...