rawalex

” while some may not accept it Automattic is not WordPress”

Yes, but the official anti-spam tool is Automattic, and is given automatic installation status where nothing else gets it. Anyone operating anything remotely commercial on wordpress is required to pay to get this service. WordPress as it stands is written with Akismet in mind, and not easy of installing any other solutions to counter spam. Everything else has to be something that works AROUND Akismet. So like it or not, you cannot talk about one without the other. Don’t think so? Try suggesting that Akismet shouldn’t be a default install or should be replaced. It quickly turns into a wagon circling event!

It’s taken 10 years for there even to be a really meaningful discussion on allowing comments to be turned off completely.

” WordPress users can and do avail themselves of those plugins.”

Can you point to some examples? I have seen a few that outrightly replace functions or try to put false doors up, but otherwise, nothing that would allow htaccess, geo_ip, and third party tools (like RBL or other spam services) to be integrated.

Perhaps I can put this in another way that might make sense to you.

Let’s say I use wordpress for a company website. The (fictional) company is “South Florida Floor Repairs”. They only server Florida, and nothing more. All of the site owners, operators, webmasters… all in Florida. Would it not be a true benefit for them to be able to say “restrict comments and logins only to people from Florida”? Do you not think that this would get rid of pretty much all of the drive by spam, and at the same time would eliminate almost all of the brute force attackers?

Let’s say I operate a website that is only in polish. Wouldn’t it be nice to be able to filter by IP, browser, and request language so they only people who could access comments would be in my target area?

Let’s say I admin a large site with only 2 administators, one in the company office and myself. We both have fixed IPs. Wouldn’t it be nice to be able to say (in a simple manner) restrict logins on these two IPs only? Or for that matter, allowing for a variation of a “door knock” which would shut out everyone from even accessing the login script unless they first do X or Y or Z?

There are many, many, many security options server side that are very powerful, but most work best on a directory level.

As wordpress moves more and more towards being a CMS rather than just a blog, and as commercial use grows, you will find that there will be more calls for improving security. In fact, I would say that improving security and cutting down webspam should be a higher priority than redesigning admin page layouts or similar.

Can you give us some details of steps wordpress have taken since, oh, 3.5 to address webspam?

[ Don’t bump. ]

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.

“I’d like to respectfully suggest that how comments are handled in WordPress is one of those usability issues that you should address.”

I would agree with you here. Comment handling on WordPress is based on the concept of accept all, refuse few, default to wide open. Perhaps 10 years ago this was an acceptable way to run websites, but the current internet world does not work as well with that. Sometimes it’s not just being too close to the forest to see the trees, but rather also being a tree lover and not considering the other options.

Any change that allows comments to be disabled should also include actively denying connections to wp-comments.php where possible, perhaps by added to the root htaccess to redirect people to 127.0.0.1 or similar. A similar “deny access” process could be created for non-apache systems (similar to how permalinks are handled). That would go a long way to lowering useless server load for sites that do not desire comments.

“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?

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.

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.

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.

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.

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.

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.

Bea, the problem I am seeing is that people who are trying to generate negative links to your site, to penalize your site in the Google search results will set up pages with the initial crap links on them, perhaps adding them as spam in forums and as comment spam. Once Google gets ahold of a single link like page 2 I showed above, WordPress perpetuates the problem by always providing the page, and providing “previous – next” page links with the junk query appended on them. That means every other page in the series is now duplicate content as far as Google is concerned.

When you have that done a few times, Google ends up thinking you are trying to spam their index, and drops your site.

I am not sure why the “previous – next” links on the page automatically copy over the query without consideration for it’s validity, nor do I understand returning a page with a crap query as valid. These crap queries should be truncated and removed, and the browser sent a 301 to the actual valid content, without the query. Returning a valid 200 code and a page is a horrible thing to do, and makes wordpress sites vunerable to all sorts of negative search engine action.

Bumping up… anyone have an answer? Idea? is there a way I can submit this bug for consideration in a future version?

I want to add this to the discussion:

https://hellomotow.net/backlinks/

This guy basically is comment spamming for a living. Doesn’t that start to ring some bells somewhere in wordpress world HQ?

Ineffective in the long run is throwing up your hands and saying there is nothing to be done.

What Jason proposes is a system that, while it can be defeated, would actually require some effort on the part of spammers to get around. It would eliminate the drive by spam, and it would make wordpress a less tasty target for every script kiddy on the planet.

I have a couple of blogs that rank very well in google and get tens of thousands of hits. The punishment for ranking well is sometimes thousands of spam comments a week. Askimet fails on about 30% of them. When you have stats like:

“Akismet has protected your site from 27,921 spam comments already”, and 30% got through, you know you have a lot of work to do just to keep spam off your site.

Spam is a big issue, likely more important than moving columns around in the admin. Why doesn’t it get the attention it deserves?

Otto, I agree there are some interesting tools out there. My concern though is that the default settings on wordpress appear to make the product “open” by nature, which is what the spammers take advantage of. You only have to read some of the installation problems people have to understand that many of the users of the WP product are not technically inclined, and wouldn’t have much consideration about spam in their comments until long after their blogs have become infested with spam. That of course relies on them actually checking, we both know they are plenty of blogs running without supervision.

So my point only is that while WP is an “open” product, isn’t it wiser to do things that by default block the most obvious and most annoying spam methods used, and make it simpler for the newbie or non-technical person to use and enjoy WP, while still giving power users like yourself the options you are looking for?

Trackback spam isn’t the big issue. It’s more like:

Author : Fishing Umbrella (IP: 174.140.170.218 , 174-140-160-218.in-addr-arpa) E-mail : [email protected]
URL : https://www.fishingumbrella.org
Whois : https://ws.arin.net/cgi-bin/whois.pl?queryinput=174.140.170.218
Comment:
*:I am really thankful to this topic because it really gives useful information .'

It appears to be a totally valid comment, except that what they are doing is setting their name to their SEO keywords and the URL to the target. While this link may be “no-follow”, there is still enough there that these spammers want to do it. This single individual submitted over 100 spam messages to me yesterday alone via an automated system and many different proxies and the like. Neither askimet or trackback validation would be able to handle this case at all.

Better education is important, but making WordPress safer out of the box is key.