From time to time we come across legacy applications and deployments that you didn’t know exist until something goes wrong with it. This week it was an unbeknown to me Joomla website that had been ticking over since 2012. However recent visits to the site got this result:
A report came in on this issue and a few checks of the domain DNS revealed it was on a platform we use for domains and web hosting.
Not overly familiar with the hosting company from a website standpoint and even less with Joomla, it was time to first fathom out how it works, and them find the problem and fix
At this stage of the initial report there’s not much that can be investigated on the fly as the whole website was offline. The only clue of the website showing a forbidden error when visiting suggests that there is a permissions conflict o the web server. Having access to the files, this could be tested by trying to browse to specific image files by using the directory path as the reference, however every file tried returned a 403 Forbidden error.
Joomla
The file structure had a lot of references to Joomla, and this was found to be an alternative blogging platform to WordPress. During the website’s commission in 2012, it seemed a choice between Joomla and WordPress, however with hindsight it seems the WordPress won the war. Essentially it’s pretty similar with an administration portal and driven by PHP and a MySQL database.
Of consideration from my experiences of WordPress is the number of updates a site will need over a year due to the vulnerabilities that constantly crop up, noting that the site has not been touched in the two years that I’ve been here, it could have been knocked offline as a result of an exploit.
With this is mind, I had to confirm that behind the 403 error was still a functioning website that could be restored.
Restoring to a New Server
Wanting to see if the site was still there and concerned about vulnerabilities, a fresh install of Windows Server 2012 in a VM was created to download the site and test.
In Windows, the Internet Information Services role was added, and the Web Platform Components 5.1 installed on top.
As a Joomla site is PHP and MySQL, I find the quickest way to get these installed and integrated with IIS is to install a new instance of Joomla via the Web Platform Installer, as it will also install all required packages in order to run on a Windows Server.
The WPI is followed to get the MySQL database and other components installed, the opening of the Joomla setup webpage is as far as is needed to go.
Adding the Website
A copy of the public_html files were restored to the emptied C:\inetpub\wwwroot folder so it can be run by the IIS default website,
To get the SQL database restored easily I used HeidiSQL, this is a great alternative to the go to MySQL Workbench CE, especially as I faced incompatibility issues with SQL version numbers and kept receiving “Bad Handshake” errors when connecting with Workbench.
In HeidiSQL, log in via the credentials entered during the initial Joomla setup. Create a new database in the left hand pane and name it the same as the backed up database.
Then with the database highlighted, choose File > Load SQL File, select the backup .sql file and open, when prompted choose to run immediately. The table structure and data will now import to the database.
Next was to create a user for the website to connect to the database, in Tools > User Manager, add a new user and give it access to Global Privileges.
Connecting
With the fundimentals now in place, the last step is to reconfigure the Joomla site so it connects to the newly restored database.
In Joomla, the database connection settings are stored in configuration.php located on in the root folder. Open this file in a text editor and amend the $user and $password fields to match the user created in HeidiSQL.
As in this instance the MySQL server and web server are on the same machine, $host can be changed to ‘localhost’
Now is the moment of truth, open a web browser on the server and navigate to http://localhost , deep breath encouraged.
Result
To my surprise it was actually there, and visibly intact. While the issue is not solved I at least know that I still have something to work with, and can continue working out what went wrong.
This also confirmed that it was indeed a permissions issue on the live web server, but without access to this it was time to raise a support ticket with the web space provider.
Update
Turns out from raising the support ticket the suspicions of an exploit reigned true. The website was blocked from the web by the provider as it was reported for being involved in a phishing attack, and it would have been nice to be notified of this!
A quick clean and a lot of patching later the site is now unblocked and back online.