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.) Bennett