Re: Remove Internal Hops from Header

On 03/30/08 11:35, David F. Skoll wrote:
> Removal of headers is considered bad because it hampers diagnosing
> routing problems. It also gains you practically no security, so the
> Sendmail authors did not provide for header removal. If you really
> need it, a simple milter is the best way to do it.

Consider if you will an install that has an SMTP server running with in
each department that forwards to the building / campus SMTP server that
forwards to one (or more) corporate SMTP servers that then forward to
the world. There would *VERY LIKELY* be internal network structure
information exposed that probably should not be exposed.

If you compare an internal SMTP structure to either an Exchange or
GroupWise structure, you will quickly notice (amongst other things) that
SMTP will have additional Received: headers added by each SMTP server.
Where as the Exchange / GroupWise system has no such headers that appear
in the messages that leave the company. I believe it is these headers
that the OP is wanting to remove.

> Please be aware of this clause in RFC 2821:
>
> 3.8.2 Received Lines in Gatewaying
>
> When forwarding a message into or out of the Internet environment, a
> gateway MUST prepend a Received: line, but it MUST NOT alter in any
> way a Received: line that is already in the header.

I agree to this for gatewaying inbound messages. However outbound
messages do not need to contain internal Received: headers.

> If you remove an existing Received: line, you may technically be
> violating RFC 2821.

Remember that RFCs are good guidelines to be followed with in reason.
Rather RFCs are not the LAW or the BIBLE of networking. I generally try
to follow them unless I have a good reason to deviate from them.



Grant. . . .

Re: Remove Internal Hops from Header

Grant Taylor wrote:

> Consider if you will an install that has an SMTP server running with in
> each department that forwards to the building / campus SMTP server that
> forwards to one (or more) corporate SMTP servers that then forward to
> the world. There would *VERY LIKELY* be internal network structure
> information exposed

So?

> that probably should not be exposed.

Why not? Do you honestly think that pretending your internal network
structure is "secret" will actually hamper anyone?

> If you compare an internal SMTP structure to either an Exchange or
> GroupWise structure, you will quickly notice (amongst other things) that
> SMTP will have additional Received: headers added by each SMTP server.
> Where as the Exchange / GroupWise system has no such headers that appear
> in the messages that leave the company. I believe it is these headers
> that the OP is wanting to remove.

So Sendmail is RFC compliant and Exchange and Groupwise are not. Color
me surprised.

> I agree to this for gatewaying inbound messages. However outbound
> messages do not need to contain internal Received: headers.

.... until the day you have a mail loop and try to diagnose it.

>> If you remove an existing Received: line, you may technically be
>> violating RFC 2821.

> Remember that RFCs are good guidelines to be followed with in reason.
> Rather RFCs are not the LAW or the BIBLE of networking.

Violating a MUST NOT clause of an RFC is pretty drastic. I do not
think you have enough justification for doing it. RFCs are the *only*
documents that ensure interoperability and violating them just for fun
will lead to chaos.

By the way, e-mails I send go from shishi.roaringpenguin.com (192.168.2.3)
to vanadium.roaringpenguin.com (192.168.10.23) to www.roaringpenguin.com
(206.191.13.82) to the Internet. Now that you know my internal network
structure... am I more vulnerable than before?

Regards,

David.

Re: Remove Internal Hops from Header

On 3/31/2008 9:51 PM, David F. Skoll wrote:
> So?

*sigh*

If you can not (or chose not) to understand why someone might not want
to expose (some of) their internal network structure via extra Received:
headers, I can not explain it to you.

> Why not? Do you honestly think that pretending your internal network
> structure is "secret" will actually hamper anyone?

If "secret" means not advertising your internal structure, and "anyone"
means more than experienced crackers with a vast tool box all the way
down to script kiddies that drop a .eml file on to a utility, then in a
word "Yes". Is removing extra Received: headers that critical of a
security measure, no. Does it expose some information that would likely
other wise not be exposed, yes. Thus not exposing it does help security.

> So Sendmail is RFC compliant and Exchange and Groupwise are not.
> Color me surprised.

Ok, I'll bite and ask. How is Exchange and GroupWise not RFC compliant
when they are running internal protocols (X.400 for Exchange) that (to
the best of my knowledge) do not have the equivalent of Received:
headers. In other words, how are they breaking RFC by not adding
something they do not have. When messages originate internally and go
out to the world, the first header you will see is the first receiving
SMTP server, the one that got it from Exchange / GroupWise. Likewise
the last Received: header you will see on an inbound message is the edge
SMTP gateway. Thus these systems have no way to expose internal structure.

Think out side of SMTP.

> ... until the day you have a mail loop and try to diagnose it.

There are ways to detect mail loops other than with Received: headers.

> Violating a MUST NOT clause of an RFC is pretty drastic. I do not
> think you have enough justification for doing it. RFCs are the
> *only* documents that ensure interoperability and violating them just
> for fun will lead to chaos.

Whether the OP or I have enough justification or not is up to us. If we
are willing to remove or never add Received: headers on outbound
messages and deal with the ramifications for doing such (having to
detect mail loops other ways with in our systems) I see no reason why we
can not or should not remove / not add the headers.

Will you please list one or two other reasons (other than "breaking RFC'
and "mail loop detection") why removing / not adding internal Received:
headers is bad?

Yes RFCs are a very strongly suggested guide to inter operate with
others. However I fail to see how not having Received: headers from
internal mail servers will make our systems any less inter operable with
others seeing as how we are speaking the same (E)SMTP that we would as
if the headers were still there.

> By the way, e-mails I send go from shishi.roaringpenguin.com
> (192.168.2.3) to vanadium.roaringpenguin.com (192.168.10.23) to
> www.roaringpenguin.com (206.191.13.82) to the Internet. Now that you
> know my internal network structure... am I more vulnerable than
> before?

Are you more vulnerable? That is tough to say. Presuming that you were
truthful, I do have more information about your internal structure and
information that I would very likely use in an attack (if I did such
things).

Based on the headers from a message you sent me the other day, I'm
deducing / predicting the following:
- ShiShi is your workstation that you sent the emails from. I know
this based on what you have said which agrees with the headers in your
message. You did not do any thing to hide or mis-represent your
Received: headers did you???
- Vanadium is an edge SMTP server that has directly routable access to
the 192.168.2.x network.
- Vanadium is connected to a generic internet connection on the
64.26.171.x network with a extremely generic looking reverse DNS.
- Vanadium is (or did) use www as a smart host, which would make sense
considering the generic looking reverse DNS.

In short, if you (and everyone else in between) are not firewalling for
spoofed packets, chances are good that I could send packets to Vanadium
spoofing ShiShi as the source IP and the replies would end up being
passed in to ShiShi. Can I use this to directly exploit any thing? I'm
not talented enough to say one way or the other. However the point
being that I do already have some information on your internal network
structure. I also have some network ranges to start throwing scans at
to see what will and will not get through. Now you are dependent on a
firewall to stop my traffic. Where as if you had not given the traffic
out in the first place I would be that far behind where I am now.

Oh, ya, WWW is not adding any indication of authentication from
Vanadium. So if I were an energetic spacker, I would be tempted to
analyze the SMTP transaction with WWW so that I could predict the
expected packets. If I can successfully predict the expected packets, I
can possibly send them with the spoofed IP of Vanadium and rely traffic
through your server.

Just think about how much harder it would be for me to exploit your
systems if I did not have any thing other than the Received: header
added by my server indicating that it received the message from www.



Grant. . . .

Re: Remove Internal Hops from Header

Grant Taylor wrote:

> *sigh*

> If you can not (or chose not) to understand why someone might not want
> to expose (some of) their internal network structure via extra Received:
> headers, I can not explain it to you.

I can understand perfectly why someone might *want* to hide that information.
I can also understand perfectly that it's *stupid* to think that hiding
the information actually makes you more secure.

> Ok, I'll bite and ask. How is Exchange and GroupWise not RFC compliant
> when they are running internal protocols (X.400 for Exchange) that (to
> the best of my knowledge) do not have the equivalent of Received:
> headers.

Sorry; I misread your post.

> There are ways to detect mail loops other than with Received: headers.

Received: headers are the *standard* way. Some of us think standards
actually matter.

> Will you please list one or two other reasons (other than "breaking RFC'
> and "mail loop detection") why removing / not adding internal Received:
> headers is bad?

If you don't think breaking RFC: and mail-loop detection/prevention
are good enough reasons... then fine; we are at an impasse.

>> By the way, e-mails I send go from shishi.roaringpenguin.com
>> (192.168.2.3) to vanadium.roaringpenguin.com (192.168.10.23) to
>> www.roaringpenguin.com (206.191.13.82) to the Internet. Now that you
>> know my internal network structure... am I more vulnerable than
>> before?

> Are you more vulnerable? That is tough to say. Presuming that you were
> truthful, I do have more information about your internal structure and
> information that I would very likely use in an attack (if I did such
> things).

I call bullshit.

> Based on the headers from a message you sent me the other day, I'm
> deducing / predicting the following:
> - ShiShi is your workstation that you sent the emails from. I know
> this based on what you have said which agrees with the headers in your
> message. You did not do any thing to hide or mis-represent your
> Received: headers did you???

That's right.

> - Vanadium is an edge SMTP server that has directly routable access to
> the 192.168.2.x network.

Ehm... not exactly.

> - Vanadium is connected to a generic internet connection on the
> 64.26.171.x network with a extremely generic looking reverse DNS.

Yep.

> - Vanadium is (or did) use www as a smart host, which would make sense
> considering the generic looking reverse DNS.

Yep.

> In short, if you (and everyone else in between) are not firewalling for
> spoofed packets, chances are good that I could send packets to Vanadium
> spoofing ShiShi as the source IP and the replies would end up being
> passed in to ShiShi.

Go ahead and try. shishi and vanadium both have private IP addresses,
so if you pull that trick off, I will be most impressed.

> Can I use this to directly exploit any thing? I'm
> not talented enough to say one way or the other. However the point
> being that I do already have some information on your internal network
> structure. I also have some network ranges to start throwing scans at
> to see what will and will not get through.

On a 192.168 address? Good luck. On the 64.26.171 address? That's
a public IP address anyway that you could find pretty quickly with
other means.

> Oh, ya, WWW is not adding any indication of authentication from
> Vanadium. So if I were an energetic spacker, I would be tempted to
> analyze the SMTP transaction with WWW so that I could predict the
> expected packets. If I can successfully predict the expected packets, I
> can possibly send them with the spoofed IP of Vanadium and rely traffic
> through your server.

Mmm... yeah... go ahead and try. :-) Good luck...

> Just think about how much harder it would be for me to exploit your
> systems if I did not have any thing other than the Received: header
> added by my server indicating that it received the message from www.

Once again, I call BS. The exploits you mentioned are completely
infeasible.

Regards,

David.

Re: Remove Internal Hops from Header

On 04/01/08 09:59, David F. Skoll wrote:
> I can understand perfectly why someone might *want* to hide that
> information. I can also understand perfectly that it's *stupid* to
> think that hiding the information actually makes you more secure.

I believe (my opinion) that each and every little thing that you do to
not expose information on top of all other security measures makes you a
little bit more secure by making you a harder target to hit. We are
both human and allowed to have different opinions. For now I think we
can both agree to disagree and move forward.

> Sorry; I misread your post.

I figured as much which is why I restated. There may be some stinky
opinions flying back and forth, but seeing as how there are no insults,
we can still discuss / debate / banter back and forth until one or the
other of us gets tired of this thread.

> Received: headers are the *standard* way. Some of us think standards
> actually matter.

I'll agree that Received: headers are the standard way to do it on the
open internet where SMTP is the standard protocol. However inside of
closed environments, where SMTP is optional, so is said method of
detecting loops.

> If you don't think breaking RFC: and mail-loop detection/prevention
> are good enough reasons... then fine; we are at an impasse.

I do not believe that removing Received: headers from outbound messages
at the SMTP edge of a network breaks mail-loop detection/prevention like
you are saying. However I am interested in having a discussion where
one or the other or both of us proposes our scenarios where things will
work and have the other poke holes in it if you are as well.

> I call bullshit.

If you have not altered or provided mis-information in your headers,
then I do indeed have some information about your set up. How useful
that information is can not be determined by its self. But I do still
have some purported information.

> That's right.

*nod*

> Ehm... not exactly.

Vanadium may not be an edge SMTP like I said, but I'm still sticking to
the fact that it appears that it has directly routable access to the
192.168.2.x network.

> Yep.

*nod*

> Yep.

*nod*

> Go ahead and try. shishi and vanadium both have private IP
> addresses, so if you pull that trick off, I will be most impressed.

Adding that tidbit of information I'm guessing that there is a NATing
firewall between Vanadium and the internet that I would have to get
through if I was to attack from the internet its self. However I do
have more information. Again the viability of the information is still
questionable.

> On a 192.168 address? Good luck. On the 64.26.171 address? That's
> a public IP address anyway that you could find pretty quickly with
> other means.

I can not directly attack your private range IP addresses. However I
could see how good your NATing firewall is. I wonder how much of a
reflected attack would get in. (Again, I'm just thinking out loud as I
will *NOT* do any of these things.)

> Mmm... yeah... go ahead and try. :-) Good luck...

I will do some more thinking about this and contact you off list if I am
more interested and you are willing to participate in a test (can I send
my someone a "Hello World" message or not).

> Once again, I call BS. The exploits you mentioned are completely
> infeasible.

Depending on what other forms of security you have in place, the things
I've mentioned may indeed be completely infeasible. How good is your
defense against social engineering? What about others in your house?
What would I gain if something was run from with in your network knowing
what you have exposed via your Received: headers and this news group?

To me, these are all crumbs along a long trail that can be used to help
exploit someone. My simple opinion is that not leaving (exposing) these
crumbs (Received: headers) does indeed provide some (limited) additional
security by making you much harder to find and attempt to exploit.

> Regards

Thank you for taking the time to respond politely with decent though out
facts / opinions in a non insulting manner (unlike some other posters in
this group as of late).



Grant. . . .

Re: Remove Internal Hops from Header [mail loops detection]

Grant Taylor wrote:

> On 04/01/08 09:59, David F. Skoll wrote:
>> [...]
>> If you don't think breaking RFC: and mail-loop detection/prevention
>> are good enough reasons... then fine; we are at an impasse.
>
> I do not believe that removing Received: headers from outbound
> messages at the SMTP edge of a network breaks mail-loop
> detection/prevention like you are saying. However I am interested in
> having a discussion where one or the other or both of us proposes our
> scenarios where things will work and have the other poke holes in it
> if you are as well.

I have seen "two hops" mail loops with smart host sending back to
sending host. It makes me suggest replacing "removing in full" with
"removing protected data from headers".

> [...]

--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl sip:896530@fwd.pulver.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick

Re: Remove Internal Hops from Header [mail loops detection]

On 04/01/08 13:14, Andrzej Adam Filip wrote:
> I have seen "two hops" mail loops with smart host sending back to
> sending host. It makes me suggest replacing "removing in full" with
> "removing protected data from headers".

Ok, I think I can go along with that.

If I may, let me suggest an example for discussion.

Received: from edgesmtp.receiver.com ...
by mailstore.receiver.com ...
Received: from smtp.company.com ...
by edgesmtp.receiver.com ...
Received: from smtp.department.company.com ...
by smtp.company.com ...
Received: from smtp.workgroup.department.company.com ...
by smtp.department.company.com ...
Received: from workstation.workgroup.department.company.com ...
by smtp.workgroup.department.company.com ...

Please show me (us) what you are recommending be done with the above
Received: headers.

....

What I'm proposing is that smtp.company.com remove (and log) the first
(bottom) three Received: headers from outbound messages. This way,
recipients out side of company.com will see the following Received: headers.

Received: from edgesmtp.receiver.com ...
by mailstore.receiver.com ...
Received: from smtp.company.com ...
by edgesmtp.receiver.com ...

Note that only messages leaving company.com would have their extra
Received: headers removed. Messages staying with in the company would
still have all the Received: headers in tact. I.e.

Received: from smtp.workgroup.differentdepartment.company.com ...
by test.workgroup.differentdepartment.company.com ...
Received: from smtp.differentdepartment.company.com ...
by smtp.workgroup.differentdepartment.company.com ...
Received: from smtp.department.company.com ...
by smtp.differentdepartment.company.com ...
Received: from smtp.workgroup.department.company.com ...
by smtp.department.company.com ...
Received: from workstation.workgroup.department.company.com ...
by smtp.workgroup.department.company.com ...



Grant. . . .

Re: Remove Internal Hops from Header [mail loops detection]

Grant Taylor wrote:

> On 04/01/08 13:14, Andrzej Adam Filip wrote:
>> I have seen "two hops" mail loops with smart host sending back to
>> sending host. It makes me suggest replacing "removing in full" with
>> "removing protected data from headers".
>
> Ok, I think I can go along with that.
>
> If I may, let me suggest an example for discussion.
>
> Received: from edgesmtp.receiver.com ...
> by mailstore.receiver.com ...
> Received: from smtp.company.com ...
> by edgesmtp.receiver.com ...
> Received: from smtp.department.company.com ...
> by smtp.company.com ...
> Received: from smtp.workgroup.department.company.com ...
> by smtp.department.company.com ...
> Received: from workstation.workgroup.department.company.com ...
> by smtp.workgroup.department.company.com ...
>
> Please show me (us) what you are recommending be done with the above
> Received: headers.

As I understand the minimum Received: header must contain:
Received: "from" host "by" host ; date

0) I suggest leaving date as it is (may be stripping seconds part)
1) removing any IP address info
2) replacing "real names" with "function names" or
"salted" CRC/md5/... codes

I think it should satisfy "non military grade" requirements :-)

> ...
>
> What I'm proposing is that smtp.company.com remove (and log) the first
> (bottom) three Received: headers from outbound messages. This way,
> recipients out side of company.com will see the following Received:
> headers.
>
> Received: from edgesmtp.receiver.com ...
> by mailstore.receiver.com ...
> Received: from smtp.company.com ...
> by edgesmtp.receiver.com ...
>
> Note that only messages leaving company.com would have their extra
> Received: headers removed. Messages staying with in the company would
> still have all the Received: headers in tact. I.e.
>
> Received: from smtp.workgroup.differentdepartment.company.com ...
> by test.workgroup.differentdepartment.company.com ...
> Received: from smtp.differentdepartment.company.com ...
> by smtp.workgroup.differentdepartment.company.com ...
> Received: from smtp.department.company.com ...
> by smtp.differentdepartment.company.com ...
> Received: from smtp.workgroup.department.company.com ...
> by smtp.department.company.com ...
> Received: from workstation.workgroup.department.company.com ...
> by smtp.workgroup.department.company.com ...

An alternative "loop prevention" methodology may place/detect special
"magic marks" in preserved/generated "received:" headers and treat such
marks in incoming mail as loop indicators.

--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl sip:896530@fwd.pulver.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
Hark ye, Clinker, you are a most notorious offender. You stand convicted of
sickness, hunger, wretchedness, and want.
-- Tobias Smollet

Re: Remove Internal Hops from Header [mail loops detection]

On 04/01/08 14:04, Andrzej Adam Filip wrote:
> As I understand the minimum Received: header must contain:
> Received: "from" host "by" host ; date
>
> 0) I suggest leaving date as it is (may be stripping seconds part)
> 1) removing any IP address info
> 2) replacing "real names" with "function names" or
> "salted" CRC/md5/... codes
>
> I think it should satisfy "non military grade" requirements :-)

Agreed.

Sorry, let me clarify, I was not wanting to alter the field with in the
Received: header, I was just using "..." because I did not want to type
all the other information in the examples. All I'm wanting to do is
remove specific Received: headers, not modify the contents of any of the
headers.

> An alternative "loop prevention" methodology may place/detect special
> "magic marks" in preserved/generated "received:" headers and treat such
> marks in incoming mail as loop indicators.

Agreed.



Grant. . . .

Re: Remove Internal Hops from Header [mail loops detection]

Grant Taylor wrote:

> On 04/01/08 14:04, Andrzej Adam Filip wrote:
>> As I understand the minimum Received: header must contain:
>> Received: "from" host "by" host ; date
>>
>> 0) I suggest leaving date as it is (may be stripping seconds part)
>> 1) removing any IP address info
>> 2) replacing "real names" with "function names" or "salted"
>> CRC/md5/... codes
>>
>> I think it should satisfy "non military grade" requirements :-)
>
> Agreed.
>
> Sorry, let me clarify, I was not wanting to alter the field with in
> the Received: header, I was just using "..." because I did not want to
> type all the other information in the examples. All I'm wanting to do
> is remove specific Received: headers, not modify the contents of any
> of the headers.
>
>> An alternative "loop prevention" methodology may place/detect
>> special "magic marks" in preserved/generated "received:" headers and
>> treat such marks in incoming mail as loop indicators.
>
> Agreed.

*My* stance is that
1) modifying/removing "*internal*" received: header should be avoided
even at high cost but not at any cost
2) *IF* anybody wants to do it against good advises *AND* RFC "MUST NOT"
recommendations *THEN* I am ready to give advises how to avoid some
easy to predict potential problems

--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl sip:896530@fwd.pulver.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
Writing about music is like dancing about architecture.
-- Frank Zappa