Malware Intrusion

We know that there is no ideally secure server. I witnessed many times that hosting companies and their employees sometimes suffer from a lack of resources, equipment and skilled people that should take care on security of servers.  One of them tried to convince me that permission for folders in public_html should be 777. (If you are new to web applications and setting up your system for open access publishing please find on the internet information about permissions on your server. Majority of hosting companies with shared hosting accounts by default set that folders do have permissions set to 755 and files to 644.  Those people who want to compromise your server usually inject code that is planned to exploit vulnerabilities and use your server for some, usually illegal, operations as on image below.  When you in the process of choosing application, hosting company and person who will administer server the security should be top priority issue.

example of intrusion codeThere are various methods how to do that. Example on presented here was part of one larger file that was present on one server used to publish scientific journals.  Sometimes, servers are safe but applications installed are very vulnerable.  Strong competition and financial urges force developers to issue product as soon as they can without proper testing. I came across several times that some pieces of software are written for very obsolete and insecure versions of PHP which poses additional risks for security of site. On the other side, various additions of custom code that is not tested can make system insecure.

Such incidents can endanger your reputation and trust of authors, readers, reviewers and librarians that would like to visit your site often. Above all, sometimes some drivers, firmware, operating systems are vulnerable and you as user of one account cannot do anything to prevent that. That is job of people in hosting company and manufacturers of hardware with vulnerable software to fix vulnerable parts of software. Nevertheless, this should not discourage your from publishing open access.  Constructive and proactive caution is always necessary and welcome.

 

Once, I received call from one association that is publisher of one scientific journal. They informed me that some strange code appeared on their site and I used various malware testing tools and my result was like on image below. I found soon that server was infected so called db.php infection.  Since malware was successfully uploaded on server, it GET requests and it infects every javascript files (.js) with javascript malware code.encoded intrusion  I decoded strings displayed on page and I found IP address of server that is infected and which is used for distribution of malware and which redirects users to other sites. Since such code was all over the site it was very hard to read pages and visitors were prevented from using open access content.

I reported editorial board of the journal on my findings and we informed hosting company and domain registrar of domains used to spread malware asking them to check issue and undertake necessary measures to stop abuse of our and possibly other sites infected by that malware.

The process was rather tense, stressful and painful for editorial board and all people concerned.  The hosting company that hosted server with domain used for spreading malware informed us that they will take care on the case. 

We used other tools to block IPs that are detected as attackers. We have had that day more than 290 attacks from computers from Panama and more than 150 attacks from computers from Ukraine. We restored our site by using fresh backups and reinstallation of web applications we use.  Our hosting company upgraded PHP version that was obsolete, unsupported and insecure at  the time.

 

Manuals for Open Journal Systems

I have found that many editorial boards struggle with a lack of concise instruction materials and a lack of people who can train them with hands-on approach.  They usually find some solutions in on-line forums, but it is time consuming for editorial boards to spend so much time and look for partial information. Sometimes people who write manuals do not explain each step.  Several people contacted me and asked: “What I have to do now?  Something is missing.”

System administrators, software developers assume that what is easy to them it should be easy to everyone.  They plan training to be done in one evening because “It is easy. ” In my experience, I often found out that such practice leads to misconfiguration of application, underuse of its features,  mistakes in performing workflow tasks and procedures.  Work with applications as the Open Journal Systems is not hard but it is complex and it takes some time until user is familiar with its functionality and simple procedures for configuration and efficient use.

I wrote manuals for authors, editorial boards and reviewers for scientific journals according to their needs.

You can find here manual for authors, editorial boards, and reviewers.

I will publish here soon manual that puts together some basic administrative and editorial functions aimed to successful configuration of your Open Journal Systems application for your journal.

 

Oh, no! Error 500 ruined my server!

I have had many times situation that servers were not properly configured since neither administrators nor journal editorial boards were fully ready and aware what is required to set up in order to meet the needs for some specific journal.  It is always good to learn more about such error although they can happen but without tragic consequences for your work.  Error 500 is one of so-called  HTTP status codes.  The error messages/status codes that begin with “5” indicate cases in which the server is not capable to perform some task. That task should be possible to be performed by the server if some settings could be adjusted.  So, that is it. Nothing is ruined!

Constructive and open communication with hosting company or your administrator will help to identify possible cause of error which will disappear when some setting will be changed.  The most often you will see so called Error 500 Internal Server Error which is generic error indicating that unexpected condition was encountered. No, big deal although does not look nice. Heh!

Appearance of that message can be expected but prior to entering any deal about web hosting plan detailed conversation with experienced administrator who will help you to precisely articulate your technical requirements that should be met by your IT department or hosting company.  That is it! Some experimentation will not ruin anything on your server!

My server exploded. Everything is gone! Aaaarghhh!

I guess many times administrators, people involved in technical support on forums have been faced with such outbursts of despair and anger.

Well, it is stress to everyone. But, server never exploded and it is very rare that everything is gone forever.  Appearance of blank screen, error message or that program is stuck does not mean that your server exploded or that you lost your work.

When you experience that kind of difficulty it is important to stay calm and to have handy information that will help your administrator, hosting company/IT department people, community support participants on support forum to look for solution.  Well, often solution is correction of code, adjusting settings on server, but in any case your work is the most probably neither damaged nor gone.

You should always have handy information on your infrastructure, browser, operating system of your server and context within which issue happened.  People who want to help you often free of charge need to reproduce the problem in order to identify the point at which problem occur.

Support people at ATutor set up their forum in  a way that the user is by default provided with hints that will help to write post in a way that will be helpful.  We have to be oriented towards solution! So, do not panic! Be calm, concentrated and focused on providing sufficient information in order to find solution. It is not shame to describe sincerely and completely what you have done. That will help you and many others. Asking for help is support to yourself and to many others.

I found helpful hints on support pages of several OA software packages.

The rule is: Do backup often, be calm, sincere and helpful to yourself, people who want to help you and others who might be in trouble as you are now.

Here it is how people from ATutor made it:

  • Beginning of message:

If you are asking for help, provide lots of detail so problems can be reproduced.

Things to describe:
Operating system ATutor is installed on –
ATutor version –
Patch #s applied –
ATutor theme name –
PHP version –
MySQL version –
Webserver & version –
Copies of error messages –
Changes to default settings –
Web browser being used –
…and anything else relevant –

  • End of message.