Re: Stopping compromised accounts

[Michael Orlitzky]

On 12/05/2016 08:52 PM, Alex wrote:
> Hi,
> 
> I have a postfix-3.0.5 system with a few hundred users. They have
> access to submission, webmail, and dovecot to send and receive mail.
> 
> On occasion, user's local desktop are compromised, and with it their
> account on this system. This leads to their local desktop using the
> submission service to send hundreds or thousands of spam emails
> through this compromised account.
> 

Sign up for the feedback loops of major providers like AOL, Comcast, and
Yahoo. When their users hit "this is spam," you'll get a report in your
inbox, and you'll be able to see immediately if it was sent from a
compromised account.

On a smallish system where the size of the active queue is usually tiny,
you can also check the number of queued messages every minute or so and
send yourself an alert if it goes over some threshold.

Neither will stop the spam from going out, but they'll at least alert
you to the problem.

Re: Port 587 users question

[Earl Killian]

On 2016/11/27 13:15, li...@lazygranch.com wrote:

I hate to bug the list for what is probably a dumb question, but is there any situation 
where an unauthorized user needs to connect to port 587? I'm wondering if there is some 
oddball  "edge" case.

My thought is to use my ipfw table of known trouble makers to block 587.
‎


I wrote a little script that monitors connections and automatically does

iptables -I input_ext -s IP -j logdrop

for any IP that connects to my port 587, port 22, etc. Obviously it 
doesn't do this for whitelisted IPs.


I implemented this because I noticed a lot of bad IPs were trying AUTH 
commands, presumably to try to guess passwords. The above gives them 
only one try. It catches a dozen or so every day. Periodically flush 
them, or coalesce them.


-Earl

SV: Stopping compromised accounts

[Sebastian Nielsen]

This depends on how the accounts are compromised.
First of, you should enforce so the MAIL FROM is locked to their account, eg 
they cannot use another MAIL FROM than they are authorized to use.

Second, it then depends on how the accounts are compromised.
You say "their local desktop using the submission service". Are you sure of 
that? Eg, the IP in the logs indicate that?
The reason I ask, is that its more common that malicious software steals the 
credentials and sends it elsewhere.

If the accounts are simply "stolen" by malicious software and then used by 
spammers at other locations of the world, I would suggest using GeoIP 
restrictions to lock the account to the country/ISP where the user first logged 
on to. If your users/customers are limited to one country (for example, if you 
only sell services inside a certain country), you can also lock access to the 
submission server alltogheter using GeoIP.
(Travelling users then need to pre-apply at your customers service desk to 
enable account for temporary travel).

However, if the accounts are compromised by the malicious software actually 
sending email through the local user's computer, then its not much you can do.
You could use something that restricts account to like 25 messages a day, and 
if that limit is reached, account is blocked until the user goes to the webmail 
and, lets say, enter a one-time code sent via SMS to the user's phone.

I Do not know any "out of the box" software that can do this, I think you have 
to write a own soiftware that counts outgoing messages per user, a CRON script 
that resets the day counters each 00:00, and if any account reach 25 messages, 
its disabled in the system.
And then some webservice where the user can reset the block with a one-time 
code.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Alex
Skickat: den 6 december 2016 02:52
Till: postfix users list 
Ämne: Stopping compromised accounts

Hi,

I have a postfix-3.0.5 system with a few hundred users. They have access to 
submission, webmail, and dovecot to send and receive mail.

On occasion, user's local desktop are compromised, and with it their account on 
this system. This leads to their local desktop using the submission service to 
send hundreds or thousands of spam emails through this compromised account.

They're only stopped after the user receives a ton of bounce messages, or we 
happen to see it somehow while watching logs.

What mechanisms are available to say, control the number of messages sent per 
day or otherwise be made aware of a pattern of messages being sent by an 
account that could be indicative of account compromise?

Thanks,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature

Re: When is .forward handled?

[MRob]

On 2016-12-05 16:45, wie...@porcupine.org wrote:

MRob:

On 2016-12-05 16:27, wie...@porcupine.org wrote:
> MRob:
>> I was recently surprised to see .forward file in user's home dir being
>> honoured in a context where mail is set to be delivered via LMTP to
>> dovecot for final delivery. A response I got on the dovecot list
>> implied
>> that the MTA is responsible for this.
>>
>> Does Postfix handle .forward just before it hands the message off
>> using
>> LMTP? How does this work? I wouldn't have expected this unless Postfix
>> was doing the actual delivery, though it's not unwelcome - it's a
>> mildly
>> helpful feature but I want to understand how it works.
>
> See http://www.postfix.org/ADDRESS_REWRITING_README.html

This says .forward is only used by local(8).


That is correct. Only the local(8) program has the privileghes that
allow it to grope around in user home directories.


So in my case, dovecot LMTP
seems to be responsible for this?


Nope. that program has no concept of UNIX home directories.

However, you may have configured mailbox_transport, in which
case local(8) delegates mailbox delivery after doing all the
local(8) things first.


A-ha, thank you!

Stopping compromised accounts

[Alex]

Hi,

I have a postfix-3.0.5 system with a few hundred users. They have
access to submission, webmail, and dovecot to send and receive mail.

On occasion, user's local desktop are compromised, and with it their
account on this system. This leads to their local desktop using the
submission service to send hundreds or thousands of spam emails
through this compromised account.

They're only stopped after the user receives a ton of bounce messages,
or we happen to see it somehow while watching logs.

What mechanisms are available to say, control the number of messages
sent per day or otherwise be made aware of a pattern of messages being
sent by an account that could be indicative of account compromise?

Thanks,
Alex

Re: When is .forward handled?

[Peter]

On 06/12/16 13:33, MRob wrote:
>> See http://www.postfix.org/ADDRESS_REWRITING_README.html
> 
> This says .forward is only used by local(8).

Correct.

> So in my case, dovecot LMTP seems to be responsible for this?

No, local(8) is.  Delivery of *all* mail to recipient domains listed in
the local address class is done by local(8).  The mailbox_transport and
mailbox_transport_maps settings are handled by local(8):

   mailbox_transport (empty)
  Optional message delivery transport that the
_local(8)_delivery_agent_ should use ...


Peter

Re: When is .forward handled?

[Wietse Venema]

MRob:
> On 2016-12-05 16:27, wie...@porcupine.org wrote:
> > MRob:
> >> I was recently surprised to see .forward file in user's home dir being
> >> honoured in a context where mail is set to be delivered via LMTP to
> >> dovecot for final delivery. A response I got on the dovecot list 
> >> implied
> >> that the MTA is responsible for this.
> >> 
> >> Does Postfix handle .forward just before it hands the message off 
> >> using
> >> LMTP? How does this work? I wouldn't have expected this unless Postfix
> >> was doing the actual delivery, though it's not unwelcome - it's a 
> >> mildly
> >> helpful feature but I want to understand how it works.
> > 
> > See http://www.postfix.org/ADDRESS_REWRITING_README.html
> 
> This says .forward is only used by local(8).

That is correct. Only the local(8) program has the privileghes that
allow it to grope around in user home directories.

> So in my case, dovecot LMTP 
> seems to be responsible for this?

Nope. that program has no concept of UNIX home directories.

However, you may have configured mailbox_transport, in which
case local(8) delegates mailbox delivery after doing all the
local(8) things first.

Wietse

Re: When is .forward handled?

[MRob]

On 2016-12-05 16:27, wie...@porcupine.org wrote:

MRob:

I was recently surprised to see .forward file in user's home dir being
honoured in a context where mail is set to be delivered via LMTP to
dovecot for final delivery. A response I got on the dovecot list 
implied

that the MTA is responsible for this.

Does Postfix handle .forward just before it hands the message off 
using

LMTP? How does this work? I wouldn't have expected this unless Postfix
was doing the actual delivery, though it's not unwelcome - it's a 
mildly

helpful feature but I want to understand how it works.


See http://www.postfix.org/ADDRESS_REWRITING_README.html


This says .forward is only used by local(8). So in my case, dovecot LMTP 
seems to be responsible for this?

Re: When is .forward handled?

[Wietse Venema]

MRob:
> I was recently surprised to see .forward file in user's home dir being 
> honoured in a context where mail is set to be delivered via LMTP to 
> dovecot for final delivery. A response I got on the dovecot list implied 
> that the MTA is responsible for this.
> 
> Does Postfix handle .forward just before it hands the message off using 
> LMTP? How does this work? I wouldn't have expected this unless Postfix 
> was doing the actual delivery, though it's not unwelcome - it's a mildly 
> helpful feature but I want to understand how it works.

See http://www.postfix.org/ADDRESS_REWRITING_README.html

Wietse

When is .forward handled?

[MRob]

I was recently surprised to see .forward file in user's home dir being 
honoured in a context where mail is set to be delivered via LMTP to 
dovecot for final delivery. A response I got on the dovecot list implied 
that the MTA is responsible for this.


Does Postfix handle .forward just before it hands the message off using 
LMTP? How does this work? I wouldn't have expected this unless Postfix 
was doing the actual delivery, though it's not unwelcome - it's a mildly 
helpful feature but I want to understand how it works.

Re: TLS issue

[Viktor Dukhovni]

> On Dec 5, 2016, at 4:40 AM, Zalezny Niezalezny  
> wrote:
> 
> Problem is generated by one of our Ironport systems which is trying to 
> establish TLS connection.
> In Postfix server I already configured it:
> 
> smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
> smtpd_tls_protocols = !SSLv2,!SSLv3
> smtp_tls_protocols = !SSLv2,!SSLv3
> 
> I suspect that TLS client is not properly configured to establish connection. 
> 
> How to properly configure Postfix to enable all type of TLS connections ?

You begin by posting a properly detailed problem description.  The above isn't
even close.

http://postfix.1071664.n5.nabble.com/TLS-issue-td87598.html#a87612
http://www.postfix.org/DEBUG_README.html#mail
http://www.postfix.org/DEBUG_README.html#sniffer

To decode TLS packet dumps:

   $ tshark -r /file/name -V -x

and look for blocks of text starting with "Secure Socket".

The configuration error is probably on the Ironport, so after
ruling out Postfix mistakes a packet dump will be needed to
see what's going wrong during the handshake.

-- 
Viktor.

Re: TLS issue

[Zalezny Niezalezny]

Problem is generated by one of our Ironport systems which is trying to
establish TLS connection.
In Postfix server I already configured it:

smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3

I suspect that TLS client is not properly configured to establish
connection.

How to properly configure Postfix to enable all type of TLS connections ?


With kind regards

Zalezny


On Sat, Dec 3, 2016 at 5:40 PM, @lbutlr  wrote:

> On 12/2/16 12:16 PM, Wietse Venema wrote:
>
> With 'no shared ciphers' happening frequently, do we want to set
>> up a TLS troubleshooting document, or is the decision tree too
>> complex for such a document to be useful?
>>
> Considering how often the question is asked, probably.
>
> However, I think the error message in the logs is partly to blame since it
> will come up in a grep search for 'error'. (yes, people should grep for
> "error:" but they don't.)
>
> Instead of "Protocol error;" I'd suggest maybe "no protocol match;" or
> similar wording that doesn't include 'error'.
>
>
>
>
>