freebsd security - May 2003 - [Fwd: Re: Down the MPD road]

Made a typo in the cc: line.  Coffee time, I guess.

-------- Original Message --------
Date: Mon, 12 May 2003 19:52:17 -0400
From: Bob K <melange@yip.org>
To: Michael Collette <metrol@metrol.net>
CC: freebsd.-security@freebsd.org
Subject: Re: Down the MPD road

 > I did this, and it does correct the immediate problem.  Of course, it
 > also
 > creates a new glitchy.
 >
 > My mail server sits in the DMZ, which is of course on a different
 > subnet than
 > the secure network.  I'm bringing in those outside users directly into
 > the
 > secure network, as they very definitely need resources from there.
 >
 > Without being able to configure routing from the secure network, those
 > users
 > can't route to the DMZ.  In that DMZ I have pop3 and ldap restricted
to
 > internal use only, while SMTP is opened up wide.  The problem
 > compounds a bit
 > when dealing with SMTP securities which is presently configured to
 > restrict
 > relaying to only those IPs that we own.
 >
 > So, the firewall prevents pop3 and ldap, while the mail server itself
 > restricts the relaying.  Unless the user is able to route to this
 > server via
 > the internal network this dog just don't hunt.
 >
 > Is there perhaps some part of this I'm missing?

Workaround: Take a box inside the secure network and have it NAT mail &
LDAP connections from the MPD'd range to the mail server.  Then have
your MPD'd users use that box.

You can use ipfw+natd to do this; something like:

natd -redirect_address ma.il.ser.ver 0.0.0.0

ipfw add divert 8668 tcp from mpd.ra.ng.es/bits to int.er.nal.ip \
25,110,389 in recv enet0

ipfw add divert 8668 tcp from ma.il.ser.ver 25,110,389 to int.er.nal.ip
in recv enet0

If resources aren't scarce, you could even use the box that's running
mpd to do it.

(if anyone can spot problems with this aside from the accounting
difficulties, please let me know)

A better solution, methinks, would be an internal mail/ldap server in
the secure range, with the one in the DMZ doing nothing but relaying
mail to/from the internal network.

On Monday 12 May 2003 05:07 pm, Bob K wrote:
> Made a typo in the cc: line.  Coffee time, I guess.
Oh boy, this mail had me running for the coffee pot.
>  > Is there perhaps some part of this I'm missing?
>
> Workaround: Take a box inside the secure network and have it NAT mail &
> LDAP connections from the MPD'd range to the mail server.  Then have
> your MPD'd users use that box.
>
> You can use ipfw+natd to do this; something like:
>
> natd -redirect_address ma.il.ser.ver 0.0.0.0
>
> ipfw add divert 8668 tcp from mpd.ra.ng.es/bits to int.er.nal.ip \
> 25,110,389 in recv enet0
>
> ipfw add divert 8668 tcp from ma.il.ser.ver 25,110,389 to int.er.nal.ip
> in recv enet0
>
> If resources aren't scarce, you could even use the box that's
running
> mpd to do it.
It seems I've run into a false alarm.  Turns out the user's mail box on
the
server had a dinked message which wouldn't let him pull down.  Once I fixed 
the dinked message, all was well.  Even without having remote gateway 
enabled.

A bit of a concern here, as by all reasoning it shouldn't be able to hop the
subnet without some way to route the packets.  Seems like this is the part in 
a How-To where "something magical happens" to the packets.

Your mail did get me thinking that it might work out a bit more securely to 
have mpd running in a jail either on the gateway or on a box behind.  I can 
definitely see where you're going with your suggestion, and even though it 
doesn't seem needed now, it might still be a worthwhile lockdown to look 
into.
> (if anyone can spot problems with this aside from the accounting
> difficulties, please let me know)
>
> A better solution, methinks, would be an internal mail/ldap server in
> the secure range, with the one in the DMZ doing nothing but relaying
> mail to/from the internal network.
I do have plans to do something very similar to this in the very near future.  
I was considering having pop3 running in the DMZ with fetchmail bringing in 
from there to a server in the secure network running IMAP.  SMTP would have 
to remain in the DMZ in order to get a proper reverse DNS for them pickier 
servers out there though.

If there's a more creative means for doing this I would LOVE to hear about
it.
That, or what other folks might consider best practices for placement of the 
mail server within the topography.

Thanks again for a creative idea here.

Later on,
-- 
"Outside of a dog, a book is man's best friend. Inside of a dog,
it's too dark
to read."
 - Groucho Marx