On Fri, Oct 18, 2013 at 12:45 PM, Noel Jones <njo...@megan.vbhcs.org> wrote:
> On 10/18/2013 8:00 AM, francis picabia wrote:
>> Hello,
>>
>> I'm looking at the logs for an SMTP only service where iptables
>> should be stopping new connections on port 25, and I'm
>> seeing connects with no sasl auth. They fail to relay, but
>> I'd rather we didn't talk to them at all.
>>
>
> Why do you think they're connecting to port 25?
They probably would, if it were not for iptables. Unless there
is some problem I don't get in the iptables.
I'll check on another list about it.
>> In the maillog-internal log:
>>
>> Oct 17 11:28:18 myserver postfix-internal/smtpd[23161]: connect from
>> unknown[142.177.130.133]
>> Oct 17 11:28:20 myserver postfix-internal/smtpd[23161]: NOQUEUE:
>> reject: RCPT from unknown[142.177.130.133]: 454 4.7.1
>> <someu...@hotmail.com>: Relay access denied; from=<u...@example.com>
>> to=<someu...@hotmail.com> proto=ESMTP helo=<[10.36.113.138]>
>> Oct 17 11:28:20 myserver postfix-internal/smtpd[23161]: disconnect
>> from unknown[142.177.130.133]
>
> This looks as if it was caught by the smtpd_relay_restrictions
> safety net. Yeah! Another open relay foiled by sane postfix defaults.
Not the case. There was no open relay here prior to getting
smtpd_relay_restrictions in 2.10. We are a medium sized
institution and there would have been several sources to call us
on running an open mail relay. I think this flaw would also show
as a huge number appearing in the cacti graphs of the mail queues.
I can typically spot a compromised account hitting secure smtp
within minutes as spammers have a signature of undeliverable
addresses.
> One of your access tables is permitting this connection without
> authentication. Check all the rules in your access tables
> (particularly the ones in smtpd_recipient_restrictions) that end
> with permit or OK to see which one isn't working as you intend. You
> can test tables with postmap -q "key" type:table.
I did have some PERMIT lines in /etc/postfix-internal/recipient_access
which didn't belong there. However, with all PERMIT cases removed
and postmap run on the file, I see a new log entry of "Relay access denied"
The only other permit type rules I have in smtpd_recipient_restrictions
are for sasl and mynetworks.
For smtpd_client_restrictions I have a file localdomain which we use
to immediately block compromised accounts coming over secure smtp
or outlook web access.
smtpd_client_restrictions = check_sender_access
hash:/etc/postfix-internal/localdomain, check_client_access
hash:/etc/postfix-internal/access
localdomain:
example.com OK
us...@example.com 550 Account compromised
I believe at the time I found that first OK line was required for
all other accounts to be able to deliver.
> Typically on an outgoing-only server you'll put restrictions that
> apply to all clients (access tables and such) in smtpd_{client,
> helo, sender}_restrictions, and keep smtpd_recipient_restrictions at
> the minimum "permit_sasl_authenticated, permit_mynetworks, reject"
> to prevent accidents like this.
>
> Consider adding -o syslog_name entries to your submission and smtps
> master.cf entries so you can tell which service a particular
> connection used. Something like:
> -o syslog_name=postfix-internal/submission
> or
> -o syslog_name=postfix-internal/smtps
> as appropriate.
Thanks for those suggestions. I was looking for better tracing on this
and that will allow me to verify what port traffic is involved.
