The what and why of WordPress security – WPCampus 2018 – WordPress in Higher Education


– [Paul] So, Good morning. My name is Paul. I am thrilled to be
back here at WPCampus. It’s been a couple of
years since I’ve presented, and I’m excited that all of
you are here joining me today. This presentation came about
because of a conversation that I had with our
fearless organizer Rachel. I’ve seen her in St. Louis
back to the airport one day, and I said, “You know, I really wanna “to do another presentation
that’s focused on security “but all of my ideas are
focusing really heavy “and are leaning quietly
for the tech side.” And she said, “Why?” And I said, “Well, because
everybody by now has read “how you secure your WordPress site art. “You know, what else can I talk about?” She said, “Well, just
because they’ve read it, “just because they’ve done it, “doesn’t mean they necessarily understand “why they’ve done those things.” And that’s when the light bulb went off. I went back, I began to research, and I read every single
article in the top 10 guides, ultimate checklist WordPress security. I began to tally all of the suggestions. So, what I wanna share with you today are the most common
suggestions you’re gonna see when you go out and research, but we’re not gonna talk about the how. You can certainly use the
information to do the how, but what I wanna focus
on are those suggestions and why they’re suggested,
and more importantly, I wanna talk about the security principles that those suggestions tie back to because I believe if you
understand those principles. You’re gonna be better informed to make informed decisions later on. I’m gonna put this back up here, so again, if you have questions, make sure you use that
hashtag and tweet at me. So, the other thing I
wanna warn you about, is I do talk a lot in
terms of ideal situations, ideally you wanna do something. This is my 19th year in higher education. I totally understand that we
do not work in an ideal world. I get it, trust me. So, I’m gonna try and give
you as many practical steps as well as well as the ideal. The other warning that I’ll give you, a lot of good content that I
wanna share with you today. I was packing slides. Way more stuff than I
could possibly get through. So, I’m gonna be going pretty quick. This is my small coffee mug, I just had the bigger coffee mug, and I’ve already gone through this. So I also get hyped up
pretty well, I drink it all. So, I go really, really fast. However, it is my goal
that when you leave here, you know more than when you came in, and I don’t like to think. So, if at any point,
something doesn’t make sense, you’re still not clear on something, don’t hesitate to stop me. It’s far more important
to me that you understand these concepts that I go over, than it is for me to get
through these slides. Deal? – [Man] Deal. – [Paul] All right. I always like to start with a TL;DR. In this case, everything I’m gonna go over boils back down to minimizing risk. Every suggestion that we go
through really comes back, you need to minimize risk. You need to do the things that
are gonna minimize that risk. So, hello! (audience laughing) I have a whole bunch of people! (audience laughing) Wait a second, these are the
hecklers that came in together. Minimizing risk. So before we can talk about risk, we have to make sure we’re all talking about the same definition of risk. So what is risk? Well, risk is the intersection of assets, threats, and vulnerabilities. Well, we need to
understand what those are. So let’s talk about assets. Assets are all the things
we need to protect. It could be data, it could be information, it could be systems, it could be hardware. All the things that are important to us that we need to protect. A threat then is anything that could have a negative effect
on those assets, right? So what we need to protect against. I’m also gonna use the term threat agent. Threat agent is an entity
that initiates a threat or makes that threat occur. A vulnerability then is a
weakness somewhere in the system. In your code, or procedures, or policies, but it could also be a gap
in our security posture, and it’s gonna be the thing
that a threat or a threat agent exploits in order to have
that negative effect. One of the best analogies
I’ve ever come across for explaining risk or understanding risk, is let’s say you are the asset. The threat is rain. So who’s the threat agent? Mother Nature, okay? (audience laughs) So the vulnerability, what’s that? (overlapping talking) So the vulnerability then,
you had hole in your umbrella. The risk therefore then
is you are gonna get wet. Or maybe, there’s a
chance you could get wet. Now there’s one key piece of information I’m missing from the original definition. Let’s say in the scenario,
you’re walking home from work, and it’s a beautiful, warm day. It just happens to be raining. You get wet. How big of a deal is it? It’s annoying, right? It’s annoying, you get a little wet, you get home, clothes in
the dryer, no big deal. Let’s say instead you just
bought a brand new pair of really expensive shoes, and you’re on your way to some big event. Now how big a threat is it? – [Man] Much worse. – [Paul] Way worse, right?! So we have to take into account the impact that that threat has. So for purposes of this presentation, this is the definition
we’re gonna agree to. And that is a risk is the potential for loss, damage, or
destruction of an asset as a result of that threat
exploiting a vulnerability, multiplied by the impacts
of that threat occurring. Makes sense? – [Man] Yes. – [Paul] We’re good? All right, so I wanna talk
real quick about how we, as an industry, how
higher ed as an industry, is a little bit different
from the rest of the world. Why are we attractive to attackers? And the first is network
capacity and availability. How many of you been around on campus when your network goes
down, students are there? What’s it like then? It’s horrible, total chaos, right! We have lost capacity. We have to be up all of the time, so have tons of availability. So if you’re an attacker and
you’re looking to run a botnet, that is extremely valuable. All right, the next up is we
are often rich in hardware. All our faculty, and
machine, our staff machines. Students bring in machines. We get connected devices. If you’re a research institution, you might have your own data centers. If you’re a big research institution, you might actually have super
computers on prem, right? Well for all that which is in hardware, we’re also extremely poor in
those people resources, right? The people power to go in
and manage, and maintain, and update, and secure
these hardware devices. And that’s where we become
ripe for exploitation. Because not everybody can have a value.edu you have be vetted, we’re all resistant to blacklisting. So you could actually have
some problems in your domain, and not get blacklisted right away because you have to be
vetted to have that value.edu Well if you’re a Black Hat, and you’re looking to run a spam campaign, that’s extremely important because you can run that spam campaign for a lot longer without
getting blacklisted. Along with that, the SEO
reputation of .edu’s. So usually search engines
give a higher ranking to those links coming from a .edu domain than they do with others. So again, if you’re a Black Hat and you’re looking at doing
Black Hat SEOs campaigns, that’s gonna be an extreme value. In addition, we have all kinds of personal and identifiable information. If you happen to have a
hospital or a med school connected to your university, if you’ve got possibly health information. If you’re a research institution, you have confidential
intellectual property. You might have export data. You’ve got government contracts. You might have National
Security Interest data. What are these all examples of? Assets, right?! Extremely valuable assets. This is why we as an industry, unlike most of the rest of the internet, are not just targets of automated attacks, those that fire out and to get everybody, like Microsoft guys. We actually are often the
focus of targeted attacks, from both nation-states
and criminal organizations, because we have stuff that they want, which means we have to
be even more vigilant about securing our stuff. Okay, I’m gonna say that the
list of items I’m gonna go is not the list of importance. I wanna make sure
everybody understands that. It’s in the order of which you’re probably gonna come across this. Make sense? All right, so the first one, backups. Well, what do I mean by backups? Everybody should probably
know that that’s a snapshot of both the files behind your website, as well as the database, all right? Well why, why do you need
to backup your stuff? (muffled audience member talking) What’s that? – [Man] So you can get it back. – [Paul] So you can get it back? Always have a Plan B, right? Well, backups are designed to
address two types of threats. First, is the threat
of data loss or damage, and the second is the disruption of your site or your service. All right, so how does this, how do backups reduce risk? (muffled audience member talking) Because you can always go back. It lowers the impact
of the threat, correct? If you know you got a
solid backup in place, losing some data, or losing it altogether, isn’t as critical because you can go back. Now, keeping with the
theme of gaming production to campus this year, I’m gonna talk about bonus points. You’re gonna earn bonus
points for these things. So, several of the things that I noticed when I was doing this research, was that a lot of the
articles didn’t discuss how often you should back
up, what you should backup, the types of backups you should be doing, and how to protect those backups. Now, there were some, but just not as often as you
just have, you should backup. You’re kinda just saying
backup and left you hanging. (audience laughing) So, what should you backup, or how to some of this start, with how often should you backup? – [Man] Depends on your data. – [Paul] Depends on your data, right? It depends on how much risk
you’re willing to accept, and how much risk you’re willing to accept in losing that data. So, as a rule of thumb, I would save them daily, start with daily. Now, if you already know, we only make about like
an update once a week. All right, well just have your updates to happen right after that. If you’re more often, you might have to adjust that schedule. What should you backup? – [Man] Everything. (audience laughing) – [Paul] You could do everything, but backups are gonna be expensive. You’re gonna have to pay
for that storage, right? So you should backup those things that you can’t get from elsewhere. Ideally, that’s gonna be the contents of your uploads directory
and your database, because you have custom
things and plugins. Where should that live, ideally? – [Man] Version control. – [Paul] Yeah, version control! So maybe just push you over
to the replace version. And where should you get the
rest of your plugins and these? – [Man] The repo that you– – [Paul] The repo, the originating source, ’cause you know those are clean. That’s ideally. (audience laughing) Yeah, that’s in quotes,
right, that’s in quotes. So, it might mean that you
have to backup the entire WP contents directory. It’s totally fine. Just know that in the event of a breach, it makes it more complex because now you’re gonna have to make sure that all the other things in
that backup aren’t corrupted. Good, all right. So some other things are how
long should you keep a backup? Depends again on (audience
laughing drowns out Paul) I came across a (audience
talking drowns out Paul) And they actually did a really great job. They had daily backups for 30 days. But then what happened? (muffled audience talking) Yeah, the breach occurred before the 45, and so they were left again
with no backup solution. So, I suggest start with three months, and then go from there. Again, it’s gonna depend on
how much risk you’re willing to accept versus the cost
of retaining those backups. Now your backups should be in triplicate. This is one thing that I
will give Mikey credit for. He just did a post
Tuesday about the types, and some other things I talk about. In fact, I messaged him,
dude you stole all my slides. (audience laughing) So, backups should be in triplicate. You should have a hot backup. One that is immediately
right next to your server, so you can have immediately
restore in case of a situation. You should have a cold
backup that’s close, that takes a little bit longer, but it’s physically separated, and then you should have a remote cold or long-term storage backup that is geographically
located somewhere else. So if the place where your physical server or your services live, is cratered, you still have that additional backup. Now a lot of cloud storage systems have made this a lot easier because you can actually sync
your code to your long term, and then you got it out in the cloud which is actually multiple locations. Now, as soon as you make a backup, what does the backup become? – [Man] An asset? – [Paul] An asset! (audience laughing) It’s one more thing you
gotta protect, right? It becomes an asset. So, a lot of the backup
plugins that you can install, put them in the uploads directory. The uploads directory just happens to be a publicly accessible area. Now they do try to protect those
by blocking access to them, but there’s still the ability
for service configuration, environmental configuration,
those things to be exposed. So as a bonus point, don’t store them in publicly accessible areas
even if they’re blocked. Move them out, let the backup plugin run, chuck ’em over somewhere else that’s not publicly accessible. Last, and nobody talked about this except for Michael’s post, is test your backups. The last thing you wanna do
is go to and have to go back and restore and then
discover they’re corrupt, they’re incomplete, or
your scripts have not been running for six months,
and you’ve got nothing. So make testing those
backups part of your routine. Second one that is most often mentioned was keeping WordPress up to date. I’m sure you’ve all
heard that over and over. You know what it means, but why, how does it reduce the risk? Well those updates often
address security issues. They often contain security updates. And those potentially remove an exploit or an exploitable vulnerability. So I am gonna mentioned
the hows real quick, and notice they’re asterisked. So, don’t turn off the
automatic minor updates. Keep up to date with the latest
branch release of WordPress. But that’s ideal, right? How many of you have strict
change manager policies where you cannot introduce change except within timeframes? I know, okay, at least a couple of you? Right, so again, that’s ideal, right? So if you are in this type of situation, where you can’t introduce
change right away, you might be candidate, a good candidate, for investing in a web
application firewall. Does anyone not heard of
web application firewalls? (Paul mumbling) Or is everybody cool? Everybody knows what those are? Need any definition,
anybody need a definition? You guys good? Okay, all right. So a web application firewall
is a piece of software that sits between your
site and the internet, and it intercepts requests to your site. And it looks at them and evaluates them, and if it determines
that those are malicious, it drops them, they can’t even get. So this can buy you time between when a vulnerability is disclosed, and when you’re able to
introduce those changes, patch those systems. You can drop those packets. All right, I said stay up
to date on the latest branch because, while I give
kudos to the core team for always so far going back
and backporting security fixes into those older branches, that doesn’t mean they’re
always gonna be able to do that. The latest branches is always
gonna have the most focus, the most eyeballs on it, so as best as possible, stay up to date. So what security principle
does this tie back into? Well, it’s either don’t use components with known vulnerabilities, or patch and remove those vulnerabilities as soon as possible. Third one is strong passwords. Again, I am sure you’ve all been hammered to death on strong passwords. I won’t be too long on this. What a strong password is
you wanna have a complex set of characters that is long and unique, that doesn’t contain any
common dictionary words. And how does it reduce risk? How does it reduce risk? – [Man] Makes it harder
to (muffled speaking) – [Paul] Yeah! Makes it harder (audience
member drowning out Paul), somebody to either guess, or, historically what we
referred to as brute force where you just tries
every possible combination of letters and characters, and try to guess your password. And the ultimate goal though, the threat we’re protecting against, is unauthorized access. We don’t want somebody to have
access they shouldn’t have. Now even more important
than complexity is length. In fact, adding just three
or four more characters to the password as the same entropy, the possible total
numbers of combinations, as does adding extra complex characters into that base password. How many of you of fans of XKCD? (muffled speaking) He did a great little article
about this very thing, right? He created these really
complex, hard passwords to remember when we really need is length. But wait, what if
instead we combined them? We take really long passwords,
make them totally random, with a whole bunch of extra characters. So here’s your new password, all right? And if we were to take a
billion guesses a second, it would take, I’m not gonna
say that, a really time. (audience laughing) A really long time to try
brute force that password. So we’re gonna need to take this password, and we’re gonna use it everywhere, right? – [Man] No. – [Paul] Oh good (audience and
Paul talking over each other) What’s even more important? Uniqueness, right? Everything, every password you
use should be unique, right? Because, as of 2017,
seven billion sets of, b with billion of b, sets of
credentials have been leaked. Now Mikey mentioned this yesterday. Has everybody heard of Have I Been Pwned? – [Audience Member] Yes. – [Paul] Yeah, all right. If you have not heard
of Have I Been Pwned, I actually have it up here somewhere. I thought I did. There it is. Have I been Pwned has
collected five billion of those sets of credentials, and you can actually search
to see where your credentials may have been leaked. I encourage you to make
this a routine thing that you go and check just to make sure, because what’s happened
is all those credentials and passwords have been compiled, they’ve been analyzed,
they’ve been cross referenced, and we now have large collections of what the most common passwords are. So instead of typical brute forcing, or historical brute forcing, we no longer see that. What we see now are gonna brute forcing it tends
with common passwords, or they actually purchase the full set of username and password and do something we now call credential stuffing, where they go and try those
known usernames and passwords in a bunch of different systems to find out where they’ve been used. All right, so, here’s all your passwords. You have long, nice, complex passwords. How many of you can remember all of these? (audience laughing) Exactly, right? So how many of you use password manager? Religiously, every day,
for every service you have no memorable password
except the ones you have to? I see a couple of you, none at all, I’m serious. Use password, like, as soon
as you get out of here, go and find a password managers. There’s pay ones that are really nice and do a whole bunch of stuff for you. There’s free ones. Get a password manager
of some sorts, okay? There’s just no way you can remember those complex passwords, but it’s crucial, crucial that you use complex, unique passwords everywhere. You also need to make sure
that you’re doing that for everyone, or to everyone
I should say, on your sites. Make sure everybody on your site is using strong, unique passwords. It might be just (muffled)
plugin, not (muffled) that actually checks
(muffled) for passwords. (muffled audience speaking) That’s an hour work instead of two. So you could use that. We in education though are often lucky in that we have single
sign-on systems, right? Integrate with those
single sign-on systems. Those systems are designed
from the ground up for authentication, right? That’s what they’re built for. They’re built to handle, let’s see, you got password audits,
and password resets, and password recoveries. Take that responsibility,
remove it from WordPress because that’s not
really what it’s best at, give it to something that’s built for that from the ground up. And then, for you, again, everywhere, don’t reuse a password anywhere because the last thing you wanna do is have those credentials out there that then makes your password
on your site a vulnerability. All right, so number three,
tied for number three, is keeping your themes
and plugins up to date. Just like core, you wanna make sure that you keep those schemes
and plugins up to date with what developers have released. Unfortunately for you, there is no real standard
for versioning, I should say so just looking at a version number, you have no way to tell if
the developer has releases. Security update or a bug update, and in addition the change
logs aren’t standardized. So some developers won’t
mention a security fix at all. Some will call them a bug fix. So you really have no way to know when you see that there’s an
update, what the update is. The best course of action
is just update everything as often as you can. Ideally, ’cause some of these strict change management policies. So again, if you find yourself, you got strict change management policy, the waft can help mitigate that risk until you’re able to patch the systems. So some bonus points is you should know what you have installed and more importantly why. If you login to your dashboard, and you can’t immediately
go through that list and know exactly what
those things are doing, that’s a problem. I have come across way
too many infected sites where I go in and I go
you’re five versions behind. Why are you not updating this? Well I don’t know what it does, and I was worried it was gonna
break the site by updating. That is not a situation you wanna be in. So what are those plugins, and remove those that
are no longer in use. The other thing you wanna do is limit your plugin and theme use. I’m not saying don’t use plugins, don’t use themes, but limit. Patch management is hard, and the more things you add
in that have to be patched, the more complex it is
to initiate those patches and do those patches. So limit it to just exactly what you need. Everybody good so far? – [Man] Mm-hmm. – [Paul] All right, next
up is hosting provider, specifically we need to talk about choosing a good hosting provider. The reason is it doesn’t
matter how much time and energy you spend
securing your WordPress site if your host is insecure, right? It’s that weakest link in the chain. So, you wanna make sure
that, oh excuse me, and it’s also one of the top
vectors for compromised site. Security principles in play here could be don’t use components with
known vulnerabilities, (mumbles) patch those
vulnerabilities as they come out. It could be establishing secure
defaults and failing safe, and beyond does a good job at this. If you fail that should
have like WP config, doesn’t contain any of
your database information, and it all points to environmental though. So if there was a
security misconfiguration and your WP environment was exposed. It’s alright, they failed safely. So failing safely, separation of duties in isolation of services
both of site, it should say. So separating sites so they can’t cross contaminate each other, but also segmenting or isolating services so they can’t contaminate each other. Now many of us don’t get to choose our hosting provider, right? Am I right? Also as a bonus point, go back, you don’t control
your hosting provider. Go back and at least look and evaluate. Okay, what am I running? What is running on this
service that I run my sites on? And look, and begin to
engage in those teams. If you notice that Apache’s out of date, go to those teams and say now
you know this is out of date. Can you explain why? It could be that they actually
backported a security fix, the version number just didn’t change so it’s a false positive. But it could be that they were hesitant to introduce that change because they didn’t know
how it affected your site. So go back and work with those teams. Number five is limit login attempts. It’s simply some mechanism that as someone is attempting to login,
there’s X number of failures, it’ll either block the
account or block the IP. How does this reduce risk? (muffled audience member talking) Right! And if it’s brute force, if the threat is unauthorized access like we talked about earlier. The vulnerability’s a weak
or compromised password, then this is gonna reduce that ability for the attacker to iterate
over those common passwords. So the security principle in play here is minimizing attack surface. We have another phrase
we have not defined, so let’s talk about
minimizing attack surface, or what attack surface is. So you can think about attack surface as being all of the different ways, all of the different paths,
and avenues, et cetera that commands and data
come into your application and back out of the application, plus all of the code that
secures those pathways, plus all of the data, third-party
data, and your own data, flowing through your application. Plus all of the code
that protects that data, because your code that protects the data can have vulnerabilities. So this makes up the entirety
of your attack surface. What’s that? – [Man] That last bullet
is what was scary, but yeah, that’s cool. – [Paul] So to further illustrate this, we’ll go back to our rain example. So if I had an umbrella and it’s raining, I’m protected when on top, right? Well what happens if
a big ol’ gust of wind blows from the side? I got all of this attack
surface that’s available, right? So our beautiful model has
demonstrated minimizing that attack surface. They have a raincoat on,
they’ve got galoshes, and they minimize the ability
for that threat to occur. That makes sense, it’s
minimizing that attack surface. All right, good, see how
much you’re learning. All right, so it’s gonna
slow down those attackers from those brute forcing
or credential stuffings. In addition, it’s now freeing some of your own site resources because your site is no longer having to respond to all those
authentication hits. Bonus points is make
sure that whatever method that you’ve engaged or used is also taking into account XMLRPC. XMLRPC that an API that allows us app to app communications in WordPress. The older one that was
there before REST API, that has authentication on it. If you and the developer
use authentication methods in the REST API, make
sure it’s also taking into account that as well. Number five was default credentials. That’s the fifth most common one or probably the fifth most common one. This is security
principle or best practice that in any new system you bring up, you change the defaults. You don’t wanna bring up a running system and leave root root as the
username and password, right? So one of the most common suggestions is that you remove or rename
that default admin account. You do that because attackers are gonna start with those defaults, they’re gonna start with admin. However, and Mikey brought this up. For those of you who were in his presentation
the other day saw this, but I happen to be a huge fan of WPScan. If you saw my previous
access denied presentation, that I would just do a
full thing of WPScan. Everybody see this in back? Okay, so WPScan is a
black box scanning tool specifically written for
WordPress for evaluations with those root finds things
in use and plugins in use, but one of the other things it can do is do some brute password
attacking with common passwords. But the other thing it does is notice, and I’m gonna do it on this board, notice what it found. It does user enumerations. So even though I changed
the admin password, what are you gonna find? That changed the admin account, excuse me. What did it find? The admin user, and then I had brute force against some 1500 common
passwords and look what I found. It’s able to identify that password. So in addition to just
changing the admin password, you wanna make sure that you remove or at least reduce the
account enumeration you do because it’s not gonna do any
good to change the admin user if they can just turn around and scan, and grab those usernames and start brute forcing again anyway. All right, number six is two factor and
multifactor authentication. Simply, if you’ve never heard of this, it simply adds an extra layer
to the authentication steps. So after you login, you have to provide some
third piece of data. That typically happens
with either a email, it’s send you an email to your account and have to grab a ping. It might ping your phone,
might text message you. You can also do hardware with YubiKeys, as your extra authentication. So how does this reduce risk? (muffled audience member speaking) Yeah, you got more things, right? It adds an extra layer of
defense to that attack. So somebody is trying to get in, somebody is trying to
get unauthorized access, this gives one extra layer to that. So the security principle here
in play is defense-in-depth. Has anyone not heard of defense-in-depth? Please, somebody raise their hand, otherwise I’ll be sad. There we go, okay. So I’m gonna explain defense-in-depth. We’re sticking with games, okay? In Missouri, we have a
game called cornhole. (audience laughing and talking) So does anybody know
what I’m talking about? Okay, so it’s a game
where you got a board, and it’s got a hole in it. Usually an old style
coffee cup underneath it, and you got bean bags, and you’re trying to throw
the bean bags in the hole. – [Woman] Lotta times, we call ’em bags. – [Paul] Just call ’em bags? Okay, whatever, so I’m gonna draw and then I’ll stoop this back up in case you can’t see ’cause I’m really short,
I understand that. (audience laughing) So let’s say instead of a flat board, we got a round one, all right? And that board has four
holes and it’s spinning. (spinning noise) How hard is it to get your
beanbag through the board, through the hole, win the prize? How hard is it? What’s that? – [Man] Crazy town hard. – [Paul] Crazy town hard, really?! (muffled speaking from audience member) – [Man] Got a lot of options. – [Paul] Got a lot of options, right? All right, let’s say it’s not one board, it’s two boards. Second board has three holes, small ones, and it’s spinning in
the opposite direction. Now how hard is that? – [Man] Stacked? – [Paul] Stacked. Well it’s like this. So you have to pretend, sorry. (muffled audience member talking) Spinning that way and this
one’s spinning this way. (muffled audience member talking) So how hard is that? – [Man] Harder. – [Paul] Harder, but you
could still kinda watch, you get a rhythm and figure
out where the holes align, and throw it through, right? (audience laughing) Let’s say it’s not two, let’s it’s three, it’s four, it’s five, it’s eight boards, all stacked one another, all spinning in the opposite directions from the one in front of it, all with holes in different places. Now how hard is it? – [Man] A lot harder. – [Paul] It is extremely hard. That’s defense-in-depth, all right? Defense-in-depth, it
acknowledges that every layer of defense either has or could have holes, could have vulnerabilities. But by stacking a whole bunch, we’re gonna hopefully
slow down that attacker that they either give up or we detect them beforehand and block. Now, in an automated attack,
they switched my slides. (groans loudly) You guys see this? (audience laughing) Darn it, it skipped playing it. Where did it go, where did it go? Come here, come here, come here. (audience laughing) Play it! There it goes! (all whooping and clapping) It’s laying waste to your
(laughter drowning out Paul). It’s gonna be loud, it’s gonna be noisy, it’s gonna be messy, and
you’re gonna be most likely to hear it, or to see it, all right. All right, next one up, number six, file and directory permissions. Just making sure that the
permissions on your files and your directories
are as low as possible in order for the application to run. And most of you probably said,
“Oh okay, that makes sense.” How many of you are gonna do that? But you’d be surprised how many companies, as they move to the cloud
have forgotten this. There have been huge breaches from Viacom, from Dow Jones, from Comcast, that have placed things in Amazon S3 box, and then totally forgot to
set the permission setup. So let’s make sure you’re doing this. So it reduces risk by ensuring an attacker doesn’t have unauthorized access to either to leak things they
shouldn’t be able to leak, or see things they
shouldn’t be able to leak, or see things they
shouldn’t be able to see, or add things they
shouldn’t be able to add. So, this is the principle
of least privilege. Okay, so what is the
principle of least privilege? It is that you give the
necessary permissions to a person or a service in
order to complete their task for a limited amount of
time with the bare minimum that they need in order to do that task, and then you go back and
remove those permissions whenever they no longer need ’em. Clear on that? We’re gonna come to
that one several times. So this is bonus points, is you should lock down
all area of WordPress that do not need write access. Really the only place that
really, really needs write access is the uploads directory. I’m getting through those backs, can’t be on again. That is exactly how their setup is, like you do not have the
ability to write anywhere except the uploads directory, and then the uploads directory
isn’t even in the same area as your web server. It’s way over here with, I think the simile exact. Yeah, shoot, more similes! (all laughing) So, if your environment allows it, don’t just lock it down to read-only, lock it down so that only the PHP process, user that runs that PHP process, can read. Now, doesn’t mean depending
on your environment that can be complex because that means you can
no longer update WordPress from the dashboard. You’re gonna have to either
change the permissions, or change it somewhere else,
and then bring it over, okay? Doesn’t make it more complex, but you’re definitely
adding those extra layers. Removing unused accounts, I talked about this briefly earlier. Removing unused themes,
plugins, and users. Again, it’s just going through
and looking and saying okay, what plugins do I have,
what themes do I have, what users do I have that
are no longer being used, because if they’re gone, they’re no longer a vulnerability, right? They can’t be exploited
if they’re not there. And one, and user account,
not an active user account, just one more account
that can be compromised. It also again, removes potential, I need a drink real quick. I’ll get it in a second. So bonus points. It’s the coffee, look at all that. So, make sure again, that
you’re doing a routine audit of your themes, your
plugins, and your users. Every time you go to check for updates, go and look through that list, and make sure that you
recognize and know everyone that’s in there. There’s an admin user
that you don’t recognize, that’s an automatic sign that
you should have a problem. The other thing with that (mumbles) so protect WP-Config. You’re gonna see that one a lot. And, it’s again, it’s another
good security practice that you don’t have configuration settings in publicly accessible areas. However WordPress does
that by default, right? Right, so, what you’ll often
see is you should add rules to prevent access, or move
the files somewhere else. Again, just in case there’s a server or an environmental misconfiguration that inadvertently exposes that data because that file often contains
your database credentials and your results. You know how I mentioned earlier, any times you’re in example A, have all of that data somewhere else. So if your file is exposed inadvertently, nothing is actually revealed. Some bonus points here, again, just like to mention,
set that file permission to only readable if you
can’t move it outside of the publicly accessible area. Set that file to only
readable by the PHP process. I did forget to start this (mumbling) (laughing) And then also see hosting provider. So the next one is protecting
and limiting the access to the admin area. So again, it adds an
extra layer of protection. Often the suggestions
are to add, like a, oh, basic authentic access, or
where it prompt up and ask for another username, password,
maybe adding a Captcha. It reduces risk because it is gonna add, similar to two factor authentication or multifactor authentication, it’s gonna add an extra layer of defense, and in addition, also
minimizes attack surface. So some bonus points that I like to do, in fact it’s part of our routine process at the University of Missouri. Every press site we launch, is limited, We limit the login areas,
we limit the admin areas, to only specific IP ranges. So let’s pretend that this represents the 3.8 billion
IP addresses possible that (mumbling and trailing off) All right, and let’s say
my address is 64.85.59.68, and I decided that
anybody who wants to login has to have an IP address that starts with at least 64.85. I have limited it from
3.8 billion down to, can you see that tiny, little sliver? – [Man] No. – [Paul] No? Let me zoom in a little bit. Can you see it now? (audience laughing loudly) There, now can you see it? So I said all right, here is everybody in the whole world who can login. Now we’re gonna limit it
down to 65,000 addresses. It’s not more than 65,000. I gonna limit, okay, I’m gonna limit it down to a narrow set of users. That is drastically gonna reduce who can actually access those areas, and you’ve seen those brute force attacks go from instantaneously, like, moments after we launch a site, and constantly, all the time,
taking up resources, to zero. Because as an institution we
are lucky often in higher ed, that we have access to
Virtual Private Networks. Like our resources on campus should not allow access off campus unless you connect via campus. So a lot of us have VPNs. Require that your users use a VPN. If you’re not familiar with VPN, VPN is a service that
encrypts the connection from your computer out to
another server service, so you can go over an unknown network and then it looks like
you’re request originated from that IP. So you can be anywhere in the world, and it looks like you’re
coming from that IP address, giving you the ability to
lock down those IP addresses. But again, XMLRPC has
authentication methods, so make sure you’re also
locking down access XMSRPC into your number rangers, or if you’re using a third-party
service like Jetpack, lock it down to its
ranges so it can compute. (muffled audience member speaking) Which you but you can
if you go to erin.net, you can look up network images of anybody. So there are services that
will allow you to look up, and in which case, you
do have to be vigilant. It’s that trade off, how much
risk are you willing to take. Limiting user roles, we
kinda talked about this. This is actually an example, what. We just talked about it. Limiting their role. (audience member muffled speaking) Attack surface, what else? – [Man] Me scribbling. – [Paul] Me scribbling. So if we’re gonna give them
the lowest possible permissions and roles and we’re doing our jobs, and then us, we, should only
login with elevated privileges when we actually need
those elevated privileges. Now, unfortunately, we’re
in crystalline ships with six roles, right? We have none, subscriber, contributor, auditor, editor, and admin, and what kind of role do you have to be to say add a menu item? (muffled audience member talking) You gotta be an admin, right? So how many do you have an editor that I need to add
menus, or widgets right? You gotta be an admin. How many of have users and
editors go I need to this, and you’re like (audience laughing loudly
and drowning out Paul) But a lot of times we take
the path of least resistance. You just give them admin. So, again, we don’t wanna do that. We wanna minimize that gate, ’cause it could be that
it’s not even malicious but it could accidentally (trailing off). So it reduces the opportunity
for an accidental problem, or even a disgruntled employees. So some bonus points. Create or add some custom roles. So if you got an editor
that needs to edit a menu, well then create a custom role for them that gives them that single permission in addition to the editor role, and let them have that. Again, minimizing those
roles as little as possible, and do those routine audits
and remove permissions from people that no longer need them. So if you’ve given that
custom role to somebody. They’re no longer in that position. Don’t just leave them it. All right, use a security plugin. This is often a common
one that you’ll see. And it’s good to install
plugin and try a bunch of or multiple of these best steps for you. It reduces risk by implementing those. Again, minimizing attack
surface could be bits and dab, it could be several of different ones. And it’s handy if you’re
not really comfortable with some of these
methods doing it yourself. It makes it nice and easy
to try and do all at once. And they’re usually fallen
into three categories, and that’s auditing, so they
can do some plugin auditing, or user auditing for you. You got prevention’s another one. It might actually implement
some of these changes, the default access changes from
things that we talked about. And there’s detection,
watching file changes. The next one up is disable file editing. Does everybody familiar with
the file editor in WordPress? Yeah, so if you’re an admin, you have the ability to go
into edit themes and plugins directly from the admin dashboard. So you’ll see this a lot
and that’s to disable it. It does minimize risk in
that it’s that minimizing that attack surface. An interesting thing here
is that you have be an admin in order to have access to it, so I wouldn’t say it’s so much
minimizing the attack surface for an external threat so much as I would an internal threat. And not even really a threat negatively, but an inadvertent
threat, accidentally going and doing things or thinking
that you can go back and change and then breaking things. I wish corporate action just
disabled this by default, and then made you consciously
to turn it back on. All right, number nine is trusted sources which is one I had never
really thought about, but I thought why would you go get plugins and things from weird places. Well, that’s one you’re gonna see a lot. I guess smaller businesses think about. As a matter of fact,
just don’t obtain plugins or themes or anything
through unknown sources or things that aren’t trusted areas, because that code may have
been altered or infected. What’s that? – [Man] So there are a lot of people that do that, especially
for the premium plugins, like I’ll find it on (Paul and audience member
talking over each other) – [Paul] Yeah, so, and if
you’re, you’re gonna, yeah, I just wouldn’t do that. Number nine, I’m not even gonna go on because I’m sure you’ve all
heard that, implementing SSL. It’s simply adding SSL
certificates to your site. It encrypts the communication
between user and your site. So those credentials as
they login are passed in clear text, and it’s
minimizing that attack surface. And we’re running out of time, so we’ll go a little faster. Bonus steps is don’t just
enforce it in the admin area, or the login area, enforce
it across the entire site. There’s no reason not to. As soon as you set up a new site, just make the site address https, so that all your doings, all your links, everything’s automatically encrypted. Number 10, because I wanna (mumbles). Do your homework on themes and plugins. This one was not talked about a whole lot. Do your homework. If somebody comes and says,
“Hey I wanna add this plugin “that does this cool new
thing, this new shiny,” you should say wait a second. We need to do some research. We need to make sure
that this plugin is safe, because do you have any
knowledge necessarily of their secure coding practices, or their security policies? No, you have no idea. The plugin ecosystem is great but there’s no standards really, and the plugin team tries
to check these plugins. There’s just no way they could
scan through all the code. So how does it reduce risk? Well every piece of code
you’ve added to your system is one more potential
exploitable vulnerability, and it’s one more area that adds or increases you attack surface. So, again, this is from Tony Perez, he said kinda basically
what I’ve just said in that, well you can see that
ecosystem is definitely what propelled WordPress to
the 31% of its market share. It’s also when it’s when
it’s a (distorted speech), because there’s also,
there’s just no standard that it’s one of the top ways
that sites are compromised. And Michael talked about that
yesterday (distorted speech) and that arbitrary file upload. So security principle in play here is be paranoid, be skeptical. Oh I didn’t actually cross out her name. Oh yeah, I did. But that’s me, I am constantly paranoid. I am constantly checking what I’m doing, so that’s not really a security principle. The security principle really in play would be that you should
treat all third-party code, all third-party plugins, all third-party data, as hostile. Anything that you add into your system you should just automatically
assume it’s hostile. So check out the vulnerability database. There’s a database,
wpvulndb, that lists out all known exposure for
every plugin, you can check. Run your plugins and
things through php grinder. It’s a static analysis code evaluator. Know that you might get false positives. You’re gonna have to
be a little comfortable with evaluating code. Run that third-party code if you can through PHP Code Sniffer
Security Audits locally. You’re used to using
PHP Code Sniffer maybe instead of your automated tests or run some other local
static code analysis. Use some type of verification
on those (distorted speech) Oh, these are all timed remember, I skipped them, I’m sorry. Back up, back up. It’s time to remember 11. What’s she say? (indistinct talking) – [Woman] Back up. – [Paul] Web application firewalls, moving and hiding your login location, routine security scans. Logging is super, super, super critical. If you’re not logging, and
there’s a vulnerability, or there’s a breach, you’re not gonna know how they got in to be able to go fix it. So logging is super critical, and then securing your local machine. Just making sure that your local machine isn’t introducing
vulnerabilities and breaches into your systems. Sorry, I’m gonna go for a hike. Warned you guys. Way too much stuff in here. So some things that were low on the list that I thought should be higher is that block the PHP execution from error it should not be executing, which is pretty much everywhere except in very few narrow areas. Logging again. Segmentation, isolation, sand boxing, both sites from each
other as well as services. Be selective with XMLRPC. I’m gonna go fast. Remove software services everywhere. Not just in WordPress, but in
your entire stack of software. If you’re not using
something, get rid of it, so it’s not exploitable. Limit the number of plugins you use. Last is monitor for file changes. And last, stay informed. You gotta stay up to date. You gotta try to make sure
you’re staying on top of things. That’s the reason why
I do the slide channel that I do the weekly
plugins disclosures list, because I gotta be able
to stay up to date. I don’t know what’s running on my support or decentralize so I’ve
got to stay up to date and send these out. So stay informed as best as possible. (sighing sharply) Here’s a good summary. (audience laughing) Always be thinking in terms
(audience drowning out Paul) Am I adding risks or
minimizing risks, right? Everything, thinking in terms of adding extra layers of defense. Don’t use known compromise stuff. Be paranoid, be skeptical. I’m out of time, gotta go! I’m easy to find online,
Gilzow, G-I-L-Z-O-W, I’m Gilzow on Missouri, I’m Gilzow on Twitter, I’m Gilzow on Facebook, I’m Gilzow on WordPress, and if you get another
Gilzow, it’s my brother. (audience laughing) (audience cheering and clapping)

Leave a Reply

Your email address will not be published. Required fields are marked *