[Fwd: Re: Down the MPD road]

From: Bob K (melange_at_yip.org)
Date: 05/13/03

  • Next message: Michael Nottebrock: "Re: xdelta files for security patches" 
    Date: Mon, 12 May 2003 20:07:02 -0400
To: freebsd-security@freebsd.org

    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.

    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"

  • Next message: Michael Nottebrock: "Re: xdelta files for security patches"

    Relevant Pages

    • RE: Physical vs. Virtual iface device vulnerability
      ... anyone who compromises your mail server gets complete ... With resolution A, they get only SQL ... > outside my internal network with its own firewall in place. ... > server an internal ip address and set up connection to MySQL ...
      (Security-Basics)
    • Re: Mail server security - best practices?
      ... The mail server in the DMZ does not need to have access to port 25 on ... As a stateful firewall, pf can be ... Is it because email is "quantified" when moved to the internal network? ...
      (comp.unix.bsd.openbsd.misc)
    • Re: need help setting a rule for ftp
      ... > serves as my firewall, mail server, and web server. ... If eth0 connects to your ... internal network, you'd do this (for iptables, though -i exists in iptables ...
      (comp.os.linux.security)
    • clamav and snat
      ... I use postfix+mailscanner on my mail server to block a lot of ... virii comming from my internal network. ... WIN are on the internal network. ... An ideea would be to extract mail traffic passing through GW1 in mbox ...
      (freebsd-isp)