The regularity in the WordPress login page access attempts (once every 5 minutes) from different IP addresses is quite remarkable. It clearly shows a coordinated attempt to gain unauthorised access to the applications that run on the sever. It was as if someone had configured systems behind those IP addresses, which if they were genuine human users would obviously never have been this synchronised, to attempt a login every 5 minutes.

This highlights an attempt by the attacker to automate a brute force attempt at gaining access. The attacker doesn’t really know much about the system. They are just guessing what the password should be and have setup an attempt to guess a password every 5 minutes, because some systems (they don’t know if this system is like that, they are just guessing afterall) are configured to have a password timeout of 5 minutes.

One thing to point out is that, due to the difference in timings of the DDOS attack and the login attempts, as well as the different geographies the IP addresses were located in (I did a search on who owned those IP addresses and where they were located as part of the investigation), I don’t think the DDOS attack and login attempts are linked.

Hacking Is Literally Hacking

The above information shows that hacking is just that – hacking. As the definition of the word says, it is usually an in-elegant way of gaining entry or breaking something, i.e. hacking your way into something or hacking (breaking) something into pieces.

This does not imply that it’s something to not respect. On the contrary, it means that it can be very, very effective. It just means that it is not something to be particularly frightened off instigated by a super genius like the way Hollywood likes to portray. Take this case for example, the fix was simply brute forcing a physical restart of the VM, and configuring the apache server to restrict some of the requests timeouts and sizes of files it would server back.

Looking further at this DDOS case, all the attacker was really doing was sending HTTP Get (or Header) requests, repeatedly, and quickly in an effort to flood the server with requests, fill up it’s cache and subsequently cause it to fail. It did this by sending 2 requests every second for half a minute, which, for a small server fitting the profile of this type of website, easily caused it to be over loaded.

Obtain Alerts Via an App

For small websites with IT staff not always on site or a dedicated incident monitoring and response team with their own separate infrastructure, it’s best to always have an independent monitor alerting you, loudly, when your website is down. I use Uptime Robot as it has, most importantly, alerting, but also monitoring and configuration functionality, via an app available for free. Other alternatives are available, however, they either only provide alerts via email, which is not ideal for something this important, or charge a fee for in app alerting.

Setup Monitoring and Logging on CloudWatch

As previously mentioned, it's advisable to setup logging and monitoring via CloudWatch. This has the benefits of providing logging capability of CPU and memory usage statistics as well as apache access and error logs which will assist in investigations. Additionally, it will provide alerting functions via email, too.

No AWS support under basic support plans

AWS does not offer any support on its basic support plans (i.e. the free one). This means that AWS will also not offer any features to prevent future attacks, or easily even accept any information from you to help them make future plans for preventing future attacks. Any steps taken, or features adopted, would have to be done without their input.

Application Layer Attacks Are Growing in Frequency and Are Not as Easily Detected as Infrastructure Layer Attacks

AWS does attempt to provide DDOS protection as standard and for free through is AES Shield Standard Offering. This is automatically available to all AWS customers and is enabled by default.

However, Layer 7 attacks, such as in this case an HTTP flood/cache-busting attack are difficult to identify and filter out.

This does not mean that everybody has to purchase an additional subscription to AWS WAF and AWS Shield Advance systems. This is because it’s not certain that those systems would fare any better in filtering out the malicious traffic.

Rather, configuring the web server to mitigate problems might be a better solution before purchasing an additional feature that is not guaranteed to work. Apache configurations, such as in my case where I have limited the size of XML requests, can also be done to limit resource consumption triggered by client input.

Log-in Pages and Web Sites are Routinely Probed for Weaknesses and Unauthorised Entry by Malicious Actors

The investigation proved, once again, that websites generally are targeted for attacks by malicious actors (such as hackers) as standard fare. In fact, it’s best to think of it as a certain that any website, no matter how big or small, will be probed for weakness or an entry point by hackers.

The key takeaway, especially in these days of remotely logging into systems, is to have strong passwords, multi-factor authentication – MFA (which this site has), and if possible, a whitelist of external IP addresses that are only allowed certain types of entry, such as admin access.

This final point however might not always be practical for large businesses who may have employees travelling all over the world and logging in from any IP address in the world. Thus relying on MFA and strong passwords would be the preferred, and possibly only currently practical approach.

My previous blog on setting up a web server goes into details of how web servers can be secured in general and expressly targeted login pages such as phpMyAdmin can be secured.