I have several websites running on OJS 3.0.1. Recently they all were attacked with a malware, which creates several folders in my public.html directory. This triggers the alter from my VPS Hosting provider as well as from Google for phising attack. I am not understanding that what I am doing wrong. My file directory is also outside Public.html , so that is not accessible.
Can anyone please help in solving the issue,I donot want it to happen again, I am also ready to pay the fees for it if any.
Identifying the original source of the attack and fixing it, and
Cleaning up your site so that any back-doors that the attacker installed have been removed.
OJS should be secure as long as you follow the instructions in docs/README.md under “Recommended Configuration” and keep your installation up to date. OJS 3.0.1 is quite old and there are a few security issues listed on https://pkp.sfu.ca/ojs/ojs_download/.
Otherwise, this is more a general server administration question than an OJS question. When trying to figure out the source of an attack you’ll have to approach it from a variety of directions – is the server configured correctly, or do e.g. lax file permissions make it unsafe? (This is often the case if you’re using mod_php; a break-in with any PHP application can can problems with any other.) Try to identify the malware files on the server and check their file dates; cross-reference that with your access logs to see if you can identify the attacking request.
When it comes time to clean up the server, you can’t just copy your website contents across to a new environment because you risk copying hidden malware as well. The safest way to clean up is to start with a clean environment, install clean packages of whatever software you’re using, and carefully introduce content from your old site (e.g. database, OJS files directory, and any PHP modifications), reviewing whatever you bring in for safety. Tools like diff can help with this.
These are just a few hints; there are probably some very good general resources on Stackoverflow or elsewhere.
Regards,
Alec Smecher
Public Knowledge Project Team
Hey Alec. This is good practice if you’re not under time pressure to move hundreds of sites, and if the software is predictable without dependencies and doesn’t break when you move it from one server to another.
In my experience what really happens on a live site is that you move the php stuff across or install a new version and:
it wants an obscure library that was on your old machine but not the new one
it is incompatible with some subtle thing in the DB… had a big issue with this with mysql sql → mysqli changeover
user accounts differ because it’s not the same distro or ISP (is that www-data, httpd, or apache2 as a username; is that sendmail, smmta, or smmsp as a username?)
etc.
In reality, it’s not an ideal world, and messing with a working copy of software is a bad idea from the pleasing customers point of view.
sometimes also I find that software is obscure about its complaints, so sometimes a chmod -R 777 is the only thing that makes a website work. This is because developers themselves do not bother to put helpful error messages, like
"Dear sysadmin, please run this:
chmod 777 /var/www/ojs/tmp"
as opposed to some cryptic unintelligble error… my 2c.
I hear you on the more-work-than-time frustration. But a risky deployment like using 777 permissions – which are never a good idea – won’t save time in the long run if it means cleaning up after a break-in later.
Regards,
Alec Smecher
Public Knowledge Project Team
You need to analyze the source of the security hole on your system. You can do it by doing some sort to the raw log access of your Webserver such as apache or Nginx access log.
I am hoping that the hacker was not gained the root right on your VPS system since he can easily delete all the log to cover his track on your site.
I think the safest way is to reinstall the ojs to a different hosting or server. I also had the same problem. Finally I reinstall into different server, and activate the cloudflare dns. It’s alot saver now.