Re: [Sshguard-users] Syslog-ng 3.x Configuration

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

We can't help but relying on reports from users like you for these things, we can't run
after all releases of all adjacent software. There's no need to get upset, just keep
doing your part.

I updated the page with Adam James' configuration block, which observes the
program() update too.

Btw, the current block seemingly passes only entries from sshd. Other processes
should be included with ... and (program(1) or program(2) or ...)
-- or more generally
and not program("sshguard")

Could you syslog-ng people please test such case and contribute a lasting
configuration block for either version?



On Dec 5, 2009, at 01:31 , Byron wrote:

> Hello,
> 
> 
> The Web page at http://www.sshguard.net/docs/setup/getlogs/syslog-ng/
> details how to set up SSHGuard to work with syslog-ng.
> 
> Unfortunately, I think this information is outdated.  It does not seem
> to work correctly with syslog-ng version 3.x.  Nowhere on that Web page
> does it specify the syslog-ng version for which the instructions are
> intended, so those using newer syslog-ng versions may come to this page
> and unknowingly receive incorrect instructions.  I believe that is what
> happened to me.  Specifically, that page asks the user to add these
> lines to /etc/syslog-ng/syslog-ng.conf:
> 
> # pass only entries with auth+authpriv facilities that contain sshd
> filter sshlogs { facility(auth, authpriv) and match("sshd"); };
> # pass to this process with this template (avoids <ID> prefixes)
> destination sshguardproc {
>        program("/usr/local/sbin/sshguard"  template("$DATE $FULLHOST $MESSAGE\n"));
> };
> log { source(src); filter(sshlogs); destination(sshguardproc); };
> 
> This will not only fail to work, it also will not give any error
> messages of any kind.  The logfiles will show that sshguard starts up,
> but then when SSH/SFTP activity occurs, absolutely nothing happens no
> matter how many failed login attempts are received.
> 
> What compounds the problem is that no documentation I could find
> actually explains what kind of string (from the logs) SSHGuard is
> expecting.  Therefore, much trial and error was required to figure out
> why that didn't work.  More on that later.
> 
> In syslog-ng version 2.x, the template "$DATE $FULLHOST $MESSAGE\n" will
> produce a string like this:
> 
> "Dec  4 19:00:19 localhost sshd[30708]: Failed password for invalid user root from 192.168.1.2 port 43296 ssh2"
> 
> 
> In syslog-ng version 3.x, the template macros have changed.  Now the
> template "$DATE $FULLHOST $MESSAGE\n" will produce a string like this:
> 
> "Dec  4 19:00:19 localhost Failed password for invalid user root from 192.168.1.2 port 43296 ssh2"
> 
> 
> And that latter one doesn't work.  SSHGuard seems to just ignore it and
> does not act on it at all, though the SSHGuard process is running.
> 
> It turns out that apparently, SSHGuard needs to see the brackets and the
> colon (or maybe just the colon) to correctly parse the string.  I
> couldn't find that mentioned anywhere in the man pages, the Web site,
> forums, etc.  I think documentation should include information like this
> but it doesn't seem to.  When there is a problem, how is the user to
> validate that they are feeding SSHGuard the correct information if they
> don't know what SSHGuard is expecting or how it parses the string?  I
> determined this through trial and error by playing with the macros
> (variables) inside of the "template()" string.
> 
> This configuration DOES work for syslog-ng 3.x.  It amounts to a way to
> tell syslog-ng 3.x to construct a string just like what syslog-ng 2.x
> would have produced from "$DATE $FULLHOST $MESSAGE\n":
> 
> #SSHGuard
> 
> # pass only entries with auth+authpriv facilities that contain sshd
> 
> filter f_sshlogs { facility(auth, authpriv) and match("sshd"); };
> 
> # pass to this process with this template (avoids <ID> prefixes)
> 
> destination sshguardproc {
> 
>        program("/usr/sbin/sshguard -a 3" template("$DATE $FULLHOST $PROGRAM[$PID]: $MESSAGE\n"));
> 
> };
> 
> log { source(src); filter(f_sshlogs); destination(sshguardproc); };
> 
> 
> All this does is restore the program name, the PID in brackets, and the
> colon.  Regarding SSHGuard, the difference between syslog-ng 2.x and
> syslog-ng 3.x is that the older one included those in $MESSAGE while the
> newer one does not.  I have verified that this does work correctly and
> will use iptables to halt a password-guessing attempt.
> 
> Is there any way the SSHGuard homepage can be updated to reflect this
> information?  If it is not updated, then other users are likely to find
> themselves in a situation where they perfectly follow all instructions
> and it still doesn't work, which is most frustrating.
> 
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users