Getting back into your website’s back end…
Ever get locked out? After being unlucky
enough to have being hacked recently, my Jet Pack plugin kicked in with a full
lock down, where I apparently was locked out of my own site and did not know
what to do?? So as all good techies would do, Google.ie was my first stop and
then JetPack customer support where a helpful chap called Ryan worked with me on
a trouble shooting regime to try and resolve my lockout issue.
My IP
address was not “whitelisted”, which allows your
home IP address to be accepted by Jetpack if it uses the “Protect” element to
lock down your site against a particular IP address that is trying to gain unauthorised
access to the site’s back end. I never “whitelisted” my IP address which is a big mistake people! You can
whitelist your IP address by doing the following:
- · Set up and/or log into wordpress.com (different to wordpress.org). Select “My Sites” then change site to the affected site. Remember you need to have JetPack installed and centralised management activated for your word press “remote” access to work.
- · Go-to “My Sites” and then “Security” tab to select the tag for whitelisting IP addresses, inputting your IP address, then clicking ok.
- · Once done, you should be able to get back in and administer your site should you have a brute force attack in the future.
If you are unlucky like me and didn’t have
a whitelisted IP address PRE hack attack, you need to do the following as a
recommended approach to resolving the issue:
Check
your email smtp (outbound) email server details on your email (if
patched into your computer) to make sure they are not deleted as part of the
lock down.
Then…
Goto
wordpress.com and log into “My Sites” and then
“Change Site” to the affected site. Go to the security tab and whitelist your
IP address.
Then…
FTP
into your site back end on your hosting server or
find your ftp hyperlink on your cloud provider’s Web App page. Remember your
login and password will be different to your front end details so click on
“download publish profile” (on Web App Dashboard page) to see your “ftp”
details for login, which is usually the first part of your email address and a
very long password.
Go to wp-config and if you have JetPack
installed, define your whitelisted IP address by inserting
“define(‘MY_IP_ADDRESS_OK’, ‘123.22.343.76’)” under the other definitions that
define the connection string (database connection, etc). Click ok, and restart
your site to allow the changes to take affect on the frontend and then try logging
in.
Another way (pre hack) to protect against
brute force attack is to modify (or create) via FTP login a “.htaccess” file
for the back end login page where the attack will likely be focused. The hack
in my case seemed to corrupt word press with view taking control of the back
end resources. I noticed data spikes (outbound) on Azure when I was not using
the back end due to being locked out.
Another learnt lesson is to get a clean set
of site backup files and copy them from the Updraft (offline) directory to a
safe location in the event of a catastrophic site attack where operational back
up file sets are corrupted. Repeating this at every development milestone is a
good idea also so you have a clean backup file set should a hacker do
catastrophic damage to your site without you even knowing it, thus substituting
tainted backups for earlier versions that are clean.
I guess the lesson is the same as the
unofficial motto of the boy scouts, which is “always be prepared”. Some main
take away points are as follows:
- a) Whitelist your home IP address via Jetpack OR Word Fence for your Word Press Website
- b) Use a backup plugin like Updraft to back up your website and store a clean copy at all developmental milestones in a secondary “offline” back up folder that is not linked to the one used by Updraft. That way, if you get hacked, you have a clean file set should the Updraft folder contain only tainted file sets, which will most likely be the case.
- c) You can whitelist your IP address via Jetpack directly whilst you have access to your site’s back end or if denied access; via FTP altering the wp-config file.
- d) A good idea is to copy your webpages onto .rtf documents (flat files) so your content is copied off line for the same reasons (corrupt back ups) as in point b.
For Word Press and Plugin developers, I
would advise the following:
- a) Develop two-step authentication for the login page as a core feature of word press. The core is vulnerable via theme and plugin weaknesses, which needs a core security feature such as two-step authentication.
- b) Testing cooperation between providers hosted by Word Press to iron out any vulnerability from plugins, which do the same thing on a site.
- c) Have a Word Press feature that allows Word Press Support to decouple all plug ins, test the site core and every plug in for bugs as they recouple them to Word Press’s site core, whilst keeping the site running. Using the site Admin credentials to download the site into a test environment for this purpose may hold the key.
What the experience has thought me is a
valuable lesson in preparedness, backups and contingency plans for keeping a
word press site running as intended. The need to restore from primary backups
via the likes of Updraft is as important as catastrophic site recovery from
secondary backups like independent backup folders and then site rebuilds from
page templates (including a plugin and associated file lists). They all matter
equally, so don’t get caught after the fact like I did, start your site’s
contingency planning today!
Sources/Credits:
Pics:
Credits;
Email Server Details – Article with
all major services:
http://en.kioskea.net/faq/9166-smtp-imap-and-pop-server-settings-for-major-isps
No comments:
Post a Comment