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

[Sshguard-users] sshguard 1.5rc1 Build failure on OpenBSD 4.6

[Johan B. <bu...@be...>]

Hey,

It looks like sshguard 1.5 beta 1 trough rc1 fails to build on one of my soekris boxes. Output from configure and forward (as well as uname/gcc info) below. 

1.4 is currently running on this box with the same configure options.

I did some minor research and found this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11942 , feels very unlikely - but it's better to get it out there..

Cheers,
Johan Bergström


# ./configure --with-firewall=pf                                                                                                                                                                  
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
checking for bison... no
checking for byacc... no
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking for pthread_create in -lpthread... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for unistd.h... (cached) yes
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for off_t... yes
checking for pid_t... yes
checking for size_t... yes
checking vfork.h usability... no
checking vfork.h presence... no
checking for vfork.h... no
checking for fork... yes
checking for vfork... yes
checking for working fork... yes
checking for working vfork... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking return type of signal handlers... void
checking for gethostbyname... yes
checking for inet_ntoa...  yes
checking for strerror... yes
checking for strstr... yes
checking for strtol... yes
checking for pfctl... /sbin
configure: Using /sbin as location for pfctl
configure: creating ./config.status
config.status: creating Makefile
config.status: creating man/Makefile
config.status: creating src/Makefile
config.status: creating src/parser/Makefile
config.status: creating src/fwalls/Makefile
config.status: creating src/config.h
config.status: executing depfiles commands
# uname -a
OpenBSD left 4.6 FLASHRD#0 i386
# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd4.6/3.3.5/specs
Configured with: 
Thread model: single
gcc version 3.3.5 (propolice)
# make 
Making all in src
make  all-recursive
Making all in parser
make  all-am
gcc -DHAVE_CONFIG_H -I. -I../../src     -I. -I.. -Wall -std=c99 -D_POSIX_C_SOURCE=200112L -g -O2 -MT attack_parser.o -MD -MP -MF .deps/attack_parser.Tpo -c -o attack_parser.o attack_parser.c
mv -f .deps/attack_parser.Tpo .deps/attack_parser.Po
gcc -DHAVE_CONFIG_H -I. -I../../src     -I. -I.. -Wall -std=c99 -D_POSIX_C_SOURCE=200112L -g -O2 -MT attack_scanner.o -MD -MP -MF .deps/attack_scanner.Tpo -c -o attack_scanner.o attack_scanner.c
attack_scanner.c:10502: warning: `yyunput' defined but not used
mv -f .deps/attack_scanner.Tpo .deps/attack_scanner.Po
rm -f libparser.a
ar cru libparser.a attack_parser.o  attack_scanner.o 
ranlib libparser.a
Making all in fwalls
gcc -DHAVE_CONFIG_H -I. -I../../src     -I. -I.. -Wall -std=c99 -D_POSIX_C_SOURCE=200112L -g -O2 -MT command.o -MD -MP -MF .deps/command.Tpo -c -o command.o command.c
In file included from command.c:35:
../sshguard_fw.h:88: error: invalid use of `restrict'
command.c:62: error: invalid use of `restrict'
*** Error code 1

Stop in /tmp/sshguard-1.5rc1/src/fwalls (line 92 of /usr/share/mk/sys.mk).
*** Error code 1

Stop in /tmp/sshguard-1.5rc1/src (line 363 of Makefile).
*** Error code 1

Stop in /tmp/sshguard-1.5rc1/src (line 212 of Makefile).
*** Error code 1

Stop in /tmp/sshguard-1.5rc1 (line 268 of Makefile).

Re: [Sshguard-users] apache logs

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

On Mar 27, 2010, at 20:15 , H wrote:

> Hi all,
> 
> I'm running sshguard for some time now and like to extend its use to
> apache access and error logs. The amount of php hack attempts gets annoying.
> 
> Can this be done with sshguard too ? It needs to tail multiple log
> files, and parse 40x etc. from apache logs.

The short answer is: easy to do and of interest for the team; some general
rules to describe attacks must be collected.


The long answer is:

Version 1.5 introduces two things that make this simple:
- the Log Sucker allows monitoring of multiple log files, and native
detection of log rotation
- the engine now gauges how dangerous attacks are, so that many
"disturbance hits" or one "punch hit" are treated differently.

with these, defending Apache or any other web server with Common
Log Format is just matter of adding appropriate rules to the parser.

Since alternative web servers like nginx/lighttpd/cherokee are on the rise,
but solutions like mod_security and mod_evasive are limited to Apache
for arguable design choices, sshguard could easily fill the gap serving as
an easy-to-deploy, portable, standalone IPS solution.

The only step here is to collect meaningful rules (or call them patterns)
that identify attacks from log entries, and how "dangerous" they are.
Possibilities are to start from OWASP databases, or match part of the open
Core Rule Set from ModSecurity, or simply rely on users with
http://www.sshguard.net/support/attacks/submit/ , since this feature is
getting increasing response among users.

[Sshguard-users] apache logs

[<ha...@la...>]

Hi all,

I'm running sshguard for some time now and like to extend its use to
apache access and error logs. The amount of php hack attempts gets annoying.

Can this be done with sshguard too ? It needs to tail multiple log
files, and parse 40x etc. from apache logs.

-- Hans

Re: [Sshguard-users] sshguard-1.5-r1 on gentoo: log entries missed

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

On Mar 17, 2010, at 21:58 , Robert S wrote:

> Thanks.
>  
> I left sshguard running overnight with the above config and recorded hundreds of attempts to log in that were not blocked.  It appears that the syslog-ng config is not sending messages to sshguard.
>  
> I have just downgraded sshguard to 1.4.4 and the logging is appearing again my my system log:

Combining the two pieces of information: if syslog-ng doesn't pass stuff to sshguard, it may not activate
the destination at all, that is, not start sshguard. In turn this may explain the absence of logs.

What about running 1.5 with log sucking? The log sucker saves the syslog configuration hassle.
See
http://www.sshguard.net/docs/setup/getlogs/log-sucker/


>  
> Mar 18 07:48:23 hostname syslog-ng[30304]: Configuration reload request received, reloading configuration;
> Mar 18 07:48:23 hostname sshguard[27966]: authenticating service 100 with process ID from /var/run/sshd.pid
> Mar 18 07:48:23 hostname sshguard[27966]: whitelist: add block: 192.168.2.0 with mask 24.
> Mar 18 07:48:23 hostname sshguard[27966]: whitelist: add '127.0.0.1' as plain IPv4.
> Mar 18 07:48:23 hostname sshguard[27966]: whitelist: add plain ip 127.0.0.1.
> Mar 18 07:48:23 hostname sshguard[27966]: Run command "iptables -L": exited 0.
> Mar 18 07:48:23 hostname sshguard[27966]: Blacklist loaded, 0 addresses.
> Mar 18 07:48:23 hostname sshguard[27966]: Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan.
> 
>  
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev_______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] sshguard-1.5-r1 on gentoo: log entries missed

[Robert S <rob...@gm...>]

Thanks.

I left sshguard running overnight with the above config and recorded
hundreds of attempts to log in that were not blocked.  It appears that the
syslog-ng config is not sending messages to sshguard.

I have just downgraded sshguard to 1.4.4 and the logging is appearing again
my my system log:

Mar 18 07:48:23 hostname syslog-ng[30304]: Configuration reload request
received, reloading configuration;
Mar 18 07:48:23 hostname sshguard[27966]: authenticating service 100 with
process ID from /var/run/sshd.pid
Mar 18 07:48:23 hostname sshguard[27966]: whitelist: add block: 192.168.2.0
with mask 24.
Mar 18 07:48:23 hostname sshguard[27966]: whitelist: add '127.0.0.1' as
plain IPv4.
Mar 18 07:48:23 hostname sshguard[27966]: whitelist: add plain ip 127.0.0.1.
Mar 18 07:48:23 hostname sshguard[27966]: Run command "iptables -L": exited
0.
Mar 18 07:48:23 hostname sshguard[27966]: Blacklist loaded, 0 addresses.
Mar 18 07:48:23 hostname sshguard[27966]: Started successfully [(a,p,s)=(4,
420, 1200)], now ready to scan.

Re: [Sshguard-users] sshguard-1.5-r1 on gentoo: log entries missed

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

On Mar 17, 2010, at 8:18 , Robert S wrote:

> After a bit of fiddling around it appears that this pattern is being recognised, but there is no evidence of this in my system log.  It appears that there are no ssghard messages appearing in my log.  For example:
>  
> hostname robert # killall -HUP syslog-ng
> hostname robert # tail /var/log/messages
> Mar 17 18:00:32 hostname syslog-ng[30304]: Configuration reload request received, reloading configuration;
> [ .. other system log messages ]
> hostname robert # ps ax |grep sshguard
> 21209 ?        Sl     0:00 /usr/sbin/sshguard -f 100:/var/run/sshd.pid -b /usr/local/var/sshguard/blacklist.db -w /etc/sshguard.whitelist
>  
> I am using syslog-ng 3.0.4 on gentoo.  Here is the relevant bit out of my syslog-ng config:
>  
> # pass only entries with auth+authpriv facilities from programs other than sshguard
> filter f_sshguard { facility(auth, authpriv) and not program("sshguard"); };
> # pass entries built with this format
> destination sshguard {
>         program("/usr/sbin/sshguard -f 100:/var/run/sshd.pid -b /usr/local/var/sshguard/blacklist.db -w /etc/sshguard.whitelist"
>         template("$DATE $FULLHOST $MSGHDR$MESSAGE\n")
>         );
> };
> log { source(src); filter(f_sshguard); destination(sshguard); };

Some of the syslog-ng guys can probably help you better here, but this conf snippet is
for sending log entries *to* sshguard only, not for gathering message *from* it.

sshguard logs its activity with AUTH facility. Where these messages go depends on
how you configured this facility (destination and level) -- I'm not familiar with gentoo's
default configuration. Try a "grep -r sshguard /var/log" if you have no clue.


> I've used the log sucker and SSHGUARD_DEBUG, but this is rather cumbersome and really only useful for debugging.

Yes, DEBUG is meant for debug, not regular use.

[Sshguard-users] sshguard-1.5-r1 on gentoo: log entries missed

[Robert S <rob...@gm...>]

After a bit of fiddling around it appears that this pattern is being
recognised, but there is no evidence of this in my system log.  It appears
that there are no ssghard messages appearing in my log.  For example:

hostname robert # killall -HUP syslog-ng
hostname robert # tail /var/log/messages
Mar 17 18:00:32 hostname syslog-ng[30304]: Configuration reload request
received, reloading configuration;
[ .. other system log messages ]
hostname robert # ps ax |grep sshguard
21209 ?        Sl     0:00 /usr/sbin/sshguard -f 100:/var/run/sshd.pid -b
/usr/local/var/sshguard/blacklist.db -w /etc/sshguard.whitelist

I am using syslog-ng 3.0.4 on gentoo.  Here is the relevant bit out of my
syslog-ng config:

# pass only entries with auth+authpriv facilities from programs other than
sshguard
filter f_sshguard { facility(auth, authpriv) and not program("sshguard"); };
# pass entries built with this format
destination sshguard {
        program("/usr/sbin/sshguard -f 100:/var/run/sshd.pid -b
/usr/local/var/sshguard/blacklist.db -w /etc/sshguard.whitelist"
        template("$DATE $FULLHOST $MSGHDR$MESSAGE\n")
        );
};
log { source(src); filter(f_sshguard); destination(sshguard); };
I've used the log sucker and SSHGUARD_DEBUG, but this is rather cumbersome
and really only useful for debugging.

Re: [Sshguard-users] Found a bug in latest svn repository

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

thanks, they're now both committed to r182

[Sshguard-users] Found a bug in latest svn repository

[El T. <ca...@gm...>]

Hi,

I found a bug in
src/fwalls/hosts.c

1. there is a global variable tempflname, but in fw_init() and
hosts_updatelist(), local variables with the same name are also defined,
this caused make_temporary_conffile() always fails. Fix: local variables
should be deleted;
2. the glboal variable tempflname should be initialized as soon as possible
in fw_init(), otherwise hosts_clearsshguardblocks() tries to create temp
file with invalid name (and fails).

cameos

Re: [Sshguard-users] sshguard-1.5-r1 on gentoo: log entries missed

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

On Mar 11, 2010, at 12:22 , Robert S wrote:

> I have been getting a lot of these messages:
>  
> Mar 11 13:40:36 myhost sshd[30548]: User root from 202.111.128.225 not allowed because none of user's groups are listed in AllowGroups
>  
> These are not triggering any response to sshguard.  I have the following line in my /etc/ssh/sshd_config:
>  
> AllowGroups ssh_users
>  
> Is there some way that sshgurard can be got to respond to these? Alternatively is it possible to activate the firewall after an attempted root login?


It seems that the "pattern submission" feature is still not apparent enough :)

Please submit to
http://www.sshguard.net/support/attacks/submit/
This is an interesting case, I'll bump up its priority.

[Sshguard-users] sshguard-1.5-r1 on gentoo: log entries missed

[Robert S <rob...@gm...>]

I have been getting a lot of these messages:

Mar 11 13:40:36 myhost sshd[30548]: User root from 202.111.128.225 not
allowed because none of user's groups are listed in AllowGroups

These are not triggering any response to sshguard.  I have the following
line in my /etc/ssh/sshd_config:

AllowGroups ssh_users

Is there some way that sshgurard can be got to respond to these?
Alternatively is it possible to activate the firewall after an attempted
root login?

Re: [Sshguard-users] proftpd maps ipv4 addresses to ipv6 in its log and sshguard treats them as ipv6

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

committed in r177, see
http://www.sshguard.net/download/repository/


On Feb 24, 2010, at 14:03 , Arne Riecken wrote:

> Hello,
> 
> when proftpd runs with ipv6 support, it maps ipv4 addresses to ipv6
> (::ffff:1.2.3.4) in the log. Then sshguard treats it as ipv6 address
> and executes e.g.
> 
> ip6tables -A sshguard -s ::ffff:1.2.3.4/128 -j DROP
> 
> so the ipv4 address will not be blocked with iptables.
> 
> I posted the problem here:
> 
> http://forums.proftpd.org/smf/index.php/topic,3817.msg13663.html#msg13663
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] proftpd maps ipv4 addresses to ipv6 in its log and sshguard treats them as ipv6

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

Interesting point. I guess the dual-stack carries inevitably an ambiguity
on how to treat mapped addresses. Although they are IPv6, it makes
sense to treat them as plain IPv4 as they traverse the IPv4 stack rather
than the 6 one.

I'll think about it over the next days.


On Feb 24, 2010, at 14:03 , Arne Riecken wrote:

> Hello,
> 
> when proftpd runs with ipv6 support, it maps ipv4 addresses to ipv6
> (::ffff:1.2.3.4) in the log. Then sshguard treats it as ipv6 address
> and executes e.g.
> 
> ip6tables -A sshguard -s ::ffff:1.2.3.4/128 -j DROP
> 
> so the ipv4 address will not be blocked with iptables.
> 
> I posted the problem here:
> 
> http://forums.proftpd.org/smf/index.php/topic,3817.msg13663.html#msg13663

[Sshguard-users] proftpd maps ipv4 addresses to ipv6 in its log and sshguard treats them as ipv6

[Arne R. <arn...@go...>]

Hello,

when proftpd runs with ipv6 support, it maps ipv4 addresses to ipv6
(::ffff:1.2.3.4) in the log. Then sshguard treats it as ipv6 address
and executes e.g.

ip6tables -A sshguard -s ::ffff:1.2.3.4/128 -j DROP

so the ipv4 address will not be blocked with iptables.

I posted the problem here:

http://forums.proftpd.org/smf/index.php/topic,3817.msg13663.html#msg13663

Re: [Sshguard-users] Welcome to the "Sshguard-users" mailing list

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

Mind the terminology there:
- attack is one "dangerous record" in your logs
- abuse as many "dangerous records" (attacks) as it takes to block the attacker

Attackers are blocked after (by default) 4 attacks, but blacklisted after 3 abuses.
That is, your attacker has got to be blocked three times (12 attacks) to end up in
the blacklist. If you want to blacklist right away, use -b 1:/var/...
However, use with care. See
http://www.sshguard.net/docs/faqs/#why-addresses-released


p.s.: do not use "Reply" to the subscription confirmation to write to the mailing list.
Be good to the archives and make the effort of producing a new message and
make up a significant Subject for it.


On Feb 18, 2010, at 03:43 , ravikiran velineni wrote:

> Hello Everyone,
> 
> I am using sshguard 1.4 version  on freebsd 7. It is able to block ip address and release according to number  of abuses. But, when i issued the command 
> sshguard b 3:/var/db/sshguard/blacklist.db  . even though from same ip there are more than three abuses it is not blacklisting the ip. it is releasing the IP again. i can able to do ssh. Anyone help me out in this regard.  I will appreciate you help.
> 
> Thank you, 
> Ravi. v.
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs 
> proactively, and fine-tune applications for parallel performance. 
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev_______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] Welcome to the "Sshguard-users" mailing list

[ravikiran v. <vr...@gm...>]

Hello Everyone,

I am using sshguard 1.4 version  on freebsd 7. It is able to block ip
address and release according to number  of abuses. But, when i issued the
command
sshguard b 3:/var/db/sshguard/blacklist.db  . even though from same ip there
are more than three abuses it is not blacklisting the ip. it is releasing
the IP again. i can able to do ssh. Anyone help me out in this regard.  I
will appreciate you help.

Thank you,
Ravi. v.

Re: [Sshguard-users] Blocking bots looking for vulnerable web apps

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

For the archives, the switch from attack counts to
weight/density/dangerousness has been committed
in r173 as part of other features, and will make it
into version 1.5.
This makes it reasonable to implement handling
of messages of the kind we discussed in this thread.
If someone is still interested, feel free to submit to

http://www.sshguard.net/support/attacks/submit/


On Jul 3, 2009, at 17:14 , Mij wrote:

> FYI, we've scheduled this for 1.5 and we'll be working on this kind of  
> soon.
> 
> 
> On Apr 22, 2009, at 11:49 , Hans F. Nordhaug wrote:
> 
>> Thx for your reply, michele, and sorry about not coming back to this
>> issue before now. To me 1 isn't such a big problem - there are many
>> ways to work around it. However, 2 is a real problem that I didn't
>> think about. I clearly can't use the same "density" for SSH and HTTP.
>> I think I'll wait for you ;-)
>> 
>> I definetly think this would be a nice addition to SSHGuard, but I
>> also realize that it might not make sense to extend SSHGuard to handle
>> every thing. Maybe there are other tools out there that all ready
>> do the job? I just happen to like SSHGuard.
>> 
>> Regards,
>> Hans
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] sshguard 1.4.4 blocking attempts only when "it's sunny" (lol)

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

Hi Teuxe

On Feb 7, 2010, at 02:33 , Teuxe wrote:

> Hi,
> 
> [This mail contains log dumps, I first apologize for its length.]
> 
> I installed sshguard some days ago as a sysconf-ng.log service:
> 
> destination dp_sshguard {
>    program("/usr/local/sbin/sshguard -f 100:/var/run/sshd.pid"
>        template("$DATE $FULLHOST $MESSAGE\n"));
> };
> filter f_sshlogs {
>    facility(auth, authpriv)
>        and not match("sshguard");
> };
> log {
>        source(s_all);
>        filter(f_sshlogs);
>        destination(dp_sshguard);
> };
> 
> I kept default configuration (4 failures adding an entry in table 
> "sshguard") and I found it was working well (at first) since it blocked 
> a login attempt from a computer connected by Ethernet.
> Later on (there was a reboot on Feb 3 09:45), I noticed in auth.log that 
> a first attempt is well detected:
> 
> Feb  3 18:24:04 neo sshd[3234]: Address 212.156.65.78 maps to 
> static.turktelekom.com.tr, but this does not map back to the address - 
> POSSIBLE BREAK-IN ATTEMPT!
> Feb  3 18:24:04 neo sshd[3234]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.156.65.78  user=root
> Feb  3 18:24:06 neo sshd[3234]: Failed password for root from 
> 212.156.65.78 port 36865 ssh2
> Feb  3 18:24:07 neo sshd[3238]: Address 212.156.65.78 maps to 
> static.turktelekom.com.tr, but this does not map back to the address - 
> POSSIBLE BREAK-IN ATTEMPT!
> Feb  3 18:24:07 neo sshd[3238]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.156.65.78  user=root
> Feb  3 18:24:09 neo sshd[3238]: Failed password for root from 
> 212.156.65.78 port 37262 ssh2
> Feb  3 18:24:10 neo sshd[3242]: Address 212.156.65.78 maps to 
> static.turktelekom.com.tr, but this does not map back to the address - 
> POSSIBLE BREAK-IN ATTEMPT!
> Feb  3 18:24:10 neo sshd[3242]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.156.65.78  user=root
> Feb  3 18:24:12 neo sshd[3242]: Failed password for root from 
> 212.156.65.78 port 37674 ssh2
> Feb  3 18:24:13 neo sshd[3246]: Address 212.156.65.78 maps to 
> static.turktelekom.com.tr, but this does not map back to the address - 
> POSSIBLE BREAK-IN ATTEMPT!
> Feb  3 18:24:13 neo sshd[3246]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.156.65.78  user=root
> Feb  3 18:24:15 neo sshd[3246]: Failed password for root from 
> 212.156.65.78 port 38040 ssh2
> Feb  3 18:24:15 neo sshguard[2138]: Blocking 212.156.65.78:4 for 
>> 420secs: 4 failures over 9 seconds.
> 
> ... but the following are not AT ALL (there are plenty of such attempts 
> in bulk):
> 
> Feb  4 00:53:19 neo sshd[3927]: Did not receive identification string 
> from 163.43.128.225
> Feb  4 00:57:14 neo sshd[3930]: Invalid user admin from 163.43.128.225
> Feb  4 00:57:14 neo sshd[3930]: pam_unix(sshd:auth): check pass; user 
> unknown
> Feb  4 00:57:14 neo sshd[3930]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=163.43.128.225
> Feb  4 00:57:15 neo sshd[3930]: Failed password for invalid user admin 
> from 163.43.128.225 port 48550 ssh2
> Feb  4 00:57:23 neo sshd[3932]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=163.43.128.225  
> user=root
> Feb  4 00:57:25 neo sshd[3932]: Failed password for root from 
> 163.43.128.225 port 49018 ssh2
> Feb  4 00:57:32 neo sshd[3934]: Invalid user stud from 163.43.128.225
> Feb  4 00:57:32 neo sshd[3934]: pam_unix(sshd:auth): check pass; user 
> unknown
> Feb  4 00:57:32 neo sshd[3934]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=163.43.128.225
> Feb  4 00:57:34 neo sshd[3934]: Failed password for invalid user stud 
> from 163.43.128.225 port 49488 ssh2
> Feb  4 00:57:42 neo sshd[3936]: Invalid user trash from 163.43.128.225
> Feb  4 00:57:42 neo sshd[3936]: pam_unix(sshd:auth): check pass; user 
> unknown
> Feb  4 00:57:42 neo sshd[3936]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=163.43.128.225
> Feb  4 00:57:44 neo sshd[3936]: Failed password for invalid user trash 
> from 163.43.128.225 port 49962 ssh2
> Feb  4 00:57:51 neo sshd[3938]: Invalid user aaron from 163.43.128.225
> Feb  4 00:57:51 neo sshd[3938]: pam_unix(sshd:auth): check pass; user 
> unknown
> Feb  4 00:57:51 neo sshd[3938]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=163.43.128.225
> Feb  4 00:57:53 neo sshd[3938]: Failed password for invalid user aaron 
> from 163.43.128.225 port 50460 ssh2
> Feb  6 03:12:16 neo sshd[12669]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= 
> rhost=xenmaster01.drecomm.nl  user=root
> Feb  6 03:12:17 neo sshd[12669]: Failed password for root from 
> 91.209.192.28 port 34608 ssh2
> Feb  6 03:12:17 neo sshd[12671]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= 
> rhost=xenmaster01.drecomm.nl  user=root
> Feb  6 03:12:19 neo sshd[12671]: Failed password for root from 
> 91.209.192.28 port 34895 ssh2
> Feb  6 03:12:19 neo sshd[12673]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= 
> rhost=xenmaster01.drecomm.nl  user=root
> Feb  6 03:12:22 neo sshd[12673]: Failed password for root from 
> 91.209.192.28 port 35196 ssh2
> 
> However after some time, it works again once (but after... 2 failures ONLY):
> 
> Feb  6 15:13:08 neo sshd[13617]: Invalid user lucus from 92.46.123.11
> Feb  6 15:13:08 neo sshd[13617]: pam_unix(sshd:auth): check pass; user 
> unknown
> Feb  6 15:13:08 neo sshd[13617]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=92.46.123.11
> Feb  6 15:13:09 neo sshd[13617]: Failed password for invalid user lucus 
> from 92.46.123.11 port 51418 ssh2
> Feb  6 15:13:16 neo sshd[13623]: Invalid user luis from 92.46.123.11
> Feb  6 15:13:16 neo sshd[13623]: pam_unix(sshd:auth): check pass; user 
> unknown
> Feb  6 15:13:16 neo sshd[13623]: pam_unix(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=92.46.123.11
> Feb  6 15:13:18 neo sshd[13623]: Failed password for invalid user luis 
> from 92.46.123.11 port 55350 ssh2
> Feb  6 15:13:18 neo sshguard[12878]: Blocking 92.46.123.11:4 for >420secs: 4 failures over 10 seconds.

seems like sshguard is not receiving these messages.
For simplifying the investigation you can try to exclude syslog-ng
and get logs directly, either with the tail+sshguard combo
http://www.sshguard.net/docs/setup/getlogs/raw-file/
or with the Log Sucker (version 1.5, fetch from the SVN).

Since version 1.5 stable, the Log Sucker will be the recommended
mean to get log entries.


> I first checked that the daemon was still running using a "ps faux | 
> grep sshguard", it was still here. There was no reboot since the first 
> detect:
> # date -R; uptime
> Sun, 07 Feb 2010, 02:27:02 +0100
> 02:27:02 up 3 days, 16:40,  5 users,  load average: 0.43, 0.24, 0.20
> 
> I decided to attempt false ssh logins from localhost: none was detected, 
> while entries are present in auth.log:
> 
> Feb  7 01:57:39 neo sshd[17773]: Invalid user xxx from 127.0.0.1
> Feb  7 01:57:39 neo sshd[17773]: Failed none for invalid user xxx from 
> 127.0.0.1 port 37225 ssh2
> Feb  7 01:57:40 neo sshd[17773]: Failed password for invalid user xxx 
> from 127.0.0.1 port 37225 ssh2
> Feb  7 01:57:41 neo sshd[17773]: Failed password for invalid user xxx 
> from 127.0.0.1 port 37225 ssh2
> Feb  7 01:57:41 neo sshd[17773]: Failed password for invalid user xxx 
> from 127.0.0.1 port 37225 ssh2
> Feb  7 01:59:37 neo sshd[17802]: Failed password for root from 127.0.0.1 
> port 37232 ssh2
> Feb  7 01:59:37 neo sshd[17802]: Failed password for root from 127.0.0.1 
> port 37232 ssh2
> Feb  7 01:59:37 neo sshd[17802]: Failed password for root from 127.0.0.1 
> port 37232 ssh2
> Feb  7 01:59:40 neo sshd[17806]: Failed password for root from 127.0.0.1 
> port 37233 ssh2
> Feb  7 01:59:41 neo sshd[17806]: Failed password for root from 127.0.0.1 
> port 37233 ssh2
> Feb  7 01:59:42 neo sshd[17806]: Failed password for root from 127.0.0.1 
> port 37233 ssh2

localhost is unilaterally whitelisted a-priori by sshguard for security reasons.
Imagine what'd happen if you prevent traffic through 127.0.0.1 .


> --> I notice that traces are well different, pam_unix is not shown for 
> localhost attempts (maybe this is normal, due to localhost?).
> Currently I have no other computer to make an "external test" (the 
> previous one is dead :-/ ).
> 
> 
> Have you any idea on what can happen? Which tests can I do?
> Thanks a lot,
> 
> 
> Teuxe
> 
> PS. By the way I may have updated my standard system in-between, maybe 
> ssh log formats have changed?

[Sshguard-users] sshguard 1.4.4 blocking attempts only when "it's sunny" (lol)

[Teuxe <te...@fr...>]

Hi,

[This mail contains log dumps, I first apologize for its length.]

I installed sshguard some days ago as a sysconf-ng.log service:

destination dp_sshguard {
    program("/usr/local/sbin/sshguard -f 100:/var/run/sshd.pid"
        template("$DATE $FULLHOST $MESSAGE\n"));
};
filter f_sshlogs {
    facility(auth, authpriv)
        and not match("sshguard");
};
log {
        source(s_all);
        filter(f_sshlogs);
        destination(dp_sshguard);
};

I kept default configuration (4 failures adding an entry in table 
"sshguard") and I found it was working well (at first) since it blocked 
a login attempt from a computer connected by Ethernet.
Later on (there was a reboot on Feb 3 09:45), I noticed in auth.log that 
a first attempt is well detected:

Feb  3 18:24:04 neo sshd[3234]: Address 212.156.65.78 maps to 
static.turktelekom.com.tr, but this does not map back to the address - 
POSSIBLE BREAK-IN ATTEMPT!
Feb  3 18:24:04 neo sshd[3234]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.156.65.78  user=root
Feb  3 18:24:06 neo sshd[3234]: Failed password for root from 
212.156.65.78 port 36865 ssh2
Feb  3 18:24:07 neo sshd[3238]: Address 212.156.65.78 maps to 
static.turktelekom.com.tr, but this does not map back to the address - 
POSSIBLE BREAK-IN ATTEMPT!
Feb  3 18:24:07 neo sshd[3238]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.156.65.78  user=root
Feb  3 18:24:09 neo sshd[3238]: Failed password for root from 
212.156.65.78 port 37262 ssh2
Feb  3 18:24:10 neo sshd[3242]: Address 212.156.65.78 maps to 
static.turktelekom.com.tr, but this does not map back to the address - 
POSSIBLE BREAK-IN ATTEMPT!
Feb  3 18:24:10 neo sshd[3242]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.156.65.78  user=root
Feb  3 18:24:12 neo sshd[3242]: Failed password for root from 
212.156.65.78 port 37674 ssh2
Feb  3 18:24:13 neo sshd[3246]: Address 212.156.65.78 maps to 
static.turktelekom.com.tr, but this does not map back to the address - 
POSSIBLE BREAK-IN ATTEMPT!
Feb  3 18:24:13 neo sshd[3246]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.156.65.78  user=root
Feb  3 18:24:15 neo sshd[3246]: Failed password for root from 
212.156.65.78 port 38040 ssh2
Feb  3 18:24:15 neo sshguard[2138]: Blocking 212.156.65.78:4 for 
 >420secs: 4 failures over 9 seconds.

... but the following are not AT ALL (there are plenty of such attempts 
in bulk):

Feb  4 00:53:19 neo sshd[3927]: Did not receive identification string 
from 163.43.128.225
Feb  4 00:57:14 neo sshd[3930]: Invalid user admin from 163.43.128.225
Feb  4 00:57:14 neo sshd[3930]: pam_unix(sshd:auth): check pass; user 
unknown
Feb  4 00:57:14 neo sshd[3930]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=163.43.128.225
Feb  4 00:57:15 neo sshd[3930]: Failed password for invalid user admin 
from 163.43.128.225 port 48550 ssh2
Feb  4 00:57:23 neo sshd[3932]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=163.43.128.225  
user=root
Feb  4 00:57:25 neo sshd[3932]: Failed password for root from 
163.43.128.225 port 49018 ssh2
Feb  4 00:57:32 neo sshd[3934]: Invalid user stud from 163.43.128.225
Feb  4 00:57:32 neo sshd[3934]: pam_unix(sshd:auth): check pass; user 
unknown
Feb  4 00:57:32 neo sshd[3934]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=163.43.128.225
Feb  4 00:57:34 neo sshd[3934]: Failed password for invalid user stud 
from 163.43.128.225 port 49488 ssh2
Feb  4 00:57:42 neo sshd[3936]: Invalid user trash from 163.43.128.225
Feb  4 00:57:42 neo sshd[3936]: pam_unix(sshd:auth): check pass; user 
unknown
Feb  4 00:57:42 neo sshd[3936]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=163.43.128.225
Feb  4 00:57:44 neo sshd[3936]: Failed password for invalid user trash 
from 163.43.128.225 port 49962 ssh2
Feb  4 00:57:51 neo sshd[3938]: Invalid user aaron from 163.43.128.225
Feb  4 00:57:51 neo sshd[3938]: pam_unix(sshd:auth): check pass; user 
unknown
Feb  4 00:57:51 neo sshd[3938]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=163.43.128.225
Feb  4 00:57:53 neo sshd[3938]: Failed password for invalid user aaron 
from 163.43.128.225 port 50460 ssh2
Feb  6 03:12:16 neo sshd[12669]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= 
rhost=xenmaster01.drecomm.nl  user=root
Feb  6 03:12:17 neo sshd[12669]: Failed password for root from 
91.209.192.28 port 34608 ssh2
Feb  6 03:12:17 neo sshd[12671]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= 
rhost=xenmaster01.drecomm.nl  user=root
Feb  6 03:12:19 neo sshd[12671]: Failed password for root from 
91.209.192.28 port 34895 ssh2
Feb  6 03:12:19 neo sshd[12673]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= 
rhost=xenmaster01.drecomm.nl  user=root
Feb  6 03:12:22 neo sshd[12673]: Failed password for root from 
91.209.192.28 port 35196 ssh2

However after some time, it works again once (but after... 2 failures ONLY):

Feb  6 15:13:08 neo sshd[13617]: Invalid user lucus from 92.46.123.11
Feb  6 15:13:08 neo sshd[13617]: pam_unix(sshd:auth): check pass; user 
unknown
Feb  6 15:13:08 neo sshd[13617]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=92.46.123.11
Feb  6 15:13:09 neo sshd[13617]: Failed password for invalid user lucus 
from 92.46.123.11 port 51418 ssh2
Feb  6 15:13:16 neo sshd[13623]: Invalid user luis from 92.46.123.11
Feb  6 15:13:16 neo sshd[13623]: pam_unix(sshd:auth): check pass; user 
unknown
Feb  6 15:13:16 neo sshd[13623]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=92.46.123.11
Feb  6 15:13:18 neo sshd[13623]: Failed password for invalid user luis 
from 92.46.123.11 port 55350 ssh2
Feb  6 15:13:18 neo sshguard[12878]: Blocking 92.46.123.11:4 for 
 >420secs: 4 failures over 10 seconds.


I first checked that the daemon was still running using a "ps faux | 
grep sshguard", it was still here. There was no reboot since the first 
detect:
# date -R; uptime
Sun, 07 Feb 2010, 02:27:02 +0100
 02:27:02 up 3 days, 16:40,  5 users,  load average: 0.43, 0.24, 0.20

I decided to attempt false ssh logins from localhost: none was detected, 
while entries are present in auth.log:

Feb  7 01:57:39 neo sshd[17773]: Invalid user xxx from 127.0.0.1
Feb  7 01:57:39 neo sshd[17773]: Failed none for invalid user xxx from 
127.0.0.1 port 37225 ssh2
Feb  7 01:57:40 neo sshd[17773]: Failed password for invalid user xxx 
from 127.0.0.1 port 37225 ssh2
Feb  7 01:57:41 neo sshd[17773]: Failed password for invalid user xxx 
from 127.0.0.1 port 37225 ssh2
Feb  7 01:57:41 neo sshd[17773]: Failed password for invalid user xxx 
from 127.0.0.1 port 37225 ssh2
Feb  7 01:59:37 neo sshd[17802]: Failed password for root from 127.0.0.1 
port 37232 ssh2
Feb  7 01:59:37 neo sshd[17802]: Failed password for root from 127.0.0.1 
port 37232 ssh2
Feb  7 01:59:37 neo sshd[17802]: Failed password for root from 127.0.0.1 
port 37232 ssh2
Feb  7 01:59:40 neo sshd[17806]: Failed password for root from 127.0.0.1 
port 37233 ssh2
Feb  7 01:59:41 neo sshd[17806]: Failed password for root from 127.0.0.1 
port 37233 ssh2
Feb  7 01:59:42 neo sshd[17806]: Failed password for root from 127.0.0.1 
port 37233 ssh2

--> I notice that traces are well different, pam_unix is not shown for 
localhost attempts (maybe this is normal, due to localhost?).
Currently I have no other computer to make an "external test" (the 
previous one is dead :-/ ).


Have you any idea on what can happen? Which tests can I do?
Thanks a lot,


Teuxe

PS. By the way I may have updated my standard system in-between, maybe 
ssh log formats have changed?

Re: [Sshguard-users] [syslog-ng] syslog-ng MSGHDR

[Balazs S. <ba...@ba...>]

On Fri, 2010-01-22 at 16:35 +0100, Mij wrote:
> On Jan 22, 2010, at 11:25 , Balazs Scheidler wrote:
> 
> >> Can you clarify what is the intended template for producing entry tags
> >> of the classic format "Jan 21 12:54:09 examplehost proftpd[18965]: applmsg"
> >> in the different versions?
> > 
> > Can you show the user posting that states MSGHDR is the wrong approach
> > to do? I might be able to help troubleshooting it.
> 
> 
> sure. Confront:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=EE040D72-0185-41EB-BECE-DED8C0272EDB%40sshguard.net&forum_name=sshguard-users
> http://sourceforge.net/mailarchive/forum.php?thread_name=DA2160C1-09A0-475D-B32A-AF10B712E403%40sshguard.net&forum_name=sshguard-users
> 
> with:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=C5633AC6-CD8F-451F-B301-D0FDC5130AB1%40sshguard.net&forum_name=sshguard-users
> http://sourceforge.net/mailarchive/forum.php?thread_name=8cb75a4a1001210418g30d0968ck79e8a4d1a6808bba%40mail.gmail.com&forum_name=sshguard-users
> 
> Notice the double "proftpd[25517]: proftpd[25517]:" occurrence when prepending $MSGHDR .
> 

I can't post there via the webpage, but the problem is most probably a
missing "@version: 3.0" line in the configuration. without that
syslog-ng 3.0 is operating in 2.x compatible mode.

However the posts there didn't include a complete configuration file,
but I guess this is the root cause of the problem.

Also, the missing @version directive is logged as a warning at syslog-ng
startup.


-- 
Bazsi

Re: [Sshguard-users] [syslog-ng] syslog-ng MSGHDR

[Arne R. <arn...@go...>]

As I understand, to use $MSGHDR$MESSAGE with syslog-ng 3.x there has
to be a version 3 header in the config file, otherwise it has to be
$MESSAGE because of version 2 compatibility. So the version 3 header
is missing in the sshguard config example.

2010/1/22 Balazs Scheidler <ba...@ba...>:
> On Fri, 2010-01-22 at 09:43 +0100, Mij wrote:
>> Dear syslog-ng folks,
>>
>> I am the maintainer of sshguard, see http://www.sshguard.net .
>> Sshguard can be interfaced with syslog-ng. Multiple users of syslog-ng
>> recently reported that switching to 3.x required a configuration change
>> for preserving the original logging format, see
>>
>> https://sourceforge.net/mailarchive/forum.php?thread_name=EE040D72-0185-41EB-BECE-DED8C0272EDB%40sshguard.net&forum_name=sshguard-users
>> https://sourceforge.net/mailarchive/forum.php?thread_name=DA2160C1-09A0-475D-B32A-AF10B712E403%40sshguard.net&forum_name=sshguard-users
>>
>> We reflected the reports by updating the setup docs to contain a block
>> for the 2.x version and one for 3.x , see
>>
>> http://www.sshguard.net/docs/setup/getlogs/syslog-ng/
>>
>> However, this change is not apparent in your documentation or changelogs,
>> and other users reported that with even more recent versions, the "old format"
>> is again the correct one.
>
> syslog-ng can operate in both 2.x compatible mode and 3.x compatible
> mode. The '@version' header in the syslog-ng configuration file controls
> which one is used.
>
> If someone has no version header, syslog-ng assumes it wants syslog-ng
> 2.x compatibility.
>
> There was no macro related changes in the 3.0 series and still the
> format with the MSGHDR is the correct one.
>
>>
>> Can you clarify what is the intended template for producing entry tags
>> of the classic format "Jan 21 12:54:09 examplehost proftpd[18965]: applmsg"
>> in the different versions?
>
> Can you show the user posting that states MSGHDR is the wrong approach
> to do? I might be able to help troubleshooting it.
>
> --
> Bazsi
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

Re: [Sshguard-users] [syslog-ng] syslog-ng MSGHDR

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

On Jan 22, 2010, at 11:25 , Balazs Scheidler wrote:

>> Can you clarify what is the intended template for producing entry tags
>> of the classic format "Jan 21 12:54:09 examplehost proftpd[18965]: applmsg"
>> in the different versions?
> 
> Can you show the user posting that states MSGHDR is the wrong approach
> to do? I might be able to help troubleshooting it.


sure. Confront:

http://sourceforge.net/mailarchive/forum.php?thread_name=EE040D72-0185-41EB-BECE-DED8C0272EDB%40sshguard.net&forum_name=sshguard-users
http://sourceforge.net/mailarchive/forum.php?thread_name=DA2160C1-09A0-475D-B32A-AF10B712E403%40sshguard.net&forum_name=sshguard-users

with:

http://sourceforge.net/mailarchive/forum.php?thread_name=C5633AC6-CD8F-451F-B301-D0FDC5130AB1%40sshguard.net&forum_name=sshguard-users
http://sourceforge.net/mailarchive/forum.php?thread_name=8cb75a4a1001210418g30d0968ck79e8a4d1a6808bba%40mail.gmail.com&forum_name=sshguard-users

Notice the double "proftpd[25517]: proftpd[25517]:" occurrence when prepending $MSGHDR .

Re: [Sshguard-users] [syslog-ng] syslog-ng MSGHDR

[Balazs S. <ba...@ba...>]

On Fri, 2010-01-22 at 09:43 +0100, Mij wrote:
> Dear syslog-ng folks,
> 
> I am the maintainer of sshguard, see http://www.sshguard.net .
> Sshguard can be interfaced with syslog-ng. Multiple users of syslog-ng
> recently reported that switching to 3.x required a configuration change
> for preserving the original logging format, see
> 
> https://sourceforge.net/mailarchive/forum.php?thread_name=EE040D72-0185-41EB-BECE-DED8C0272EDB%40sshguard.net&forum_name=sshguard-users
> https://sourceforge.net/mailarchive/forum.php?thread_name=DA2160C1-09A0-475D-B32A-AF10B712E403%40sshguard.net&forum_name=sshguard-users
> 
> We reflected the reports by updating the setup docs to contain a block
> for the 2.x version and one for 3.x , see
> 
> http://www.sshguard.net/docs/setup/getlogs/syslog-ng/
> 
> However, this change is not apparent in your documentation or changelogs,
> and other users reported that with even more recent versions, the "old format"
> is again the correct one.

syslog-ng can operate in both 2.x compatible mode and 3.x compatible
mode. The '@version' header in the syslog-ng configuration file controls
which one is used.

If someone has no version header, syslog-ng assumes it wants syslog-ng
2.x compatibility.

There was no macro related changes in the 3.0 series and still the
format with the MSGHDR is the correct one.

> 
> Can you clarify what is the intended template for producing entry tags
> of the classic format "Jan 21 12:54:09 examplehost proftpd[18965]: applmsg"
> in the different versions?

Can you show the user posting that states MSGHDR is the wrong approach
to do? I might be able to help troubleshooting it.

-- 
Bazsi

[Sshguard-users] syslog-ng MSGHDR

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

Dear syslog-ng folks,

I am the maintainer of sshguard, see http://www.sshguard.net .
Sshguard can be interfaced with syslog-ng. Multiple users of syslog-ng
recently reported that switching to 3.x required a configuration change
for preserving the original logging format, see

https://sourceforge.net/mailarchive/forum.php?thread_name=EE040D72-0185-41EB-BECE-DED8C0272EDB%40sshguard.net&forum_name=sshguard-users
https://sourceforge.net/mailarchive/forum.php?thread_name=DA2160C1-09A0-475D-B32A-AF10B712E403%40sshguard.net&forum_name=sshguard-users

We reflected the reports by updating the setup docs to contain a block
for the 2.x version and one for 3.x , see

http://www.sshguard.net/docs/setup/getlogs/syslog-ng/

However, this change is not apparent in your documentation or changelogs,
and other users reported that with even more recent versions, the "old format"
is again the correct one.

Can you clarify what is the intended template for producing entry tags
of the classic format "Jan 21 12:54:09 examplehost proftpd[18965]: applmsg"
in the different versions?

thanks

Re: [Sshguard-users] proftpd login failures are not matched when using $MSGHDR in syslog-ng template as the docu says

[Arne R. <arn...@go...>]

template("$DATE $FULLHOST $MESSAGE\n") gives:

Jan 21 12:54:09 examplehost proftpd[18965]: examplehost.fqdn.tld
(1.2.3.4[1.2.3.4]) - USER test: no such user found from 1.2.3.4
[1.2.3.4] to 4.3.2.1:21


template("$DATE $FULLHOST $MSGHDR$MESSAGE\n") gives:

Jan 21 13:04:22 examplehost proftpd[25517]: proftpd[25517]:
examplehost.fqdn.tld (1.2.3.4[1.2.3.4]) - USER test: no such user
found from 1.2.3.4 [1.2.3.4] to 4.3.2.1:21


syslog-ng version is 3.0.4



---
interesting. Based on others' reports, the cases should look like the following:

1) with "$DATE $FULLHOST $MESSAGE" (v2):
Dec 4 19:00:19 localhost host.domain.com (1.2.3.4[1.2.3.4]) - USER
foobar: no such user
found from 1.2.3.4 [1.2.3.4] to 5.6.7.8:21

2) with "$DATE $FULLHOST $MSGHDR$MESSAGE\n" (v3):
Dec 4 19:00:19 localhost proftpd[345]: host.domain.com
(1.2.3.4[1.2.3.4]) - USER foobar:
no such user found from 1.2.3.4 [1.2.3.4] to 5.6.7.8:21

If this is not the case, please indicate the two formats produced instead.
Essentially, sshguard expects a standard format for syslog/syslog-ng's prefix.