Re: Public / private IP addresses

From: Nate Duehr (nate_at_natetech.com)
Date: 12/31/03

  • Next message: Michel Dänzer: "Concurrent sound playback without a sound server" 
    To: Antony Gelberg <antony@antgel.co.uk>, debian-user <debian-user@lists.debian.org>
Date: Wed, 31 Dec 2003 11:16:14 -0700

    On Monday 29 December 2003 04:43 am, Antony Gelberg wrote:

    > But if they wanted to run a public email server as well, clearly that
    > needs a public IP address. Fine, but how does the routing aspect
    > work? Do I need to ditch the bridging configuration on the firewall
    > and reconfigure it as a router with 3 NICs? One connected to the
    > WAN, one to the private LAN switch, and one to the public server(s)
    > switch?

    There are a number of ways to accomplish what you're looking to do.
    Agreed, for your current setup your bridged firewall is probably a nice
    way to do things.

    The three port bridged environment looks tricky to implement correctly,
    and while it could be done, it'll probably long-term be more trouble
    than it's worth.

    Some folks gave you some other options, which were definitely "workable"
    but mix your public and private traffic. If you trust your switches to
    keep that traffic separate even under the load of a DoS attack, that
    might be a reasonable way to go.

    I like to think in terms of "what MUST be up and running for this to
    work" and engineer the network accordingly. For example, if you were
    to move the mail server completely OUTSIDE the firewall (put a switch
    between the DSL router and the firewall and hang the mail server off of
    that) and then if you're careful and harden the box, you can just place
    it directly on a public IP and run a host-based iptables firewall and
    say maybe snort to keep an eye on suspicious traffic to it.

    Why do this? Well, perhaps one reason is that if the firewall is down,
    the mail is still up and getting deliveries. The DSL router and a
    switch are an order of magnitude more "robust" than the firewall which
    could be down for upgrades, etc. Think "maintenance".

    The "just put a public address inside the firewall" works fine too but
    could create havok if the mail server is attacked or heavily loaded...
    affecting overall network performance for the clients already on the
    private-side network.

    Port-forwarding would be my least likely pick because it puts public
    traffic directly on the internal IP range. I don't like that idea at
    all if it can be avoided. I have used it in the past for a
    quick-and-dirty solution to get something working that was originally
    an "internal only" application that suddenly needs to have a worldwide
    presence, but that's definitely not my proudest "security decision"
    I've ever had to make.

    It's all about risk-management and load-management and documenting the
    possible solutions and then picking one for a reason... going through
    that process will also point out the negatives of any particular setup
    and will allow you to know more fully where your system has weaknesses.

    Have fun, 

    -- 
Nate Duehr, nate@natetech.com
-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: Michel Dänzer: "Concurrent sound playback without a sound server"