It is a crime if a Linux OS or application stops or does not work. :)
For me, you should think like it is a crime scene. I'm not referring to CSI style thinking about crimes like attackers, crackers, hackers, etc. It's about a frame of mind of thinking where you gather as much evidence, then you or the vendor fix it. Once fixed, ask questions like what happened? what can be fixed or patched so that this won't happen in the future? Ask this question, because your manager and upper management would ask you exactly the same question. For john, it's a judgment call. As mentioned in the last e-mail, It's up to you/manager to restart the service immediately or give you 30 minutes to collect the data or consult the vendor first on what to do next. Have learned a hard lesson few years ago where i could have created a core file live. When the box rebooted, the vendors are having a hard time finding the real cause. And to Linux Admins out there, when was the last time you configured Linux to have crash dump support? None? Raise your hand if you have. What I have seen so far, it's off or not even installed by default in popular Linux distros. And that's one of my beef. Other *nix like Solaris is on by default. Which should be. Just a friendly reminder to check it out. For the others, in the *nix world, 95% most of the time a reboot won't solve the problem. It may look fixed and be up and running, it may work for a couple of months, but it will rear it's ugly head in the future. For some it is overkill especially for a small/medium shop, but for the enterprise this is basically SOP. There is no satisfaction like giving a vmcore to an OS Vendor, then said vendor finds and states it's a DB problem, call DB Vendor about it, and let the two fight it out... :) -- regards, Andre | http://www.varon.ca On 12/29/06, John Peter Loh <[EMAIL PROTECTED]> wrote:
On 12/29/06, Danny Ching <[EMAIL PROTECTED]> wrote: > On 12/29/06, Ariz Jacinto <[EMAIL PROTECTED]> wrote: > > you must be referring to the OSI layer ( > > http://en.wikipedia.org/wiki/OSI_model ) > > which is indeed an abstract description for communications _but_ it doesn't > > apply > > to the procedural digital forensics. > > My bad. i wasn't refering to the forensics in the matter. I was more > concerned about getting services up first. You know, baka magalit ang > mga boss at mga clients and all that. > > Is that the right way to do it? or would it also obliterate any traces > of the culprit? should a cpu with problems like these be treated like > a crime scene. As in bawal galawin? I know the steps to restoration, > but I have no experience in forensics eh. I don't see why you shouldn't treat it like a crime scene. If the incident was a result of a crime, then you can use forensics to trace the attacker and know how the attack was made. Then you can prevent the attack from happening again.
_________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
