RE: Patching

From: Graydon McKee (graydon.s.mckee.iv_at_orcmacro.com)
Date: 10/22/03

  • Next message: Golden_Eternity: "RE: POP3 passwords"
    To: "'Ansgar -59cobalt- Wiechers'" <bugtraq@planetcobalt.net>, <security-basics@securityfocus.com>
    Date: Wed, 22 Oct 2003 15:41:24 -0400
    
    

    I'm getting into this discussion a bit late here but I thought I'd put
    my two cents in.

    There seems to be at least 5 or 6 new vulnerabilities released on
    BUGTRAQ or similar mailing lists daily. As information security people,
    or just regular systems administrators for that matter, we need to keep
    on top of each of these to see if they apply to the systems we control.
    Look at all the worms and viruses that have come out that exploit
    vulnerabilities that have been known about for months or sometimes even
    years. Without patching our systems we are not only open to the newer
    crop of vulnerabilities but all the old ones as well.

    If you have a concern about a system being vulnerable then you can take
    a couple of steps. Turn off every service you don't need running on a
    given system. Decide what is mission critical and turn off everything
    else. If you are not sure what services you need, turn them off and see
    what breaks. I know that is sometimes easier said than done. If your
    UNIX based machine has the sendmail daemon enabled and its not acting as
    a mail server - turn it off. If Mail is sent out from that machine the
    mail client runs the sendmail executable directly from the disk it
    doesn't need the daemon running. Set a cron job to periodically process
    the queue or drop the -bd switch from the boot script but its something
    that can be turned off.

    Once you have everything turned off that you don't need then take a look
    at those patches you need for what you do have running. Install those
    patches and make note of the patches for the services you turned off
    incase you ever need to turn them back on again.

    The point is that you still need to pay attention to patches. If your
    system is exploited and damage is actually done, the excuse that you
    didn't patch it because you thought it could have caused a problem
    doesn't hold water. Do a full backup and then patch the system. If it
    breaks then restore your backup and your back to square one.

    Just my two cents.

    Graydon S McKee IV
    Firewall/Security Administrator
    ORC Macro - Macro International
    11785 Beltsville Drive
    Calverton, Maryland 20705
    301-572-0583 Fax: 301-572-0982

    -----Original Message-----
    From: Ansgar -59cobalt- Wiechers [mailto:bugtraq@planetcobalt.net]
    Sent: Wednesday, October 22, 2003 6:58 AM
    To: security-basics@securityfocus.com
    Subject: Re: Patching

    On 2003-10-21 Alessandro Bottonelli wrote:
    > On Tuesday 21 October 2003 10:33, Ansgar -59cobalt- Wiechers wrote:
    > > On 2003-10-20 Alessandro Bottonelli wrote:
    > > > Hmmmm. I am not convinced yet that all this makes sense from a
    > > > "wider" security perspective. Must a vulnerability / hole be known
    > > > to be a risk?
    > >
    > > Yes.
    >
    > The more I think about it, the more I do not agree. Security is
    > availability, confidentiality and integrity, isn't it? An unknown hole
    > / vulnerability can still hit you hard (data loss, data integrity,
    > system availability to name a few instances). Humans may not know
    > about such vulnerability but systems run that code, and if the code is
    > flawed, systems do not need humans to fail or to behave incorrectly
    > from a security perspective.

    Availability, confidentiality and integrity are separate issues that
    have to be addressed in different ways. When talking about security (at
    least on this list) the majority is referring to confidentiality and
    partly integrity (to the extent that data isn't manipulated by
    unauthorized persons). At least that's my perception. Please correct me
    if I'm wrong.

    You are right that might affect availability and/or integrity and that
    those issues need to be taken into consideration, but AFAIK they are
    usually not considered _security_ risks.

    [...]
    > Was the price of closing a known hole that maybe someone one day might
    > have exploited (and maybe I might have had another option for
    > proctecting my systems) worth a failed Disaster Recovery?

    Deal with that problem when you run into it. That's what you test
    patches for. There is no point in avoiding a patch just because it
    *might* break something.

    If it breaks something you will have to make a decision whether to apply
    it (and forfeit on some functionality) or not (and face the risk of
    getting 0wnzed). That decision can only be made for each individual
    incident.

    If anyone happens to have a golden rule here, I'd like to know too ;)

    > I am not saying patching is evil, but is dawning on me the idea that
    > is not "necessarily" good, or in other words its worthness is not
    > axiomatic.

    It may rise other problems, but it gets you rid of a security breach
    that is known to the world. That's the only point I was referring to.

    > The list suggested a testbed system should be used for testing patches
    > before going onto production systems. This would be a good step
    > forward in making patches less dangerous, yet many organizations (or
    > at least most of those I deal with) cannot (or do not want to) afford
    > such luxury which requires a duplicate system, time and human
    > resources (and even then I wonder how thorough and reliable a test
    > would be on a non-production system, probably not fully interconnected
    > with the whole infrastructure).

    There has been a discussion on this a while ago, and there were some
    valuable suggestions (e.g. using VMware). You might want to take a look
    into the list's archive.

    Regards
    Ansgar Wiechers

    ------------------------------------------------------------------------

    ---
    Visual & Easy-to-use are not words that you think of when talking about 
    network analyzers. Are you sick of the three window text decodes?
    Download ClearSight Network's Analyzer and see a new network analysis
    tool that 
    makes the complex - easy
    http://www.securityfocus.com/sponsor/ClearSightNetworks_security-basics_
    031021
    ------------------------------------------------------------------------
    ----
    ---------------------------------------------------------------------------
    Visual & Easy-to-use are not words that you think of when talking about 
    network analyzers. Are you sick of the three window text decodes? Download ClearSight Network's Analyzer and see a new network analysis tool that 
    makes the complex - easy
    http://www.securityfocus.com/sponsor/ClearSightNetworks_security-basics_031021
    ----------------------------------------------------------------------------
    

  • Next message: Golden_Eternity: "RE: POP3 passwords"

    Relevant Pages

    • Sec. Vulnerability in SNMP (rev. 9)
      ... The information in the following Security Bulletin should be acted ... Vulnerabilities in SNMP request and trap handling. ... Patches for some affected systems are available now. ...
      (comp.security.misc)
    • Sec. Vulnerability in SNMP (rev. 9)
      ... The information in the following Security Bulletin should be acted ... Vulnerabilities in SNMP request and trap handling. ... Patches for some affected systems are available now. ...
      (comp.security.unix)
    • Sec. Vulnerability in SNMP (rev. 9)
      ... The information in the following Security Bulletin should be acted ... Vulnerabilities in SNMP request and trap handling. ... Patches for some affected systems are available now. ...
      (comp.security.unix)
    • Security Vulnerability in SNMP (rev. 7)
      ... The information in the following Security Bulletin should be acted ... Vulnerabilities in SNMP request and trap handling. ... Patches for some affected systems are available now. ...
      (comp.security.unix)
    • Security Vulnerability in SNMP (rev. 7)
      ... The information in the following Security Bulletin should be acted ... Vulnerabilities in SNMP request and trap handling. ... Patches for some affected systems are available now. ...
      (comp.security.misc)