Such a response only shows disrespect and a lack of understanding for what we try to do here. As your replies in this thread warrant a more verbose response, here it goes:

Frequenting the Linux Security forum, and liking what I saw, I became a Linuxquestions.org member approximately three years before you did. Like in the fora I was an active member of before I came to LQ, I have taken an active interest in all GNU/Linux security matters here up to the point that I can say that until recently, I have taken part in responding to at least ninety-nine percent of the security incidents members have posted about in this forum over the years.

The reason I require security incidents to be handled a certain way is that in the LQ Linux Security forum at the time, as well as in other major GNU/Linux fora on the 'net, members and moderators do not tend to apply a structured approach to incident handling making it a fire-and-forget chaos with "I got first post" competition running wild, members telling fellow members their machine got rooted w/o evidence, offering reinstallation "advice" without knowing entry vectors or other confusing messages. Our LQ members combined knowledge and R/L experience, a certain level of quality and using a structured approach towards incident handling makes the LQ Linux Security forum stand out from the rest.

It does require LQ members who want to do incident response (IR) to have the right mindset though: realizing that running GNU/Linux is all about performance, protecting assets and providing services in a continuous, stable and secure way. That security incidents are not only bad for the "victim" but also are bad news for those connected to the same networks and that they reflect badly on the GNU/Linux image as well. This means any security incidents have to be handled correctly, swiftly and decisively. And that's why you see me sometimes post that in the LQ Linux Security forum we deal with facts, not fiction. After all a security issue, computing in general, in essence is binary: integrity is either maintained or it is not, a machine is either compromised or it is not. Handling security incidents is like troubleshooting in general: until the situation is clear the "victim" should be asked questions. "Victims" often do not have the right amount of knowledge to assess things on their own but with a little help they often can work out the math themselves. Often help means making the "victim" see priorities differently, that one can not judge a situation before information is gathered, applying order to the whole fact-finding process and interpreting posted results.


That is why members who "think" everything is OK, "guess" a machine is "probably" compromised or tell a fellow member "not to worry" are reminded, if necessary with use of --force, that that is not the right approach to help. That is why telling a fellow LQ member "you've been rooted" without proof is useless. That is why telling a fellow LQ member to restore a backup without pinpointing the infection vector(s) (if any) is plain wrong. That is why telling a member to "cut losses and start again" without knowing if a breach of security has actually occurred is at least inefficient and ill advice.


From the above naturally follows that I do not care for "winning" an argument about IR. I'm telling you how it should be done in this forum. In case anything is unclear you're invited to discuss the IR process here. Anything else should probably be in a forum like /General or be redirected in an email to me.

I read the thread. I disagreed with smoker in thinking that a reinstall or usage of a backup strategy is a solution to the OP's question. Some of us that frequently participate in these types of investigations (here in these forums and IRL) know that one should always attempt to understand what happened before reinstalling or going to a last known good backup. The reasoning is because you could very well not be solving anything. System owners should always strive to understand the who/what/when/where/why/how questions/answers of incident analysis, as those answers are crucial to ensuring that someone else (or the same person) doesn't use the exact same vector to get into the machine AGAIN.

I've been in the IT security field as a security professional going on 8 years and I'm definitely not the most versed person on these forums regarding forensics or incident handling. I'm certainly not bold enough to throw anything in my signature that hints at me being some type of forum guru and I'm sure that would rub some people here the wrong way. If there's one thing I've learned in being a security professional and Linux user, it is this: there's no such thing as a guru. I don't think you (smoker) know anything that the collective IA enthusiasts here don't already know...

unSpawn and the other mods that frequent the security forums have been doing this for awhile. Even if there's some 20-year veteran of IT security that frequents these forums as a regular user, I'm pretty sure that unSpawn, win32sux, and the others understand how LQ should represent itself as a Linux security entity that can back up what they say based on successful histories of IA...they don't need anyone attempting to step on them or establish some new order.

If you noticed, unSpawn typically uses the same set of links and docs in assisting someone with an intrusion issue. I think that anyone here that participates (or would like to) with IA should ensure that they are familiar with those resources so that we can all at least appear to be less of a cluster-fsck when it comes to assisting people. The documents contain proven strategies in incident handling. Assisting people by having them perform investigative steps is far more valuable than one-liners that say something akin to, "you've been hacked. Reinstall your OS."

Assisting someone with IA is difficult enough...let's not make things further complicated by not being nice.

3 members found this post helpful.