3

A website I do some volunteer work for was recently one of those affected by a wordpress plugin vulnerability.

Following advice in the answer to this question, which contains details of the attack, I am hoping someone can advise me on how to go about securing my website, since it is unknown to me if the script I posted about there managed to run itself before I killed it.

In particular, any information on how to go about ascertaining whether or not there is a SOCKS server active on the website would be appreciated (and how to kill it, if there is). I am fairly new to the behind-the-scenes aspect of websites, as you may be able to tell. If any other information is needed, for example the tools provided by my host, please let me know.

EDIT: this is not the same as the questions marked as similar, since those are general questions about how to secure a server. While I will take the advice in those questions, I am interested here specifically in how to find a kill the specific manifestation of the malware on my server - a SOCKS server.

Community
  • 1
KBriggs
  • 133
  • 4
  • I don't think this is a duplicate of the question indicated. The question indicated asked generally how to secure a server - I am interested in how to specifically find and kill a SOCKS server that was started on my website. – KBriggs Jan 07 '15 at 00:12
  • You kill a SOCKS server the same way you kill any other malware: by wiping the system and restoring from backup. – Mark Jan 07 '15 at 04:22

1 Answers1

1

IPTables!

It's the first thing I can think of.

This will happily let you block all outbound/inbound traffic that you don't want. So first you can configure SSH to be open on a non-standard port (ssh server config) and of course open port 80 (and 443 if SSL), for your inbound.

And only open port 80 and 443. Now, whilst this does not completely mitigate the risk, it's a tad more unlikely malware will go after the web ports to route it's proxy thru.

Since we are talking about WordPress. Always make sure you have everything up to date. Lock down the write accesses (ug WP autoupdate, who thought that was a good idea overrall?!).

.htaccess/blank index.html to lock down plugin folders that the author has overlooked.

Looking at the post you linked, that should help mitigate the attack in question.

Edit 1: It is of course always important to regularly audit your box(es) for running processes/open network ports.

Barry Carlyon
  • 126
  • 1
  • 5