OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: CIDR blocks & relay security...
From: Wietse Venema (wietseporcupine.org)
Date: Sat Dec 09 2000 - 11:10:48 CST

I'll think about it.

This discussion cannot screw up my code freeze and release plan.
I am in the middle of releasing a snapshot this weekend.

This weekend's snapshot involves about 100 pages of context diffs
than I am currently reviewing.

These are some of the files affected when mynetworks is set to /32.

    RELEASE_NOTES document the incompatible mynetworks change
    HISTORY document change of default configuration
    RELAY_README (new) document how to set up a relaying server
    conf/main.cf update text, examples, defaults
    conf/sample-smtpd.cf update text, examples, defaults
    html/uce.html note that mynetworks needs change on mail relay
    html/basic.html note that mynetworks needs change on mail relay
    html/faq.html update mail hub/firewall/etc examples
    html/faq.html new "postfix won't relay for local systems"
    global/mynetworks.c implement the change

As you see, changing mynetworks involves an order of magnitude more
than just editing a trivial C file.

As you will understand, that is a lot of change that won't be
included in this weekend's snapshot.

However, there is more. If the default is not to relay mail from
any other machine, then the above change does only half the work,
as Postfix will still relay on the basis of the client hostname.
One would also have to change the relay_domains default setting.
That involves changes to:

    global/mail_params.h implement the change

Plus changes to EVERY text file that references the relay_domains
parameter and what the default setting does.

And as if that is not enough, if we're changing the relay control
model, then why not take the opportunity to do a proper job and
eliminate check_relay_domains and friends in favor of something
better.

        Wietse

Brad Knowles:
> Folks,
>
> I've been following this discussion. I don't want to get down
> into a rat hole of quoting specific long sequences of exchanges ad
> nauseum, but I think that there is a valid point here.
>
> It is no longer possible to determine what a "safe" range of
> IP address is to allow for relaying, because the old class model
> of IP addresses no longer applies. You can't even look at interface
> netmasks, because you can subnet CIDR blocks.
>
>
> So, as I see it, there are two choices:
>
> 1. Continue to make the same guesses as are done today,
> and accept that this will occasionaly get the guess
> wrong, and either refuse to relay in circumstances when
> it should, or accidentally act as an open relay in
> circumstances when it should not.
>
> However, in this case, I think you have to abandon the
> claim that postfix is secure out-of-the-box.
>
> 2. Avoid making guesses any more, although you do know
> that you can always safely relay anything that came
> from the machine itself.
>
> In this case, you have to abandon the idea that postfix
> will "just work" out-of-the-box, and instead accept
> that this will always be something that will have to
> be manually updated by the administrator when they
> originally install postfix.
>
> As we know, security and ease-of-use are frequently in direct
> opposition to each other. IMO, this is yet another case that proves
> the point.
>
>
> Since CIDR blocks make it impossible to what you can and cannot
> securely relay, IMO you shouldn't be trying to second-guess the
> admin. It's their responsibility to configure their machine(s)
> correctly -- you can do everything you can to help them, but there
> are just some things you can't do for them.
>
> If they don't update their "mynetworks" setting correctly, then
> it's their own fault of the machine refuses to act as a relay in
> situations where they want it to.
>
>
> The truly amazing thing about this situation is that we didn't
> discover this problem sooner. CIDR blocks have been around for
> years, and I presume that the offending code has been around a
> while.
>
> I wonder how many other postfix servers out there are actually
> acting as open relays for networks they don't own, due to mistaken
> guesses that this code has made? Maybe we need to think about
> contacting the CERT-CC to make them aware of this issue?
>
>
> I'd really hate for it to come to this, and I'd hate to be the
> guy to notify them of a potential problem with the code in postfix,
> but I think that this is a very serious security issue, and needs
> to be addressed.
>
> It would be best if the code can be fixed first, and then the
> appropriate notices sent out later, so that people can just update
> to the latest version and be secure. The alternative is alerting
> the junkmailers to this issue and having them start actively
> searching for broken postfix servers in certain networks where the
> default guesses are likely to be too broad.
>
> However, if push comes to shove, I have no compunctions whatsoever
> about playing the heavy and contacting the guys at CERT-CC.
>
>
>
> Wietse, the ball is in your court -- do you want postfix to be
> secure out-of-the-box, or do you want it to be able to "just work"
> out-of-the-box?
>
> -Brad
>
>
>