On 17/11/2014 07:23, Ron Leach wrote:> On 16/11/2014 07:24, Robert Schetterer wrote (re-ordered):
>> Am 16.11.2014 um 02:24 schrieb Reindl Harald:
>>
>>> * if you find a security issue in postfix running
>>> on 587 over TLS cry out loud
>
> I'm thinking beyond that; I want to get to the position that when
> there is an issue in the MTA, our systems are less exposed than they
> might otherwise be. It's not about the MTA.
>
>>>
>>> that's it and if you think that combination is not secure
enough pull
>>> the network cables
>>>
>
> That's pretty much what we have at the moment, but we need to be able
> to submit from offsite, and I'm keen to implement that together with
> our migration to 2.2. Of course offsite submission is easy, but in
> our experience that is also vulnerable.
>
>>> Am 16.11.2014 um 00:03 schrieb Ron Leach:
>>>> There has been mention
>>>> from time to time of a dovecot SMTP submission server. Last I
saw was
>>>> Timo suggesting this would be a 2.3 feature, but that there was
>>>> already
>>>> a 'basic' capability in 2.2 that, more or less, merely
provided a
>>>> secured/authorised SMTP submission. I would like to
>>>> *not* have our MTA capable of being exploited as a relay (it
isn't, at
>>>> the moment) whereas users are logging into our dovecot from
offsite
>>>> using imaps with passwords.
>>>> [snip most of background]
>>>>
>>>> So, is there some kind of SMTP submission service for a logged
in
>>>> dovecot user, and how would a client make use of that? Is it
possible
>>>> to setup 2.2.15 for this? And, crucially, would the
connections
>>>> between
>>>> the client (eg at a hotel in some unreliable location) be
encrypted
>>>> right from the start, not using STARTTLS, as is the case in
imaps?
>>>> And,
>>>> just to be really demanding, could we configure its use on a
>>>> non-standard port?
>>>
>>
>> i dont see your point...
>>
>
> I wondered whether the background might hinder an answer but it
> normally helps, I'm sorry it was unclear, and especially so since you
> took the time to read it.
>
> Let me list the approach we'd prefer:
>
> (i) MTA open on port 25 for inbound email.
>
> (ii) MTA not open on any other port, because (for example, our) MTAs
> are constantly faced on port 25 with password attacks, malformed
> packets, malformed messages that contain scripts, and malformed
> protocol sequences; all these show up in the logs. In the past, at
> least one of those succeeded. We have a saying: 'once bitten, twice
> shy'. So, now I would prefer that any MTA we use (that is capable of
> outbound messaging) be *not* capable of relaying from any inbound SMTP
> protocol. (Because inbound SMTP is the focus of so much attack.
> Though current versions of MTAs are conscientiously engineered to be
> as secure as is practical, they will be broken. They may even be
> broken through no action or omission of their own designers; you may
> have seen recent discussions on a cryptography list [1] where the
> optimising option in a popular tool chain resulted in some protection
> algorithm being rendered ineffective. But that's just one example of
> a long line of subsequently revealed security weaknesses, so
> architectures based on assumptions that the implementations are now
> perfect and that they will remain perfect even though the toolchains,
> the OSs, the crypto routines and the attacks evolve would be
> ill-founded. And attacks don't become weaker, they constantly
improve.)
>
> (iii) Users who are logged in to Dovecot (ie, authorised by Dovecot,
> so not authorised by any software which is subject of attack and which
> will be compromised from time to time) able to submit outbound
> messages through Dovecot on the internal network to an MTA which will
> only relay from the internal network.
>
> (iv) No use of STARTTLS; all client messaging to be secure at and from
> the point of protocol initiation. SSL=required, in terms of the
> Dovecot conf.
>
> This type of approach goes some way towards limiting the exposure from
> a compromised MTA (attacks will succeed, from time to time),
> irrespective of the cause of that compromise. (Let me be clear, I am
> sure any compromise will be unexpected and undeserved by the highly
> respected and careful and committed designers of the leading MTAs; the
> compromises that occur will be despite their efforts.) Simply, I'm
> trying to create a mail environment where remote submission of
> outbound mail is practical, whilst ensuring that any MTA compromise
> can be undamaging.
>
> >
> > submission server in dovecot is on its way ( my last info )
> >
>
> So I guess the basic SMTP submission feature is not in 2.2.
>
> Off topic for Dovecot list, but I might think instead about separate
> inbound and outbound MTAs to achieve containment of inbound MTA
> compromise.
>
> Robert (and Harald), thanks,
>
> Ron
>
> [1] Among very many threads, on GCC bug 30475, in April this year:
> http://www.metzdowd.com/pipermail/cryptography/2014-April/021074.html
Hi Ron,
Firstly these questions mostly relate to MTA configuration and are hence
probably on the wrong list now; however:
I second Reindl's views here.
The issues you describe as vulnerabilities all stem from bad configuration.
Run Postfix 2.11.x (production ready, hardened) or Postfix 2.12.x
(development, but run by the author... also hardened).
Ensure you're running postscreen within Postfix. Use of the deep
protocol tests will eject script kiddies like crazy. Basic postscreen
goes after zombie attacks and is still very effective on its own. Either
way the attackers won't even get close to an inbound SMTPd process.
As Reindl said switch off SASL on port 25 (hence in the SMTP
conversation following the ehlo line, the client isn't even offered AUTH
and hence the chance to login to try to relay).
In Postfix SASL isn't switched on by default - either on port 25 or 587.
To enable it edit the master.cf file uncommenting the section for
submission (587) with a few options passed in via -o:
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
As others have said moving the MSA - Mail Submission Agent - out of
Postfix into Dovecot or another IMAP server doesn't help. If anything
you're moving a service out of extremely well tested and battle-hardened
code into relatively new untested code. Which would you trust more?
Join the postfix list, if you aren't already a member, and submit more
questions there regarding hardening your configuration further. Steps
you may wish to look at in future include setting up DKIM to sign all
outbound mail, and verify all inbound mail. Add whitelisting and
blacklisting services to your setup as appropriate.
You really can't get stronger mail injection than using the standard
submission port only accepting AUTH via TLS encrypted connections on
port 587 and Postfix running postscreen (with or without deep protocol
tests) to reject the majority of zombie type spammers. The postfix
documentation is good and very thorough.
--
Kind Regards,
Mark Homoky
IT Consultant