Go Back   HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials > ISPConfig 3 > Installation/Configuration

Do you like HowtoForge? Please consider supporting us by becoming a subscriber.
Thread Tools Display Modes
Old 31st May 2013, 18:32
cbj4074 cbj4074 is offline
Senior Member
Join Date: Nov 2010
Posts: 395
Thanks: 30
Thanked 58 Times in 50 Posts
Default Able to relay mail from remote IP w/o authentication if I forge the "from" address

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[]
May 31 07:36:53 server postfix/smtpd[22163]: 1C45519018F2: client=rrcs-1-2-3-4.nys.biz.rr.com[]
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[]
May 31 07:36:53 server postfix/smtpd[22163]: connect from rrcs-1-2-3-4.nys.biz.rr.com[]
May 31 07:36:53 server postfix/smtpd[22163]: NOQUEUE: reject: RCPT from rrcs-1-2-3-4.nys.biz.rr.com[]: 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=<[]>
May 31 07:36:54 server postfix/smtpd[22163]: disconnect from rrcs-1-2-3-4.nys.biz.rr.com[]
May 31 07:36:54 server postfix/smtpd[22175]: connect from localhost.localdomain[]
May 31 07:36:54 server postfix/smtpd[22175]: 76B0319018F3: client=localhost.localdomain[]
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, [] [] <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=[]: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([]: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[]
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:


Can anyone verify this behavior (or confirm that it "doesn't happen for me")?
Reply With Quote
Sponsored Links
Old 31st May 2013, 19:10
cbj4074 cbj4074 is offline
Senior Member
Join Date: Nov 2010
Posts: 395
Thanks: 30
Thanked 58 Times in 50 Posts

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).

Last edited by cbj4074; 31st May 2013 at 19:31.
Reply With Quote
Old 31st May 2013, 20:10
cbj4074 cbj4074 is offline
Senior Member
Join Date: Nov 2010
Posts: 395
Thanks: 30
Thanked 58 Times in 50 Posts
Thumbs up

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:


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 = 
	check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf
I'm considering this solved until further notice.
Reply With Quote
Old 31st May 2013, 20:18
till till is offline
Super Moderator
Join Date: Apr 2005
Location: Lneburg, Germany
Posts: 37,015
Thanks: 840
Thanked 5,651 Times in 4,461 Posts

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.
Till Brehm
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
The Following User Says Thank You to till For This Useful Post:
cbj4074 (4th June 2013)
Old 31st May 2013, 21:47
cbj4074 cbj4074 is offline
Senior Member
Join Date: Nov 2010
Posts: 395
Thanks: 30
Thanked 58 Times in 50 Posts

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 ( [::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.

Last edited by cbj4074; 31st May 2013 at 22:13.
Reply With Quote
Old 2nd June 2013, 02:55
pititis pititis is offline
Senior Member
Join Date: Dec 2010
Location: Mnchen
Posts: 364
Thanks: 39
Thanked 89 Times in 68 Posts

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

Tons of tutorials, also here in howtoforge.

Reply With Quote
The Following User Says Thank You to pititis For This Useful Post:
cbj4074 (4th June 2013)



Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Postfix not working after update SpeedyB ISPConfig 3 Priority Support 4 14th May 2013 17:11
Multiple postfix errors iandoug Server Operation 4 6th February 2013 23:40
Postfix not sending mail arnolette Server Operation 3 4th November 2012 14:22
Fail2ban configuration Captain Installation/Configuration 2 28th June 2011 20:48
Postfix + postfixadmin = SMTP errors... Rashef Server Operation 4 25th June 2009 17:12

All times are GMT +2. The time now is 15:03.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.