Re: [logs] Re: Reliably detecting things like the SQL worm.... (p rotection for those "other" networks)

From: Bennett Todd (betat_private)
Date: Wed Jan 29 2003 - 10:54:22 PST

  • Next message: Daniele Muscetta: "[logs] Novell logs"

    2003-01-28T15:48:38 Ogle Ron (Rennes):
    > For those of you who incorporate an architecture like was
    > described from Nate [ out-of-band management net ], how do you
    > make sure that the "middle" or "back" network is not used as a
    > conduit for a compromised system to compromise other systems?
    I've seen two approaches taken as extreme positions, as well a
    hybrids using a mix of approaches.
    For the population of machines which can be perfectly hardened ---
    all unnecessary services completely disabled, necessary services
    engineered and maintained to prevent them from being successfully
    attacked, and configured to refuse to even attempt to process any
    traffic other than that from required machines (host packet
    filtering is a big help here), you can use an open net with little
    fear that it will be used to propogate evil; all you need to do is
    wire the switches to refuse mac addr forging (relatively easy for
    this sort of net, where changes are rare, and they're mostly
    additions and not moves --- switches can automate the case of
    additions by learning one, and only one, non-conflicting MAC addr
    per port and refusing to let it change after). Switch mac-addr
    enforcement combined with hardwired ARP tables in hosts for the one
    or two hosts they are willing to accept traffic from pretty much
    closes out the interesting attacks. This sort of stuff isn't so
    practical in complex and fluid in-house nets, for desktop farms or
    application server farms or whatnot, but for the service machines
    for an internet DMZ architecture it is practical and worthwhile.
    Another approach is a "fully-routed net", where the "hub" is a
    firewall with a separate port for each machine. For small DMZs
    this can be done with a simple PC with a lot of quad 100baseT
    interfaces.  For a larger plant, today you can pull it off by
    carefully configuring a modern switch with up-to-date firmware to
    use one VLAN-per-port, and 802.11q trunking that to your firewall
    machine.  This is arguably more fragile, since configuration errors
    can more easily open vulnerabilities, and it didn't use to be safe,
    there used to be bugs in switches that rendered this protection
    vulnerable to attack. But switch vendors have responded to customer
    demand to be able to do this sort of jiggerypokery, and at least
    some of them support this, and will accept a description of a
    newly-discovered bug allowing bypass of such vlan+trunking barriers
    as a high-priority security bug to be addressed promptly.
    It is the case that such management nets do require careful thought,
    lest they become infection transport vectors.

    _______________________________________________ LogAnalysis mailing list LogAnalysisat_private

    This archive was generated by hypermail 2b30 : Wed Jan 29 2003 - 23:03:24 PST