Able to relay mail from remote IP w/o authentication if I forge the "from" address

[cbj4074]

If I send email to my ISPC server and forge the "from" header, I'm able to send mail, with no authentication required, to real mailbox recipients whose mailboxes are hosted on the server -- all from a remote IP address on my ISP's network.

I find this to be alarming, and this seems to be possible with the default ISPC configuration. To be fair, I don't know how much ISPC modifies Postfix's default configuration, and whether the too-permissive default value is something that exists off-the-shelf, or if it's something that ISPC adds/removes. In fact, it's entirely possible that I have misconfigured something myself.

So, I setup a test-case. The "real-world" application is a Web form. Now, it is important to note that I am running this Web application on my personal workstation; that is, on a desktop PC at home, connected to a residential ISP's network. I am not runnin the test application on the actual server to which I am sending mail. The fact that it's a Web application isn't even relevant, actually. I could replicate this same scenario just using telnet or a desktop email client. I am using this example scenario only as a frame of reference.

This test application takes two actions in the way of email:

1.) Sends a message to the "customer care" email address (this address is hard-coded in the application logic). This email address is identified as realaddress@customer-care-domain.com below.

2.) Sends a copy of the same message to the "submitter's" own email address (the address field is a free-form text field). This email address is identified as myaddress@my.real-domain.com. (The attacker would put the spam "target/recipient" address of the user whose mail is hosted at my.real-domain.com into this field.)

The "from" header is set via the Web form application logic and is identified as fakeaddress@my.real-domain.com below. (This is the address that is being "forged"; I intentionally set this to a fake/nonexistent address as my real domain.)

In any case, here's the mail.log excerpt when I perform this test.

May 31 07:36:52 server postfix/smtpd[22163]: connect from rrcs-1-2-3-4.nys.biz.rr.com[1.2.3.4]
May 31 07:36:53 server postfix/smtpd[22163]: 1C45519018F2: client=rrcs-1-2-3-4.nys.biz.rr.com[1.2.3.4]
May 31 07:36:53 server postfix/cleanup[22169]: 1C45519018F2: message-id=<1370011015.51a8b587172b8@desktop-pc>
May 31 07:36:53 server postfix/qmgr[22123]: 1C45519018F2: from=<fakeaddress@my.real-domain.com>, size=1037, nrcpt=1 (queue active)
May 31 07:36:53 server postfix/smtpd[22163]: disconnect from rrcs-1-2-3-4.nys.biz.rr.com[1.2.3.4]
May 31 07:36:53 server postfix/smtpd[22163]: connect from rrcs-1-2-3-4.nys.biz.rr.com[1.2.3.4]
May 31 07:36:53 server postfix/smtpd[22163]: NOQUEUE: reject: RCPT from rrcs-1-2-3-4.nys.biz.rr.com[1.2.3.4]: 554 5.7.1 <realaddress@customer-care-domain.com>: Relay access denied; from=<fakeaddress@my.real-domain.com> to=<realaddress@customer-care-domain.com> proto=ESMTP helo=<[169.254.97.163]>
May 31 07:36:54 server postfix/smtpd[22163]: disconnect from rrcs-1-2-3-4.nys.biz.rr.com[1.2.3.4]
May 31 07:36:54 server postfix/smtpd[22175]: connect from localhost.localdomain[127.0.0.1]
May 31 07:36:54 server postfix/smtpd[22175]: 76B0319018F3: client=localhost.localdomain[127.0.0.1]
May 31 07:36:54 server postfix/cleanup[22169]: 76B0319018F3: message-id=<1370011015.51a8b587172b8@desktop-pc>
May 31 07:36:54 server postfix/qmgr[22123]: 76B0319018F3: from=<fakeaddress@my.real-domain.com>, size=1848, nrcpt=1 (queue active)
May 31 07:36:54 server amavis[31493]: (31493-01) Passed CLEAN, [1.2.3.4] [1.2.3.4] <fakeaddress@my.real-domain.com> -> <myaddress@my.real-domain.com>, Message-ID: <1370011015.51a8b587172b8@desktop-pc>, mail_id: aatmW129ovvQ, Hits: 4.357, size: 1037, queued_as: 76B0319018F3, 1185 ms
May 31 07:36:54 server postfix/smtp[22170]: 1C45519018F2: to=<myaddress@my.real-domain.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=1.4, delays=0.24/0.01/0.01/1.2, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=31493-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 76B0319018F3)
May 31 07:36:54 server postfix/qmgr[22123]: 1C45519018F2: removed
May 31 07:36:54 server dovecot: deliver(myaddress@my.real-domain.com): sieve: msgid=<1370011015.51a8b587172b8@desktop-pc>: stored mail into mailbox 'INBOX'
May 31 07:36:54 server postfix/pipe[22176]: 76B0319018F3: to=<myaddress@my.real-domain.com>, relay=dovecot, delay=0.03, delays=0/0.01/0/0.01, dsn=2.0.0, status=sent (delivered via dovecot service)
May 31 07:36:54 server postfix/qmgr[22123]: 76B0319018F3: removed
May 31 07:36:54 server postfix/smtpd[22175]: disconnect from localhost.localdomain[127.0.0.1]

from=<fakeaddress@my.real-domain.com> to=<realaddress@customer-care-domain.com> (Relay access denied)
<fakeaddress@my.real-domain.com> -> <myaddress@my.real-domain.com> (is permitted!)

What this means is that anyone can simply setup a desktop email client and send email to my server, from some external network, and the email will be accepted for delivery as long as a) the sender uses any "from address" ("local part") @my.real-domain.com, and b) the recipient has a mailbox @my.real-domain.com.

Postfix "postfinger" output for this server:

http://pastebin.com/QGE3cah5

Can anyone verify this behavior (or confirm that it "doesn't happen for me")?

[cbj4074]

After finding the thread at http://ubuntuforums.org/showthread.php?t=2060287 , I decided to try "volkswagner's" suggestion: put a "reject" at the end of whatever is listed in the "smtpd_client_restrictions" directive.

Sure enough, this seems to have "solved the problem" and "closed the hole". Now, both messages are being rejected:

from=<fakeaddress@my.real-domain.com> to=<realaddress@customer-care-domain.com> (Relay access denied)
<fakeaddress@my.real-domain.com> -> <myaddress@my.real-domain.com> (Recipient address rejected: Access denied)

It seems that the default Postfix configuration does not include a reject at the end of this directive. The output from "postconf -d" shows:

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

So, is the default Postfix configuration inadequate? If not, does it become inadequate after ISPC modifies it? Or have I added other items to smtpd_recipient_restrictions that have opened this "loophole"?

EDIT: Actually, the solution was not to add a "reject" at the end of "smtpd_recipient_restrictions"; when I do that, I am unable to receive mail from any legitimate server on the Internet (such as those at google.com).

[cbj4074]

It seems that the proper solution was to use the new-ish (as of Postfix 2.10) "smtpd_relay_restrictions" directive, instead of trying to account for every possibility in the "smtpd_recipient_restrictions" directive.

Even though I had read this in the Postfix manual while attempting to troubleshoot this issue, its importance didn't sink-in straight away:

http://www.postfix.org/postconf.5.ht...t_restrictions

With Postfix versions before 2.10, the rules for relay permission and spam blocking were combined under smtpd_recipient_restrictions, resulting in error-prone configuration. As of Postfix 2.10, relay permission rules are preferably implemented with smtpd_relay_restrictions, so that a permissive spam blocking policy under smtpd_recipient_restrictions will no longer result in a permissive mail relay policy.

For backwards compatibility, sites that migrate from Postfix versions before 2.10 can set smtpd_relay_restrictions to the empty value, and use smtpd_recipient_restrictions exactly as before.

Well, setting smtpd_relay_restrictions to an empty value didn't solve the problem; only setting it as follows did:

smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination

And, it was important to leave the same restrictions in smtpd_recipient_restrictions, too:

smtpd_recipient_restrictions = 
	permit_mynetworks,
	permit_sasl_authenticated,
	reject_unauth_destination,
	check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf

I'm considering this solved until further notice.

[till]

The ispconfig default postfix configuration is correct of course. If you want to test if your server is a open relay, use a open relay test, you find many of them when you search for open relay test at google.

What you log shows is a normal delivery to a local email address and not a email relaying. The purpose of a email server is to accept emails for local addresses, thats not relaying.

[cbj4074]

Thanks for jumping-in here, Till. I appreciate your feedback and time.

Also, thanks for the correction; the behavior I describe is not relaying. I have used the tool at http://www.mailradar.com/openrelay/ and it reports, "All tested completed! No relays accepted by remote host!".

The bottom line is that I don't want unauthenticated user-agents to be able to send mail through my server, at all, unless those agents are sending mail from $mynetworks (127.0.0.0/8 [::1]/128).

Do you know how to achieve this using Postfix?

To be clear, I'm able to connect to my server via a desktop client, over SMTP, and send email, without authenticating, as long as the "from" header's domain-part is one of my own domains, and as long as the "to" header (recipient) has a mailbox on my system.

I don't want this. I want to refuse all mail from such senders. If someone who is unauthenticated wishes to send me mail, he should be forced to send the message through his own mailserver, not mine. I wish to refuse the connection outright, at the soonest opportunity.

Is this done with the "smtpd_sender_restrictions" directive? If so, what value is necessary to achieve this?

EDIT: Never mind. Apparently, there is no difference between the user-agent connecting directly to my server via SMTP to send mail to my users, and the user-agent connecting to his ISP's SMTP server to do the same (beyond the various spam-related checks that are performed). Great. I can relax now.

[pititis]

Add SPF support to your postfix setup, software + dns changes.

Tons of tutorials, also here in howtoforge.

Cheers