BuddyPress.org

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

Two more methods that help. I recently had a crazy spam attack – probably 300 fake signups per day. I implemented these two methods and it dropped to near 0.

1. Change the /register/ slug to something unique. An example would be /create-your-account/, or something of that nature. It just needs to be unique and also make sense in a URL for your user. Spammers targeting BuddyPress look for /register/ as the signup page. It’s all automated so you want to filter them out at the first step.

2. Add this to your functions.php file in your theme or child theme.

It presents a dummy field that humans don’t see. Spambots will fill it out, and if the field captures a value it will reject the signup.

// BuddyPress Honeypot
function add_honeypot() {
    echo '';
}
add_action('bp_after_signup_profile_fields','add_honeypot');
function check_honeypot() {
    if (!empty($_POST['system55'])) {
        global $bp;
        wp_redirect(home_url());
        exit;
    }
}
add_filter('bp_core_validate_user_signup','check_honeypot');

Credits for #2 go to:
http://mattts.net/development-stuff/web-development-stuff/wordpress/buddypress/anti-spam-techniques/registration-honeypot/

I edited it slightly to remove the required redirect. Add that back from his tutorial if you want to. It requires that you make an extra page to send the spammer to, and I personally think that’s not necessary. I actually want them to have no indication their signup failed.

5-10 is OK — When I was handling a job application site every month we received 4000-5000 applicants and and had about 75-200 “bad users” we did have people entering bad email for their job application but it was also sometime the applicant mistype their email AND ending up shooting registration confirmation to the wrong/closed/nonexistent email at Gmail/Yahoo/Hotmail etc (I had to deal with those email providers 1-2 times a year to make sure that my Mail Server is not on the blacklist).

Btw on the Stop Spammers setting add the StopSpamForum API that way it easier for you to check or submit bad user (add Honeypot & Botscout if possible). Also “Check Spam Words” on the setting and add to them if you see a bad username keep popping up with different IPs.