On Fri, Feb 27, 2015 at 12:05 PM, Alessandro Vesely <ves...@tana.it> wrote:
> On Fri 27/Feb/2015 10:28:12 +0100 Jan Ingvoldstad wrote:
> >
> > I hoped I could, by using e.g. less to view the debug log (debug level 1)
>
> The debug log is useful for debugging, but lines get garbled if there are
> concurrent logins, and it's not quite machine-readable.
>
That's what I'm getting at.
> > [DATE] [host] imapd: LOGIN FAILED, method=PLAIN, ip=[::ffff:192.168.0.1]
> >
> > That is, I hoped that the authdaemond entries would be buffered and put
> in the
> > log so that I could see which IP address tried to login as which user,
> but failed.
>
> The last log line (quoted) is the regular --not debug-- log. At mine, it
> is
> piped through a parser which finds repeated attempts from the same IP and
> bans
> it accordingly.
That's useful, but not what I'm really looking for here.
> (Doing so is bound to require intervention when users change
> passwords or configure new clients.) Besides authentication failures, the
> parser looks for 513 Relaying denied, 517-Domain does not exist, 502 ESMTP
> command, and Maximum connection limit, so knowing the IP for authentication
> failures only wouldn't be enough to eliminate the parser.
>
These errors are not relevant to IMAP, though it's interesting to note that
the same log issues may be present in the MTA as well.
>
> For distributed attacks, I log the attempted user/pw pair using authpipe as
> shown below. Not very useful, but may help getting an insight on what
> goes on.
>
> I get this from yesterday's log:
>
> Feb 26 06:17:48 north pipeauth[31330]: user: info pw: info not found
> Feb 26 08:06:57 north pipeauth[31070]: user: vesely pw: vesely not found
> Feb 26 08:07:00 north pipeauth[31341]: user: vesely pw: vesely123 not found
>
> No IP is passed by authdaemond, as you say, but what would it be useful
> for?
>
> The IP is known by authdaemond's clients who authenticate users. They
> don't
> pass an IP address to authdaemond in turn. It could be possible to gain
> that
> knowledge by examining /proc, as in netstat --program, but would it be
> worth?
>
>
Use case 1:
Hi, this is $customer,
could you please provide a log for which IP addresses have tried to logon
as $user?
Use case 2:
Dear $customer,
we have regretfully had to block your IMAP account $user due to too many
invalid login attempts. The login attempts came from the following IP
addresses:
$IP1
$IP2
...
IPn
Use case 3:
Dear $abusedept,
your IP address $IP has been involved in multiple login attempts to
numerous IMAP accounts, and we have therefore been forced to block access
from it.
As it is now, I don't see how I can provide logs back to a customer who
wants to check for unauthorized login attempts, nor can I tell a user which
IP addresses were involved, nor how I can say whether an IP address has
attempted to login to 1 or 1000 accounts.
--
Jan
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
