Question Possible Attack on Kunena Forum

Yesterday my hosted Virtual Server had a very high cpu load. I was very proud of myself to find the issue - I am a real Linux noob:
From varius Russian IPs came requests to
www.mydomain.de/forum/1-My-Kunenyforum-Name/administrator
which made on my server about 10 php5-cgi processes with heavy CPU load.

To solve the problem fast, I made a 301 Redirect on this URL to a Domain I don't use, and immediately the load was gone.

Is this a random test of a script kiddie or a possible attack on the Kunena Software?

Hello,

There are robots which scan all the web to check vulnerabilities or tries if some URL exists.

Yes, I believe that this were bots, too. But the strange thing is, that these requests were causing really heavy load. I had PHP processes running 1-2 minutes with 10-20% CPU, and 100 or more at the same time. I guess that somehow the Kunena Script was running longer than usual.

In the error log was:

[Mon Apr 25 23:57:28.771140 2016] [fcgid:warn] [pid 10130] [client 123.123.123.123:52069] mod_fcgid: stderr: PHP Warning: simplexml_load_file(): I/O warning : failed to load external entity "/var/www/vhosts/mydomain.de/httpdocs/components/com_kunena/template/default/template.xml" in /var/www/vhosts/mydomain.de/httpdocs/libraries/kunena/template/template.php on line 142

(I changed IP and my domain)

On a webrowser if you try to access the template.xml from your Kunena template, are-you able to see it ?

indeed, this file - well the whole directory /default is missing. On the server and of course with the browser. But I am also missing it in the latest install.zip in the Download...

What should be in that directory?

Before the version 4.0.x of Kunena the template by default was on directory : /components/com_kunena/template/default/

Maybe you can prevent the access to xml files from all our joomla directory in the htaccess

well, if this file is "old", some of my Kunena scripts still expects that file there, and throws the error in the errorlog. It seems that I dont need to block that file, it doesn't exist anyway.

Solving this error in the errorlog is one thing, but can this be also the source of the heavy load? I just casually found this error because I was analyzing the reason for the CPU load.