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

[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.

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

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

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.


On Jan 20, 2010, at 12:52 , Arne Riecken wrote:

> Hello,
> 
> http://www.sshguard.net/docs/setup/getlogs/syslog-ng/
> 
> says
> "For syslog-ng 3.x, use these lines for the configuration file:
> [...]
> template("$DATE $FULLHOST $MSGHDR$MESSAGE\n")
> [...]
> "
> 
> But proftpd login failures only get matched when I use
> template("$DATE $FULLHOST $MESSAGE\n")
> 
> as it is said for syslog-ng 2.x
> 
> Versions:
> sshguard 1.4.4
> syslog-ng 3.0.4
> proftpd 1.3.2b
> 
> ------------------------------------------------------------------------------
> 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] sshguard and syslog-ng on gentoo

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

uhm. Let's nail this down:

Please extract the exact log snippet (= all and only the lines
resulting from the single action) for each of the following cases,
and send in the result
- connect with a non-existing user (ssh non...@ho...)
- connect with a non-allowed user (eg, one in DenyUsers or not in AllowUsers)
- connect with a valid and allowed user, failing the password once
- connect with a valid and allowed user, failing the password all three times

What's your gentoo & OpenSSH version?
Please do not obfuscate anything other than IP addresses. Feel free to send in
privately.


On Jan 18, 2010, at 22:06 , Andreas Schuerch wrote:

> Hi again! :-)
> 
> I've found out, that it works when a user isn't existent on the system...
> But it doesn't catch for example a root (or other known user) bruteforce!
> 
> My guess is that its because i don't get a third log-line (the  
> explanation why the auth failed actually) when it was just the wrong  
> password...
> But to be honest, i don't know how that behavior could be changed!?!?
> 
> 
> This example gets blocked:
> Jan 18 22:31:12 sdb sshd[29953]: pam_unix(sshd:auth): authentication  
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3
> Jan 18 22:31:14 sdb sshd[29949]: error: PAM: Authentication failure  
> for illegal user bla from 192.168.0.3
> Jan 18 22:31:14 sdb sshd[29949]: Failed keyboard-interactive/pam for  
> invalid user bla from 192.168.0.3 port 40559 ssh2
> 
> This doesn't:
> Jan 18 22:32:26 sdb sshd[29958]: pam_unix(sshd:auth): authentication  
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.196   
> user=cron
> Jan 18 22:32:28 sdb sshd[29956]: error: PAM: Authentication failure  
> for cron from 192.168.0.196
> 
> Any advice would be appreciated!
> 
> Thanks once more.
> 
> Andreas
> 
> 
> Zitat von Andreas Schuerch <ma...@na...>:
> 
>> 1.0 ist the one marked as stable for me right now... :-/
>> 
>> This is what i get in the auth-log, apparently it looks quite like  
>> your example, and i tried from different hosts so they won't get  
>> suppressed as duplicate...
>> But still the same debug output!
>> 
>> Jan 13 21:56:57 sdb sshd[16629]: Accepted keyboard-interactive/pam  
>> for root from 192.168.0.196 port 35271 ssh2
>> Jan 13 21:56:57 sdb sshd[16629]: pam_unix(sshd:session): session  
>> opened for user root by (uid=0)
>> Jan 13 23:12:20 sdb sshd[31245]: pam_unix(sshd:auth): authentication  
>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3   
>> user=root
>> Jan 13 23:12:22 sdb sshd[31225]: error: PAM: Authentication failure  
>> for root from 192.168.0.3
>> Jan 13 23:12:28 sdb sshd[31624]: pam_unix(sshd:auth): authentication  
>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3   
>> user=root
>> Jan 13 23:12:30 sdb sshd[31225]: error: PAM: Authentication failure  
>> for root from 192.168.0.3
>> Jan 13 23:12:55 sdb sshd[3565]: pam_unix(sshd:auth): authentication  
>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.1   
>> user=root
>> Jan 13 23:12:57 sdb sshd[3553]: error: PAM: Authentication failure  
>> for root from 192.168.0.1
>> Jan 13 23:12:58 sdb sshd[3948]: pam_unix(sshd:auth): authentication  
>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.1   
>> user=root
>> Jan 13 23:13:00 sdb sshd[3553]: error: PAM: Authentication failure  
>> for root from 192.168.0.1
>> 
>> Oh, it doesn't crash via syslogger... I was just a bit confused from  
>> all those debug-messages! ;-)
>> 
>> Thanks so far!
>> 
>> Andreas
>> 
>> 
>> Zitat von Mij <mi...@ss...>:
>> 
>>> Hi Andreas,
>>> 
>>> 1.0 is older than me, so old that it's even antecedent to the  
>>> current repository :)
>>> 
>>> My best record is that the log message you are trying was removed as
>>> redundant. I.e., when the authentication failure occurs, there is another
>>> message generated that goes detected.
>>> 
>>> Looking through the attack submission database, I find this example:
>>> Jan 28 18:36:57 hostname sshd[11616]: pam_unix(sshd:auth):  
>>> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=  
>>> rhost=mail.host.cn
>>> Jan 28 18:36:58 hostname sshd[11616]: Failed password for invalid  
>>> user username from 1.2.3.4 port 43065 ssh2
>>> 
>>> Intuitively, the first message is generated by the PAM module performing the
>>> concrete auth lookup, and the second is generated by sshd itself when pam
>>> returns the failure to its caller.
>>> Of course, feel free to bitch back here if your logs say anything different.
>>> 
>>> I assume that by "crash" you mean that the pattern is not recognized. The
>>> output you paste is totally standard when a message is not recognized.
>>> 
>>> 
>>> On Jan 13, 2010, at 13:37 , Andreas Schuerch wrote:
>>> 
>>>> Hi,
>>>> 
>>>> i get an error with sshguard and syslog-ng on gentoo.
>>>> The version 1.0 works without problems, but version 1.4 and 1.5beta2
>>>> just seems to crash when invoked directly from the syslogger!
>>>> If i start them via "tail -n0 -F /var/log/auth.log | tee -a
>>>> /dev/stderr | env SSHGUARD_DEBUG="" /usr/sbin/sshguard" i get the
>>>> following output:
>>>> 
>>>> Run command "iptables -L": exited 0.
>>>> Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan.
>>>> Jan 13 14:10:22 sdb sshd[21506]: pam_unix(sshd:auth): authentication
>>>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.1
>>>> user=root
>>>> Starting parse
>>>> Entering state 0
>>>> Reading a token: --accepting rule at line 102 ("Jan 13 14:10:22 sdb
>>>> sshd[21506]:")
>>>> Next token is token SYSLOG_BANNER_PID ()
>>>> Shifting token SYSLOG_BANNER_PID ()
>>>> Entering state 1
>>>> Reading a token: --accepting rule at line 186 (" ")
>>>> --accepting rule at line 185 ("pam_unix")
>>>> Next token is token WORD ()
>>>> Error: popping token SYSLOG_BANNER_PID ()
>>>> Stack now 0
>>>> Cleanup: discarding lookahead token WORD ()
>>>> Stack now 0
>>>> Jan 13 14:10:24 sdb sshd[21504]: error: PAM: Authentication failure
>>>> for root from 192.168.0.1
>>>> Starting parse
>>>> Entering state 0
>>>> Reading a token: --accepting rule at line 102 ("Jan 13 14:10:24 sdb
>>>> sshd[21504]:")
>>>> Next token is token SYSLOG_BANNER_PID ()
>>>> Shifting token SYSLOG_BANNER_PID ()
>>>> Entering state 1
>>>> Reading a token: --accepting rule at line 186 (" ")
>>>> --accepting rule at line 185 ("error")
>>>> Next token is token WORD ()
>>>> Error: popping token SYSLOG_BANNER_PID ()
>>>> Stack now 0
>>>> Cleanup: discarding lookahead token WORD ()
>>>> Stack now 0
>>>> 
>>>> 
>>>> What could be wrong here!?
>>>> 
>>>> Thanks in advance,
>>>> Andreas
>>>> --------------------------
>>>> --> NativeMail System <---
>>>> --------------------------
>>>> 
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Verizon Developer Community
>>>> Take advantage of Verizon's best-in-class app development support
>>>> A streamlined, 14 day to market process makes app distribution  
>>>> fast and easy
>>>> Join now and get one step closer to millions of Verizon customers
>>>> http://p.sf.net/sfu/verizon-dev2dev
>>>> _______________________________________________
>>>> Sshguard-users mailing list
>>>> Ssh...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Verizon Developer Community
>>> Take advantage of Verizon's best-in-class app development support
>>> A streamlined, 14 day to market process makes app distribution fast and easy
>>> Join now and get one step closer to millions of Verizon customers
>>> http://p.sf.net/sfu/verizon-dev2dev
>>> _______________________________________________
>>> Sshguard-users mailing list
>>> Ssh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>> 
>> 
>> 
>> --------------------------
>> --> NativeMail System <---
>> --------------------------
>> 
>> 
> 
> 
> --------------------------
> --> NativeMail System <---
> --------------------------
> 
> 
> 
> ------------------------------------------------------------------------------
> 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

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

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

Hello,

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

says
"For syslog-ng 3.x, use these lines for the configuration file:
[...]
template("$DATE $FULLHOST $MSGHDR$MESSAGE\n")
[...]
"

But proftpd login failures only get matched when I use
template("$DATE $FULLHOST $MESSAGE\n")

as it is said for syslog-ng 2.x

Versions:
sshguard 1.4.4
syslog-ng 3.0.4
proftpd 1.3.2b

Re: [Sshguard-users] sshguard and syslog-ng on gentoo

[Andreas S. <and...@na...>]

Hi again! :-)

I've found out, that it works when a user isn't existent on the system...
But it doesn't catch for example a root (or other known user) bruteforce!

My guess is that its because i don't get a third log-line (the  
explanation why the auth failed actually) when it was just the wrong  
password...
But to be honest, i don't know how that behavior could be changed!?!?


This example gets blocked:
Jan 18 22:31:12 sdb sshd[29953]: pam_unix(sshd:auth): authentication  
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3
Jan 18 22:31:14 sdb sshd[29949]: error: PAM: Authentication failure  
for illegal user bla from 192.168.0.3
Jan 18 22:31:14 sdb sshd[29949]: Failed keyboard-interactive/pam for  
invalid user bla from 192.168.0.3 port 40559 ssh2

This doesn't:
Jan 18 22:32:26 sdb sshd[29958]: pam_unix(sshd:auth): authentication  
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.196   
user=cron
Jan 18 22:32:28 sdb sshd[29956]: error: PAM: Authentication failure  
for cron from 192.168.0.196

Any advice would be appreciated!

Thanks once more.

Andreas


Zitat von Andreas Schuerch <ma...@na...>:

> 1.0 ist the one marked as stable for me right now... :-/
>
> This is what i get in the auth-log, apparently it looks quite like  
> your example, and i tried from different hosts so they won't get  
> suppressed as duplicate...
> But still the same debug output!
>
> Jan 13 21:56:57 sdb sshd[16629]: Accepted keyboard-interactive/pam  
> for root from 192.168.0.196 port 35271 ssh2
> Jan 13 21:56:57 sdb sshd[16629]: pam_unix(sshd:session): session  
> opened for user root by (uid=0)
> Jan 13 23:12:20 sdb sshd[31245]: pam_unix(sshd:auth): authentication  
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3   
> user=root
> Jan 13 23:12:22 sdb sshd[31225]: error: PAM: Authentication failure  
> for root from 192.168.0.3
> Jan 13 23:12:28 sdb sshd[31624]: pam_unix(sshd:auth): authentication  
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3   
> user=root
> Jan 13 23:12:30 sdb sshd[31225]: error: PAM: Authentication failure  
> for root from 192.168.0.3
> Jan 13 23:12:55 sdb sshd[3565]: pam_unix(sshd:auth): authentication  
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.1   
> user=root
> Jan 13 23:12:57 sdb sshd[3553]: error: PAM: Authentication failure  
> for root from 192.168.0.1
> Jan 13 23:12:58 sdb sshd[3948]: pam_unix(sshd:auth): authentication  
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.1   
> user=root
> Jan 13 23:13:00 sdb sshd[3553]: error: PAM: Authentication failure  
> for root from 192.168.0.1
>
> Oh, it doesn't crash via syslogger... I was just a bit confused from  
> all those debug-messages! ;-)
>
> Thanks so far!
>
> Andreas
>
>
> Zitat von Mij <mi...@ss...>:
>
>> Hi Andreas,
>>
>> 1.0 is older than me, so old that it's even antecedent to the  
>> current repository :)
>>
>> My best record is that the log message you are trying was removed as
>> redundant. I.e., when the authentication failure occurs, there is another
>> message generated that goes detected.
>>
>> Looking through the attack submission database, I find this example:
>> Jan 28 18:36:57 hostname sshd[11616]: pam_unix(sshd:auth):  
>> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=  
>> rhost=mail.host.cn
>> Jan 28 18:36:58 hostname sshd[11616]: Failed password for invalid  
>> user username from 1.2.3.4 port 43065 ssh2
>>
>> Intuitively, the first message is generated by the PAM module performing the
>> concrete auth lookup, and the second is generated by sshd itself when pam
>> returns the failure to its caller.
>> Of course, feel free to bitch back here if your logs say anything different.
>>
>> I assume that by "crash" you mean that the pattern is not recognized. The
>> output you paste is totally standard when a message is not recognized.
>>
>>
>> On Jan 13, 2010, at 13:37 , Andreas Schuerch wrote:
>>
>>> Hi,
>>>
>>> i get an error with sshguard and syslog-ng on gentoo.
>>> The version 1.0 works without problems, but version 1.4 and 1.5beta2
>>> just seems to crash when invoked directly from the syslogger!
>>> If i start them via "tail -n0 -F /var/log/auth.log | tee -a
>>> /dev/stderr | env SSHGUARD_DEBUG="" /usr/sbin/sshguard" i get the
>>> following output:
>>>
>>> Run command "iptables -L": exited 0.
>>> Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan.
>>> Jan 13 14:10:22 sdb sshd[21506]: pam_unix(sshd:auth): authentication
>>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.1
>>> user=root
>>> Starting parse
>>> Entering state 0
>>> Reading a token: --accepting rule at line 102 ("Jan 13 14:10:22 sdb
>>> sshd[21506]:")
>>> Next token is token SYSLOG_BANNER_PID ()
>>> Shifting token SYSLOG_BANNER_PID ()
>>> Entering state 1
>>> Reading a token: --accepting rule at line 186 (" ")
>>> --accepting rule at line 185 ("pam_unix")
>>> Next token is token WORD ()
>>> Error: popping token SYSLOG_BANNER_PID ()
>>> Stack now 0
>>> Cleanup: discarding lookahead token WORD ()
>>> Stack now 0
>>> Jan 13 14:10:24 sdb sshd[21504]: error: PAM: Authentication failure
>>> for root from 192.168.0.1
>>> Starting parse
>>> Entering state 0
>>> Reading a token: --accepting rule at line 102 ("Jan 13 14:10:24 sdb
>>> sshd[21504]:")
>>> Next token is token SYSLOG_BANNER_PID ()
>>> Shifting token SYSLOG_BANNER_PID ()
>>> Entering state 1
>>> Reading a token: --accepting rule at line 186 (" ")
>>> --accepting rule at line 185 ("error")
>>> Next token is token WORD ()
>>> Error: popping token SYSLOG_BANNER_PID ()
>>> Stack now 0
>>> Cleanup: discarding lookahead token WORD ()
>>> Stack now 0
>>>
>>>
>>> What could be wrong here!?
>>>
>>> Thanks in advance,
>>> Andreas
>>> --------------------------
>>> --> NativeMail System <---
>>> --------------------------
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Verizon Developer Community
>>> Take advantage of Verizon's best-in-class app development support
>>> A streamlined, 14 day to market process makes app distribution  
>>> fast and easy
>>> Join now and get one step closer to millions of Verizon customers
>>> http://p.sf.net/sfu/verizon-dev2dev
>>> _______________________________________________
>>> Sshguard-users mailing list
>>> Ssh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Sshguard-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>
>
>
> --------------------------
> --> NativeMail System <---
> --------------------------
>
>


--------------------------
--> NativeMail System <---
--------------------------

Re: [Sshguard-users] sshguard and syslog-ng on gentoo

[Andreas S. <and...@na...>]

1.0 ist the one marked as stable for me right now... :-/

This is what i get in the auth-log, apparently it looks quite like  
your example, and i tried from different hosts so they won't get  
suppressed as duplicate...
But still the same debug output!

Jan 13 21:56:57 sdb sshd[16629]: Accepted keyboard-interactive/pam for  
root from 192.168.0.196 port 35271 ssh2
Jan 13 21:56:57 sdb sshd[16629]: pam_unix(sshd:session): session  
opened for user root by (uid=0)
Jan 13 23:12:20 sdb sshd[31245]: pam_unix(sshd:auth): authentication  
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3   
user=root
Jan 13 23:12:22 sdb sshd[31225]: error: PAM: Authentication failure  
for root from 192.168.0.3
Jan 13 23:12:28 sdb sshd[31624]: pam_unix(sshd:auth): authentication  
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3   
user=root
Jan 13 23:12:30 sdb sshd[31225]: error: PAM: Authentication failure  
for root from 192.168.0.3
Jan 13 23:12:55 sdb sshd[3565]: pam_unix(sshd:auth): authentication  
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.1   
user=root
Jan 13 23:12:57 sdb sshd[3553]: error: PAM: Authentication failure for  
root from 192.168.0.1
Jan 13 23:12:58 sdb sshd[3948]: pam_unix(sshd:auth): authentication  
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.1   
user=root
Jan 13 23:13:00 sdb sshd[3553]: error: PAM: Authentication failure for  
root from 192.168.0.1

Oh, it doesn't crash via syslogger... I was just a bit confused from  
all those debug-messages! ;-)

Thanks so far!

Andreas


Zitat von Mij <mi...@ss...>:

> Hi Andreas,
>
> 1.0 is older than me, so old that it's even antecedent to the  
> current repository :)
>
> My best record is that the log message you are trying was removed as
> redundant. I.e., when the authentication failure occurs, there is another
> message generated that goes detected.
>
> Looking through the attack submission database, I find this example:
> Jan 28 18:36:57 hostname sshd[11616]: pam_unix(sshd:auth):  
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=  
> rhost=mail.host.cn
> Jan 28 18:36:58 hostname sshd[11616]: Failed password for invalid  
> user username from 1.2.3.4 port 43065 ssh2
>
> Intuitively, the first message is generated by the PAM module performing the
> concrete auth lookup, and the second is generated by sshd itself when pam
> returns the failure to its caller.
> Of course, feel free to bitch back here if your logs say anything different.
>
> I assume that by "crash" you mean that the pattern is not recognized. The
> output you paste is totally standard when a message is not recognized.
>
>
> On Jan 13, 2010, at 13:37 , Andreas Schuerch wrote:
>
>> Hi,
>>
>> i get an error with sshguard and syslog-ng on gentoo.
>> The version 1.0 works without problems, but version 1.4 and 1.5beta2
>> just seems to crash when invoked directly from the syslogger!
>> If i start them via "tail -n0 -F /var/log/auth.log | tee -a
>> /dev/stderr | env SSHGUARD_DEBUG="" /usr/sbin/sshguard" i get the
>> following output:
>>
>> Run command "iptables -L": exited 0.
>> Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan.
>> Jan 13 14:10:22 sdb sshd[21506]: pam_unix(sshd:auth): authentication
>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.1
>> user=root
>> Starting parse
>> Entering state 0
>> Reading a token: --accepting rule at line 102 ("Jan 13 14:10:22 sdb
>> sshd[21506]:")
>> Next token is token SYSLOG_BANNER_PID ()
>> Shifting token SYSLOG_BANNER_PID ()
>> Entering state 1
>> Reading a token: --accepting rule at line 186 (" ")
>> --accepting rule at line 185 ("pam_unix")
>> Next token is token WORD ()
>> Error: popping token SYSLOG_BANNER_PID ()
>> Stack now 0
>> Cleanup: discarding lookahead token WORD ()
>> Stack now 0
>> Jan 13 14:10:24 sdb sshd[21504]: error: PAM: Authentication failure
>> for root from 192.168.0.1
>> Starting parse
>> Entering state 0
>> Reading a token: --accepting rule at line 102 ("Jan 13 14:10:24 sdb
>> sshd[21504]:")
>> Next token is token SYSLOG_BANNER_PID ()
>> Shifting token SYSLOG_BANNER_PID ()
>> Entering state 1
>> Reading a token: --accepting rule at line 186 (" ")
>> --accepting rule at line 185 ("error")
>> Next token is token WORD ()
>> Error: popping token SYSLOG_BANNER_PID ()
>> Stack now 0
>> Cleanup: discarding lookahead token WORD ()
>> Stack now 0
>>
>>
>> What could be wrong here!?
>>
>> Thanks in advance,
>> Andreas
>> --------------------------
>> --> NativeMail System <---
>> --------------------------
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Sshguard-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>


--------------------------
--> NativeMail System <---
--------------------------

Re: [Sshguard-users] sshguard and syslog-ng on gentoo

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

Hi Andreas,

1.0 is older than me, so old that it's even antecedent to the current repository :)

My best record is that the log message you are trying was removed as
redundant. I.e., when the authentication failure occurs, there is another
message generated that goes detected.

Looking through the attack submission database, I find this example:
Jan 28 18:36:57 hostname sshd[11616]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.host.cn
Jan 28 18:36:58 hostname sshd[11616]: Failed password for invalid user username from 1.2.3.4 port 43065 ssh2

Intuitively, the first message is generated by the PAM module performing the
concrete auth lookup, and the second is generated by sshd itself when pam
returns the failure to its caller.
Of course, feel free to bitch back here if your logs say anything different.

I assume that by "crash" you mean that the pattern is not recognized. The
output you paste is totally standard when a message is not recognized.


On Jan 13, 2010, at 13:37 , Andreas Schuerch wrote:

> Hi,
> 
> i get an error with sshguard and syslog-ng on gentoo.
> The version 1.0 works without problems, but version 1.4 and 1.5beta2  
> just seems to crash when invoked directly from the syslogger!
> If i start them via "tail -n0 -F /var/log/auth.log | tee -a  
> /dev/stderr | env SSHGUARD_DEBUG="" /usr/sbin/sshguard" i get the  
> following output:
> 
> Run command "iptables -L": exited 0.
> Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan.
> Jan 13 14:10:22 sdb sshd[21506]: pam_unix(sshd:auth): authentication  
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.1   
> user=root
> Starting parse
> Entering state 0
> Reading a token: --accepting rule at line 102 ("Jan 13 14:10:22 sdb  
> sshd[21506]:")
> Next token is token SYSLOG_BANNER_PID ()
> Shifting token SYSLOG_BANNER_PID ()
> Entering state 1
> Reading a token: --accepting rule at line 186 (" ")
> --accepting rule at line 185 ("pam_unix")
> Next token is token WORD ()
> Error: popping token SYSLOG_BANNER_PID ()
> Stack now 0
> Cleanup: discarding lookahead token WORD ()
> Stack now 0
> Jan 13 14:10:24 sdb sshd[21504]: error: PAM: Authentication failure  
> for root from 192.168.0.1
> Starting parse
> Entering state 0
> Reading a token: --accepting rule at line 102 ("Jan 13 14:10:24 sdb  
> sshd[21504]:")
> Next token is token SYSLOG_BANNER_PID ()
> Shifting token SYSLOG_BANNER_PID ()
> Entering state 1
> Reading a token: --accepting rule at line 186 (" ")
> --accepting rule at line 185 ("error")
> Next token is token WORD ()
> Error: popping token SYSLOG_BANNER_PID ()
> Stack now 0
> Cleanup: discarding lookahead token WORD ()
> Stack now 0
> 
> 
> What could be wrong here!?
> 
> Thanks in advance,
> Andreas
> --------------------------
> --> NativeMail System <---
> --------------------------
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users