Another frequently asked question about SMTP mail – how can I remove internal host names and IP addresses from outbound Internet mail? More often than not, this results from the belief that somehow if the outside world finds out an organization’s internal IP addresses and host names, it makes the organization vulnerable. Auditors love to point this out for some reason. Perhaps it’s a part of an IT audit checklist written by a security expert at some law firm somewhere and given the viral nature of checklists it’s all over the place!
Let’s take a look at what we’re talking about here. As a message makes its way from one server to another, it may be handled by more than one SMTP hosts. Each host adds a RECEIVED header at the beginning of message headers, leaving a trace of where the message has been and when (a timestamp).
Here are headers from a message received from Dell. (Unnecessary headers removed).
Received: from smtp.easydns.com (205.210.42.52) by exchange.somedomain.com
(192.168.2.171) with Microsoft SMTP Server id 8.1.240.5; Mon, 19 May 2008
03:12:46 -0700
Received: from mh.dell.m0.net (mh.dell.m0.net [209.11.164.66]) by
smtp.easydns.com (Postfix) with ESMTP id 647C222914 for <me>;
Mon, 19 May 2008 06:14:46 -0400 (EDT)
Received: from [192.168.138.130] ([192.168.138.130:57330]
helo=fc13a1.dc1.prod) by oms1.dc1.prod (ecelerity 2.1.1.24 r(19486)) with
ESMTP id 3B/AF-18306-11351384 for <me>; Mon, 19 May 2008
03:14:41 -0700
Message-ID: <[email protected]>
Date: Mon, 19 May 2008 03:14:41 -0700
From: Dell Small Business <dell>
Reply-To: <dell<
To: <dell<
Subject: $429 desktop, plus new laptops. Hurry and shop now.
Errors-To: [email protected]
Return-Path: [email protected]
These headers can be used to determine the path taken by a message— useful information for troubleshooting and preventing message loops.
What the standards say
Let’s take a look at what the standards say. RFC 2821 says (capitalization of words as it appears in the RFC, emphasis added):
4.4 Trace Information
When an SMTP server receives a message for delivery or further processing, it MUST insert trace (“time stamp” or “Received”) information at the beginning of the message content, as discussed in section 4.1.1.4.
This line MUST be structured as follows:
– The FROM field, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.
and prohibits removing received headers (repeatedly). One example:
An Internet mail program MUST NOT change a Received: line that was previously added to the message header. SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location.
Is it really more secure?
Should you remove these Received headers and “hide” internal hosts and IP addresses? Are they really a security risk?
There are many opinions about security through obscurity, but if your security relies on hiding internal hostnames and IP addresses, you probably have other things to worry about.
Steve Riley, Senior Security Strategist at Microsoft, says:
In general, you can’t achieve any additional security by trying to hide things that weren’t designed to be hidden. IP addresses, wireless SSIDs, hostnames—these are all identifiers, and by definition, an identifier is intended to be known. Efforts to hide them generally fail, because the thing that the identifier points to still exists! Determined attackers will find the thing regardless of what you name it.
Microsoft does not remove internal message routing headers. Nor do Dell (as the message headers in the example above reveal), HP, and many other large organizations.
In many ways, the issues faced are similar to changing fqdn on SMTP Virtual Server/Receive Connector. Even if you make these changes in order to mask the internal hostname of a server, at least one internal hostname is likely to be revealed by the Message-ID (read “Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain“).
Nevertheless, many organizations may have a legitimate need to cleanse outbound mail of internal host names and IP addresses, and you probably don’t want to invite adverse remarks in an IT or compliance audit (should you find such a requirement on the auditor’s checklist).
How to remove Received headers in Exchange Server 2007/2010
Exchange 2007/2010 offers an easy way to accomplish this. If your transport server sends outbound email directly using DNS lookup, or delivers to a smarthost without authentication, simply remove the Ms-Exch-Send-Headers-Routing permission assigned to Anonymous Logon — a well-known security principal that refers to anonymous users, as shown below:
Get-SendConnector “Connector Name” | Remove-ADPermission -AccessRight ExtendedRight -ExtendedRights ms-Exch-Send-Headers-Routing -user “NT AUTHORITY\Anonymous Logon”
What’s your take?
Does your organization remove internal Received headers? What are the reasons cited? Does removing internal received headers make your organization more secure? Feel free to leave a comment and share your opinion about this.
{ 30 comments… read them below or add one }
Great post!
Is there a way to do this on Exchange 2003?
Thanks for publishing an excellent blog.
Jon
Brilliant
Well, it will help me in future server security hardening
Thanks
great post…. well done!
hi,
i understand the comments about it not really increasing security to hide the internal IP’s and FQDNs, however, being the nosey little SH*T that i am, i often peruse other peoples message headers to see what i can see. Maybe it is just a personal thing, but the naming of our internal servers is somthing of an in-joke so i dont really want them broadcasted around the net, and heaven forbid i ever had a problem which needed an external source to look into my headers… well r2d2 and c3p0.domain.local might leave me a bit redfaced – perhaps i should just come up with better server names, jahjah perhaps?
So after installing exchange 2007 i was a bit worried when my first few test messages proudly showed off my new server and domains internal info. im not having that.. i thought. So a few hours on google led me to your post, and a few others like it. I wasnt keen on removing permissions, so i stumbled apon a transport rule.
I have a transport rule that applies to messages sent to users outside the organisation and it removes the header ‘received’ and thats it.
Headers now show the message orginating at my external IP which is publically resolvable to a more respectable name, and i am happy again :)
@Jon: Not aware of a way to do this in Exchange 2003.
@Others: Thank you for the feedback!
Hi All,
Need an immediate assistant on this email problem. My problem is i cannot send email to only 1 domain email so far. When try to sending to this domain [email protected], there is and bounce back with error ‘[email protected]
#550 4.4.7 QUEUE.Expired; message expired ##’. Please help..
i tried this but still i am able to see my internal ip detail.
Hi,
Removing this permission can caused undetected message loops and potentially even bring down exchange. Much better to use transport rules to remove the Received and Message-ID headers from inside users.
F
This is great, I have something similair, where my internal hostname and IP shows up. My question is I have heard that some places block .local addresses from going through there IP gateways is that true? Wouldnt that be a reason to make this Best Practice?
I have tried the suggested transport rule and cannot get it to work. Also the suggested permission removal also does not work for me and anyway, the server name is also visible in the messageid field.
My biggest issue is that we are on a ListServ list that tries to verify the sending server. When it tries to verify server.company.local [192.168.1.2] it is unable to contact the server and the user is then removed from the list.
In my line of work (Security Engineer with much experience in penetration testing) I use this information in reconnaissance AND attack. Whatever means necessary to map out an infrastructure.
The concern is not for the honest people and the information available to them… it's for the truely malicious people involved in targetted attacks.
It's not a matter of if–but when.
Enjoy.
I wouldn't cite Microsoft's methods since they certainly do not conform to the RFCs. Also, they don't have a desirable security reputation.
Microsoft has expertise in security? As soon as I read that implication, I considered this entire article tainted because Microsoft's swiss-cheese approach to security (it's full of holes) is one of the de-facto industry examples of what not to do.
Given the number of times I've been burned by Microsoft's security techniques, I have no choice but take all of their recommendations with a grain of salt.
@Anonymous from Oct. 14: Understand the point of view.
@Anonymous from Oct. 15: It's not just Microsoft – plenty of other organizations including Dell and HP don't hide internal IP addresses in message headers. Microsoft's security reputation isn't what it once was – in fact, Microsoft products have increasingly proven to be more secure and less vulnerable, and its secure development lifecycle cited as an example for other software companies to emulate.
@Anonymous from Oct. 14: And how does it help you, besides showing off to your customers that you can read their headers? Please provide real life example where you were able to utilize that, other then stating "oh you've got 1 or 2 mail relays and this is the name of your mail server". I mean carry out an attack and be successful based on the info from header. As the article says "if your security relies on hiding internal hostnames and IP addresses, you probably have other things to worry about." If your firewall is wide open and you are running unpatched OS and Mail server, you are asking for it and no amount of obscurity is going to protect you.
@Anonymous from Oct. 15: It is actually them conforming to RFCs that does not allow you to remove the info from headers. Did you read the article?
@Anonymous Coward: Really? Please let me know when was Microsoft hacked last time?
Its still trendy to bash MS these days?!? I thought those were the jokes that went the way of the Dodo. Whilst i hold no allegiance or partiality to any vendor or product im so tired of hearing this same tired line about Microsoft’s apparent lax security.
@ Anonymous Coward: I suggest you pick up a manual if you’ve been burnt by endless MS products. A poor workman always blames he’s tool’s.
Anyway EXCELLENT blog Bharat. Your work is valued in the Exchange community.
Keep it up.
Thanks for the feedback!
Yes, ridiculing Microsoft product security and security practices is as passé as the “I’m a Mac” ads in 2010.
I done exactly mention above. but result no changes. still internal IP Address have been display in email header. i have Exchange 2007 SP 3, HUB/CAS/Mailbox and Edge Server. if any1 have any other trick to hide internal ip address of exchange server would be grateful to guide me.
Thank and advance,
good article, thanks
My question has nothing to do with mail, but more to do with IRC. how can I hide or change my internal hostname and ip from programs like Mirc. I’ve used hotspot shield, but it doesn’t change my hostname but am sure it changes my ip. any help would be appreciated……..TY
Thank you very much!
this is really good article and i followed your instructions and got successfull result!
But now I have another trouble – How to revert it back???
Thanks in advance for any help!
Try with Get-SendConnector “Connector Name” | ADD-ADPermission -AccessRight ExtendedRight -ExtendedRights ms-Exch-Send-Headers-Routing -user “NT AUTHORITY\Anonymous Logon”
or recreate send connector and give it a different name.
In this you changed permission on one- named connector, adding the new one will create permissions from scratch. My opinion :)
This method did not work on my Exchange server. I really doubt that it can easily be done, as I have always thought.
Transport Rules for removing Received headers worked for me in earlier versions of Exchange (2007, 2010 SP1?) but had strangely stopped working after some updates.
Thanks for this post which helped me to solve the issue!
Hello Alexey,
I have the same need, but for deleting the “acceptlanguage” header field.
I’m not a pro in Exchange tech., so I deliver here my first analysis after some days of research and test (also using the PipelineTracing tool).
Thank to correct me or help me back with any feedback.
I have a SBS 2008/Exchange 2007 SP3 with Hub but no Edge server.
The common way for deleting an header field without programming transport agent or installing extra filtering tools is to implement a Transport Rule, BUT :
I think the Transport Rule effect is in this case overloaded by the “post-routing” process in the Hub server (i.e. the categorizer in the content conversion module):
– the header fields are created somewhere when constructing the mail
– the headers fields are effectively deleted after the “OnRoutedMessage” step by the “Transport Rule Agent”
– the headers fields (or some of them), are created again by the “conversion module”
So it seems that the only way is to install an Edge server (an extra tool, finally !) taking care of the outgoing mails and program similar “Transport Rule” but on the Edge.
In my case this doesn’t seem to be very compliant with SBS 2008
That’s the status of my research.
Regards
Although I agree that hiding internal headers is more “security by obscurity” I will have these things to do to shut up internal security believers ;-)
There is a tool that could help:
http://ivasoft.com/headerrewriter.shtml
At last a person that writes in words I can comprehend.
Removing Message ID results in removing message in some systems. After first message with messageId = $null all other messages from this sender will be considered as duplicate messages.
{ 2 trackbacks }