Yeah I know that most break-ins do happen using third-party web apps; fortunately the servers I'm running don't have or need any of those. But then what about what my friend 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." Is that an extremely rare freak occurrence? Or are you just saying it's rare *compared* to breakins using web apps? Or am I misunderstanding what my friend was referring to in the above paragraph? Bennett 2011/12/27 夜神 岩男 <supergiantpotato at yahoo.co.jp> > 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. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >