Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

Web access URL’s containing ‘RK=0/RS=’ string

We have noticed over the past few months an increase in the number of web access upon various URL addresses upon our site with a string starting ‘/RK=0/RS=’, followed by strings of other characters.  To us they are obviously some attempt to get access to information but we were a little puzzled as to how they might possibly work. The URL’s they are attached to are varied but seem to be upon a lot of Blog addresses. The RS= looks like it could be a regular expression for a pattern match of sorts, since some(but not all) are sometimes followed by a caret ^ but that is speculative.

They look to be a form of  SSI injection with the header, with the attempt to try and pass tokens into the URL for some purpose..

Apparently we are not alone and there is much discussion upon the web as to exactly what it is trying to achieve and who might be behind it, but no clear answer is currently known.

One way to remove them might be a simple .htaccess rule similar to the following:

RewriteRule ^(.*)RK=0/RS= /$1 [L,NC,R=301]

An alternative would be to block the IP addresses from which they are coming, but if they are not ‘hard addresses’ in the sense that they are not reusable,  then the risk is that you may end up blocking legitimate traffic.

Recent Comments
Guest — Gadgets
I believe the culprit may be scripts, bots or people 'scraping' the search results of Yahoo, and then attempting to access the url... Read More
Tuesday, 06 May 2014 17:44
Geoffrey Chapman
You could well be correct, just not quite what they are trying to achieve/access. We currently see up to 100 attempts with these ... Read More
Wednesday, 07 May 2014 08:57
Guest — chatterb0x
The first comment is correct. bots scraping yahoo search results.
Wednesday, 31 December 2014 06:43
  3009 Hits

Debugging PHP with Java console.

b2ap3 thumbnail joomlaIt may seem a strange title for a blog, but we have been looking at a small ‘opportunity’ in converting one of our components to Joomla 3.x.

First a brief explanation is required. The module in question is a PHP module which calls some Javascript code which in turn then calls a separate PHP routine.  The error we were trying to resolve involved this ‘second’ PHP routine.  The module was designed to display a Google map and the first PHP module sets up the display, the Javascript code builds up the required map and it is in turn, populated with data obtained from the database and formatted by the second PHP routine.

This ‘inner’ PHP routine was working perfectly on Joomla 2.5 but on Joomla 3.1 only the map itself was displayed, not the 'map points’.  It was apparent therefore that there must be ‘code’ that was not Joomla 3.x compatible but how to find it.  Code inspection did not reveal any apparent cause. The changes to remove JRequest and replace it with JInput were working fine, and attempts to use print, dump, enqueueMessage, etc. statements were accepted but would never display any information which one could see.  [This might possibly be due to our trying to display text ‘after’ the ‘error point’, but am not totally convinced yet.] Inspection of error logs also were not informative, mainly it is suspected due to the Javascript ignoring the errors and proceeding to execute even after receiving a error from the PHP routine.

Continue reading
  3081 Hits

MySQL versions and binlog_format settings

Following on from an earlier post, there has been further investigations into the settings of the binlog_format setting for MySQL.  The problem is possibly aggravated by the use of InnoDB tables, which are the default in MySQL 5.5, the use of which offers some distinct advantages.  This setting seems to have been introduced in version 5.1.5 of MySQL.  Prior to that date it didn't exist and attempts to use the setting would generate an error, which is not totally surprising.

Continue reading
  2292 Hits

MySQL logs and QNAP systems


All (most) company development and testing making use of MySQL databases locates the databases upon QNAP systems.  The default MySQL installing being by the QNAP installation itself.  Recently there has been some interest in the space being consumed.  Looking at the database settings in the /etc/my.cnf file it can be seen that it is not optimum.
The main areas of interest are the log files.  It is noted that the binlog format is set to STATEMENT which is why the messages about log format have been seen.  [It is not known how many systems are set to the default so it is sensible perhaps to leave the setting alone.  In this way we have a 'worse' case scenario for when we distribute software and have to include session settings to enable the software to install and/or function.]

Continue reading
  3998 Hits
Go To Top

The Macrotone Consulting Web site would like to use cookies to store information on your computer, to improve our website. Cookies used for the essential operation of the site have already been set. To find out more about the cookies we use and how to delete them, see our Privacy Policy.

I accept cookies from this site.