Solved Do I need plugins to secure WordPress?

Hi,

I run a a few WordPress sites on FreeBSD webserver.
Could anyone please tell me if I do need to use plugins to secure WordPress or can I secure WordPress at a server level?

In case I need pluggin, is would you recomend between ithemes security pro and BulletProof Security pro?

Thank you
Fred
 
No, you don't necessarily need plug-ins to secure WordPress. I do, however, recommend to remove everything from your headers that could tell too much, like your WordPress version.

See the wpscan utility (on Github) to see if you are safe.
 
Usually it is a better idea to avoid using Wordpress plug-ins. Many of the security issues WP websites have is with outdated or poorly written plug-ins. You are probably better off making sure your file permissions are correct and that you don't have any unnecessary WP user accounts.
 
Thank you for your reply Cthulhux .
I am trying to install wpscan utility...
what is the FreeBSD version of sudo gem install bundler && bundle install --without test ?
 
sudo gem install bundler && bundle install --without test. ;)

(But you'll need to install gem first, of course. Get Ruby and Rubygems from the ports or packages and you're all set.)
 
you'll need to install gem first
Oops!

I didn't realise that gem was Rubygems
pkg search Rubygems
Code:
rubygem-rubygems-mirror-1.1.0  Mirror rubygems
rubygem-rubygems-tasks-0.2.4  Rake tasks for managing and releasing Ruby Gems
rubygem-rubygems-test-0.4.3_1  Run automated tests

Is it rubygem-rubygems-mirror that I need?
 
Perfect!
Thank you... I'll install that now.

Could you please give me some advise on what to do on the server level to secure Wordpress?

At the moment I use a secure webserver (hiawatha) and use fail2ban to scan bad IP and block them and that's about it really
 
You might want to install a plug-in to restrict the login attempts to 3 to avoid brute-forcing. Or does WordPress already do that in its current version?
 
You might want to install a plug-in to restrict the login attempts to 3 to avoid brute-forcing. Or does WordPress already do that in its current version?
Just tested it and no it didn't block me even after 12 failed attempt..

Could PF and wordpress work together in the same way that pf can block 3 failed ssh login after so many time?
 
Hi TeamBlackFox, the Hiawatha webserver is better than nginx from my experience in terms of security.
I will follow your advise regarding changing my files from 644 to 600 mode or maybe 444 if allowed.
If you want to be super safe with PHP based services, putting the webroot on a separate filesystem with "noexec,nosuid,nosymfollow"
Could you please tell me if this is possible from inside a jail (iocage). I use zfs so it shoul be easy enough to create a new zfs mountpoint but how do I then link the two together?
 
I wouldn't concentrate much on the webserver. May it be Nginx, Apache, Lighty or whatever - they won't help much with a poorly configured PHP. So first focus on PHP, then the rest - setting open_basedir, memory limits, avoiding extensions you won't need, using fastcgi / fpm to run each Vhost under a separate user account.

Then - may it be ZFS or not - do some "magic" by mounting the entire webroot read-only by either a ZFS mountpoint or via nullfs. If Wordpress really needs to write somewhere, see if it can outside the docroot, if not due to some cache files that need to be served create another mountpoint read-write, but disable PHP (e.g. removehandler in Apache).

If bruteforcing for your wp-login.php is an issue, mod_security might help or similar modules, if you've a static client IP maybe think about using restrictions and forbid public access.

Final point - by just replacing your webserver there won't be much increase in terms of security, if the rest of the system is poorly configured. If the entire system is properly maintained, nearly each webserver may do the job pretty well.
 
Last edited by a moderator:
Final point - by just replacing your webserver there won't be much increase in terms of security, if the rest of the system is poorly configured.
I forgot where I read this but 80% of all wordpress sites get hacked. It's a very insecure environment to begin with and I won't use it for my client sites; nor will I take on clients that use it.
 
WordPress isn't insecure on its own. It's actually a pretty solid environment. The problem is people tend to just set it up and leave it, not installing security updates or installing plug-ins that are not vetted/updated. It's like any other software. I mean, if most FreeBSD users installed their OS and left it on-line with weak account passwords, a bunch of random network ports installed and no security updates it would probably get hacked 80% of the time too. That isn't FreeBSD's fault, it is the admin's.

In short: feel free to send those potential WordPress clients my way. I'll be happy to work with them. ;)

Back to the topic at hand, I recommend reading the Hardening WordPress document in the WP documentation. It offers a number of tips for keeping WP locked down. http://codex.wordpress.org/Hardening_WordPress
 
Last edited by a moderator:
The only security breach I ever experienced was trough a Wordpress skin (not plugin, skin). Apparently this allowed shell execution, and someone uploaded and executed a IRC bot or some such. I discovered this during a random ps, and saw there was a "httpd" process, but we were using lighttpd and not Apache, which triggered some suspicion...

Note that no real damage was done, because all machines had a firewall which severely restricted outgoing access to the bare minimum, and the outgoing requests to IRC ports (6667, etc.) were blocked.

It is very difficult for anyone to judge if a skin or plugin can be considered secure, but in general:
- Keep everything (Wordpress *and* plugins *and* skins!) up-to-date.
- Try to stick to stuff that's used a lot; if there's a security problem this will most likely get discovered (and fixed) sooner.
- Don't just firewall the incoming traffic, *also* firewall outgoing traffic.
- Try and monitor your system and see if anything strange is going on. I don't really know of an "out-of-the-box" solution that works well (I'm mostly a developer, and not really a sysadmin) but you could run a script that alerts on unauthorized processes being started, or some such...

As for webservers, I used Hiawatha a lot. It's a nice little server and has some unique features. daemonforums.org was hosted by it when I did the hosting. At the same time, nginx is deployed a *lot* more, has a *lot* more features, and is probably equal or faster in terms of performance. I would never use Hiawatha in a professional environment, but in a small hobby-site: go for it!
 
Hi Carpetsmoker

Thank you very for taking the time to reply :)
I will revisite my pf(4) rules as everything is allow to go out... I only filter incoming.

As you used Hiawatha quite a lot and have experience with the software, could you please tell me why you wouldn't use it in a production environment?

I used NGINX before and found it a lot harder to get to grip with and didn't have all the security aspect that hiawatha offer out of the box.

Fred
 
You might want to look at the stuff https://calomel.org does with nginx and FreeBSD. They do a lot of research on how to set things up.

How good is their advice? I've seen a lot of people reference them but, just recently, I saw a post somewhere where they berated them as clueless. I've blindly tried some of their settings in the past, which caused problems for a site, but I didn't take the time to fully understand what the setting did.
 
As you used Hiawatha quite a lot and have experience with the software, could you please tell me why you wouldn't use it in a production environment?

I used NGINX before and found it a lot harder to get to grip with and didn't have all the security aspect that hiawatha offer out of the box.

I never said I wouldn't use it in a "production environment", I said I wouldn't use it in a "professional environment", which is not exactly the same.

In a professional environment, I would expect any other competent sysadmin to take over and fix problems in a reasonable timeframe. Using standard technologies allows this, and is an important reason why stuff like sendmail and BIND holds out so long, even though vastly superior alternatives exist. Any other sysadmin would first have to read up on Hiawatha and its peculiarities, before being able to actually fix anything. The chances of this person already being familiar with Hiawatha are very small, while the chances on being familiar with at least *some* nginx are rather large.

Another problem is that it's developed almost entirely by a single person (Hugo), and that very few people actually use it. Being developed by a single person doesn't have to be a bad thing; look at Bernstein's software for example. But djbdns has been extensively audited and found to be secure. Hiawatha hasn't (AFAIK, anyway). Even the smartest person can overlook something obvious. It also hasn't (AFAIK) been tested extensively with larger loads. I have no idea how well it holds up performance and stability-wise, and that it's used more also means you can more easily find solutions to problems on account of other people already having experiences (and fixed) those problems.

Like I said, I used it for daemonforums.org for years, and it worked great; and while that's hardly a top site, it's certainly a "production environment". I can't recall ever having any problems with it in about five years that I used it.

As for difficultly, I would say both nginx and Hiawatha are about the same in easy-of-use, but that's really a personal thing I suppose... Both are significantly better than Apache, anyway.
 
I think Carpetsmoker is right where he said that you should not use a piece of software your administrators aren't familiar with. However, your administrators not being familiar with a piece of software should not be the reason for not using a piece of software if it's the best choice for you. Of course, you should give your administrators the time to learn to maintain the software before actually using it. With Hiawatha, I'm very sure that I've made a piece of software that's easy to learn and easy to maintain. A get a lot of positive feedback from many people saying how easy it was for them to learn how to use the software.

Yes, Hiawatha is completely written by me. That could be a bad thing but it can also be a good thing. Give me any two developers and you'll have two different opinions about how to write software. Because Hiawatha is written by one person, it's entire code is written in a consistent way. And it's not true that Hiawatha hasn't been audited. Not by a professional company, but in the years that I develop Hiawatha, I've had many e-mail from people who claim to be security professionals or software developing professionals and who have taken a look at the code. Many came up with only minor findings or change suggestions. Only once, someone found an actual exploitable bug. In the past I've done a lot of pentesting, security auditing and code reviewing myself, so I know what I'm doing. Of course, that's no 100% guarantee for bug-free code, but 14 years of development and only 1 found exploitable bug shows at least that I'm doing things right. Because I claim to have a secure webserver at the Hiawatha website, it receives a lot of hack attempts. 14 years of development and no single hack or defacement. Of course, my secure PHP framework (http://www.banshee-php.org/) is also responsible for that. But while the whole world was panicking with heartbleed and shellshock, Hiawatha users could simply sit back and relax.

With Hiawatha, I don't aim at having a 100% Apache replacement. Hiawatha does not and will never have all the functionality that Apache has. For the main reason that I believe many of Apache's features should not be inside a webserver. I often receive questions from people who want to try Hiawatha and have trouble with converting their Apache configuration to Hiawatha. The amount of shit people have in their Apache configuration. omg... Of course, they are not to blame. It's developers who don't know who to write a proper web application. With Hiawatha I always keep KISS in mind. Keep it Short and Simple. No fancy and complex shit, just be a webserver. Less complexity means less code, less chance for bugs, so less chance for security issues.

If you wonder about Hiawatha's performance capabilities, you are free to test http://www.ikhebniksteverbergen.nl/. It's a Dutch website about privacy I made. It's build with the Banshee framework and has all the speed functionalities in both Hiawatha and Banshee enabled. I'm sure its speed will be more than what you're looking for. And yes, it also has been tested with heavy-load websites (http://www.followgrubby.com/). With several thousand simultaneous connections, the load on the server was low. Mainly due to smart caching by Hiawatha.

NewGuy: "WordPress isn't insecure on its own." I seriously think that's not correct. There have been many vulnerabilities in Wordpress itself. But even there weren't, it's code is a complete mess. It has no readable structure inside the code (no MVC) or its directories and files. I've used Wordpress before. In my secure webdevelopment course that is. To show students how NOT to write code. Look at its code and than look at how I did things in Banshee. I'm not trying to say that Banshee is perfect, but at least it has structure. And with Banshee, I do not only focus on secure code, but also at provable secure code. Not only does Banshee prevent SQL injection attacks, with a few simple steps I can also simply proof that it does prevent SQL injection. The same can not, and with its current code structure can never, be said for Wordpress.
 
None, because I don't know any e-commerce solution very well. Personally, I would write it myself if I ever was in need of it. But I'm sure that's not the answer you're looking for.
 
Well, I wish I had the skills... That been said, I am starting on banshee framework for my static site.
 
Back
Top