[logs] Re: Reliably detecting things like the SQL worm....

From: Bennett Todd (betat_private)
Date: Mon Jan 27 2003 - 06:12:00 PST

  • Next message: Rainer Gerhards: "[logs] SQL Slammer Learnings"

    2003-01-26T16:53:00 Chris Adams:
    > The biggest lesson is simply network structure:
    Hear, hear!
    > if you have all of your control and logging going over the same
    > network (or a VLAN without some sort of prioritization or reserved
    > bandwidth), you're screwed.
    Now _that_ I'm less completely in agreement with.
    Rather, I'd say that you need to stay on top of security; anybody
    who had any MS-SQL servers anywhere approaching visible from the
    internet wasn't paying attention to basics.
    And you do not enable multicast routing on routers that you care
    about having resistent to DoS, another lesson that people should
    already have nailed, if only because previous worms also trashed
    routers when they randomly zinged multicast addrs.
    If you really are such a gamer or whatever that you need multicast
    to and from the internet, you've got various choices. You can just
    acknowlege that your internet access is easy to DoS and be done with
    it. Or you can provision completely separate connectivity transiting
    totally distinct routers for the multicast -vs- your regular
    internet traffic. Or, you can achieve a similar effect by colocating
    a multicast endpoint at some friendly providers' well-connected
    internet space, and encapsulating (e.g. GRE) the multicast from
    there to a special, isolated, termination point within your
    internet-facing plant.
    Totally segregated logging and/or admin LANs are a nice luxury,
    and in some contexts they're justifiable, but they aren't the
    only way to do things; you can set your sights lower (in terms of
    functionality) and refrain from doing things that are risky --- like
    allowing direct internet access to MS-SQL server, or supporting
    multicast routing to and from the internet along your primary
    internet access path.
    Now I won't deny that anything can be DoSed, but if you've designed
    your net to be as tough as practical, you'll capture enough info
    before the DoS is complete to perform diagnosis, and you'll retain
    enough ability to use your machines to recover over the net --- it's
    _easy_ to provision many orders of magnitude more LAN bandwidth than
    you get internet bandwidth, so you just need to be careful not to
    offer multipliers to attackers.

    _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis

    This archive was generated by hypermail 2b30 : Mon Jan 27 2003 - 09:04:56 PST