Relocate wp-comment post and other features

my suggestion is creating a new folder called wp-interactive and putting things like the wo-comments, wp-trackback, and any other similar code into this folder.

How would moving the location of those files change anything? .htaccess can be used on any URL/filename combination.

It’s time to take action on these important security issues.

The location of those files, including wp-login.php have nothing to do with security. The security capabilities is within the code and moving them doesn’t do anything to change that.

There is the concern about brute force attacks but there’s already some very good advice published for dealing with that.

How would moving the location of those files change anything? .htaccess can be used on any URL/filename combination.

Jan, honestly, if you tried to write an .htaccess to restrict access to specifically 3 or 4 files that can block a combination of ip addresses AND country codes (if you have geoIP available)? You would need to add for each and every item that you wanted to block, which would make for a horrifically long and complex htaccess file that most people would not be able to do.

I challenge you: Post up an htaccess to block 3 IP blocks and 1 country from accessing comments posting, while blocking 3 other countries from only login functions. The htaccess for that isn’t short and is beyond most people’s ability to construct.

The concept is to separate out functions that specifically provide interactive functions (login, comments,pings) which can create problems and be used as attack vectors. It’s many times easier to create beefed up security if you can control to some extent who can even try to use the tools.

The location of those files, including wp-login.php have nothing to do with security. The security capabilities is within the code and moving them doesn’t do anything to change that.

By moving the code to a folder and allowing you to use htaccess to simply protect them, you can do a lot more than the security in the code. As an example, if I took a wordpress blog and denied access to add comments, login, or ping the blog for users from russia, turkey, china, and a few other select places, I could cut down the amount of spam that would end up in my admin.

Further, by removing access to certain groups (including by IP block if needed) you could lower server load by not allowing these people even to interact with the code. At the same time, you don’t have to deny people access to the site in general for reading, which means that you don’t have to deny surfers from a country access to your site, only access to the comments, as an example.

The safest door lock is one that a crook never gets a chance to pick. Having the option to easily block by IP, country, or other options would be another wonderful tool to help secure wordpress against the constant attacks that are out there.

Jan, honestly, if you tried to write an .htaccess to restrict access to specifically 3 or 4 files that can block a combination of ip addresses AND country codes (if you have geoIP available)?

Sure and I’ve done that before in the past. It’s “fire and forget” because you don’t have to maintain it.

If you do have to maintain that .htaccess file then you’re using unsafe software. That’s not the case here and the brute force article works.

I challenge you: Post up an htaccess to block 3 IP blocks and 1 country from accessing comments posting, while blocking 3 other countries from only login functions. The htaccess for that isn’t short and is beyond most people’s ability to construct.

Right. Here’s were I disagree (and that’s fine BTW reasonable people can disagree): that doesn’t add security at all. It does block IPs and there are ways to do that do not required changing the architecture or design.

https://www.ads-software.com/plugins/search.php?q=block+country

I could make that .htaccess file without moving anything. It’s the same amount of work and maintenance. But what problem would that solve? It doesn’t make anything more secure to do that and The Great Hacker Zombie Bot Net? lives in countries that you want to accept too.

Unless you wish to maintain a moving map of the Internet (and you really don’t want to do that) this doesn’t make anything more secure. It’s the code and following best practices that makes your installation secure.

Right. Here’s were I disagree (and that’s fine BTW reasonable people can disagree): that doesn’t add security at all. It does block IPs and there are ways to do that do not required changing the architecture or design.

Yes, there are ways, the same way that I have dedicated stuff in my server config that makes it impossible to execute programs in the upload directory. But that is something that a small percentage of total users can accomplish by themselves, so for the most part it’s too complex to be considered a valid way to accomplish things.

Isolating different classes of programs into different areas makes a lot for sense. It’s why there is wp-admin and wp-content – they are fundementally different. Blog viewing and blog access are two different things, and keeping them split off for purposes of security is always a good thing. It’s many, many times easier to write rules to deal with your entire secure area than it is to write rules for individual programs.

” It doesn’t make anything more secure to do that and The Great Hacker Zombie Bot Net? lives in countries that you want to accept too.”

We also agree here, but I deal with probably close to a half a million hits onto comments, logins, and pings each month, and the vast majority of the unwanted stuff comes from a very small base. The amount of wasted server resources and bandwidth dealing with these pests is amazing.

As you know, using htaccess as opposed to code level blocking is also many times more effecient on the server, and allows you to create as simple or as complex a solution as you desire, which can include anything up to blocking a country but allowing a single IP from that country, or allowing only those with the correct browser. In the world of security, keeping the people with bad intentions away from the server to start with is a much better way to deal with the issues.

It’s the code and following best practices that makes your installation secure.

See, this is where we fundementally disagree, because I think you are looking at security as only an inward facing issue. You seem to forget that WordPress (and most other similar software) are very widespread and are a perfect vector for all sorts of attacks, and not all of them are on against your security. We have very recently seen how innocent WordPress installs may have been used for a form of reflected DDoS on other servers. You also have to concern yourself with the server load when you get anywhere between 10 and 50 thousand requests to add comments in an hour from spammers, or trying to access login. It’s not just “did they get in” but “how much damaged did they cause even trying?”.

See, the plug ins and methods you point to are processing intensive and in the end self defeating. A DDoS as an example does not require a successful login or a successful comment post, only that the server is endlessly tied up. PHP coded security to handle this just doesn’t scale, it actually ends up causing as many problems as it resolves. It works in theory in small cases, but I was looking at an attack that cloudflare handled the other day that was 10,000 requests in a matter of minutes. Could your server or service provider handle that? Really?

You have to think of simple solutions that product end users can easily relate to, and that demand the least amount of server resources to handle. Otherwise, you are playing into the hand of the brute force and spam bots who will drag a server down to dead with their endless onslaughts.

rawalex – That’s why I installed ConfigServer Firewall to block things for me. It’s got some awesome code to say things like “Oh, some doofus in Michigan is hitting my server 20 times in 30 seconds? Probably botted, let’s block.” It’s crazy powerful, and stops people before they hit .htaccess.

Ditto Mod_security, which can do a lot of that heavy lifting for me.

I’ve not had to touch a geo-block via htaccess in years, and those 10-50 thousand requests are killed before they cause me damage ??

Ipstenu, I agree with you, but there are risks here for a few reasons. One of those reasons is that as an example, MSN is currently running their bots on a new IP block, a significant shift from their previous habits. Having to whitelist every IP block that might have a good bot on it is quite the pain.

You also have predictive downloading, where an ISP might download the next most likely pages to get hit. That could mean a suddenly flood of requests for a short period of time. An automated firewall with too fast a trigger may get you in trouble by blocking out valid users from time to time.

For the record, I do have a firewall, and I do have plenty of people blocked, but volume attacks are only one of many issues at hand, and you can’t be trigger happy because not all volume visitors are attacks.

The question is “is wo-comments.php wp-login.php (and such) fundamentally different from index.php? The answer is yes, because these programs are often accessed with bad intention. The are things that generally you put in a robots.txt file not to be indexed (why let the bots index your login page?), and they are things that having the full luxury of all server tools from firewalls (as you suggest) down to .htaccess and other tools so that you can limit the risks.

There is a huge difference between a bot visiting your site a lot and someone hitting wp-login a bunch of times. Automated firewalls are not as good at picking up the difference. They are one security measure, but can be a bit of a blunt instrument for dealing with attacks.

Most importantly, I see little reason NOT to do something like this. On a wordpress level, moving these files can be handled either with 301s or by replacing the current wp-commnents.php and wp-login.php with header redirects to the new location. Nothing breaks, and you get plenty of potential benefits.

Oh, and your blocking technique also blocked out the predictive downloaders used by some companies to speed internet use, and likely blocked out certain bots that are beneficial to your site. Automated blocking is not a great solution, and certainly there is a difference between 50k hits to your blog and 50k hits direct to your wp-comment.php by a spammer.

Also, what percentage of wordpress users do you think could apt-get, install, and propertly configure your firewall? I suspect the number is small. Giving them an easier way to handle certain issues (like being able to add IPs to a block list for comments, logins, and user signups as an exmaple) would go a long way to helping the average guy handle the big security issues of running wordpress.

Another tidbit that has come up in support of this sort of change is this:

More and more spammers are using VPNs, proxies, and TOR to comment and trackback spam. If you move to block these proxies off of your site for spamming, you are very likely also blocking off potential normal visitors or readers who might use those same services. As a result, any IP blocking done to automatically block out spammers also generally denies access to your blog site for everyone using that same service. Even if you are very careful in which IPs you drop, it is quite possible to end up dropping real visitors from time to time as well.

Ultra-cheap disposable cloud computing instances are another current fave, and you may not want to allow these people access to try to brute force a login or dump comments on your blog.

Also, you have to be careful of htaccess size creep. In a world where Google penalizes sites for being too slow to load, adding any processing time to every page view isn’t a good way to operate. Even non-matching rules still have to be considered to see if they match, which in turn slows every page request.

So the solution is pretty simple: Move access to key components to a place where they can be handled uniquely and in their own manner. You may not want to do a geoip on every page load of your blog, but you might find it very helpful when you are considering who may or may not add a comment or log into your blog.

So as an example, having a writable .htaccess file, you could allow within the comment moderation area the chance to take an IP and add it to a deny list in the htaccess directly. It wouldn’t stop that IP from enjoying the rest of your blog, only to deny them access to comments or to log in.

My concern is that anti-spam services are what the wordpress owners “sell” to pay for all of this, so perhaps there isn’t as much desire to find a solution that doesn’t involve a paid plug in.

Even if you move things, a spammer will still hammer your server. They don’t care about a 404. Your site will still crash.

Right now, there’s not a good, safe, sustainable way for WordPress to handle this, so it’s left in the purview of hosts and proxy services like CloudFlare.

Do we think WP can do things better? Of course. We just don’t agree about moving files as a viable answer ??

There would be no 404. I am not saying “remove the files and let them get a 404”, rather just to redirect certain existing files to a new location where you can do additional apache / httpd level processing on them.

You would 301 the old location to the new location. That would make it entirely backward compatible, supporting all existing themes and links. Sending them to a new location means you can use filtering specific for those exceptional cases directly. Rejected IPs at this point would get a 403, or could be reflected back to the source (which in theory means the load would shift to their server).

The key here is that the less you do in PHP (and the more you do within the very effecient apache security) the lower the load would be on your server. Your site is less likely to crash if they never access beyond opening a connection and getting dropped.

Remember, you have plenty of options here, from limiting access to certain countries to specific IP addresses. It would be very easy to create within wordpress a simple method by which IP addresses marked as spammers in comments are also then blocked from further commenting by being added to the htaccess that would limit access to the comment posting functions. I could even imagine a plugin that operates similar to the RBL to block out comment spammers before they have even spammed you the first time.

There are good, safe, sustainable ways for wordpress to handle things, but it requires that you have to think about efficient ways to handle and process this type of traffic. The answer isn’t in PHP, because PHP uses a lot of resources, and invoking any part of wordpress by nature comes with that load.

I am not saying “remove the files and let them get a 404”, rather just to redirect certain existing files to a new location where you can do additional apache / httpd level processing on them.

I fail to see how that is protection if the files are redirected… Then the attacker gets sent to the new location and off they go to the races again. I may be not understanding what your goal is with this though.

From my perspective, the end result remains this: Person hits my site, gets punted to a new location via .htaccess (keep in mind Nginx and IIS for this, you have to account for everything) OR via WP (which will run PHP). So my site still has attacker traffic and vulernability.

I am a staunch supporter for keeping the processing out of PHP, but for ultimate compatibility with WordPress, it MUST be in PHP :/ Ergo the solution is not to protect myself with WordPress, but to install tools to protect WP from people ??

“I may be not understanding what your goal is with this though.”

The goal is that almost every operating environment (including Windows and Nginx) has web server level tools to sllow you to handle, process, and ultimately decide what to do with visitors. In Apache (by far the largest user base), that is done with .htaccess, which is both effective in it’s ability to filter, and also light on the server.

However, before you even get to that point, you have to consider that there are a very few points where someone goes from being a reader only towards being more – a comment writer, a contributor, an author, or an admin. In very basic terms, you might allow anyone to read your blog, but you would likely only allow a very few to admin. Putting those points of access together in one place where you can apply “better” tools seems like a much easier way to do things.

Moreover, in the case of using htaccess, it is very possible to make the htaccess at that level able to be written (and even edited) within wordpress. I was thinking more of a situation where marking a comment as spam would (if you setup that way) to also add that IP to the .htaccess as denied to access those areas.

So you can create a basic system that would perhaps help to block out the most annoying repeat comment spammers for users with a basic technical background, and for those of us with more skills we could apply all sorts of filtering at the apache level to deal with the issues at hand. That is everything from GEO-IP to filtering by browser, language, or using any number of other tools that exist for use with htaccess.

In the same manner, in a windows server installation, it would allow those files to be treated as common (on the folder level) which is significantly easier to do (and to explain, for that manner) than trying to apply things to individual files.

Let me put it another way: Can you see a reason why you wouldn’t want to allow people the OPTION to do more to protect themselves? Even if you did nothing else and only relocated the files, those of us with more skills would be able to take steps to protect our installations better, and perhaps plug-ins could be written to do the same and offer all users better security.

I appreciate that the goal is to do everything within wordpress/PHP. However, we are already depending on Apache or IIS to serve the web pages, why make it difficult to use the powerful security and filtering tools that exist at that level?

Can you see a reason why you wouldn’t want to allow people the OPTION to do more to protect themselves?

Sure can ?? And it mostly comes down to supporting them.

See that’s my main job. I am a WP professional support tech. I do it for my company, who also pay me to do it here. That means I know exactly how clever the majority of users are, and I gotta tell you… They will screw up that protection VERY easily. Given how much time I spend helping them unravel the extant plugins, if we give them the chance to move around those other files, we will effectively kill the ability of anyoe here in the free support forums to help them, because they will not be able to tell us “I moved the folder….”

I see it every day. I’m aware of how technically apt people are and how much they’re not. I know that by having lowered the bar in WP as we did, we made it easier for them.

Making their life more complicated for a small gain isn’t worth it unless we can make it foolproof. And until then, I’ll be firmly against this kind of idea.

those of us with more skills

Sadly, you mean the minority of WP users. And they’re capable of installing firewalls, or understanding that they may want to hire someone to do so.

I am sorry you still misunderstand. It’s not an OPTION to move the files, it’s move the files which as a result gives MORE options.

Clearly, anything to do with comment spam is a sensitive issues with Automattic. Understood, it’s the revenue source.

This topic really is going round and round. It’s a variation of another idea that is routinely rejected.

Clearly, anything to do with comment spam is a sensitive issues with Automattic. Understood, it’s the revenue source.

Oh, come on. Cut that out, that’s got nothing to do with this idea of your’s and that’s completely untrue and baseless.

Independent of any 3rd party company (and yes, while some may not accept it Automattic is not WordPress) moving items that way doesn’t accomplish anything practical. As Ipstenu stated it does make it more difficult to support a WordPress installation for the majority of users.

Let me put it another way: Can you see a reason why you wouldn’t want to allow people the OPTION to do more to protect themselves?

You do understand that that option already exists as add-ons in the form of plugins let you do this already? Users have many options. Re-doing the file architecture doesn’t save load from the server. It doesn’t by itself add any protection. Attackers can easily adjust and moving files around won’t add value for preventing attacks.

While I do not use any security plugin myself, and 100% believe that messing with the location of files is unwise there are many plugins in the WordPress repository that move, hide, or alter items such as the login URL. WordPress users can and do avail themselves of those plugins.