Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

Lessons to be learnt from RBS debacle?

The recent debacle/fiasco around the RBS banking group has attracted much interest, with various comments made about whether it was preventable and the possible causes.

There have been many suggested causes such as whether this was an ‘accident waiting to happen’, or whether RBS should have retained IT support in-house rather than out-sourcing, a lot of which were by parties with their own self supporting agendas

One thing that did catch our eye was the article that RBS is set to sue the supplier for the problem.  Somehow it would turn our very ironic is the suppliers were insured for liability insurance (which all reputable suppliers are) though an RBS subsidiary.  That really would be something of an own goal, and for a group that is majority owned by the UK tax payer, must raise some interesting questions.

Anti-Spam measures

We received an interesting comment in the site the other day about the anti-spam options that we incorporate into the Issue Tracker component.   The main gist was that Recaptcha was the only anti-spam option that we use.   However we had to reply that there were also other features such as word filtering, IP blocking, checks on the number of links, and the ability to ban specified email addresses and URLs.

We have (and still are) considering other options but do wonder whether it is the best approach to build all of these tools into a specific product such as Issue Tracker.   A typical Joomla site will have a number of components such as a Blog, a forum, a general article commenting system, etc., installed.   Other web sites even if not based on Joomla will have similar constituents.  Is it wise to have all of these parts with their own separate anti-spam measures?  The likelihood is that they will all adopt slightly different approaches with different measures of success, and all requiring updates to keep up with new techniques and methods.

Continue reading

Three Strokes and you are out

I have previously written about Spam entries on the web site and their elimination, but now I turn to 'Invalid Login attempts'.

I have been watching these with interest for a few weeks, and it is particularly interesting to see where they originate from.

Like the Spam entries a lot of these seem to originate from the Far East.  I am currently adopting a policy of immediately blocking 'Administrator Login attempts'.  No quarter given, I can think of no valid reasons why they should be tried by anyone other than those authorised to do so.

Turning to normal login attempts I have a policy of seeing how many different user names are tried from a specific IP address.  Once they have tried 3 different ones I immediately block them.  I must admit I am building up quite a long list.  Perhaps I should generate a graphical display of the souces, it could be quite interesting to see, and watch how it changes over time.

Given a single host country as being the source of a lot of these attempts, one could always block all the IP addresses assigned to that specific country but it does seem like 'using a sledge hammer to crack a nut' approach.  Possibly I will come round to that approach eventually.

The one single thing that I have not yet investigated is how accurate the IP address actually is.  Programs such as 'tor' generate anonymity of the IP address so do we actually know where they come from at all?  If its' use became widespread blocking of IP's might be a little bit of a waste of time anyway!

 

Blogging problem using WLW (Windows Live Writer)

Just found a small problem when using Windows Live Writer (WLW) as a blogging tool.

The situation is that for network reasons when WLW attempted to get hold of the blog entry on the server it failed yet still displayed the article.

Then when the article was changed and published it overwrote the original post, even though the title and most of the text had changed.   Never seen it do that before but will need to watch it very closely from now on in.

Now all I have to do is get back the original post from the backup.  - Never mind.

Seems it doesn't like it when you change destinations either for an entry, as it assumes that it is a new rather  than an edited old entry.

Tags:

LinkedIn password follow-up

Since my previous post  there have been additional reports of hacking into Last.fm and also Dating website e-Harmony (a US-based relationship site) has admitted that a "small fraction" of its users' passwords have been leaked.

Whilst the majority of our readers will not be so interested in the latter, there does seem to be a current spate of web site hacks around.

LinkedIn has said on its blog that it had reset the passwords of the affected users, who would receive an email with instructions on how to set new passwords.


What to do


Security experts have advised users to change their passwords on LinkedIn even if they were changed yesterday. Here's how:

 

  1. Visit www.linkedin.com, and log-in with your details
  2. Once logged-in, hover over your name in the top right-hand corner of the screen, and select 'Settings' from the menu
  3. You may be asked to log-in again at this point
  4. On the next screen, click the 'Account' button which is near the bottom of the page
  5. Under the 'Email & Password' heading, you will find a link to change your password

If you use the same password on other sites, be sure to change those too.

Problem remote posting blog entry with htaccess rule - resolved.

I recently implemented the strict htaccess rules generated by the Akeeba Admin Tools utility.   I then discovered that it was not possible to use Windows Live Writer to post entries to the blog anymore.   It was obviously a problem with the htaccess rules since a simple test removing the htaccess file enabled a post to complete successfully.

Looking at the configuration in more detail the most obvious cause appeared to be two rules related to access the xmlrpc directory:

RewriteRule ^xmlrpc/(index\.php)?$ - [L]
RewriteRule ^xmlrpc/ - [F]

But these rules permit access, they do not deny access. so they were obviously not the cause of the problem.

Then the light dawned.  There was a rule to redirect www addresses to non-www addresses:

RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R,L]

Because the Windows Live Writer (WLW) blog account was set up before the htaccess setting were changed it was set up to use the ‘www.xxxx’ address NOT the ‘xxxx’ address.

For this reason the posting was being disallowed.   The redirection was getting in the way.  Just disabling this one rule enabled the posting to proceed.  It was desirable to have the rule in place, so once I had changed the WLW blog account to use the non-www address posting could resume and complete successfully.

I hope others find this interesting and perhaps do not spend as much time as I have trying to resolve it.

I thoroughly recommend Akeeba Admin Tools Professional as a user since it has stopped SPAM on the site almost completely.  That alone is a triumph.

Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries