From owner-freebsd-security@FreeBSD.ORG Mon May 12 18:52:26 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB37237B401 for ; Mon, 12 May 2003 18:52:26 -0700 (PDT) Received: from testequity.com (postal.testequity.com [205.147.14.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C4CE43FB1 for ; Mon, 12 May 2003 18:52:26 -0700 (PDT) (envelope-from metrol@metrol.net) Received: from metlap [205.147.14.249] by testequity.com with ESMTP (SMTPD32-7.13) id AF6DE4001EC; Mon, 12 May 2003 18:50:37 -0700 From: Michael Collette To: FreeBSD Security Date: Mon, 12 May 2003 18:52:07 -0700 User-Agent: KMail/1.5.1 References: <3EC03726.105@yip.org> In-Reply-To: <3EC03726.105@yip.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305121852.07018.metrol@metrol.net> Subject: Re: [Fwd: Re: Down the MPD road] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2003 01:52:27 -0000 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