Thanks for taking the time to reply. Now you're kind of new to LQ and therefore you may not have much experience reading posts and interacting with the folks in the Linux security
forum. Members who seem to live here, members with a good grasp of Linux Security, and especially those with practical incident handling or forensics experience know there's a certain order, a structured approach to "solving" these types of problems. Because time is of the essence and risks should be mitigated as soon as possible the order of stages I try to promote is: information gathering, mitigation, analysis, aftercare. Understanding what actions to perform at which stage ensures both the incident handler and the "victim" have a clear view on what to do. This should keep the "victim" from getting distracted by conflicting "advice", nitpicking or whatever else.
More fundamentally solving any
problem requires one to be methodical about things. IMHO that starts with proper diagnosis: reviewing the nfo at hand while not assuming anything
and asking questions.
If on doesn't do that then one might miss a clue and any advice one gives may range from just inefficient to the completely unsuitable in certain situations.
Originally Posted by Nbiser
I'm sorry if I wasn't clear enough: I only meant that the unnecessary ports should be closed.
And likewise I'm sorry if what I wrote above wasn't clear enough: in a priority-ordered list of actions to perform this isn't number 0, 1 or 2 until you have gotten the information to base such advice on.