If like me, you manage one or more Joomla websites, you will no doubt be aware of the sorry lack of user friendly documentation and the appalling lack of a powerful native log facility. This seems to me to be an enormous oversight on the part of the developers however it is possible with a little jiggery pokery to get the information you need.

I noticed recently that there were enormous amounts (1500 per day) of failed login attempts at the default backend URL (site.com/administrator/). This is to be expected of any installation like this however one cannot help but feel uneasy at the incessant minute by minute brute force dictionary attacks rolling by in the log. If your passwords are secure then you'll almost certainly be fine. If your administrator username is anything but admin, you'll be even better. Still I wasn't satisfied and I decided to call in the big guns.

When it comes to defence against brute force attacks, few tools are better than Fail2ban. In the words of Wikipedia:

"Fail2Ban is an intrusion prevention software framework that protects computer servers from brute-force attacks. Written in the Python programming language, it is able to run on POSIX systems that have an interface to a packet-control system or firewall installed locally, for example, iptables or TCP Wrapper."

It really is a great tool for defending against the legions of casual script kiddies.

So, to work. I needed to configure F2B to ban anybody (any address) which appeared regularly in the log as having failed authentication. First I needed to find the logs.

It turns out that the logs are to be found at System > Global Configuration > System > Path to Log Folder. On my system this was in ~mysite/administrator/logs. Who knew!

Armed with this information it was time to set up F2B.

I already had F2B set up covering such things as sendmail and sshd so it was just a matter of adding support for a new service. I won't go into detail about setting up F2B from scratch as there are plenty of good guides out there covering that.

It was the paucity of guides covering the addition of a service to F2B however which prompted me to write this post. There just doesn't seem to be one which is set out properly and logically so Ill do my best to cover it here.

First, it is necessary to navigate to /etc/fail2ban/filter.d/ and create a new filter file to protect Joomla. I called mine joomla-login.conf and its contents are shown below.

# Fail2Ban configuration file

#

# Author: Paula Livingstone

# Rule by : Paula Livingstone

[Definition]

# pattern(s):

#2018-10-12T09:23:16+00:00 INFO 185.206.225.144 joomlafailure Username and password do not match or you do not have an account yet. ("admin")

# Option: failregex

# Notes.: regex to match the password failure messages in the logfile. The

# host must be matched by a group named "host". The tag "<HOST>" can

# be used for standard IP/hostname matching and is only an alias for

# (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)

# OPTMISED REGEX (good for J1.5 - J2.5 - J3.xx)

failregex = ^\tINFO\ <HOST>\tjoomlafailure\tUsername and password do not match or you do not have an account yet.*$

This file tells F2B the make up of the lines in the log and, by using Regex, enables it to parse the necessary information from the lines within the log.

Having completed this, we now need to add an entry to our jail.local file which can be found at /etc/fail2ban/jail.local. Within this file we add the following:

So, all that remained was to restart the F2B service and watch the attackers get banned. F2B has the facility to send an email each time it carries out a given action so this is no great shakes to set up and watch the fireworks.

The Information Commissioner's Office today published new guidance for home Wi-Fi security after a YouGov report found that 40% of home users did not understand how to manage the security settings on their networks.

The survey also found that in spite of most ISPs now setting up and installing security on Wi-Fi equipment, 16% of the people surveyed were unsure whether or not they were using a secured network, or were aware they weren't, but didn't give a toss either way.

The new guidance includes information on managing encryption settings and how to think of a secure password. Top tip? Don't use pa55w0rd.

Giving people unsolicited access to your network could reduce connection speed, cause you to exceed data caps, or allow hordes of criminals to use your network for nefarious purposes, said the ICO.

Welcoming the move, D-Link's Chris Davies pointed out that there was no excuse for being caught out.

"There is no doubt that in the past setting up security on wireless networks could be tricky," said Chris. "But this is no longer the case with most wireless products.

"Security can be set up wiin a couple of minutes with no prior technical knowledge required. We've also been working with ISPs to help them ship products to consumers with security pre-configured."

Let's just hope the ICO doesn't start fining home users for data breaches. Or maybe that would be the kick in the butt some of them need?

As IT systems continue to extend across multiple environments, IT security threats and vulnerabilities have likewise continued to evolve.

Whether from the growing insider threat of rogue and unauthorised internal sources, or from the ever increasing number of external attacks, organisations are more susceptible than ever to crippling attacks. It's almost become simply a matter of "when it will happen" rather than "if it will happen."

For IT resellers, security issues have always persisted as critical to all communications for an organisation's IT department.

However, with the increase in the levels of access to a company's network compounded by these maturing threats, it is no longer feasible to merely recognise the existence of more simplistic, perimeter threats.

Resellers must be able to provide customers with a comprehensive risk assessment of the entirety of an organisation's IT assets to their vulnerabilities--inclusive of both software and hardware.

This risk assessment must incorporate an understanding of external threats and internal vulnerabilities and how the two continue to merge to create increasingly susceptible IT environments.

At the most basic level, organisations and resellers alike must understand the different types of threats. Malware, a generic term for malicious software, such as trojan horses, worms, and viruses, is the most common form of attack that is originated by an external hacker. Malware attacks have persisted for years - from the infamous Morris worm to common spyware attacks - and they remain the easiest and most damaging tactic deployed by malicious hackers.

With enterprises extending to the cloud, and more organisations adopting SaaS-based applications, social media and other Web 2.0 tools, damaging malware attacks and viruses can now originate through simple SPAM messages and emails.

Internally, organisations are typically susceptible to threats from either authorised rogue users who abuse privileged accounts and identities to access sensitive information, or unauthorised users who use their knowledge of administrative credentials to subvert security systems. It is this type of vulnerability - unauthorised internal access - that has continued to emerge as the most volatile and disruptive.

To truly understand the risks involved with these "insider threats", organisations and resellers need to understand the root of the vulnerabilities.

Most commonly, the risks lie with the use of embedded credentials, most notably hard coded passwords, a practice employed by software developers to provide access to administrators during the development process. The practice occurs frequently since application developers tend to be more focused on the development and release cycle of the application, rather than any security concerns. While it may appear harmless at first glance, it is extremely risky as it can potentially provide unauthorised users with powerful, complete access to IT systems.

To compound the matter, by hardcoding passwords to cover embedded credentials, vendors create a problem that cannot be easily fixed nor assuaged by tools such as Privileged Identity Management systems. Once embedded into an application, the passwords cannot be removed without damaging the system. At the end of the day, the passwords provide malicious outsiders with a bulls eye target - a key vulnerability to leverage to help them gain powerful access and control on a target device, and potentially throughout the entire organisation.

One of the most well known examples is the Stuxnet virus. We've all been blown away by the design of Stuxnet, and were surprised by the pathway the virus took in targeting SCADA systems. Reflection shows that the virus used the hard coded password vulnerability to target these systems - which should serve as a lesson for all businesses.

The existence of vulnerabilities embedded within these types of systems is not necessarily new, but the emergence of new threats continues to shed light on the ease with which they can be leveraged for an attack. While malicious outsiders and insiders have focused often on the administrative credentials on typical systems like servers, databases and the like, in reality, IT organisations need to identify every asset that has a microprocessor, memory or an application/process. From copiers to scanners, these devices all have similar embedded credentials that represent significant organisational vulnerabilities.

While steps can be taken to proactively manage embedded credentials without hardcoding them in the first place - Privileged Identity Management tools can help - the onus is on the organisation, and the reseller, to ensure that a holistic view of all vulnerabilities and risks has been taken.