Open Relay on local lan

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Open Relay on local lan

Software Information
Hi All
I have my postfix server up and running now for some time. Recently though, auditors made a deal that the server is an open relay. It is true that on the local lan it is. What's the best way to change this behavior? For example, is there a way to configure postfix to accept mail from say two domains, test.net and test.com but no other?

Regards
SI
Reply | Threaded
Open this post in threaded view
|

RE: Open Relay on local lan

Fazzina, Angelo

Hi, I run 2.10.1

 

I think this should help

http://www.postfix.org/VIRTUAL_README.html

 

maybe

virtual_alias_domains =  test.net test.com

 

 

not sure what you would need to configure for

mynetworks =

http://www.postfix.org/postconf.5.html#mynetworks

 

 

-ANGELO FAZZINA

 

ITS Service Manager:

Spam and Virus Prevention

Mass Mailing

G Suite/Gmail

 

[hidden email]

University of Connecticut,  ITS, SSG, Server Systems

860-486-9075

 

From: [hidden email] <[hidden email]> On Behalf Of Software Information
Sent: Tuesday, July 24, 2018 1:31 PM
To: [hidden email]
Subject: Open Relay on local lan

 

Hi All

I have my postfix server up and running now for some time. Recently though, auditors made a deal that the server is an open relay. It is true that on the local lan it is. What's the best way to change this behavior? For example, is there a way to configure postfix to accept mail from say two domains, test.net and test.com but no other?

 

Regards

SI

Reply | Threaded
Open this post in threaded view
|

Re: Open Relay on local lan

Viktor Dukhovni
In reply to this post by Software Information


> On Jul 24, 2018, at 1:31 PM, Software Information <[hidden email]> wrote:
>
> I have my postfix server up and running now for some time. Recently though, auditors made a deal that the server is an open relay.

If there are systems on your network that need to use the machine as a
smarthost for outbound mail, and it is not practical to enable SASL or
TLS client certificate authentication, then allowing all systems on your
internal network to send email is not considered unreasonable.  You can
don't generally have to make changes in response to every finding by your
auditors, documenting the reason why you accept the status-quo is likely
sufficient.

> What's the best way to change this behavior?

If the various and sundry systems on your LAN don't need to send email
to the public Internet, you could by default restrict them to send email
only to your own domains, and make specific exceptions for authenticated
clients and/or particular hosts.

> For example, is there a way to configure postfix to accept mail from say
> two domains, test.net and test.com but no other?

Limiting sender domains does not close an open relay.  Open relaying
is about being to send to *any* recipient, rather than being able to
send as any sender.

What do your auditors mean when *they* say "open relay"?  If they
mean the ability to send from remote domains, you could perhaps
limit outbound mail to just envelope senders in your own domains,
but keep in mind that this will not prevent external addresses
in the message "From:" or "Resent-From:" headers.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Open Relay on local lan

Software Information
Hi. Thanks for replying. Let's say my internal domain is test.com. I can telnet to the server and send an email as [hidden email] out to anyone on the internet. They have a problem with that. So I thought maybe I could fix this by configuring the server to only accept outgoing mail from [hidden email]. Not sure if that is best of there is a better way.

On Wed, Jul 25, 2018 at 8:42 AM, Viktor Dukhovni <[hidden email]> wrote:


> On Jul 24, 2018, at 1:31 PM, Software Information <[hidden email]> wrote:
>
> I have my postfix server up and running now for some time. Recently though, auditors made a deal that the server is an open relay.

If there are systems on your network that need to use the machine as a
smarthost for outbound mail, and it is not practical to enable SASL or
TLS client certificate authentication, then allowing all systems on your
internal network to send email is not considered unreasonable.  You can
don't generally have to make changes in response to every finding by your
auditors, documenting the reason why you accept the status-quo is likely
sufficient.

> What's the best way to change this behavior?

If the various and sundry systems on your LAN don't need to send email
to the public Internet, you could by default restrict them to send email
only to your own domains, and make specific exceptions for authenticated
clients and/or particular hosts.

> For example, is there a way to configure postfix to accept mail from say
> two domains, test.net and test.com but no other?

Limiting sender domains does not close an open relay.  Open relaying
is about being to send to *any* recipient, rather than being able to
send as any sender.

What do your auditors mean when *they* say "open relay"?  If they
mean the ability to send from remote domains, you could perhaps
limit outbound mail to just envelope senders in your own domains,
but keep in mind that this will not prevent external addresses
in the message "From:" or "Resent-From:" headers.

--
        Viktor.


Reply | Threaded
Open this post in threaded view
|

Re: Open Relay on local lan

Viktor Dukhovni


> On Jul 25, 2018, at 11:24 AM, Software Information <[hidden email]> wrote:
>
> Hi. Thanks for replying. Let's say my internal domain is test.com. I can telnet to the server and send an email as [hidden email] out to anyone on the internet. They have a problem with that. So I thought maybe I could fix this by configuring the server to only accept outgoing mail from [hidden email]. Not sure if that is best of there is a better way.

That's not what an "open relay" is.  What you have is, arguably, a lack
of "egress filtering", where you're not checking that messages leaving
your network claim to originate from your network.

Whether such "egress filtering" is the right thing to do depends on what
use-cases you support for email.

   1.  Do you have any externally reachable email lists that expand
       to a recipient list that includes external addresses?  Say a
       list for a board of directors, that includes outside directors?

   2.  Do any of your users automatically and legitimately forward some
       of their incoming mail to an external mailbox?

   3.  Do any of your users "resend" messages, retaining the original
       message structure, adding only Resent-{From,Date,Message-Id}
       headers?

In cases 1 and 2, you'd expect to see some legitimate outbound email
that has an external "From:" address and an external envelope sender
address.  In case 3, you'd expect to see some legitimate outbound
email that has an external "From:" (header) address.

It is not too difficult to configure Postfix to restrict outbound
email to internal envelope sender addresses, which will work,
provided you don't have cases 1, 2 or similar.

It is considerably more difficult to restrict external email
delivery based on the message "From:" header.  What should
happen with a multi-recipient message with some internal
and some external recipients when it is discovered that
the "From:" header is not internal?  You'd need a complex
content filter or milter to implement policies in this
space.

The auditors were following a checklist, their job is done
once they've raised every potential issue.  Now you need to
decide which issues require changes, and which issues are
acceptable features of your environment.

If you do decide to filter outbound email by envelope sender,
you can add:

   main.cf:
        indexed = ${default_database_type}:${config_directory}/
        smtpd_sender_restrictions =
                check_sender_access ${indexed}relay-senders,
                reject_unauth_destination

   relay-senders:
        example.com permit_mynetworks, permit_sasl_authenticated
        example.net permit_mynetworks, permit_sasl_authenticated

--
--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Open Relay on local lan

Software Information
Wow. you learn as you go. Thanks very much for the insight. I will experiment to see what works best for us.

On Wed, Jul 25, 2018 at 10:44 AM, Viktor Dukhovni <[hidden email]> wrote:


> On Jul 25, 2018, at 11:24 AM, Software Information <[hidden email]> wrote:
>
> Hi. Thanks for replying. Let's say my internal domain is test.com. I can telnet to the server and send an email as [hidden email] out to anyone on the internet. They have a problem with that. So I thought maybe I could fix this by configuring the server to only accept outgoing mail from [hidden email]. Not sure if that is best of there is a better way.

That's not what an "open relay" is.  What you have is, arguably, a lack
of "egress filtering", where you're not checking that messages leaving
your network claim to originate from your network.

Whether such "egress filtering" is the right thing to do depends on what
use-cases you support for email.

   1.  Do you have any externally reachable email lists that expand
       to a recipient list that includes external addresses?  Say a
       list for a board of directors, that includes outside directors?

   2.  Do any of your users automatically and legitimately forward some
       of their incoming mail to an external mailbox?

   3.  Do any of your users "resend" messages, retaining the original
       message structure, adding only Resent-{From,Date,Message-Id}
       headers?

In cases 1 and 2, you'd expect to see some legitimate outbound email
that has an external "From:" address and an external envelope sender
address.  In case 3, you'd expect to see some legitimate outbound
email that has an external "From:" (header) address.

It is not too difficult to configure Postfix to restrict outbound
email to internal envelope sender addresses, which will work,
provided you don't have cases 1, 2 or similar.

It is considerably more difficult to restrict external email
delivery based on the message "From:" header.  What should
happen with a multi-recipient message with some internal
and some external recipients when it is discovered that
the "From:" header is not internal?  You'd need a complex
content filter or milter to implement policies in this
space.

The auditors were following a checklist, their job is done
once they've raised every potential issue.  Now you need to
decide which issues require changes, and which issues are
acceptable features of your environment.

If you do decide to filter outbound email by envelope sender,
you can add:

   main.cf:
        indexed = ${default_database_type}:${config_directory}/
        smtpd_sender_restrictions =
                check_sender_access ${indexed}relay-senders,
                reject_unauth_destination

   relay-senders:
        example.com permit_mynetworks, permit_sasl_authenticated
        example.net permit_mynetworks, permit_sasl_authenticated

--
--
        Viktor.


Reply | Threaded
Open this post in threaded view
|

Re: Open Relay on local lan

@lbutlr
In reply to this post by Software Information

On 24 Jul 2018, at 11:31, Software Information <[hidden email]> wrote:
> Recently though, auditors made a deal that the server is an open relay.

Based on the rest of this thread, it sounds very much like the auditors are incompetent. I mean, not knowing what an open relay is is concerning.



Reply | Threaded
Open this post in threaded view
|

Re: Open Relay on local lan

John Peach
On 07/25/2018 01:36 PM, @lbutlr wrote:
>
> On 24 Jul 2018, at 11:31, Software Information <[hidden email]> wrote:
>> Recently though, auditors made a deal that the server is an open relay.
>
> Based on the rest of this thread, it sounds very much like the auditors are incompetent. I mean, not knowing what an open relay is is concerning.

I still remember trying to explain to auditors why I did not have AV on
a Solaris server and, having won that battle, having to prove it really
was Solaris.....

>
>
>




--
John
PGP Public Key: 412934AC