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

Discussion in 'Installation/Configuration' started by cbj4074, May 31, 2013.

  1. cbj4074

    cbj4074 Member HowtoForge Supporter

    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 [email protected] 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 [email protected]. (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 [email protected] 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.

    Code:
    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=<[email protected]>, 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 <[email protected]>: Relay access denied; from=<[email protected]> to=<[email protected]> 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=<[email protected]>, 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] <[email protected]> -> <[email protected]>, 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=<[email protected]>, 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([email protected]): sieve: msgid=<1370011015.51a8b587172b8@desktop-pc>: stored mail into mailbox 'INBOX'
    May 31 07:36:54 server postfix/pipe[22176]: 76B0319018F3: to=<[email protected]>, 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=<[email protected]> to=<[email protected]> (Relay access denied)
    <[email protected]> -> <[email protected]> (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")?
     
  2. cbj4074

    cbj4074 Member HowtoForge Supporter

    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=<[email protected]> to=<[email protected]> (Relay access denied)
    <[email protected]> -> <[email protected]> (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:

    Code:
    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: May 31, 2013
  3. cbj4074

    cbj4074 Member HowtoForge Supporter

    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.html#smtpd_recipient_restrictions

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

    Code:
    smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination
    
    And, it was important to leave the same restrictions in smtpd_recipient_restrictions, too:

    Code:
    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.
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
  5. cbj4074

    cbj4074 Member HowtoForge Supporter

    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.
     
    Last edited: May 31, 2013
  6. pititis

    pititis Member

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

    Tons of tutorials, also here in howtoforge.

    Cheers
     
: postfix

Share This Page