Script Kiddies and the Complacency of Open Source

SkidI love Open Source technologies as so do many church website administrators.  Open Source Content Management Systems (CMS) such as WordPress, Joomla!, and Drupal can be used to build some very nice church websites and for very low cost. Besides the robustness and easy of use of these CMSs, one of their other key benefits is their rich, 3rd party plugin and widget libraries.  If the CMS doesn’t come with a good form editor, image viewer, or another piece of needed functionality, chances are there are multiple 3rd party components already and immediately available that do this and are free and simple to install.

The facts that Open Source CMSs are free and they come with a vibrant 3rd party component repository are why many church web admins gravitate towards these tools.

However, these same facts also breed complacency and carelessness.

I was shocked to read a report last year by Symantec the online security and anti-virus firm that reported that “religious and ideological websites can carry three times more malware threats than pornography sites“.  Religious sites aren’t being directly targeted by hackers; we just make it far too easy for them.  Our churches need to be a safe haven on all fronts and that also includes an online safe haven from computer viruses and malware.

Unfortunately, much of this issue is due to a lack of rigor and diligence.  Using open source technologies particularly with their corresponding 3rd party components comes with responsibility that your website administrator or vendor needs to assume.  Sure that slideshow viewer you just found for Joomla! would look great on the home page of your website, but does it really work?  What vulnerabilities come along with it?  Did the author consider security issues when he wrote it and is he committed to upgrading it in the future?  These are the real questions you need to worry about before thinking about how great it would look on your homepage.

Unfortunately, I get to talk to a church every couple of months that has had their website hacked, broken into, taken over, used to send spam, or is being clandestinely leveraged as a phishing website.   Often hackers are not trying to just defame your website, but rather leverage its resources.  Once they gain access to your system, they can:  steal your email addresses, use your email server to send spam, setup their own web pages so that you’re website appears as a phishing website.

There are far too many hackers out there and we’re making it too easy for them to do their dirty work.  There is an amateur class of hackers out there is disparagingly referred to by the “professional” hacker as Script Kiddies.  Script Kiddies really don’t know much about hacking, but they do know how to find known, documented system vulnerabilities and then run scripts that search for websites that have not corrected these vulnerabilities.   These Script Kiddies are easily stopped providing we website admins do our job in maintaining our websites.

Here are a few simple rules that you can follow to keep your websites protected:

Stay Current

Your CMS will tell you when it is out of date.  You don’t have to immediately jump on the next version the day its out, but I set a simple rule of never getting more than 2 point releases behind and always upgrade to the next major version within 3 months.  Each CMS will tell you when its out of date.  Here’s what I see on my WordPress site.  If yours says it’s out of date or worse you don’t know if anyone is checking, you will eventually have issues.

Screen Shot 2013-04-08 at 6.24.08 AM

 

 

 

Look Before You Leap With Plugins and Widgets

Before just installing a cool sounding widget, read the reviews and better yet look at the code.  Can’t really read the code that you’re installing?  That means you’re placing a lot of trust in whoever wrote that widget.  You are saying I trust this unknown person to write good code, consider security issues, and keep it updated for me in the future.  Should you really be placing your trust there?

Don’t Customize the Code Unless Your Assuming Upgrade Responsibility

The moment you customize the underlying code on a widget or plugin, you break any future ability to obtain an upgrade from its author.  So when that author issues a security patch for a recent vulnerability that was discovered with their code, how are you going to implement it?

Someone Needs to Assume This Responsibility

Most importantly, someone needs to assume the responsibility for the above tasks.  Religious sites are too often ripe targets for hackers because this responsibility is lacking.  How many years ago did that passionate volunteer create your website?  Yes, you know how to maintain the content, but what about upgrading the code?  If you’re reading this and have no idea what CMS use use, what version of code its currently on, or when the last time its been updated, it is time to look at an alternative.  There are a number of fine church-oriented websites services out there.  Admittedly, I’m biased to my own product, WeConnect, but here’s a list of quite a few good vendors to choose from.

With a little responsibility and effort we can help make our online world a safer place!

Related Posts Plugin for WordPress, Blogger...

Tags: , ,

Author:Joe Luedtke

Joe Luedtke is the Chief Operating Officer for Liturgical Publications (LPi). Joe specializes in Social Media and Web 2.0 and is currently leading LPi’s efforts to move into the on-line world. Joe works for the world's largest and oldest social network, religion, and believes that this social network could benefit tremendously from the the proper use of Internet technologies.
  • Pingback: Script Kiddies and the Complacency of Open Source | Catholic Tech … | Church Web()

  • Speller

    Another thing to get right is spelling. Your / you’re are the wrong way round throughout this article.

    • http://www.catholictechtalk.com/ Joe Luedtke

      Dear Speller, I’m embarrassed, particularly in an article where I speak of rigor and responsibility.

      I re-read my own article and corrected quite a few grammar issues. Thanks for the nudge! I will endeavor to curb my zeal and re-read these articles prior to posting.

  • http://twitter.com/carsonweber Carson Weber

    It seems like the theme for this website is broken (see http://www.screencast.com/t/JnHovokuvcVH)

    The thing I love about Drupal is that the community is über-security-conscious, and I receive an email as soon as a security patch/upgrade is required for any one of the core or contrib modules I employ… which makes Drupal and incredibly secure platform for building websites.

    • http://www.catholictechtalk.com/ Joe Luedtke

      Carson, not to sure what theme you’re referring to.

      However, on your comments on Drupal, I agree completely. The only challenge with Drupal is it requires more technical competency than the other open source CMS’ like Joomla! and WordPress, but if you have the technical capability its a great choice. For the websites I work on, we’ve actually left the Joomla! world about a year and half ago in favor of a little more custom work. We’re still all open source, but employ the Zend Framework instead of an Open Source CMS. One of the key reasons we did this was for security as well as performance.