How Tony Perez of Sucuri Sets Up His Own Security
This is a guest post by Tony Perez, the COO at Sucuri Sucuri, the provider of choice of WordPress information security, and WP Engine partner. Tony specializes in malware detection, incident handling, and log analysis. He’s also passionate about Martial Arts, The Military, and Weapons, always welcomes a good MMA fight, and is likely to talk your ear off about website security over a pint.
Holy smokes, what a month right? WP Engine asked me to contribute a post in April for their Website Security month, I was ecstatic to be invited and intended to write this weeks ago, then, as if on queue, the month blew up with issues. It seems like there has been an issue every week, from global brute force attacks, to vulnerabilities in some of the most prominent plugins, to exploiting our trust by leveraging popular plugins to do bad things via their core files.
I know it feels a bit overwhelming and probably makes most of you feel as if you’re better off unplugging the CAT 5e/6 cable from your machine and disabling the WiFi card, or maybe disabling your website altogether. I urge you to not do any of those things. While the internet may be a bit scary and growing in complexity, staying secure often revolves around two things:
- Access Control
- Software Vulnerabilities
This is good. These are two things that you can definitely control to a large extent. I’ll cover how to control these from the perspective of an end-user.
A Pragmatic Approach to Website Security
One of the things I am often asked is, “What do you do, Tony?,” and “What does Sucuri Security do?” to protect ourselves. As a company, we have to eat our own dog food, and we follow the same security processes we recommend to our customers. If you want to know our secrets, read on. In this post I’m going to walk you through the things I do across my personal sites, and the things Sucuri does across our company properties.
A Little Background
I am one of three owners of a three year-old website security company called Sucuri. We’re based out of Southern California, with resources distributed around the world, offering 24×5 operations during the week and 16×2 operations on weekends. Our predominent focus so far has been detection, alerting, and remediation of website malware. With the rise in remediation we started focusing on the preventive suite about 12 months ago and have recently released the product, CloudProxy.
The luxury we have comes from the volume of attacks we get to see. We not only get to monitor our own properties, both personal and professional, but we also get to keep tabs on each of our client sites. We put in an extraordinary effort to track and monitor so we can get ahead of the attacks altogether, and that’s where this post will become most valuable, I hope. Here’s some of the numbers we’re seeing right now across all our sites. Our plugin web application firewall (WAF) is currently blocking about 1 million attacks across its network. CloudProxy is still in beta, so it’s hard to provide much tangible data.
Our personal properties alone see somewhere in the neighborhood of 150,000 attacks a month. This doesn’t include server-level attacks, only attacks against our websites. This includes malformed post requests, malicious URL’s, brute force attacks, etc.. The attacks range from automation to targeted attacks. We’re continually working to combat attacks on our own sites. After all, every self-respecting hacker wants to deface a web security company, right?
Our approach is very simple. We employ the InfoSec concept of Defense in Depth. Defense in Depth is a fancy way of saying “layer your defenses.” You don’t want to put all your eggs in one basket, you want to employ various controls, sometimes 1 or 2 for every area you’re looking to address. The idea is that through overlapping layers of security you greatly improve your protection and reduce your overall risk.
Simple, right? Let me show you how we go about this.
Applying a Layered Defense
When we start putting up our layered defense, we focus on the two areas I identified earlier, access and vulnerabilities. I won’t get into server level defenses so Austin doesn’t kill me for writing 5000 words, so let’s focus strictly on your website.
Many folks undervalue the importance of managing site access. There seems to be a prevailing belief that technology is making web-based brute force attacks technologically impossible. This is false. Last week with the massive bot-net attacks, we saw the reality that when you don’t limit site access, it’s easy to gain control of your site. Even in last year’s compromise of WordPress.comm which saw some 50,000 website owners hacked and serving SPAM posts illustrated that. Fortunately, there are a number of things you can do to protect your access controls.
I do the following:
- Whitelist IPs (instead of blacklisting them)
- Apply Two-Factor / Multi-Factor Authentication
I greatly prefer the whitelist approach over the blacklist as it’s much easier to maintain. Now, I know most folks are going to say it’s impossible to only whitelist my own IPs because the travel all the time or have a team distributed around the world. Right… Everything is possible. The question I like to ask in response is, “what is the impact of a compromise?” Does the colosal risk outweigh the small pain of whitelisting IPs and adding controls to accommodate a global workforce?
Matt Cutts put together a really nice, applicable, writeup on the subject that I’d encourage you to read if you’re looking to do this yourself via your own .htaccess files. The other way, if you’re a client of ours, is to look at our CloudProxy solution. We built this feature in at the proxy level to avoid you having to do any configurations on your own.
You can also do what I do, purchase a cheap VPS which I use solely for SSH tunneling when on the road. This allows me to whitelist the VPS server IP and allows me to go about my business. If you have a small dev team, you can do the same thing and funnel everyone through your VPS. You can also look at getting a VPN service that you use when on the road. That gives you a static IP to employ. The awesome part about this is you’d require someone to first know your IP, and then spoof it in order to brute force. Most opportunistic attackers won’t even bother with that level of security and move onto the next site that doesn’t have that level of security.
I also employ a second layer defense by introducing either Basic Access Authentication, configured via your .htaccess file, or enabling Duo Security Two Factor Authentication plugin. This sends me a code which I have to then have to approve in order to gain access to my administrator pages. If you’re interested in better understanding the concepts around Two-Factor security I encourage you to read Ipstenu’s most recent post on the subject. It was very thorough, and very readable for all users.
Ok, but it doesn’t stop there. The two layers I discussed above strictly focus on getting into wp-admin. There is another dual layer that we focus on to address the “Oh Crap,” moment that ensues if a hacker manages to bypass those controls.
- Least Privileged
The principles of least privileged is simple. Apply only the necessary roles to each user and nothing more. Not every user needs to be an admin or editor. Just the other day a client had 15 admins, and swore she needed all 15 to have those privileges. We went on to ask why and what they did, turns out all they did was contribute articles. None of them needed to change settings or add users.
Out of the box, WordPress comes with a variety of key roles and capabilities, learn them, apply them, and leverage them where possible.
Who isn’t tired of hearing about the importance of passwords? Yeah, that makes two of us, I assure you of that. The importance of passwords is not sinking in to most of the owners of the close to 634 million websites on the internet (as of December 2012). We have to continue to convey the importance of strong passwords to everyone.
Mark Jaquith recently posted his preferred approach to passwords on Twitter. I like it, so I’m going to steal it:
@photomatt Right on. My password advice: C.L.U.E. — Complex, Long, Unique, Esoteric. No one will just “guess” a good password.
— Mark Jaquith (@markjaquith) April 13, 2013
I don’t have room to get into the various issues with today’s passwords but I did write a post about it a while back. The key to remember is that you’re not as unique as you think you are. Attackers know that e = 3 and a = @ or 4. There are even tools designed to check all variation of characters, so you’re not fooling anyone.
To generate complex, random passwords, I use the generators out of 1Password and LastPass, depending on my mood. My personal passwords are often close to 50 characters.
In terms of plugins, Login Security Solution is one I really like to use to enforce my password policy. Not only is the developer well-known in the PHP coding community, but I’ve looked at his code, and love how secure it is. The plugin offers a number of features, including throttling access, enforcing password policies, and giving you actions in the event that you are compromised.
Vulnerabilities are a bit harder for most people to grasp. Why would someone build something with vulnerabilities in the first place? The audacity, right?
The reality is it happens to the best of us – Facebook has them, Microsoft has them, Apple has them. If it happens to these companies with their billions of dollars in the bank, it’s unrealistic to think it won’t happen to everyone else.
What’s my guidance? Learn to live with them, but also learn what to do to protect against them.
Our approach includes:
- Web Application Firewall
- Staying Current – Updating
The beautiful thing about most of the vulnerabilities plaguing WordPress installs is that they come from themes and plugins. To address this, there’s been a massive increase in a number of things known as Web Application Firewalls (WAF). If you look through the repository you’re likely to get engulfed by WAF products. I haven’t tested them all, so it’s hard to provide any really good guidance on which ones to employ.
In the past, our approach was to use ModSecurity via a proxy to offload the attacks on web server resources. As of late, we’ve build a new WAF solution that’s not built on ModSecurity, and functions as a reverse-proxy for websites, our new beta product, CloudProxy. That’s what we employ on all our properties now. The beta is only available to clients so far.
For those that aren’t clients, there are other solutions. I am particularly fond of Incapsula over CloudFlare. My fondness comes from two independent reports that have tested their products from a security standpoint. I wr0te about them here. However, I am personally not a big fan of the WAF plugins because of the limitations they face.
Stay up to date
There is no better example of the importance of staying up to date than the recent issue with W3TC Total Cache and Super Cache. In almost major release of WordPress there appears to be some security issue to address. Granted, most over the past year or so have been marginal. Unfortunately, that is not the same with plugins and themes. Keeping themes and plugins up to date is your first defense against software vulnerabilities, and is much easier than long, random passwords.
If you just add one of these I’ve covered layers to your security, you’ll be better off than you were before. Invest your time wisely so you don’t get overwhelmed. Do what you can. Ipstenu phrased this very eloquently in one of her recent posts about False Security:
Part of security is knowing where to spend your time. – Mika Epstein
She couldn’t be more right. It pays dividends to step back and look at your overall security posture holistically. Think through the things you are doing, asking does it all make sense? Are you really doing everything you can to protect yourself? Are the things you are doing really effective?
I’ll leave this with you.
Complex things, break in complex ways.
The idea of security isn’t that everyone does it the same way. Instead, listen to a variety of sources, and take from each person what you like and apply it. Don’t fool yourself into thinking that because you have every security plugin and service installed and configured you’ll never be compromised. That’s liable to set you up for a very bad day. Stay frosty.
You can find more from Tony about security on Sucuri’s blog, Tony’s personal blog on security, and on Twitter. Definitely feel fre to say “Hi!”
Join the conversation.
There are 8 comments
Awesome post Tony — so much to think about here. Going to be running through a bunch of these ideas and concepts and apply them to our current setups.
Yikes, 50 character passwords, looks like we better increase ours to at least 15 🙂
Thanks for sharing Tony!
Thank for all the info! Great post!
You probably don’t have to go 50, but do try to stay above 15. The key to all this is key in on one area and make it work. Once you feel comfortable, move on to the next.
Nice insight into how your security is setup / levels of security in place. Nice to see that my time on implementing similar procedures is not wasted and undertaken by others.
Great post Tony, I’m sure I’ll be referencing this post often.
Thanks for your article. Our web designer is gun-shy about updating WP as he is afraid that the various plug-ins will be incompatible. As a result, we have an old WP version that has been hacked. Is compatibility really that tenuous and worth risking being hacked?
Compatibility isn’t tenuous at all. WordPress is backwards compatible, which means that chances are great that plugins created for previous versions will work. That’s not true on other CMSs, Drupal for example, is not very backwards compatible.
Additionally, most plugin authors update their plugins frequently, particularly when new versions of WordPress come out. If a plugin hasn’t been updated in several versions of WordPress, that’s usually a good reason to NOT use the plugin. It’s going to be insecure, and there are nearly always other plugins that offer the same feature or functionality.
To wrap up, PLEASE update your WordPress, otherwise you WILL CONTINUE TO BE HACKED. If your developer has problems with that, then he’s standing in the way of your website’s security. It’s pretty black and white.
Let us know if you have any questions.
Well, I wish there was more information about the IP Whitelisting…I am sure the .htaccess fix you’ve come up with is one or two lines (I presume for access to the wp-admin admin directory as suggested), but God is in the details