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 <rili...@me.com> wrote: >> >>> >>> >>> >>> >>> On Dec 27, 2011, at 11:29 PM, Bennett Haselton <benn...@peacefire.org> >>> wrote: >>> >>>> On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste < >>>> seben...@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/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
