Website Security with WordPress

Hello, everyone, and good evening. Welcome to WordPress Security for the Baltimore WordPress Meetup. This is our February 22nd, 2023 Meetup. The Baltimore WordPress Meetup is an informational gathering.

Please use the information, products, and services that we show at your own risk. Just because we show a website, plugin, theme, etc. Is not an official WordPress endorsement of it. And of course, please make sure to keep it family friendly as many of us are attending from home.

The Baltimore WordPress Meetup follows the WordPress community standards, so we will do our best to make sure that the rules are followed. No spamming or spammer like behaviors. We have people of all skill levels and backgrounds, so no judgment for those who have a different skill level than where you are at. And of course, don’t be a jerk.

I’m Gen and I organize the Baltimore WordPress Meetup. If you’re interested in more information about me and what I do, I have posted a link in the chat. Tonight’s speaker is Greg, and he will be speaking about WordPress security.

I am going to stop screen sharing and allow Greg to get going.

(Greg) Thanks, Gen. I will now bring up the security screen.

(Gen) Excellent.

(Greg) Great. I’ll just go right into it. WordPress security for all levels. Per the official hardening WordPress documentation, security is not about perfectly secure systems. Such a thing might well be impractical and impossible to maintain. It’s about risk reduction, not risk elimination.

Museums are good real world examples of this. They want to display valuable items while keeping them safe and secure. They put up walls, they use glass enclosures, they limit entrances and access, they hire guards, they install security cameras. All of this reduces risk, but the risk never entirely goes away.

That remaining risk is still great fodder for some big Hollywood blockbusters, though.

This presentation is far from an end all be all. Some of the suggestions I’m going to cover might seem like they do little to stop a determined hacker, and you’d be right. But most hacking attempts aren’t by determined hackers.

They’re by people looking for that low hanging fruit. If you have legitimate reason to believe your site might be more likely to be targeted by a hacker, you’re better off hiring a professional to harden your site and secure it against hacks.

At the end of the presentation, I’ll walk through one popular security plug in, iThemes Security, to demonstrate how to configure it and and also how it implements some of the principles I’m going to discuss here.

Risk elimination may be impossible, but what is preventable is the loss of your site. The most obvious way to do this is to regularly back up your site, both content, media, themes, plug ins, and data, posts, pages, settings, etc.

The frequency of updates is really dependent on how frequently you update your site.

A busy site might back up multiple times a day, but a less busy one might only need to back up monthly. Regardless, it’s a good idea to keep multiple backups on hand from varying time frames in case you don’t detect an issue.

Sorry, I lost where I was.

(Gen) All right. In case you don’t detect an issue immediately.

(Greg) Okay, it’s also a good idea to keep backup somewhere safe that isn’t the same as the web server. It can be local or in the cloud, but if your web server was compromised, your backups could be too. Make sure you can access and restore your backups in the event you lose access to your site.

Going over ways to back up and restore your site is a presentation in and of itself, so we’re
not going to cover that here. Just know that it’s of critical importance.

The WordPress team, as well as plugin and theme authors, in addition to providing new or improved features, are routinely patching for security issues. The only way you’ll gain the benefits
of those patches is by updating.

Reuters was actually hacked in 2012 because of an exploit in the old version of WordPress they’d been running. It’s also good to remove themes and plug ins that when you’re confident, you’ll no longer be using them as even inactive plug ins can provide an avenue of attack.

If for some reason you’ve got legitimate reason for keeping one around, keep it updated as well. I’d recommend checking weekly for updates, put it on your schedule.

Now, word of warning, it’s always best to back up your site before updating because sometimes
changes can break things. Yes, even if it’s part of an automatic update. That’s why backing up is step number one.

I’ve personally seen this happen with themes, but it can happen with plugins and in theory, even with the core WordPress updates. If something does go wrong, you may need to do some troubleshooting to figure out exactly what’s causing the problem.

Is it a theme, a plugin, the WordPress core or something else, and reach out for support or call in an expert. I do want to take a moment to stress that you should only be using legitimate plugins and software. There are some less than official ways to get access to premium plugins, some of which may technically be legal, but these can also provide back doors into your site, and so they’re best avoided.

It’s also good to ensure the plugins you’re using are current. According to research done by WP Loop, over 50 % of the plugins in the WordPress Repository have not been updated in over two years. This doesn’t mean the plug in won’t work or that it even has any security issues, just that there’s a greater potential for issues.

Sadly, I don’t know of a good way to check for the age of your installed plug ins. It’s also worth noting that it’s not just everything contained within WordPress that should be kept current and up to date.

All the software, the powers of the server, the operating system, php, your database server, and web server software should be kept up to date as well. This is outside of the scope of this presentation, but it’s still good to know.

I will note that if your provider is using a version of php that doesn’t start with eight, you should demand that they update as all earlier versions have reached their end of life. That means they will no longer get any security updates.

You can offload some of the hassle by picking hosting providers who are reliable and include maintenance and updates as one of their services. There are other things to look out for when you’re selecting a provider, but again, that’s outside of the scope of this presentation.

Reinforcing the importance of updates. Here we see a chart from Kinsta that’s relating to how
most WordPress sites were compromised. And by and far, the largest cause was plugins, so keep them up to date.

The WordPress core is the third largest cause and themes are the fourth, so don’t slack on those updates either. Secure your logins.

Excuse me.

Now we’re getting into the real meat of this presentation. Logins are the gateway to your website.

While there are other means of getting in, it’s still the most straightforward and easiest route that attackers target. Speaking of attacks, you’ve likely heard of the term brute force attack before.

It’s one of the most simplistic forms of attack, but it’s also incredibly effective against sites with poor login policies in place. A brute force attack is simply an attack in which an effort is made
to guess your password.

It can be done manually, by someone you know, or it can be automated. The former can utilize social knowledge about you to their advantage, especially if you happen to use a simplistic password like
a pet name or family name, etc.

But the real threat is in automation. A lot of allowing for literally any combination of characters, special or not, to be combined and attempted with the hope that eventually they’ll hit on the correct password.

Because of how common some bad passwords are, they may even front load a script to try and rule out those common choicesbefore they start stepping through every possible combination. There are several ways to combat brute force attacks, and it’s best to combine them all. First and foremost, though, are strong passwords.

I’m sure everyone here tonight could comment on what makes up a good password. You’ll have your upper and lowercase letters, numbers, special characters. None of those hurt.

But surprisingly, the biggest factor in ensuring a strong password is that it is long.

This image from Hive system shows how long passwords consistent… I’m sorry. How long passwords consisting of certain combinations of characters would take to guess given current computing technology.

If you work in your favorite and well secured password manager, you should have no issues using a secure password. As I said in the last slide, strong passwords are crucial.

Unfortunately, by default, WordPress doesn’t care how strong your password is. This is bad.

Several of the features I’m discussing here tonight can be implemented via plug ins and requiring strong passwords is one of them.

Multifactor or two factor in some cases, authentication is another. In addition to requiring your username and password, these make up what’s called the first factor.

Multifactor authentication requires you to provide something additional. There are many different forms this something additional can come in, but for our purposes, we’re going to discuss time based one time passwords. Skipping over the technical details, the server will provide you with information, typically in an easy to scan QR code to allow you to sync the necessary information with an authentication app like Google or Microsoft Authenticator.

Once synchronization is confirmed, the next time you attempt to log in, you’ll open your authentication app and provide the necessary code. Some tools will also let you use
SMS or email for the code, but do note that these are slightly less secure means of authentication.

Proper user permissions. This should be a no brainer, but only ever give your users
the permissions they’ll actually need, never more, and never, ever give a user administrator permissions unless you truly want them to be able to administer the site.

Limiting login attempts and login lockouts. Plugins can give you the ability to limit how frequently someone can try and fail to log in.

This will dramatically slow down the speed of a brute force attack. They can also be used
to permanently lock out bad actors. Just be careful as you can inadvertently lock yourself out.

Restricting logins to email. By default, WordPress lets you log in via your username or your email address. Your username, while possibly obfuscated by a nickname, is very prevalent on most
sites, but your email is less so, especially if you’ve hidden it from the author page.

By using a plug in to restrict logins to email, you’ve made it much harder for hackers to get in.

Limited IP login access. If only a few people log into your site and those people have fixed IP addresses, you can further restrict access to your login by limiting it to only specific IP’s. Again, be careful as you can find yourself locked out if your IP address were to change.

This can further be expanded to include overall white lists of allowed IP’s and black lists, blocked
IP’s for your login and or your site. Custom login and admin URL’s. These are a bit of an oddball here.

They constitute a type of security known as security by obscurity. Generally speaking, any security expert is going to tell you that this is a bad type of security. However, when you’re dealing
with automated attacks, what might otherwise be bad security, ironically, becomes good security.

This won’t do a lot to stop a determined hacker, but automated scripts target the default WordPress login and admin areas. So if these change, they won’t target them anymore.

Disabling common usernames like custom URL’s, the reason you’d want to do this is because it continues to narrow down the avenues of attack, particularly for automation, which often will target the admin account, knowing that in many cases it exists and has administrator privileges on most WordPress sites.

If your site happens to have an admin account like this, you can easily remove it. To do this, you just need to create a new account, assign it the administrator role, log into that new account, and then delete the original admin account.

Secure sockets layer is something I’m not going to go into in great detail because it’s not something you can easily do with a plug in or from within WordPress, but you should know that by using SSL, it encrypts communication.

This prevents attacks called man in the middle attacks where someone is able to intercept communications between you and your website and captures your password. If your site isn’t using SSL, talk to your hosting company or consider getting help from a professional.

Other benefits of using SSL are that it improves SEO ranking, provides better analytics, and has support for HTTP2, and it generally allows your site to appear more trustworthy.

File security. Disable File Editing. WordPress includes a built in File Editor. This can make it easy to tweak things on the fly, but it lacks all of the advanced capabilities provided by a modern IDE.

It also makes it far easier for malicious actors to discreetly injectcode into your site. It’s best to disable this. If you need to update your files, make sure you know what you’re doing and use SFTP.

File permissions. Read, can I access a file? Write, can I change a file? Execute, can I run files?

It’s a bit more complicated than that, but the permissions on your files and directories are important, and they can determine who can do what with your files.

It would take a lot of time to tell show you which files are recommended to have which settings, but there are resources available that do that, including security plug ins.

File monitoring. A surefire way to detect something fishy on your site is to monitor for file changes.

If something changes and you didn’t change it, something clearly isn’t right.

Some plug ins can make note of these changes and alert you, and you can check to see if it’s tied
to something you did like updating your themes or your plug ins or if it’s something more shady.

Now we’re going to cover some miscellaneous settings.

Hiding WP or WordPress Metadata. Did you know that by default, WordPress will actually broadcast which version it is? This is great for would be attackers as it lets them check to see what exploits might exist and apply to that specific version of WordPress.

This information is relayed in both your site metadata and in the README.html.

Disabling that metadata and removing the README.html won’t necessarily protect your site, but it will obfuscate the vulnerabilities.

Disable XML-RPC, also known as Extensible Market Language Remote Procedure Call. XML-RPC is used for certain advanced communication with the site. The reason why this is a vulnerability because it allows you to execute multiple commands in a single HTTP request.

This includes multiple sets of login credentials. Unfortunately, if you happen to use JetPack, the WordPress app, or another plug in that relies on it, you won’t be able to disable it without breaking functionality.

But for everyone else, you’re encouraged to disable it.

If you absolutely need to use it, there are some plug ins that will let you restrict it to only allow a single authentication request at a time. Malware scanning. By scanning for malware, a plug in can quickly alert you if something suspicious has managed to find its way onto your server, be it by an upload, a bad plug in, or a vulnerability, and it allows you to act quickly to stop it.

It can also alert you to potential issues with plug ins and themes that you’re using.

Spam and comment protection. No one likes spam, so why would you want it on your website?

Spam bots typically fill out every available field that they see. To combat this, something known as a honeypot will add a hidden field that the spam bots will see and fill out.

When submitted, the system rejects it outright and may flag the user for additional blocking. In some cases, you can automatically block sources of known spam by their IP address.

WordPress configuration hardening. There are a handful of tweaks that can be made to your WordPress configuration file to improve its security.

Some of those can be managed by a plug in and some of them require manual intervention.

A few of the tweaks a plug in can provide are updating the WordPress security keys.

These keys are what are used to encrypt your cookie data.

You shouldn’t need to change them often, but if you suspect there’s an issue, it can’t hurt to update them. This will log all users out, so just be warned in advance.

You should also make sure WordPress debugging is disabled as this can broadcast exploitable issues with your website.

The file permissions of your WordPress configure should be substantially more restrictive than all the others.

Database hardening. Given that the bulk of your site’s content and data is stored in the database, it makes sense that you want to make sure that it was secure.

In point of fact, the majority of ensuring your database is secure is actually handled by just keeping things up to date and applying some of the other security practices we discussed.

There are a few more things you can do, though, like changing the database from the default of WordPress and changing table prefixes from the default of WP. This is another case of security by obscurity.

Secure Connections. This starts to get back outside the scope of this presentation, but sometimes you might find yourself needing to access your site by a means other than the web interface.

It’s important that if you do, these means are also secure as well. You secure file transfer protocol,
SFTP, not FTP, and so on. Preventing hot linking. Hot linking is when someone takes an image and reshares it, pointing directly at the original location.

This is problematic because it offloads the bandwidth from the person who’s resharing it to the person who originally posted it.

The website, The Oatmeal, had this issue once when the Huffington Post decided to hot link to a multi image cartoon of his on their website.

This led to a massive spike of usage and a massive bill. So obviously you don’t want all that.

Now I’m going to move on to something a little more hands on.

I’m going to walk through one of the security plug ins that exists for WordPress, iThemes Security. This is not an endorsement of a plug in, but it does cover several of the topics we’ve discussed.

And so here I have a clean install.

I’m going to just go in straight, find iThemes from the plugin directory, install it and activate it.

And now you’ll see there’s a security section in the menu over here.

So go in and go to set up.

Now, personally, I’m not a big fan of this kind of select your type of website, but I can also see how a lot of people it would be beneficial to.

I would probably personally skip the set up and go straight into the settings, but I suspect a lot of people would use these settings.

So I’m just going to set up as if I was doing an e-commerce site.

You go in, they have this Enable Security Check Pro.

This is something that’s tied to detecting IP addresses correctly.

So you can go ahead and turn that on.

Now, this is more for an existing site that you’re setting up.

I’m just going to set up as if it’s my own personal site.

The WordPress user roles.

If I had customers, what role they would go with, I didn’t change any roles, so I’m just going to say
subscriber is the equivalent of customer.

You’ll see what these user groups are like in a minute.

So yes, I want to enforce a password policy for these users.

This says, hey, make sure they have strong passwords.

Now here, and this is another thing that I don’t like.

It shows you only a subset of the settings until we’ve gone through everything.

So I’ll go through it now and then I’ll show you again how there’s actually more settings in here later.

Local brute force.

That’s the brute force that we were talking about.

If somebody keeps trying to get in and failing, it will lock them out for time.

They actually have something called network brute force, excuse me, which basically lets you join a network of other sites that basically report: Hey, this person’s tried to log in several times and failed.

You should probably know about this too so that your site can share basically bad actors so that you can proactively block out potential hackers.

Site scanning schedule.

This is tied to looking for malware and other problems.

I say go ahead and turn that on.

Two factor authentication.

Again, I say turn that on.

Now in this case, this is turning it on, but it’s not actually applying it to anything.

So we’ll get to that in a minute.

Now, while we’ve gone through all the next, actually, then it lets you go through subsets of those same settings.

So we already went through all of those.

Here you have user groups.

I’m going to just go with the defaults.

Excuse me again.

Your customers, you don’t want to manage your settings, your security settings, of course.

We did want them to have strong passwords and not compromise passwords.

The skip two factor onboarding basically would let people bypass having to use two factor authentication.

I would say if you’re turning it on…

I mean, if you’ve turned on two factor authentication, you probably don’t want to skip it, but that’s up to you.

Application passwords are passwords that can be used with certain other tools and use XML-RPC.

I’m not going to really discuss application passwords much, but they are technically here if you want to set them up for your users.

Administrators – you would, of course, want to have access to the security settings. That’s up here.

Basically, you just go through for each of your user groups, editors, authors, contributors, everybody else, and so on.

Now you get into some more configuration.

Authorized hosts, you could add your own IP address to this list if you know it wasn’t going to change.

That way you wouldn’t get locked out.

This is the IP detection to make sure that your…

So it knows what your IP address is.

Now, if you wanted to use that network brute force where it shares information between sites of people who keep failing to log in, you would have to provide them with your email address.

Notifications from email, if you for some reason wanted it to be different than WordPress’s default email address, who the notifications would go to.

By default, it goes to all your administrators.

And then they have one final set to secure the site where it implements all the settings that you just went through.

And now I’m going to let you look at the dashboard that it gives you, which shouldn’t have any information in it because it hasn’t been running very long, but you can see in here results from your site scans.

You could scan right away, lock out reports, ban reports, brute force hacking reports, a list
of banned users, and database backups.

So this plugin actually does back up your database for you.

It does not back up your content, though,

so make sure that you’ve got that backed up separately.

But it does provide database backups.

Now I’m going to go back into the settings

and show you how things are going to look a little different now.

If you notice there’s actually more options in here now, which is why I don’t like the way they broke it up.

But if you come in here, you’ll see Enforce SSL.

To be clear, this does not give your site SSL.

This just makes sure that if you have SSL, all of the connections will go through the SSL.

Because sometimes you might have a link on your site that accidentally just
points to a regular non SSL connection.

This basically says make sure that they use SSL.

Here we have the database backups, like I’d mentioned.

Here we have File Change Monitoring.

So if files change, it can let you know.

I think we covered all of the other settings, though.

Now, I will mention, depending on if you had two factor or not turned on now that I think about it,
if it’s turned on, you’ll see a group…

This is where the two factor section is.

If it’s turned off, this section just won’t show up.

So just be sure of that. And configuration…

Now there’s actually more settings in here as well.

You can see this setting just says, let iThemes Security edit certain configuration files for you.

You can disable it if you want. These are certain timings for the lockouts, what the time frame is that it should be checking for failed logins, how long to remember it, a ban threshold for blocking an IP address, certain error messages to give when people are locked out.

Your authorized host list, again. They have logging.

You can actually configure the logging to go to a file, or it can go to both your database and a file.

I don’t know if that’s something that really benefits a whole lot from going to a file, but if you thought differently, you can set it differently.

Login security. Authentication methods that are available to users.

By default, all methods are allowed.

You could say all methods except email.

And this is for two factor authentication, I should say.

So if you remember, I mentioned two factor authentication usually uses an authentication app, but it could also use text messages or email.

In this case, I think they have the mobile app, they have an email.

And there’s also something called a backup authentication code, which is a set of codes that you can use one time before they’re invalidated as an emergency.

If for some reason you lost access to your app, you could use a backup code to get in.

And so this is just letting you select which methods people are allowed to use.

This is the onboarding text for two factor authentication.

Here are some settings for the login lockouts.

You can ban user agents.

So if you happen to know certain spam bots or other things have certain user agent strings
that you could add here.

Local brute force.

These are just the timings.

Again, you can go back if you forgot to add an address for the network brute forcing, you can add your email address here.

This is for the file changing monitoring.

You can basically specify folders and files that you don’t want to check for changes, and you can
ignore certain file types by default.

It doesn’t check for images and audio and media files to change.

Usually, that’s not how a hacker would change something.

Then they have a utility setting here.

You can enable scheduled database backups.

By default, it will back up every three days.

You can go as frequently as once a day.

You can’t go more frequently than that with this plugin.

The backup method by default is email.

You can also set it up to save locally and email or locally only.

Here, I’ll show you a list of the tables that it’s including.

By default, WordPress core tables are always included.

So if you’re wondering why those aren’t showing, that’s because they’re always in there.

It also excludes certain tables that it doesn’t think are really critical for a backup.

And you can easily select ‘Exclude a table’, ‘Include table’ like that.

There are notification settings.

These just let you go in and determine, okay, for these reports, who gets the email.

Let’s look at some of the advanced settings.

And by default, they protect access to certain files like that Readme.html file, the install php, and other files that should be protected, it prevents people from accessing.

It prevents people from viewing a list of files which can allow for seeing vulnerabilities, so it disables that.

It disables executing php in sections that php shouldn’t be executed.

Some other tweaks.

This here you have, it disables the File Editor.

By default, they allow XML-RPC, but they actually do have a built in restriction on how many authentication attempts it will allow.

If for some reason you wanted to bypass that, you could.

I wouldn’t recommend doing that.

You can still disable it or you could disable pingbacks.

Here’s where you can set how you want people to be able to log in.

If they can log in with the email and user name.

Only email is what I would personally recommend.

You could do it user name only.

But if you do user name only, I’d suggest you also check force unique nickname.

That way people can’t use their nickname… can’t use their username as their nickname.

So that’ll make it at least a little bit harder for someone to guess.

And this lets you disable user pages, basically the author pages for people who don’t have any posts.

And the hide back end is just a little…

I don’t entirely know what this does, to be honest, but it’s not an important setting.

(Gen) That is the…Hi, Greg.

(Greg) Sure.

(Gen) The hide back end, that is where if you wish to, you can change your login URL.

(Greg) Oh, that’s what that was. Okay.

I never bothered to check it.

That’s why I didn’t see that. Yeah.

So you can change, instead of the default of wp-login, you can put in whatever you want.

Login-here, whatever.

So then you need to make sure, though, that when you go to log into your site, you use that slug instead of wp-login.

And then they also have a slug for the registration page.

Okay. Thanks for clearing that up.

(Gen) I think that basically wraps up the settings.

(Greg)For the most part, yeah.

(Gen) All right.

So we will open up the chat for questions.

If you wish to unmute to ask your question, please type in the chat that you have a question and wish to unmute.

Hi, Terry.

(Terry) Hi, thanks.

I have a client that accesses the website to handle various features.

Some of them seem to require administrative access to be an administrator in order
for them to show up in the dashboard.

And I’m uncomfortable with her being an administrator because of all the damage that could be done with her not being careful with passwords and so on.

So is that something for me to look into?

I’ve tried different user role editors, which have probably changed over the
years, but I don’t know how to give somebody access to those things without
giving them everything.

(Gen) As Eric posted in the chat, there’s a plug in called Advanced Access Manager.

There are also several other plug ins.

I know of Branda and a few others, but the name is not coming to mind at the moment.

But there are many plug ins out there which allow you to customize the dashboard and hide certain sections from either certain user roles or from certain individuals.

(Terry) But it’s not so much a matter of hiding within the dashboard.

It’s… If you’re an administrator, you can kill the site, right?

(Gen) Yes.

(Terry) You’re saying that would be the feature to hide?

I’m trying to give her access to those particular parts of the plugins that seem to only show up.

I’m wanting things to show up rather than to be hidden and not to have administrative access.

(Gen) Look at the user role editor where you can create a customized user role and then check or uncheck specific permissions, which will then show and hide the applicable items that go with that.

(Terry) That’s what…Yeah.

Okay.

And then I’ll look into that other one, too.

I appreciate it. Thank you.

(Gen) All right.

The next question looks like it’s from Danielle.

Danielle, I’ll give you the ability to unmute if you wish to.

But you mentioned you haven’t looked into…

(Danielle) I’ve used the WooCommerce

I mean, not WooCommerce…

What is it?

(Gen) Well, you have used WooCommerce.

(Danielle) I have used WooCommerce. It’s Wordfence. I’ve used Wordfence in the past and I found it to be a little heavy, did a little too much.

Does iThemes have a similar weight? I know Eric had mentioned, obviously it’s best to do this on
the server level or the network level. Sometimes you don’t always have that control or you just want something in the meantime while you’re setting things up on the server.

I do like the look of iThemes. It looks like it does provide a lot that’s really easy to understand without offering extra things you don’t need. But is there any insight into maybe how it compares?

(Gen) So,I found that because it doesn’t do as much scanning, it doesn’t have its own firewall system, it tends to be less impactful than, say, Wordfence. I mean, I’ve had Wordfence literally add 60 seconds to a website load. It’s just atrocious.

So I have found iThemes to be less impactful. That doesn’t mean it’s no impact. I have found it to be LESS impactful. And yes, I have found the user interface to be a lot more straightforward than Wordfence. Wordfence can be intimidating.

(Danielle) Yeah. And I find it doesn’t do… It’s not as straightforward. So I do like that I can enable what I need. And then this way, as I’m trying to figure out how to do it, from a more technical standpoint, I can at least check a box and have it be done.

(Gen) Yeah. There’s, of course, significantly more to security, but I would say you could go worse than where we’re at.

(Danielle) Got it. Cool. Thanks.

(Gen) All right. The next question I see is from Gary: are there any alternative plugins that might be recommended that are less robust but easier to configure?

(Greg) I do have one I could…

I don’t want to give it an endorsement, but I’ve used SiteGround Security as well. It’s substantially less robust, but it might be a little easier to digest the first time around.

(Gen) Yes. There are also a few plugins that do specific tasks, such as plugins that handle just the brute force. They prevent brute force.

So there are some very limited scope plugins, which just do a little bit which are out there.

Sherry asked: If it’s possible that we don’t need any plugin and you can handle security at a server level and make it very comprehensive.

The answer is yes, you can.

You can handle the security at the server level, at the site level.

As long as you have full control, you can install all the tools you want.

I do know several security professionals who use no plugins. They handle everything at the server level. They also implement quite a bit in Cloudflare, so they handle preventing problems before they even reach the server through DNS.

(Greg) Eric made a few good comments, though, that it probably is good to use something that gives you two factor authentication, or at the very least, I would say a password policy.

Because you can have a secure server and have terrible password policies, and arguably, depending on what your users were, that could be a big flaw.

(Gen) Yes. Eric also says, plus one for Cloudflare. Yes, Cloudflare is wonderful. Very powerful. Very intimidating for a first time user as well.

Were there other questions?

All right, I will go ahead with the exit slides.

Thank you, Greg, for sharing.

Since we did record this, it will be posted up on YouTube once Paul gets it ready, we thank Paul greatly for his contributions, getting our videos ready to go for YouTube.

Our meetup is run by volunteers, so if you would like to present on a topic, please let me know.

If you’re looking for assistance outside of our meetup time, please check out our meetup page.

And I’m just going to put that link into the chat.

https://www.anphira.com/baltimore-wordpress-meetup/ There we go. And our next scheduled meetup is April fourth at 7 PM Eastern.

It is an Ask Me Anything, and you can RSVP for it at the meetup group.

Thank you, everyone, for joining us.

And thank you again, Greg, for presenting.