There is a CentOS 5.2 machine that is sometimes found to be offline. It runs a few websites but nothing very high traffic. I happened to notice a few days ago that before it went down, one of the sites written in PHP was throwing errors that it could not connect to the MySQL backend. Two hours later, the whole server was down and wasn't even responding to SSH. It's not my box, but I may have opportunity to look at it. After going through dmesg and messages, if I don't find anything obvious, what should I start looking for? What are the likely, common culprits and how to identify them? Is there a page of the fine manual that addresses issues like this? Thanks. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com
Dotan Cohen wrote on 01/23/2012 08:39 AM:> There is a CentOS 5.2 machine ...I'd have a look at why an apparently Internet-facing server is 5 point releases, plus a lot of subsequent errata, behind the current 5.7 release level; and what resultant vulnerabilities might have been exploited. Phil
On Mon, Jan 23, 2012 at 7:39 AM, Dotan Cohen <dotancohen at gmail.com> wrote:> > It's not my box, but I may have opportunity to look at it. After going > through dmesg and messages, if I don't find anything obvious, what > should I start looking for?Forwarding on behalf of Mark whose emails are being rejected: Patrick Lists wrote:> On 23-01-12 16:13, Dotan Cohen wrote:<snip>> There is no other option than to reinstall the box with 5.7 (or whateverthe latest is) and *always* update the box. I would also throw out that "specific software". Vendors who force you to stay with a version of an OS that no longer gets security updates should be avoided at all cost. And, for that matter, if it's in-house software, you managers are going to *have* to bite the bullet and spend the money to have your in-house people fix the software so that it is compatible with current releases. Beyond that, how do you *know* that it's not compatible with 5.7? Have you tried it on a 5.7 box? At least bring up a 5.7 VM and try it. If you don't have one, you really, really need to have a test system - if your managers have had development and test done on a production box, and they don't understand why this is bad, then I might recommend looking for another job, where they're not amateurs, in the worst sense of the word. mark
On Mon, Jan 23, 2012 at 18:57, <m.roth at 5-cent.us> wrote:> a) You should NOT, under any circumstances, be backing it up to your home > systems. You should be backing it up to a work server - there are very > serious legal implications involved here. >Thanks, but there are no customer data or other sensitive data on the server. I wouldn't dream of compromising customer data!> b) Since it's in a datacenter, presumably being hosted, you need to > contact the datacenter provider and inform them that you believe it may be > infected, and work with them to investigate - they may have an intrusion > response team far more qualified than you to investigate whether there's > been an intrusion. On the other hand, you've also got to worry about your > company's proprietary data, and what they should see, and what they should > not. >That is a good idea. There do exist professionals for this type of work, and that is the place to find them. Thanks.> As I said, a *lot* of legal issues - don't put yourself into a position > that could get you, personally, out of a job, sued, or even, as an > extreme, jailed. >Thank you for the concern. I will be cautious and not reckless! My own security is not worth that server! -- Dotan Cohen http://gibberish.co.il http://what-is-what.com