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

Re: [Sshguard-users] "Connection closed by x.x.x.x [preauth]" attack not handled

[<jo...@te...>]

On Sun, 18 May 2014 22:31:40 +0200,
Anders Bergh <an...@gm...> wrote :

> May  7 08:28:26 vm sshd[15657]: Connection closed by 83.191.86.213
> [preauth]

> Reading a token: --accepting rule at line 110 ("May  7 08:28:26 vm
> sshd[15657]: ")

As can be seen, sshguard will not react on these messages.  I think
this was the reason of your initial post :)

Having sshguard in debug though, enables to see why.  It did not took
much time to make it work with those sshd messages which, after, if
made furiously, could provoke some resources stealing.

Thing is, I made it using the sshguard that I already modify for other
uses.  I think it could be good to have support for that type of
message in the official releae but it looks like sshguard upstream is
not maintained.  Nor is this mailing list read by the
author/maintainer.  Tell me if I'm wrong. 

I will certainly include it in the personalized sshguard I'm working on.

So here's the recipe to make it work.  It's not a formal diff, sorry.
It starts with a working demo in two parts, then followed by the
code modifications to add.  I defined '[preauth]' as somethign lex can
return.

A) Demo: one try

[...]
Started successfully [(a,p,s)=(40, 420, 1200)], now ready to scan.

May  7 08:28:26 vm sshd[15657]: Connection closed by 83.191.86.213
[preauth]
[...]

Cleanup: popping token $end ()
Cleanup: popping nterm text ()

Matched address 83.191.86.213:4 attacking service 100, dangerousness
10.

B) Demo: after a few copy/paste of same log msg

Matched address 83.191.86.213:4 attacking service 100, dangerousness
10.

Purging stale attackers.

First abuse of '83.191.86.213', adding to offenders list.

Offender '83.191.86.213:4' scored 40 danger in 1 abuses.

Blocking 83.191.86.213:4 for >630secs: 40 danger in 4 attacks over 7
seconds (all: 40d in 1 abuses over 7s).

Setting environment:
SSHG_ADDR=83.191.86.213;SSHG_ADDRKIND=4;SSHG_SERVICE=100.


C) Code modifications in three parts, then recompile.  
                                                                                             
1)
attack_parser.h                                                                           
                                                                                             
   enum yytokentype
{                                                                        
   [...]
     SSH_NOLOGIN = 280,
     SSHPREAUTH = 281,

#define SSH_NOLOGIN 280
#define SSHPREAUTH 281


2) attack_scanner.l

Add ssh_nologin:

%s ssh_notallowed ssh_loginerr ssh_reversemap ssh_nologin

Add recognition of extra string:

\[preauth\]             return SSHPREAUTH;

Add parsing regex:

 /* SSH: initiate a connect but terminates without login */
"Connection closed by "  { return SSH_NOLOGIN; }


3) attack_scanner.y

Add token:

%token SSH_NOLOGIN SSHPREAUTH

Add to sshmsg definitions:

sshmsg:
 [...]
     | ssh_nologin
 ;

Add syntax:

ssh_nologin:
    SSH_NOLOGIN addr SSHPREAUTH
    ;

Re: [Sshguard-users] "Connection closed by x.x.x.x [preauth]" attack not handled

[Anders B. <an...@gm...>]

On Sun, May 18, 2014 at 12:25 PM, jo...@te...
<jo...@te...> wrote:
> sshguard will recognize 'May  7 08:28:26 vm sshd[15657]:'  This means
> you can launch sshguard in debug mode and copy/paste the rest of the
> log msg to see what the behaviour is.  Debug mode:
>
> env SSHGUARD_DEBUG=foo <your path to sshguard>
>

Started successfully [(a,p,s)=(40, 420, 1200)], now ready to scan.

May  7 08:28:26 vm sshd[15657]: Connection closed by 83.191.86.213 [preauth]

Starting parse
Entering state 0
Reading a token: --accepting rule at line 110 ("May  7 08:28:26 vm
sshd[15657]: ")
Next token is token SYSLOG_BANNER_PID ()
Shifting token SYSLOG_BANNER_PID ()
Entering state 1
Reading a token: --accepting rule at line 220 ("Connection")
Next token is token WORD ()
Error: popping token SYSLOG_BANNER_PID ()
Stack now 0
Cleanup: discarding lookahead token WORD ()
Stack now 0

-- 
Anders Bergh

Re: [Sshguard-users] "Connection closed by x.x.x.x [preauth]" attack not handled

[<jo...@te...>]

On Wed, 7 May 2014 18:25:08 +0200,
Anders Bergh <an...@gm...> wrote :

> I have thousands of lines like this in my auth.log:
> 
> May  7 08:28:26 vm sshd[15657]: Connection closed by 83.191.86.213
> [preauth]
> 
> sshguard 1.5.0 (Debian wheezy) doesn't seem to do anything about this.
> Should it?

sshguard will recognize 'May  7 08:28:26 vm sshd[15657]:'  This means
you can launch sshguard in debug mode and copy/paste the rest of the
log msg to see what the behaviour is.  Debug mode:

env SSHGUARD_DEBUG=foo <your path to sshguard>

Re: [Sshguard-users] ipfw sshguard not working for mail

[<jo...@te...>]

On Tue, 29 Apr 2014 15:34:22 +0200,
Oliver FdeV <ol...@fa...> wrote :

> How can I get ipfw-sshguard working for mail and smtp?

Since I'm currently adding lex/yacc code to support log msgs from a
middleware, I'd say try it in debugging mode.  Simply launch sshguard
in debug mode.  It will run foreground enabling copy/paste of log
messages, as well as detailed reaction to the log messages.

To enable debug mode:

env SSHGUARD_DEBUG=foo <your path to sshguard>

By doing this you'll know which parts fails, parsing or launching the
firewall.

If you already know this, sorry for the redundancy !!

[Sshguard-users] "Connection closed by x.x.x.x [preauth]" attack not handled

[Anders B. <an...@gm...>]

Hi,

I have thousands of lines like this in my auth.log:

May  7 08:28:26 vm sshd[15657]: Connection closed by 83.191.86.213 [preauth]

sshguard 1.5.0 (Debian wheezy) doesn't seem to do anything about this.
Should it?

(not subscribed to ML so please CC me)

-- 
Anders Bergh

[Sshguard-users] Writing new parsing expressions

[<jo...@te...>]

Hello !

  Has anyone anything at all to share about writing new parsing
expressions to a total newbie to Lex/Yacc, specifically how to
write/compile for sshguard ?  Any help would be greatly appreciated -
thanks !

[Sshguard-users] ipfw sshguard not working for mail

[Oliver F. <ol...@fa...>]

How can I get ipfw-sshguard working for mail and smtp?
 
It definitely works for ssh, that is checked and works
 
This is what I added to /etc/rc.conf
firewall_enable="YES"
firewall_type="simple"
firewall_script="/etc/ipfw.rules"
firewall_logging="YES"
sshguard_enable="YES"
sshguard_pidfile="/var/run/sshguard.pid"
sshguard_watch_logs="/var/log/auth.log:/var/log/exim/mainlog:/var/log/maillog"
sshguard_flags=""

To /etc/syslog.conf I added:
 
auth.info;authpriv.info                         /var/log/auth.log
mail.info                                       /var/log/maillog
smtp.info                                       /var/log/exim/mainlog
 
and:
 
auth.info;authpriv.info;mail.info;smtp.info;ftp.info |exec /usr/local/sbin/sshguard -w xx.xx.xx.xx
 
What else do I need to get it to check the exim mainlog and add ips to the block?
 
thanks
 
OliverJim

[Sshguard-users] ipfw sshguard not working for mail

[Oliver F. <ol...@fa...>]

How can I get ipfw-sshguard working for mail and smtp?
 
It definitely works for ssh, that is checked and works
 
This is what I added to /etc/rc.conf
firewall_enable="YES"
firewall_type="simple"
firewall_script="/etc/ipfw.rules"
firewall_logging="YES"
sshguard_enable="YES"
sshguard_pidfile="/var/run/sshguard.pid"
sshguard_watch_logs="/var/log/auth.log:/var/log/exim/mainlog:/var/log/maillog"
sshguard_flags=""

To /etc/syslog.conf I added:
 
auth.info;authpriv.info                         /var/log/auth.log
mail.info                                       /var/log/maillog
smtp.info                                       /var/log/exim/mainlog
 
and:
 
auth.info;authpriv.info;mail.info;smtp.info;ftp.info |exec /usr/local/sbin/sshguard -w xx.xx.xx.xx
 
What else do I need to get it to check the exim mainlog and add ips to the block?
 
thanks
 
OliverJim

[Sshguard-users] ipfw sshguard not working for mail

[Oliver F. <ol...@fa...>]

How can I get ipfw-sshguard working for mail and smtp?

It definitely works for ssh, that is checked and works

This is what I added to /etc/rc.conf
firewall_enable="YES"
firewall_type="simple"
firewall_script="/etc/ipfw.rules"
firewall_logging="YES"
sshguard_enable="YES"
sshguard_pidfile="/var/run/sshguard.pid"
sshguard_watch_logs="/var/log/auth.log:/var/log/exim/mainlog:/var/log/maillog"
sshguard_flags=""

To /etc/syslog.conf I added:

auth.info;authpriv.info                         /var/log/auth.log
mail.info                                       /var/log/maillog
smtp.info                                       /var/log/exim/mainlog

and:

auth.info;authpriv.info;mail.info;smtp.info;ftp.info |exec /usr/local/sbin/sshguard -w xx.xx.xx.xx

What else do I need to get it to check the exim mainlog and add ips to the block?

thanks

OliverJim

[Sshguard-users] Fwd: heads up: tcpwrappers support going away

[Jeff W. <wi...@pu...>]

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <tt>This is an announcement </tt>that appeared in the
    openssh-unix-dev list<br>
    yesterday:<br>
    <br>
    -------- Original Message --------
    <table class="moz-email-headers-table" border="0" cellpadding="0"
      cellspacing="0">
      <tbody>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject: </th>
          <td>heads up: tcpwrappers support going away</td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
          <td>Tue, 22 Apr 2014 17:33:59 +1000 (EST)</td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
          <td>Damien Miller <a class="moz-txt-link-rfc2396E" href="mailto:dj...@mi...">&lt;dj...@mi...&gt;</a></td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
          <td><a class="moz-txt-link-abbreviated" href="mailto:ope...@mi...">ope...@mi...</a></td>
        </tr>
      </tbody>
    </table>
    <br>
    <br>
    <pre>Hi,

This is an early warning: OpenSSH will drop tcpwrappers in the next
release. sshd_config has supported the Match keyword for a long time
and it is possible to express more useful conditions (e.g. matching
by user and address) than tcpwrappers allowed.

Removing it reduces the amount of code in the 'hot' pre-authentication
path in sshd and rids us of a dependency.

-d
_______________________________________________
openssh-unix-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ope...@mi...">ope...@mi...</a>
<a class="moz-txt-link-freetext" href="https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev">https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev</a>

</pre>
    <br>
    <pre class="moz-signature" cols="72">-- 
          Jeff Wieland            |         Purdue University
   Network Systems Administrator  |        ITIS UNIX Platforms
       Voice: (765)496-8234       |        155 S. Grant Street
        FAX: (765)494-2253        |      West Lafayette, IN 47907</pre>
  </body>
</html>

[Sshguard-users] man page discrepencies in touchiness

[Dennis N. <djn...@ya...>]

The man page on the sshguard.net site and as included with the source has a couple small problems in the touchiness section (I'm using sshguard-code-238-trunk). The first problem is this statement:

     For example, if address A attacks repeatedly and the base blocking time is

     420 seconds, A will be blocked for 420 seconds (7 mins) at the first
     abuse, 2*420 (14 mins) the second, 2*2*420 (28 mins) the third ... and
     2^(n-1)*420 the n-th time.

Sticking with the 420 seconds example, inspecting sshguard.c shows that the blockage for the n-th time actually occurs for 1.5^n*420 seconds. This progresses as:

    11,16, 24, 35, 53, 80, ... minutes

which quickly falls behind the man page representation, which progresses as

    7, 14, 28, 56, 112, 224, ... minutes

I wonder if it wouldn't be better to be more aggressive instead of less - say 3*(n-1)*420 seconds, which would be:

    7, 21, 63, 189, 567, 1701, ... minutes

or, expressed differently, approximately

    1/9, 1/3, 1, 3, 9, 27, ... hours

The other problem occurs later in the man page in this statement:

     The -b command line option enables blacklisting and requires the filename
     to use for permanent storage of the blacklist. Optionally, a custom
     blacklist threshold can be prefixed to this path, separated by ’:’.

This might lead you to believe (as it did me) that blacklisting does not occur without the -b option and the blocking time would just keep growing. In truth, with default parameters, blacklisting occurs on the third attack. You can see this in the sshguard log entries that say "for >630secs", then "for >945secs", and then finally "for >0secs", It's not really a full-fledged blacklisting because, lacking any blacklist file, the block stays in force in the firewall only until sshguard is restarted or until a reboot (this may be dependent upon which firewall is used).

Given the above, I've compiled in the 3*(n-1)*420 seconds rule (remember, the 420 part is only an example value, albeit the default value) and provided the -b option on the command line with a count of 7 and an appropriate file name.

I hope this helps someone. I know I've found substantial help in posts from this mailing list.
-dennis

[Sshguard-users] sshguard maillog

[Leon F W. <jag...@ja...>]

Greetings

Is there a way to get sshguard to protect a vpopmail maillog file? It's 
contents look like this:

Apr  5 16:48:27 mail vpopmail[11527]: vchkpw-smtp: vpopmail user not 
found crystal23@:91.188.1.46
Apr  5 16:48:38 mail vpopmail[11542]: vchkpw-smtp: vpopmail user not 
found crystal23@:91.188.1.46
Apr  5 16:48:49 mail vpopmail[11554]: vchkpw-smtp: vpopmail user not 
found crystal23@:91.188.1.46

and would like to block this also

Apr  5 16:50:12 mail vpopmail[11621]: vchkpw-smtp: password fail (pass: 
'iloveyou') cry...@do...:91.188.1.46
Apr  5 16:50:23 mail vpopmail[11670]: vchkpw-smtp: password fail (pass: 
'password') cry...@do...:91.188.1.46
Apr  5 16:50:35 mail vpopmail[11675]: vchkpw-smtp: password fail (pass: 
'123456') cry...@do...:91.188.1.46

Thank you in advance..

leon

[Sshguard-users] Why did this get blacklisted?

[David K. K. <dk...@gm...>]

I've just started using sshguard and I want to implement blacklisting for
repetitive attacks. I'm a little confused about the following:

First, here's what's running:
 /usr/local/sbin/sshguard -l /var/log/messages -l /var/log/authlog -w
192.168.0.0/24 -b50:/var/db/sshguard.db

In /var/log/authlog, I found the following sequence:

Mar 28 01:05:46 onett sshd[27466]: Did not receive identification string
from 191.238.52.115
Mar 28 01:37:44 onett sshguard[17709]: Offender '191.238.52.115:4' scored
110 danger in 1 abuses (threshold 50) -> blacklisted.
Mar 28 01:37:44 onett sshguard[17709]: Blocking 191.238.52.115:4 for
>0secs: 110 danger in 1 attacks over 0 seconds (all: 110d in 1 abuses over
0s).

So it looks like I got one "failure to identify" then about 25 minutes
later sshguard blacklisted that IP permanently. Perhaps I have set up my
blacklist badly, but shouldn't something like this be considered a pretty
low-level issue, not requiring a blacklist?

I've verified that the IP shown is in the sshguard table and strings shows
it in /var/db/sshguard.db.

The system is OpenBSD 5.4 and I'm using PF.

[Sshguard-users] "preauth" failures not blocked

[CSS <cs...@mo...>]

I'm curious about attacks that look like this - it appears there's a connect, then multiple tries to authenticate (perhaps by password when keys are the only option?), and then a disconnect:

(100s of these…)
Mar 17 13:51:17 h26 sshd[20882]: Disconnecting: Too many authentication failures for root [preauth]
Mar 17 13:51:19 h26 sshd[20884]: Disconnecting: Too many authentication failures for root [preauth]
Mar 17 13:51:19 h26 sshd[20886]: Disconnecting: Too many authentication failures for root [preauth]
Mar 17 13:51:19 h26 sshd[20888]: Disconnecting: Too many authentication failures for root [preauth]
Mar 17 13:51:20 h26 sshd[20890]: Disconnecting: Too many authentication failures for root [preauth]
Mar 17 13:51:20 h26 sshd[20892]: Disconnecting: Too many authentication failures for root [preauth]
Mar 17 13:51:20 h26 sshd[20899]: Received disconnect from 218.28.26.59: 11:  [preauth]
Mar 17 13:51:20 h26 sshd[20894]: Received disconnect from 218.28.26.59: 11:  [preauth]
Mar 17 13:51:20 h26 sshd[20902]: Received disconnect from 218.28.26.59: 11:  [preauth]
Mar 17 13:51:20 h26 sshd[20896]: Received disconnect from 218.28.26.59: 11:  [preauth]
Mar 17 13:51:20 h26 sshd[20898]: Received disconnect from 218.28.26.59: 11:  [preauth]

I'm not really clear on just what's being logged here, mainly due to the huge volume and not being able to match up pid numbers between the "Disconnecting" messages and the "Received disconnect…" messages.

Regardless, here's some overall stats that made me wonder how this is slipping past sshguard:

Log runs for 24 hours.

Number of loglines when nagios ssh checks are omitted:
[root@h26 /home/spork]# bzgrep -v "10.99.88.xx" /var/log/auth.log.0.bz2 |wc -l
   2428

Number of hosts blocked:
[root@h26 /home/spork]# bzgrep Blocking /var/log/auth.log.0.bz2 | wc -l
      2

Number of disconnects not from nagios ssh checks:
[root@h26 /home/spork]# bzgrep -v "10.99.88.xx" /var/log/auth.log.0.bz2 | grep "Received disconnect from" | wc -l
    108

Number of auth failures not from nagios ssh checks (not that nagios should be failing auth):
[root@h26 /home/spork]# bzgrep -v "10.99.88.xx" /var/log/auth.log.0.bz2 | grep "Disconnecting: Too many authentication failures" | wc -l
   2215

What's letting 2215 failures slip through?

Thanks,

Charles

[Sshguard-users] SSHGUARD-IPFW and freebsd 10.0

[Paul B. <me...@me...>]

Hello all!

  I was wondering if anyone else was having an issue with getting sshgueard 
to react in freebsd 10.

  I have IPFW running and the /var/log/auth.log reflects a successful 
launch of sshguard.

  That's the end of the good news, however. No matter how many times I 
initiate and fail ssh attempts to test it, sshguard never generates 
blocking messages in the log nor firewall rules to block the attempt.


Has anyone else seen this behavior in Freebsd 10?

Thanks,
  Mechno

Re: [Sshguard-users] Blocks that never go away

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

On Fri, Feb 14, 2014 at 10:40:42AM -0500, Jeff Wieland wrote:
> Has any else seen this - sshguard will indicate that the blocking
> is ">0secs", and the block doesn't go away until sshguard is
> restarted?  The log line looks like:
> 
> Feb 14 01:22:40 mymachine.purdue.edu sshguard[8951]: [ID 702911 
> auth.notice] Blocking nnn.nnn.nnn.nnn:4 for >0secs: 60 danger in 2 
> attacks over 2 seconds (all: 120d in 2 abuses over 85461s).

This is the intended final behavior for abusers who keep coming back after
their previous entries expire.  Your logs will show earlier blocks of
increasing duration for the abusers.


Richard

[Sshguard-users] Blocks that never go away

[Jeff W. <wi...@pu...>]

Has any else seen this - sshguard will indicate that the blocking
is ">0secs", and the block doesn't go away until sshguard is
restarted?  The log line looks like:

Feb 14 01:22:40 mymachine.purdue.edu sshguard[8951]: [ID 702911 
auth.notice] Blocking nnn.nnn.nnn.nnn:4 for >0secs: 60 danger in 2 
attacks over 2 seconds (all: 120d in 2 abuses over 85461s).

-- 
          Jeff Wieland            |         Purdue University
   Network Systems Administrator  |        ITIS UNIX Platforms
       Voice: (765)496-8234       |        155 S. Grant Street
        FAX: (765)494-6620        |      West Lafayette, IN 47907

[Sshguard-users] Postfix SASL patch

[Darrin S. <da...@dj...>]

Hi All,

I've made a patch against SVN rev 238, for detecting Postfix SASL authentication errors of the form:

   warning: unknown[6.6.6.0]: SASL XYZ authentication failed: 

The patch is at: http://www.djs.to/2013/10/1-postfix-sasl-support-for-sshguard/

I have using it for a couple of months, and haven't found any problems.

I also had to change the SYSLOG_BANNER_PID & SYSLOG_BANNER rules, as the postfix process name comes up as a two-part ("postfix/smtpd") on my system.

Hope this is useful out there.

Darrin

Re: [Sshguard-users] ssh-guard blocking ansible connections

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

On Sun, Dec 01, 2013 at 06:02:45PM -0200, Eric Chaves wrote:
> Since all those connections are properly authenticated (using key pairs)
> shouldn't ssh-guard not block them?

I expect the intent is to consider authenticated connections safe.

You may be missing the 'successful' part of the signal in the logs that
sshguard sees.  Without more details on your sshd make (OpenSSH, dropbear,
other?) and version, as well as on your logging setup and  your sshguard's
view of those logs, it's not possible to tell.

> Is it possible, apart from disabling ssh-guard during maintenance, to
> somehow whitelist my ip address?

Have you consiered multiplexing the ssh sessions opened by ansible under
the first/master ssh connection (c.f ControlMaster in ssh_config(5) for
OpenSSH)?

Have you considered adjusting your firewall rules to allow connections
from the ansible system before sshguard blocking is applied?


Richard

[Sshguard-users] ssh-guard blocking ansible connections

[Eric C. <er...@cr...>]

Hi folks,

I'm new to ssh-guard and just installed in one of my servers to try it out.
The problem I'm facing is that I use an automation tool (ansible) for
server setup and maintenance that works on top of ssh and therefore it does
open multiple ssh connections in short period of time, which seems to be
triggering ssh-guard alarms.

Since all those connections are properly authenticated (using key pairs)
shouldn't ssh-guard not block them?

Is it possible, apart from disabling ssh-guard during maintenance, to
somehow whitelist my ip address?

Thanks in advance for any help,

--
Eric Chaves

[Sshguard-users] Courier IMAP (imap, pop3 daemon) attack pattern/parsing patch

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

The attached patches allow sshguard (1.5 and current trunk) to detect bad
login attempts against Courier IMAP seen in my /var/log/maillog.  It gives
each attempt the default badness of 10.

There may be a better way to handle this.  A badness of 5 might be OK
too.


Richard

[Sshguard-users] Bug report and general question

[hays <ha...@cs...>]

I found a bug today, under osx the -b flag produces a
fatal error:

/usr/local/sbin/sshguard -b /var/log/blacklist
Assertion failed: (addresses[0] != NULL), function
ipfwmod_buildblockcommand, file ipfw.c, line 291.

This is reproducible on two machines, one 10.8 server and one 10.7 server.

The project hasn't been updated in a while. So the question is, is
anyone active on the project? Or have folks got to much else to do?
tia,
bil


-- 
_______________________
bil hays
Infrastructure Manager
Computer Science, UNC CH
www.cs.unc.edu/~hays
https://wwwx.cs.unc.edu/~hays/gpg.asc

[Sshguard-users] Reading SSHGUARD log

[Lutchy H. <lut...@ou...>]

From: lut...@ou...
To: ssh...@li...
Subject: Reading SSHGUARD log
Date: Wed, 2 Oct 2013 17:11:19 +0000

Hello,
I was going over sshguard documentation (at http://www.sshguard.net/docs, which is well written) and I couldn’t find information regarding how to read sshguard log entires, ie:
Blocking x.x.x.x:4 for >5400 secs: 10 danger in 1 attacks over 0 seconds (all: 10d in 1 abuses over 0s)
What does *:4 mean? 10 danger? and all: 10d in 1 abuses?
Thanks for any support that can be providedRegards

Sent from Windows Mail
 		 	   		  

[Sshguard-users] Reading SSHGUARD log

[Lutchy H. <lut...@ou...>]

Hello,


I was going over sshguard documentation (at http://www.sshguard.net/docs, which is well written) and I couldn’t find information regarding how to read sshguard log entires, ie:


Blocking x.x.x.x:4 for >5400 secs: 10 danger in 1 attacks over 0 seconds (all: 10d in 1 abuses over 0s)


What does *:4 mean? 10 danger? and all: 10d in 1 abuses?


Thanks for any support that can be provided

Regards






Sent from Windows Mail

Re: [Sshguard-users] sshguard arguments question

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

On 2013-09-04 13:41, Joop Boonen wrote:
> Dear all,
>
> I have a question/request about the sshguard arguments.
>
> Currently the white lists are entered via -w .. -w .. -w etc
> And the watched logs via -l .. -l .. -l etc
>
> As this is not easily maintainable via a configuration files that holds
> the variable with white spaces.
> I have a request could the input for the white lists and the watched
> logs be changed?
> For -w <var1> -w <var2> etc to -w <var1> <var2> etc and the the white
> list will also except an empty with list -w <space>

How about loading all the whitelist address into a file and letting 
sshguard load that file....
Way much more easily mainted

> And for the watched logs -l <var1> -l <var2> etc to -l <var1> <var2> an
> empty value is in the case not needed, as it doesn't make sense.

If you want to do this on the commandline?
Just script it a bit eg.:
	logifles = ` echo $logfilelist | sed -e '/^/-l /' -e '/ / -l /'`

--WjW