Re: warning: TLS library problem - messages in log

2018-04-28 Thread Dominic Raferd
On 27 April 2018 at 17:17, Viktor Dukhovni  wrote:
>
>
>> On Apr 27, 2018, at 2:22 AM, Dominic Raferd  wrote:
>>
>> $ grep -a "warning: TLS library problem" /var/log/mail.log.1
>> /var/log/mail.log|grep -o "error:.*"|sort|uniq -c|sort -nr
>> 12 error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
>> number:s3_pkt.c:362:
>> 11 error:1408A10B:SSL routines:ssl3_get_client_hello:wrong
>> version number:s3_srvr.c:960:
>> 10 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
>> protocol:s23_srvr.c:640:
>>  2 error:1408A0E3:SSL routines:ssl3_get_client_hello:parse
>> tlsext:s3_srvr.c:1239:
>>
>> Should I be concerned about these messages?
>
> To know the answer you need to consider which clients are running into
> this, and whether:
>
>   * These clients are just network scanners and never send email
>   * Are spammers and would send email if they could, but you're happy for 
> them to fail
>   * Are legitimate email senders, and fall back to cleartext.  In which case
> you're perhaps rather they use TLS, and should investigate further.
>   * Are legitimate email senders, and don't fall back to cleartext (you don't
> see a message in the clear from them shortly after each TLS failure).
> In which case you're losing some email and really should investigate.
>
> The errors broadly suggest use of unsupported TLS protocol versions or
> unsupported TLS features, or simply malformed handshake messages.  That
> would be expected from scanners, but can also happen if you're configured
> too strictly, for example, to exclude everything below TLSv1.2.
>
> So if you want to be sure, you'll need to do some further log analysis,
> and perhaps collect some PCAP files with full packet captures for any
> clients or netblocks that exhibit the symptoms repeatedly.

Thanks Viktor for that very clear explanation. I will start using
(something like) this for monitoring my logs:

sed -n '/SSL_accept error/{N;/warning: TLS library problem/{s/.* from
\([^:]*\).*/\1/;/unknown\[/d;/shodan\.io\[/d;p}}' /var/log/mail.log

So far I have one genuine sender that is failing TLS, but upon
checking I see that it falls back to cleartext.


Re: rsyslogd and postfix

2018-04-28 Thread Mike
On 4/26/2018 3:08 PM, @lbutlr wrote:
> On 2018-04-26 (06:46 MDT), Mike  wrote:
>>
>> I have a similar log strategy but I let postfix do it for me.
>>
>> For example, my postscreen entry in master.cf is:
>>
>>
>> smtp  inet  n   -   n   -   1   postscreen
>>  -o syslog_facility=local2
>>
>>
>>
>> That sends the postscreen logging to the local2 log facility.
> 
> Sure that's a perfectly workable solution, but I am able to log the specific 
> information that I nearly never need into a specific log file without having 
> to keep track of which of the nearly identically named local1 local2 etc 
> facilities is setup for what. It's also easy for me to add other data that I 
> don't need in the logs (like I have one automated user who logins in ever 3 
> minutes. The only thing I ever need to know is if that login fails for some 
> reason or all the warnings about hosts not resolving (but not any other 
> warnings)). there's a lot more flexibility in configuring rsyslog than there 
> is in simply using local1-local6.
> 
> But, whatever works for you is fine. I was just sharing what worked for *me* 
> in case it was of use to someone else.
> 


I wanted the solution to be a part of this thread.

I fully realize that different operators have differing requirements.

For my needs, the solution I posted satisfies my requirement quite
nicely.  You have more extensive requirements that requires more
extensive solutions.  :)




Re: warning: TLS library problem - messages in log

2018-04-28 Thread Viktor Dukhovni


> On Apr 28, 2018, at 3:40 AM, Dominic Raferd  wrote:
> 
> So far I have one genuine sender that is failing TLS, but upon
> checking I see that it falls back to cleartext.

It'd be interesting to know why that particular sender is having
trouble.  Can you provide more detail?

Some senders have SMTP client implementations that refuse to complete
a STARTTLS handshake when they can't verify the server's certificate
chain, but are then willing to send in the clear.  The logic of
downgrading from unauthenticated encryption to unauthenticated cleartext
rather escapes me. :-)

  http://postfix.1071664.n5.nabble.com/Another-yahoo-problem-tp89756p89769.html


-- 
Viktor.



Re: rsyslogd and postfix

2018-04-28 Thread Alex
Hi,

On Thu, Apr 26, 2018 at 8:46 AM, Mike  wrote:
> On 4/25/2018 2:08 PM, @lbutlr wrote:
>> This might be of use to others out there. I decided that monitoring mail.log 
>> was too much of a pain with all the postscreen and dnsblog 'noise' from 
>> obscuring the information that I wanted to see, so I split those log events 
>> into their own log file using rsyslogd with the following lines in 
>> rsyslogd.conf (before the lines that log mail.log)
>>
>> if $syslogtag contains 'postscreen' then /var/log/postscreen.log
>> if $syslogtag contains 'postscreen' then ~
>> if $syslogtag contains 'dnsblog' then /var/log/postscreen.log
>> if $syslogtag contains 'dnsblog' then ~
>>
>> This lets me keep mail.log for quite a while and rotate off postscreen.log 
>> very quickly since it is not something I need to check very often at all.
>>
>> I've been doing this for a week or two now and found it useful enough I 
>> thought it worth passing along.
>
> I have a similar log strategy but I let postfix do it for me.
>
> For example, my postscreen entry in master.cf is:
>
> smtp  inet  n   -   n   -   1   postscreen
> -o syslog_facility=local2

I'm also using rsyslog on fedora but have considering storing my logs
in mariadb, along with those from amavisd-new and spamassassin. I've
configured amavisd-new to use JSON logging.

Is it possible to log directly to mariadb from postfix and skip
rsyslog entirely? It appears there are several third-party tools, but
there doesn't seem to be a native way...

Is it possible to configure postfix to log using JSON?

Is there an updated version of collate.pl? There's no version number
within the file, but the version I have produces "Use of uninitialized
value in concatenation" on line 112 on my system.

   111  $transaction{$newid} =
   112  $_ . $transaction{$newid};
   113  $seqno{$newid} = ++$i if (! exists
$seqno{$newid});
   114  }