[CentOS] what percent of time are there unpatched exploits against default config?

Wed Dec 28 15:40:44 UTC 2011
Johnny Hughes <johnny at centos.org>

On 12/28/2011 07:55 AM, Johnny Hughes wrote:
> On 12/28/2011 01:40 AM, Bennett Haselton wrote:
>> On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Foster <rilindo at me.com> wrote:
>>
>>>
>>>
>>>
>>>
>>> On Dec 27, 2011, at 11:29 PM, Bennett Haselton <bennett at peacefire.org>
>>> wrote:
>>>
>>>> On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste <
>>>> sebenste at weather.admin.niu.edu> wrote:
>>>>
>>>>> On Tue, 27 Dec 2011, Bennett Haselton wrote:
>>>>>
>>>>>> Suppose I have a CentOS 5.7 machine running the default Apache with no
>>>>>> extra modules enabled, and with the "yum-updatesd" service running to
>>>>> pull
>>>>>> down and install updates as soon as they become available from the
>>>>>> repository.
>>>>>>
>>>>>> So the machine can still be broken into, if there is an unpatched
>>> exploit
>>>>>> released in the wild, in the window of time before a patch is released
>>>>> for
>>>>>> that update.
>>>>>>
>>>>>> Roughly what percent of the time is there such an unpatched exploit in
>>>>> the
>>>>>> wild, so that the machine can be hacked by someone keeping up with the
>>>>>> exploits?  5%?  50%?  95%?
>>>>>
>>>>> There's no way to give you an exact number, but let me put it this way:
>>>>>
>>>>> If you've disable as much as you can (which by default, most stuff is
>>>>> disabled, so that's good), and you restart Apache after each update,
>>>>> your chances of being broken into are better by things like SSH brute
>>>>> force attacks. There's always a chance someone will get in, but when you
>>>>> look at the security hole history of Apache, particularly over the past
>>>>> few years, there have been numerous CVE's, but workarounds and they
>>> aren't
>>>>> usually earth-shattering. Very few of them have. The latest version that
>>>>> ships with 5.7 is as secure as they come. If it wasn't, most web sites
>>>>> on the Internet would be hacked by now, as most run Apache
>>>>>
>>>>
>>>> I was asking because I had a server that did get broken into, despite
>>>> having yum-updatesd running and a strong password.  He said that even if
>>>> you apply all latest updates automatically, there were still windows of
>>>> time where an exploit in the wild could be used to break into a machine;
>>> in
>>>> particular he said:
>>>>
>>>> "For example, there was a while back ( ~march ) a kernel exploit that
>>>> affected CentOS / RHEL. The patch came after 1-2 weeks of the security
>>>> announcement. The initial announcement provided a simple work around
>>> until
>>>> the new version is released."
>>>>
>>>
>>> What was the nature of the break-in, if I may ask?
>>>
>>
>> I don't know how they did it, only that the hosting company had to take the
>> server offline because they said it was sending a DOS attack to a remote
>> host and using huge amounts of bandwidth in the process.  The top priority
>> was to get the machine back online so they reformatted it and re-connected
>> it, so there are no longer any logs showing what might have happened.
>> (Although of course once the server is compromised, presumably the logs can
>> be rewritten to say anything anyway.)
>>
>>> Security is more than just updates and a strong password.
>>>
>>>  - Rilindo Foster
>>>
>>
>> Well that's what I'm trying to determine.  Is there any set of default
>> settings that will make a server secure without requiring the admin to
>> spend more than, say, 30 minutes per week on maintenance tasks like reading
>> security newsletters, and applying patches?  And if there isn't, are there
>> design changes that could make it so that it was?
>>
>> Because if an OS/webserver/web app combination requires more than, say,
>> half an hour per week of "maintenance", then for the vast majority of
>> servers and VPSs on the Internet, the "maintenance" is not going to get
>> done.  It doesn't matter what our opinion is about whose fault it is or
>> whether admins "should" be more diligent.  The maintenance won't get done
>> and the machines will continue to get hacked.  (And half an hour per week
>> is probably a generous estimate of how much work most VPS admins would be
>> willing to do.)
>>
>> On the other hand, if the most common causes of breakins can be identified,
>> maybe there's a way to stop those with good default settings and automated
>> processes.  For example, if exploitable web apps are a common source of
>> breakins, maybe the standard should be to have them auto-update themselves
>> like the operating system.  (Last I checked, WordPress and similar programs
>> could *check* if updates were available, and alert you next time you signed
>> in, but they didn't actually patch themselves.  So if you never signed in
>> to a web app on a site that you'd forgotten about, you might never realize
>> it needed patching.)
> 
> System Administration is a time consuming and complicated thing.  That
> is why there are System Administrators.  That is why there are
> certifications like RHCT, RHCE, CISSP.  There are a whole slew of things
> that people who want to run secure server need to know, and dozens of
> security related certifications:
> 
> http://issa.org/page/?p=Certifications_13
> 
> 
> Running your own server is not like using a toaster.  It requires
> someone with a detailed level of knowledge to install and maintain it.

If you are interested in research, here is the checklist that the US DOD
uses to secure their Unix/Linux servers:

http://iase.disa.mil/stigs/os/unix/unix.html

Inside the STIG section, you will find a generic UNIX checklist ...
there is also a RHEL 5 specific checklist here:

http://iase.disa.mil/stigs/os/unix/red_hat.html

One needs to read through that checklist and decide which of the items
in the checklist are applicable to the individual situation, but that is
a starting point.

Also a good source of info is this page:

http://people.redhat.com/sgrubb/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20111228/57931c1e/attachment-0005.sig>