On 12/28/2011 01:29 PM, Bennett Haselton 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." > > Was this a sufficiently high-profile incident that you know what he's > referring to? If this kind of thing happens once a year or more, than > surely this is a much greater threat than "brute forcing the SSH > password"? That's what I'm talking about -- how often does this sort of > thing happen, where you need to be subscribed to be a security mailing list > in order to know what workaround to make to stay safe, as opposed to simply > running yum-updatesd to install latest patches automatically. Nearly every time servers get broken into they are web servers, and web servers serving applications the greatest percentage of those. The "web" never having been intended as an applications platform provides a huge number of attack vectors which are entirely separate from the OS layer. For example, a perfectly secure operating system running a perfectly secure Apache configuration on a perfectly secure MySQL deployment could be running an application that permits injection of arbitrary SQL commands into the database. The server itself may not be compromised (or it may, depending on what else that SQL command can touch/be referenced by) in the sense that someone can open a shell, but in most cases there is nothing of interest on a web server anyway. What is interesting is what is in the database or lives within the application being served, and that is an application/database layer problem, not an OS, web-server or kernel problem. With the vast majority of web applications being developed on frameworks like Drupal, Django and Plone, the overwhelming majority of "server hacks" with regard to the web have to do with attacking these structures (at least initially), not the actual OS layer directly at the outset. Compare this with email server software, which, if the OS layer were the inherent problem, would be heard about every day -- much more often than web-related cracks. But email server software is mature and just as secure as Apache is. However, web-based email is a common target, and for a good reason. http is inherently insecure, and bouncing someone from http to https is just as insecure because the initial http link and DNS can be attacked, both being deliberately insecure, public protocols. Blah blah. My point is, the OS is rarely attacked directly in web-related cracks. A good cracker tries to discover flaws in young, fast changing web frameworks which require priviledged access to things like MySQL instead of trying to attack Apache or an SE-enabled OS layer directly.