BuddyPress.org

Hi @baldarab

What’s the content of your robots.txt file?

I found this answer to this issue by: @donalyza. He said:

“if you use phpmyadmin, you can easily export the 3 tables related to groups from site 1 and import them in site 2. phpMyadmin has natively import/export tools and avoids you to use an extra plugin to generate CSV or sql formated files.

xxx_bp_groups
xxx_bp_groups_groupmeta
xxx_bp_groups_members

xxx is the prefix you entered during the wp install. By default it is wp, but it is recommended to use another one. Spambots are too much in love with wp_ prefix. You’re warned ! :d”

I just tried it and it worked, however I had to edit my prefix accordingly to the database prefix I was uploading it to. I used “Coda” to do this, but any similar program works. The site I exporting from had “wp_bp_groups_members” and I changed it to “qou_bp_groups_members” which was the new site prefix.

Wide subject and several answered on this forum.

Askimet covers comment spam and doesn’t avoid clever spam bots to hit directly the DB.

Basic recommandation is to use table prefix different of the classic wp_. This calms down most bots.

A closed door is always a challenge for any spammer. WP is not fort Knox and depending your host, what YOU did and many other security details, this has no end in fact. If your site is Facebook, you’ll probably receive more spam than if it would be mykittycat homepage. Glory has a price ! 😉

Some htaccess rules against reputated spam server and one or to plugins aside what exist natively in WP should be enough to protect you a little from massive spam.

For example: buddypress honeypot + ban hammer for BP

or more simple and rought
http://mattts.net/development-stuff/web-development-stuff/wordpress/buddypress/anti-spam-techniques/registration-honeypot/

… + searching this forum, maybe you can find more tips. 😉

I’ve run into the same problem and asked for ideas around here and seen others that have posted about it in the yoast forums a few times – don’t know why yoast does not get into the bp pages thing. I got some help from the wpmu-dev guys that cobbled together some code that creates page titles and meta descriptions for members and groups pages – which is awesome!

Does not fix the member/username/messages and similar sub-sub pages (but I block those with robots.txt wildcard matching anyhow)

Would like to see buddypress pages added to some kind of taxonmie thing that yaost would auto pickup.. and love to see the options for setting templates within buddypress itself, so as to not rely on yaost for some this, and custom mu=plugins hack to fix other parts of it… google’s webmaster tools alerts missing info on many pages of an active bp site, and has for a long time.

Hi @olaska
you need to add some more validations to your registration page read this post for more info
https://buddypress.org/support/topic/registration-validation/#post-235934
plus install bp-security question plugin which throws a math challenge on registration page this will help you keep out few more bots
Thanks

The robots.txt just says

User-agent: *
Disallow: /wp-admin/

which is pretty standard. The profile pages are under the ‘/members’ directory
(Here’s a link to the site)

Hi @independent

What does your robots.txt file look like?

Spam bots are clever, that’s it.

What does your robots.txt file look like?

@sbraiden – I had similar 24 second page load times, and tried to get advice for enqueing, dergistering, and compacting the multiple and overlapping java and css all these plugins attached to buddypress are mixing in on top of the themes stuff.

Y Slow gives my BP site with basic plugins an “F” – WP professionals shrug it off – meh.

(more one all that here: http://premium.wpmudev.org/forums/topic/deregister-enque-compact-css-and-java-jquery-buddypress-load-time )

I have a sneaky suspicion however that my load times were an issue for me when logged in, and perhaps being logged in as an admin, I THINK that the (stupid) wpmudev dashboard plugin was slowing down my page load speed dramatically more than anything else. It was strange that after I complained of my long page loads, that 2 days later wpmudev had an update for their dashboard thing, and then my page load time went to like 3 seconds. – Coincidence, maybe, nothing definitive. – Everyone else said the pages loaded fine – so maybe it was just an admin thing – or maybe my ghostery blocking gravatar loads or something.

ANYHOW – in regards to hosting, I have a small buddypress site running fine on a shared server with amerinoc. I have one that is fairly busy running fine on a dedicated server at certified hosting.

I personally think that most important thing for a WP based site to perform well is blocking all the bad bots.

I have found that blocking all the naver and badu spiders (And most others) with a robots/txt file has decreased the sql over load (at peak times) on my servers by more than 80%.

I found that hosting a few wp sites on a shared server or dedicated could cause problems not just with spiders crawling pages too much too fast for indexing, but also all the attempting account creations / account brute force logins – even if they are blocked with something like sucuri or limit login attempts – every time they tried to login – they were using up server resources to load the login page, then hit the database to check credentials.

I also suggest using a pwd auth like explained here: http://support.hostgator.com/articles/specialized-help/technical/wordpress/wordpress-login-brute-force-attack

locking down the login with a double thing like that is fine for most WP installs, and a private family / friends BP site should be fine – when the bots can’t login through the first thing there is no need for wordpress to load a bunch of php / css files and pull from SQL a bunch of times just to give a bot a failed login – It becomes a problem for general open to the public buddypress comms I guess.

Now I set all my non-BP sites to use the double auth, I block all search engine bots aside from the top three selectively with robots.txt – and now just about any server can run fine with wp / bp – especially if some attention is paid to plugin overhead, wp-cacheing tools.

I have my fingers crossed the new bp-mediapress (sp? and Beta!) plugin thing will decrease the plugin overhead of rtmedia and offer a better alternative for pics and stuff.

Same random thoughts – I’m not an expert so take my 2 cents with a grain of salt or two..

It’s not buddypress but WP who manage registering and concerning bots, they go directly on your server.

A good starting point is to read the WP Codex:
https://codex.wordpress.org/Hardening_WordPress

And at least,
Never use “admin” as username
Never user wp_ as table prefix

If you search for “spam” on this forum, you will find many topics about this subject.
And the latest one, even if not directly related to your issue, is one of the sticky post on the forum homepage. https://buddypress.org/support/topic/this-is-why-we-cant-have-nice-things/

@@henrywright yes we essentially had to shut off access to the WP backend as the only effective way to cut off the bots as it was such an overwhelming and sustained onslaught, unlike anything I’ve seen before and I’ve experienced a few over the years. When access restored you should be able to post, hopefully whoever has had access previously i.e published pages was/is an author should find they continue to be able to edit/publish as they used to.

@xprt007,

my 3 word recommendation: disallow group creation !
And prevent your users, if they need a group, that they have to ask you to create it for them.

A good pratice to avoid spam, is to use another table prefix as the default wp_table_name. Bots really like this prefix to rape databases. 👿

Aside you can also try to stop some spambots via htaccess.
Search on the web for more information on how you can do this.

Here 2 lines you can add to htaccess to block some russian spambots (without any waranty)

RewriteCond %{HTTP_REFERER}  ^(.*).ru/(.*)
RewriteRule ^.*$   -   [F]

@donalyza,

if you use phpmyadmin, you can easily export the 3 tables related to groups from site 1 and import them in site 2. phpMyadmin has natively import/export tools and avoids you to use an extra plugin to generate CSV or sql formated files.

xxx_bp_groups
xxx_bp_groups_groupmeta
xxx_bp_groups_members

xxx is the prefix you entered during the wp install. By default it is wp, but it is recommended to use another one. Spambots are too much in love with wp_ prefix. You’re warned ! :d

The security question works, so bots cannot register in the website.

How long are WangGuard active in your website?

If are active less than 2 days, maybe are signups made before WangGuard was installed.

All users has 48h for activate their accounts, so maybe bots are blocked. Wait 2 days and update the result here.

I’m the developer of BuddyPress Security Check. Unfortunately, it appears that spammers have found a way to complete the math sum, allowing them to register. This means that BuddyPress Security Check will probably not prevent bots from registering. It certainly isn’t generating fake signups though. Probably best to disable BuddyPress Security Check until I figure out how I can fix it and release a new update.

Thanks for the ping @johnjamesjaccoby

@robg48 something else you could do is use a honeypot. An example is

http://www.pixeljar.net/2012/09/19/eliminate-buddypress-spam-registrations/

It works by adding a hidden field to your registration form. Users can’t see the field so will never complete it (it will always be blank). Spam bots, however, don’t view the page in the same way as users. They ‘see’ the page source so will always ‘see’ the hidden field and try to complete it.

On registration form submission, if the hidden field is blank then we know it’s a genuine user trying to sign up. If the field is completed then we know it’s a spam bot and we can halt the registration. Hence, the name honeypot.

@robg48 just a thought – try changing the name of your registration page. Spam bots automatically look for pages such as /register/ so maybe use /sign-me-up/

Most of wordpress plugins mentions above work like

Attacker > HTTP server > PHP > WordPress > PLUGINS

We all need to have something before WordPress that’s why I recommend

NinjaFirewall (I do not have any relation with the plugin creator)

https://wordpress.org/plugins/ninjafirewall/

Block the attacker before the WordPress

Attacker > HTTP server > PHP > NinjaFirewall > WordPress > PLUGINS

As always in installing any plugins that possibly can block your admin access you have to read the Installation note and have access to the FTP.

NinjaFirewall will work as another layer to protect your site.

In addition if you have not done it:

1. Change your “Admin” username to something dificult and at least 10 characters (+) but easily to remember (+ for you – for security) or you have to read a note (-) safely secured in your safe locker (+)
2. Make your password at least 25 COMBINATION of characters (+) but easily to remember (+ for you – for security) or you have to read a note (-) safely secured in your safe locker (+)

NinjaFirewall:

• Web Application Firewall
• Full standalone web application firewall
• Multi-site support
• Compatible with shared hosting accounts
• Protects against RFI, LFI, XSS, code execution, SQL injections, brute
• force scanners, shell scripts, backdoors and many other threats
• Scans and/or sanitises GET / POST requests, HTTP / HTTPS traffic, cookies, server variables (HTTP_USER_AGENT, HTTP_REFERER, PHP_SELF, PATH_TRANSLATED, PATH_INFO)
• Sanitises variables names and values
• Advanced filtering options (ASCII control characters, NULL byte, PHP built
• in wrappers, base64 decoder)
• Blocks username enumeration scanning attempts through the author archives and the login page
• Blocks/allows uploads, sanitises uploaded file names
• Blocks suspicious bots and scanners
• Hides PHP error and notice messages
• Blocks direct access to PHP scripts located inside specific directories
• Whitelist option for WordPress administrator(s), localhost and private IP address spaces
• Configurable HTTP return code and message
• Rules editor to enable/disable built-in security rules
• Activity log and statistics
• Debugging mode