On 12/28/2011 01:40 AM, Bennett Haselton wrote: > On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Foster <rilindo@xxxxxx> wrote: > >> >> >> >> >> On Dec 27, 2011, at 11:29 PM, Bennett Haselton <bennett@xxxxxxxxxxxxx> >> wrote: >> >>> On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste < >>> sebenste@xxxxxxxxxxxxxxxxxxxxx> 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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
