Executive Summary: PEBKAC.
Details:
Thanks to Phillip for his informative correspondence. Following up on his
suggestions, I tried:
strace -vff -p $(pgrep rsyslogd) -s100 2>&1 | egrep "(recvmsg|write)"
looking at the other end of the send() to rsyslogd.
That gives output like:
[pid 766] recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"<37>May 2 16:05:40
ipop3d[18290]: Login failed user=kjohnson auth=kjohnson host=[10.10.10.32]",
8096}], msg_controllen=44, {cmsg_len=20, cmsg_level=SOL_SOCKET,
cmsg_type=0x1d /* SCM_??? */, ...}, msg_flags=0}, MSG_DONTWAIT) = 94
recvmsg
[pid 768] write(12, "May 2 16:05:40 localhost ipop3d[18290]: Login failed
user=kjohnson auth=kjohnson host=[10.10.10.32]"..., 101) = 101 write
lsof -p $(pgrep rsyslogd) gives (in part)
rsyslogd 755 root 1w CHR 1,3 0t0 1039 /dev/null
rsyslogd 755 root 2w CHR 1,3 0t0 1039 /dev/null
rsyslogd 755 root 3u unix 0xf664ec00 0t0 8631
/run/systemd/journal/syslog
rsyslogd 755 root 4r REG 0,3 0 4026532003 /proc/kmsg
rsyslogd 755 root 5w REG 8,7 1409383 704739 /var/log/syslog
rsyslogd 755 root 6w REG 8,7 1827024 705183
/var/log/daemon.log
rsyslogd 755 root 7w REG 8,7 13221 705198
/var/log/user.log
rsyslogd 755 root 8w REG 8,7 15267 705200
/var/log/messages
rsyslogd 755 root 9w REG 8,7 4464467 705182
/var/log/mail.log
rsyslogd 755 root 10w REG 8,7 3673941 705064
/var/log/mail.info
rsyslogd 755 root 11u FIFO 0,5 0t0 8687 /dev/xconsole
rsyslogd 755 root 12w REG 8,7 794966 705195
/var/log/auth.log
rsyslogd 755 root 13w REG 8,7 3338 705199 /var/log/debug
rsyslogd 755 root 14w REG 8,7 1138 705066
/var/log/mail.warn
rsyslogd 755 root 15w REG 8,7 1138 705158
/var/log/mail.err
Which correspond to the FDs of 3 and 12 shown in strace.
So I looked again and the failure message for the event above was, in fact,
present in the auth.log file.
I think that for whatever reason, hostile attempts against ipop3d and imapd
have become less constant, and on the particular day I looked, there were
none in the current auth.log file. Which seemed to explain why I did not
see those events in the daily summary. It turns out that those events are
not in the daily summary for a different reason, which I am now exploring.
Regards,
Ken
-----Original Message-----
From: Imap-uw [mailto:[email protected]] On Behalf
Of [email protected]
Sent: Friday, April 27, 2018 4:15 PM
To: [email protected]
Subject: [Imap-uw] [Fwd: RE: Failed logins in Debian 8 (old-stable)]
---------------------------- Original Message ----------------------------
Subject: RE: [Imap-uw] Failed logins in Debian 8 (old-stable)
From: [email protected]
Date: Fri, April 27, 2018 4:13 pm
To: [email protected]
--------------------------------------------------------------------------
Just realized that link doesn't work for me , below is what i was attempting
to say....those <37> and <22> entries are the facility and severity levels
being sent to syslog, would be interesting to see how yours compares.
[root@www ~]# strace -vff -p $(pgrep inetd) -s100 -e trace=send 2>&1 | grep
Login [pid 25619] send(2, "<37>Apr 27 16:11:12 imapd[25619]: Login failed
user=badloginname auth=badloginname host=localhost [1"..., 109,
MSG_NOSIGNAL) = 109
^C
[root@www ~]# strace -vff -p $(pgrep inetd) -s100 -e trace=send 2>&1 | grep
Login [pid 25625] send(2, "<22>Apr 27 16:11:27 imapd[25625]: Login
user=phillip host=localhost [127.0.0.1]", 79, MSG_NOSIGNAL) = 79
> Thanks!
>
> Ken
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Friday, April 27, 2018 3:33 PM
> To: [email protected]
> Subject: Re: [Imap-uw] Failed logins in Debian 8 (old-stable)
>
> Ken, i did some testing on my own and the below link shows my
> testing...You can see the facility & severity level being sent from
> inet
> -> syslog of a failed & successfull login. (37) looks to be sent when
> -> a
> failed login happens...(22) on a successfull one.
>
> http://deanengineering.us/paste/?f99faa4d9b9d27e4#ZkTMINq4V55AOC44vlJm
> L3Zyt9
> /CUFUvuhP1MHUSHWE=
>
> Hopefully this helps you , you can sniff the traffic being sent over
> the socket using strace
>
>> Mats,
>>
>> Thanks for the helpful reply.
>>
>> On inspection, rsyslog.conf and the contents of rsyslog.d pre-date
>> Debian 7.
>>
>>
>>
>> The messages with respect to successful ipop3d and imapd usage in
>> mail.log are still present. Only the failed login messages, formerly
>> in /var/log/auth.log, have gone missing. Anyone know of a way to spy
>> on calls to syslog(3)?
>>
>> Thanks all,
>>
>> Ken
>>
>>
>>
>> -----Original Message-----
>> From: Mats Dufberg [mailto:[email protected]]
>> Sent: Monday, April 23, 2018 4:54 PM
>> To: Ken Johnson
>> Cc: [email protected]
>> Subject: Re: [Imap-uw] Failed logins in Debian 8 (old-stable)
>>
>> On Apr 23, 2018, 12:30 (-0500) Ken Johnson <[email protected]> wrote:
>>
>>> Running uw-imap under Debian 8. Under Debian 7, failed logins would
>>> show up in /var/log/auth.log.
>>>
>>> That no longer happens in Debian 8.
>>
>> Have you checked configuration of syslog, e.g. syslog.conf? imapd
>> sends its log messages to syslog, and syslogd will save them into
>> files. Enable logging of all facilities into different log files on
>> INFO level to see where they go.
>>
>>
>> Mats
>>
>> -----------------------------------------------------------------
>> | Mats Dufberg [email protected] |
>> | Spånga kyrkväg 618 +46-8-384859 |
>> | SE-16362 Spånga, Sweden +46-70-258 2588 |
>> -----------------------------------------------------------------
>>
>> _______________________________________________
>> Imap-uw mailing list
>> [email protected]
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-uw
>>
>
>
>
_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-uw
_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-uw
