Search Blog


Get the latest on what's happening at itomic

Informative commentary on the web industry from the experts at Itomic.

May 23, 2016

Itomic’s Firewall. How we protect the websites we host

By Ross Gerring

… a firewall is a network security system that monitors and controls the incoming and outgoing network traffic based on predetermined security rules. A firewall typically establishes a barrier between a trusted, secure internal network and another outside network, such as the Internet, that is assumed not to be secure or trusted.

source: Wikipedia

firewall image

A firewall helps to protect a server from unwanted visitors

Itomic has been hosting websites since 2000, a responsibility we take very seriously. After all, your website will likely be the first impression your prospective clients have of your organisation, and we want this to be a great one.

A wise man once said that a truly secure server is one that is unplugged from everything, encased in concrete, and sitting at the bottom of the ocean. But that wouldn’t making for a very good website hosting service, so we have to make compromises 🙂

One of the ways we make compromises is to employ a firewall. It’s a service that attempts to permit the good guys (e.g. yourself, your clients, and other stakeholders) to view and interact with your website, and block everyone else – the bad guys – from doing so.

But how to tell the good guys from the bad guys? Sometimes it’s obvious, sometime less so. When it’s less so, should we give the visitor the benefit of the doubt and let them in regardless? Or should we block them just-in-case, and risk a “false positive” block? It’s the firewall and associated services that are responsible for making these decisions in the blink of an eye, and taking appropriate action(s). Firewalls don’t get it right every time, but through manual and automatic intervention they tend to get better over time.

Getting a lot more technical (you have been warned!)…

We use ModSecurity and CSF in tandem.

The purpose of ModSecurity is to prevent common malicious web based attacks and close security holes in applications. ModSecurity focuses on HTTP(s) traffic. ModSecurity prevents attacks in real time but does not permanently/temporarily block IP addresses, it assumes other software will be used to parse the log entries for this purpose. Modsecurity works at the application level.

CSF is an IPtables frontend used to automate/simplify firewall tasks. LFD (part of the CSF suite) watches logs to count how many times an attack occurs from an IP address and the timeframe. CSF/LFD work at the server/account level.

This ties in with ModSecurity since attacks are logged each time they are triggered. Here’s an actual example from our log files of a specific IP address ( being repeatedly flagged as malicious because the activity coming from that IP matched a certain ‘bad guy’ rule (id 210831):

root@ariel [/home] # grep /usr/local/apache/logs/error_log|grep mod_sec
2016-05-11 00:11:02.644 [NOTICE] [] mod_security rule [Id ‘210831’] triggered!
2016-05-12 20:46:56.986 [NOTICE] [] mod_security rule [Id ‘210831’] triggered!
2016-05-13 02:26:24.048 [NOTICE] [] mod_security rule [Id ‘210831’] triggered!
2016-05-13 13:20:25.426 [NOTICE] [] mod_security rule [Id ‘210831’] triggered!
2016-05-20 09:20:54.438 [NOTICE] [] mod_security rule [Id ‘210831’] triggered!

LFD obtains the IP address from the log and creates a counter and a timer. The counter increases by 1 each time a rule is triggered up to 10. If an IP address triggers a certain number of rules (e.g. 10) within a certain time frame (e.g. 1 hour) the IP is blocked using CSF. If an hour passes and the IP did not trigger 10 rules the counter is reset to 0 for that IP.

Need assistance with your website hosting, shared or dedicated? Call Itomic today on 1300 ITOMIC for all-Australian website hosting.

February 12, 2016

Drupal 6 end of life. Official support drops from 24 Feb 2016. Your choices.

By Ross Gerring

It’s been standard Drupal policy for some time that only the current and the previous major versions are officially supported, at least as far as core security updates are concerned.

Drupal 8 was released in late 2015, and the official Drupal 6 end of life date for Drupal 6 sites was set at 24 Feb 2016.

So as an owner of a Drupal 6 site, what to do?

Option 1: Do Nothing

Drupal 6 end of life doesn’t mean site is going to collapse in a heap on 25 Feb 2016. As at 31 Jan 2016 you’re still in very good company, with over 100,000 sites worldwide still using Drupal 6, see:

Although support might no longer be “official”, there will still be a great deal of unofficial support going on for Drupal 6 sites for some time to come. That said, especially where security updates are concerned, such support will likely take longer to deliver, and therefore be more expensive in terms of labour. This is because Drupal 6 developers are no longer going to be given free security updates through official channels, and therefore will have to work on patches for themselves, which may or may not get shared with the wider Drupal community.

Is your Drupal 6 website hosted by a reputable, good quality hosting provider? In the event that your Drupal 6 site gets hacked, a common sign is that it starts sending out spam. A good quality hosting provider will have the appropriate security controls and monitoring in place to ensure that malicious activity is detected and minimised quickly. Also, a good quality hosting provider will have multiple backups of your site in the event that your site needs to be restored.

How security sensitive is your website? Does it contain financial, personal, or otherwise confidential (e.g. client) information? If it does, then you should be more concerned about the reducing security profile of your Drupal 6 site.

How concerned are you that your Drupal 6 website should be upgradeable to play nicely with the latest industry standards and technologies, such as HTML5, mobile-friendly (“responsive”), web services, etc? The chances are the Drupal 6 will be either difficult (= expensive) or effectively impossible to upgrade. That’s nothing to do with the ending of official support. It’s all to do with the fact that many of today’s standards and technologies weren’t even dreamt of when the core of Drupal 6 was being architectured. And compatible modules to extend the features and functionality of Drupal 6 will only take you so far.

Option 2: Rebuild your site in Drupal 8 (or Drupal 7, or another CMS)

If you have the budget, there’s absolutely no doubt that a rebuild of your site is highly recommended. You can go for an “as is” rebuild, i.e. the same as your current Drupal 6 site, which will keep costs down. Or you can take the opportunity to review every aspect of your current site (design, mobile-friendliness, functionality, content, etc.) with a view to making your next site a significant improvement over your current site.

Notice we deliberately used the work “rebuild” instead of “upgrade” or “migration”. The brutal reality is that Drupal, in common with many other CMS, doesn’t offer a smooth, quick, comprehensive upgrade path between major versions (5, 6, 7, etc.). There are valid reasons for this that are beyond the scope of this article, but the main reason is that the major versions are so significantly re-architectured that, unless your site is a really simple brochure site, all the features and functions will not naturally map from version 6 to version 7/8. Yes, there are Drupal modules and documentation that can assist with moving (primarily) content from Drupal 6 to Drupal 7 or 8… but moving content is typically only a small % of the overall effort.

As stable, popular and supported as Drupal 7 is, Drupal 8 truly is a major leap forward in all areas, so you really want to target Drupal 8 first for your new site. The only, and rapidly diminishing, reason why you might still consider rebuilding your Drupal 6 site in Drupal 7 is if Drupal 8 doesn’t (yet) include some critical functionality that your new site must have, and is too expense to custom-develop.

Of course Drupal isn’t the answer to all the world’s CMS needs. Although generally not considered to be as enterprise-grade as Drupal, WordPress is the world’s most popular CMS. So if your site doesn’t have sophisticated enterprise-grade requirements, you shouldn’t completely rule out other CMS. Do your own research (Google is your friend!), and/or chat with your favourite website development person or agency about this.

Further reading: Drupal 6 end of life

What Happens if You Keep Using Unsupported Software? (OSTraining)
Drupal 6 end of life announcement (

December 8, 2015

Itomic Christmas and New Year break 2015

All Itomic offices will be closed from Friday 18/12/2015 through to Monday 04/01/2016.

Our skeleton team on standby during this period for any urgent support matters, please contact to get in touch. We thank you for your support over 2015 and look forward to an amazing 2016!

Itomic Christmas

July 1, 2015

Have you checked your MailChimp lately? – PSA

By Izumi Mitsui

As MailChimp continues to evolve for the better there’s been a recent update with their API  (MailChimp API V3.0 Release)

Version 3.0 of the API has been through months of development and internal testing. We’ve had it in public beta for 2 months. With this launch, the API is stable enough that applications and integrations can start offering v3.0 functionality to their users.

In light of this, make sure you test any signup forms on your website linked to your MailChimp account to ensure it’s working correctly.

If you notice anything not quite right, let us know and we will get a resolve for you ASAP.

May 14, 2015

Mobile Responsive – Why bother?

By Izumi Mitsui
Most agencies/web developers will incur additional costs to develop a mobile responsive website.
The responsive element will ensure your website will adjust itself to multiple screen sizes across all devices and introduce user-friendly features such as ‘touch friendly’ navigation.


Is it worth the extra cost? Especially if you’re the website admin that only needs to access your website from the office desktop, why would you bother?


Here are 2 compelling reasons:


  1. Numbers don’t lie.
    Ever since early 2014 the mobile figures have overtaken the desktop usage for website access globally.Mobile friendly itomic
    The trend isn’t slowing down anytime soon, the increased advancements in technology allows more people access to affordable smart-devices.
    While you may not have a need to access your website on your portable device, it’s not about you! Your website is for your users/customers first and foremost, so it’s only wise to make  sure its easily accessible for all.
  2. Mobilegeddon has hit and gone
    On April 21st, 2015 Google’s ‘Mobile Friendly Update’ was introduced. (deemed as ‘Mobilegeddon’ by some)
    This update was simple: Google will give favour over to websites that are responsive or have a mobile friendly page over those that don’t.

    Why? Because mobile friendly pages are easy to read, access and increase the chances of the user finding what they’re after swiftly (which is the whole goal of Google).


Take away (for the note takers):

In 2015, mobile responsiveness should be a mandatory term with web development.
If your website is non-responsive we encourage you to take action and stay ahead of the curve.
Unsure if your website is responsive? Take the mobile friendly test 
Additional help available here.