Security threat posed by names and IPs in SMTP headers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Security threat posed by names and IPs in SMTP headers

Scott A. Wozny

I haven’t been able to find any particularly good guidance about this on the Internet so I figured I’d ask those in the trenches for their opinions regarding where they land on this. I know it’s not a Postfix specific matter and if anyone thinks I should be posing this question elsewhere, please let me know where.


One of the fundamental tenets of security is not to give out any information to an adversary you don’t have to, but in the real world, there are operational considerations that need to be balanced against extreme security paranoia. So how does that balance work with message headers? In your average message header there are system names and IPs (both often internal) all along the path of delivery which would, on one hand, seem to be a needless leak of information useful to a hacker but, on the other hand, absolutely critical to troubleshooting mail delivery problems for any individual message.


So is there a line or philosophy one follows looking at this? I know inside Postfix there are a number of things you can do to adjust the system names at each hop (and, presumably, suppress the IP but I don’t know how, personally) but I would think each one would add burden to troubleshooting. However, how much burden that is compared to how much security benefit is gained from shielding that information is something I also don’t know.


So, assuming most of this list is operational folks with that particular bias, does anyone want to share their thoughts on the balance they have achieved on this that doesn't spin their auditors into a tizzy?


Thanks,


Scott


Reply | Threaded
Open this post in threaded view
|

Re: Security threat posed by names and IPs in SMTP headers

Wietse Venema
It is really simple. If you allow information to go out, then you
will leak information. Postfix assumes that you're willing to send
and receive email, and that means you will have to accept some
leakage that is inherent with SMTP, TLS, TCP, DNS, UDP, and related
protocols. The options for message-shaping and traffic-shaping are
fairly limited.

But wait, there is more. Unless all those protocol implementations
are perfect, there may be exposures that in the worst case provide
remote access to a root shell on the server, as happened recently
in OpenSMTPD. A good mail server architecture can function as a
fire retardant and limit the impact of mistakes.

Personally I am less concerned about the inherent leaks.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Security threat posed by names and IPs in SMTP headers

Ralph Seichter-3
In reply to this post by Scott A. Wozny
* Scott A. Wozny:

> In your average message header there are system names and IPs (both
> often internal) all along the path of delivery which would, on one
> hand, seem to be a needless leak of information useful to a hacker
> but, on the other hand, absolutely critical to troubleshooting mail
> delivery problems for any individual message.

There are some assumptions I usually make for production systems:

  - Organisation A has 0..n Intranet-only Postfix instances which don't
    connect to the Internet.

  - There are 1..m Postfix instances used as outbound relayhosts, and
    only these do connect to MXs using the Internet.

  - Troubleshooting can be separated into either the route
    Intranet-to-Relayhost or Relayhost-to-Internet.

  - Once a message reaches the relayhost(s), existing routing
    information is no longer relevant when it comes to debugging
    possible mail routing problems.

If these assumptions hold true, I see no harm in removing message
headers you consider sensitive on your relayhosts. Postfix's cleanup[1]
daemon can do it for you, using the header_checks[2] option:

  # pcre:/etc/postfix/my_cleanup_header_checks
  /^Received: from \w+\.myinternaldomain\.org\b/ STRIP

The STRIP action logs header removal, while the alternative IGNORE would
delete headers silently.

-Ralph

[1] http://www.postfix.org/cleanup.8.html
[2] http://www.postfix.org/header_checks.5.html
Reply | Threaded
Open this post in threaded view
|

Re: Security threat posed by names and IPs in SMTP headers

Jaroslaw Rafa
In reply to this post by Scott A. Wozny
Dnia 12.12.2020 o godz. 23:46:42 Scott A. Wozny pisze:
> I know it’s not a Postfix specific
> matter and if anyone thinks I should be posing this question elsewhere,
> please let me know where.

The "mailop" list (https://list.mailop.org/listinfo/mailop ) may be also a
good place to discuss this.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: Security threat posed by names and IPs in SMTP headers

Scott A. Wozny
In reply to this post by Wietse Venema
Hi Wietse,

I definitely agree there are LOTS more important things in the world to be worried about when connecting a system to an untrusted network, I was just curious how much people doing this in the real world were worried about the information leakage that sits somewhere between "inherent to using the protocol in the real world; get over it" and "I've taken extraordinary measures to limit all information leaks that are not absolutely necessary, even if it makes my job a lot harder".  🙂

Thanks for your feedback (and everything else you do for this project),

Scott


From: [hidden email] <[hidden email]> on behalf of Wietse Venema <[hidden email]>
Sent: December 12, 2020 7:32 PM
To: Postfix users <[hidden email]>
Subject: Re: Security threat posed by names and IPs in SMTP headers
 
It is really simple. If you allow information to go out, then you
will leak information. Postfix assumes that you're willing to send
and receive email, and that means you will have to accept some
leakage that is inherent with SMTP, TLS, TCP, DNS, UDP, and related
protocols. The options for message-shaping and traffic-shaping are
fairly limited.

But wait, there is more. Unless all those protocol implementations
are perfect, there may be exposures that in the worst case provide
remote access to a root shell on the server, as happened recently
in OpenSMTPD. A good mail server architecture can function as a
fire retardant and limit the impact of mistakes.

Personally I am less concerned about the inherent leaks.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Security threat posed by names and IPs in SMTP headers

Scott A. Wozny
In reply to this post by Ralph Seichter-3
Wow!  Thanks, I didn't realize this was an option.  A really pretty balance of maintaining the internal routing information for troubleshooting purposes without sending it to the Internet.  Not totally settled on the actual level of threat posed by leaking this info, but a great option to know I have.

Much obliged,

Scott


From: [hidden email] <[hidden email]> on behalf of Ralph Seichter <[hidden email]>
Sent: December 13, 2020 6:14 AM
To: [hidden email] <[hidden email]>
Subject: Re: Security threat posed by names and IPs in SMTP headers
 
* Scott A. Wozny:

> In your average message header there are system names and IPs (both
> often internal) all along the path of delivery which would, on one
> hand, seem to be a needless leak of information useful to a hacker
> but, on the other hand, absolutely critical to troubleshooting mail
> delivery problems for any individual message.

There are some assumptions I usually make for production systems:

  - Organisation A has 0..n Intranet-only Postfix instances which don't
    connect to the Internet.

  - There are 1..m Postfix instances used as outbound relayhosts, and
    only these do connect to MXs using the Internet.

  - Troubleshooting can be separated into either the route
    Intranet-to-Relayhost or Relayhost-to-Internet.

  - Once a message reaches the relayhost(s), existing routing
    information is no longer relevant when it comes to debugging
    possible mail routing problems.

If these assumptions hold true, I see no harm in removing message
headers you consider sensitive on your relayhosts. Postfix's cleanup[1]
daemon can do it for you, using the header_checks[2] option:

  # pcre:/etc/postfix/my_cleanup_header_checks
  /^Received: from \w+\.myinternaldomain\.org\b/ STRIP

The STRIP action logs header removal, while the alternative IGNORE would
delete headers silently.

-Ralph

[1] http://www.postfix.org/cleanup.8.html
[2] http://www.postfix.org/header_checks.5.html