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

[Johnny Hughes]

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.

-------------- 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/7d277bdb/attachment.sig>