Re: FW: (REPOST) Sendmail 8.11 configuration/security issue

[<john65 () pobox com>]

<snip>
> -----Original Message-----
> From: Keith T. Morgan
> Sent: Sunday, January 05, 2003 9:55 PM
> To: john65 () pobox com; security-basics () securityfocus com
> Subject: RE: Sendmail 8.11 configuration/security issue
>
>
> <snip>
> > (What if
> > mary () xyz com wants to use her xyz.com return address when she's sending
> > mail from home to joe () xyz com via her local ISP dialup -- Why would you
> > want to block that?) What's the difference if incoming spam has one
> > forged address or another anyway? It's still spam!
>
> > 'Switching to Postfix', using a 'content security gateway,' or 'TLS' are
> > not going to solve this problem (forging of email headers).
> <snip>
>
> You are in error sir. Please check out the feature sets of eSafe
> Content Security Gateway, Network Associate's security gateway and
> others. eSafe for example does indeed check that email originates on
> the correct interface for local users. I found out that the network
> associates CSG does the exact same thing on a penetration test just
> last week when the customer explicitly asked me to attempt to send a
> false directive in email by spoofing the sender's address to an
> executive's address. Not only do the content security gateways address
> this issue, but postfix addresses it specifically. SSL/TLS would be an
> encryption mechanism protecting client authentication which would also
> defeat this problem if auth were required to send mail.

All I said was that these products will not stop the forging of email. I
didn't say that don't do other things or that they're not useful
products, or that they can't be used to allow remote users to do
authenticated relaying from untrusted networks.

> The problem as I understand it:
>
> spammer masquerading as fakeuser () yourdomain com connects to
> mail.yourdomain.com and sends a message to any recipient.
> Additionally, this would be a way for an attacker to send false
> business directives, bogus or misleading communications etc... by
> pretending to be a member of your organization. (yes, I know about
> digital signatures and 90% of the organizations out there don't use
> them, nor do people look at headers as a rule).
>
>
> All of the listed solutions prevent "spoofing" of internal email
> addresses by external resources. Authentication (via SSL/TLS) solves
> the problem of the roadwarrior using a dialup somewhere. Postfix has a
> specific configuration parameter limiting *@yourdomain.com to sending
> from a specific network.
>
> <snipped per moderator's suggestion/requirement>
> Here's some FM to R.
>
> ftp://ftp.ealaddin.com/pub/manuals/esg/esg3.x/econsole_admin.pdf See
> page 113. The sections on "ANTI SPOOFING" and "ANTI RELAY" which talk
> about how to do EXACTLY what you claim it won't do.

Sure. You could write a sendmail ruleset to prevent this too (there are
attempts of varying quality findable via groups.google.com). You can
also write sendmail rulesets to bounce all mail with 'DUCK' in the
subject line, but that won't protect you from all offensive content. My
point was that it 'breaks stuff' and it doesn't solve the problem of
forged email except maybe for a single domain, or a list of domains.
Lots of perfectly legitimate mail is floating around where the relay
doesn't 'match' the return address. How do you decide?

I'm coming from the school that says unsigned (and/or unencrypted) email
should not be used for 'business directives' anyway (for a variety of
reasons) and that's what I tell clients. I don't think it's that hard to
convice people of this. Our users aren't stupid. They just need to have
things explained to them.


> Also see:
> http://www.postfix.org/basic.html#mydomain

I think this _particular_ link speaks about relaying, not forging?

        " My own networks The mynetworks parameter lists all networks
        that this machine somehow trusts. This information can be used
        by the anti-UCE features to recognize trusted SMTP clients that
        are allowed to relay mail through Postfix. "