I'm sorry if I wasn't clear enough: I only meant that the unnecessary ports should be closed.

Well, you and I seem to live here.

Hopefully, this will be the catalyst that the user needs and sees that the time for such questions is before any compromises.

As per the usual, I suspect stolen credentials or a reverse-shell dropped in via loose permissions.

Hosting is the pits.

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.


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.

I'll admit, I'm no security expert. What I know I've learned from my father, a certified ethical hacker and a certified forensics investigator. As for myself I'm more of a hardware and operating system guy.