Yesterday, we noticed a brute-force login attempt on our own website. No compromise occurred but the attempt prompted proactive action on our part. Upon contacting our hosting partner, we discovered that this wasn’t an isolated attempt. It was happening to other servers running WordPress.
In our line of work, we witness or experience online hosting issues and hacking events ranging from mischievous to worrisome. This hacking attempt lands in the range of annoying and mischievous because it didn’t succeed.
Typically, we don’t post about these issues. We are alerted to performance issues through an internal monitoring service and handle them for ourselves & clients as they occur. However, I thought this post would be helpful to both peers and our clients.
We suspect this is a scripted dictionary attack because of the particular behaviors observed. According to our hosting partner, servers most heavily impacted are those with limited memory resources – especially those with 1GB of RAM or less.
I want to be very clear that this isn’t a shortcoming of the WordPress software. It’s an inherent issue with the practice of using passwords. Passwords are, by their very nature, not especially secure so it’s important that they are created with some level of security in mind.
Passwords that are based on dictionary terms are the most vulnerable to hacking attempts. We recommend that passwords include both numbers and punctuation to decrease the likelihood that a dictionary attack will succeed.
The security of your password, no matter what your role in the company, is a business continuity issue. In the wrong hands, it’s an open door to problems everyone really wants to avoid.
Simply using “hacker language”, changing certain letters to numbers, isn’t enough. Don’t use your company name, pet’s name, mother’s name, maiden name, etc. That’s just too easy.
For our clients hosting with us, we’ve got you covered. Our systems have been hardened against this attack. If you’re not hosting with us, please contact your hosting provider with any questions or concerns.
For our peers, the initial solution was a mod_security rule that blocks http requests to the WordPress login page after a certain number of failed attempts and then blocking the IP.
I’ll update this post with any further developments, should they occur.