BuddyPress.org

Please try to supply answers to the following questions.

1. Which version of WordPress are you running?
Lastest (stable)
2. Did you install WordPress as a directory or subdomain install?
Directory
3. If a directory install, is it in root or in a subdirectory?
Root
4. Did you upgrade from a previous version of WordPress? If so, from which version?
No
5. Was WordPress functioning properly before installing/upgrading BuddyPress (BP)? e.g. permalinks, creating a new post, commenting.
Yes
6. Which version of BP are you running?
Lastest (stable)
7. Did you upgraded from a previous version of BP? If so, from which version?
No
8. Do you have any plugins other than BuddyPress installed and activated? If so, which ones?
Yes, many plugins and all of them BP related, since I don’t have any error/problem with my current installation, I won’t insert here this big list. Need to mantion BP Like/Dislike though
9. Are you using the standard BuddyPress themes or customized themes?
Standart
10. Have you modified the core files in any way?
Yes, In many way 😀
11. Do you have any custom functions in bp-custom.php?
No
12. If running bbPress, which version? Or did your BuddyPress install come with a copy of bbPress built-in?
Lastest, I downloaded it from WP Plugins
13. Please provide a list of any errors in your server’s log files.
Strange but no errors (with Debug turned off)
14. Which company provides your hosting?
Local installation
15. Is your server running Windows, or if Linux; Apache, nginx or something else?
Linux Ubuntu, apache 2.2 php5

@bp-help

good suggestions. thx. 2 of them r new to me, so other people may find them helpful also.

on our sites we r using::

Keith Graham’s most excellent ‘stop-spammer-registrations-plugin’ – https://wordpress.org/plugins/stop-spammer-registrations-plugin/

– has stopped over 53,000 spammers since feb this year! it uses external lookups on StopForumSpam, ProjectHoneyPot, BotScout, (Akismet, which we dont use), others – thus great collective benefit/advance warning of bad traffic. also traps brute force attacks (bad logins/registrations/comment posts, etc), etc. is simple enough to play nice with most plugins.

to try & keep as much load off the front-end of the server as possible, we also have set up:

linux iptables ( & ufw add on )- as the basis of all firewall stuff. also has our manually maintained blacklists & whitelists. various custom rule chains setup. takes a while to get your head around, but is essential.

linux fail2ban – essentially an add on to iptables, puts people in jail for bad behaviour – eg: brute force attacks against ssh, ftp, mail logins. we also have set up custom rules detecting bad activity against wp-login.php itself via fail2ban. am looking to do some more with this.

linux apache – mod-security2, libapache2-mod-evasive, libapache2-mod-antiloris, libapache2mod-spamhaus – which help protect against general bad behaviour, DDOS, blank header attacks, the infamous ‘Loris’ script (which we’ve experienced!), and bot-nets. still assessing how effective these r.

we have also had to tune apache on our VPS for resilience in the face of DDOS type attacks and heavy-handed brute force attacks.

some further good tips here: http://www.dannytsang.co.uk/index.php/apache-2-hardening-tips/ & elsewhere.

linux logwatch – reports various access stats (the good & the bad & the ugly) via email – very useful indeed for checking whther situation is under control (or not).

linux rkhunter – scans for rootkits on the server from time to time – just be sure – & particularly useful if u ever do get infected in hunting down the intruder’s code.

obviously we also have file system bolted down. (there is a good wp plugin to check permissions bolt-down, i forget what its called). we also spend a LONG time analysing logs etc.

anway, that takes care of many of the bad boys, but we r still left with the following problems to crack:

1) we have observed that many bad bots/scripts are exhibiting ‘learning behaviour’ (ie. heuristic) and r finding ways around fail2ban rules/jails, etc. in particular:

a) rotating IP addresses to match ‘ban counts’ – currently we have them wasting an IP address every 3-4 attempts, but they still seem to have an inexhaustable supply, else are spoofing extreamly well.

b) varying their retry period to match the length of jail sentence. (ie. they are not wasting their mips whilst in jail, just enough to detect when they are released,record it, and tune their future responses).

2) content scrapers, probes and bad-bots generally – these r wasting enormous resource on our servers. typically i would suggest such ‘bad traffic’ is responsible for over 50% of total server load (ie. not good at peak times on a busy site). additional problems we r facing here:

a) bad bots often spoof the agent string to pretend to be eg. google, bing, etc. the only way u can tell is by reverse lookup of ip address and try and match to one of well known range of ‘good bot’ addresses. but, despite fact that many ranges are well known, most of them are never actually published or confirmed, many are variable. i am not aware of any definitve list of ip addresses of good bots (though there is http://www.iplists.com/ whichis not bad, & http://www.webmasterworld.com/search_engine_spiders/ which is often helpful – these are very much ‘best efforts/as seen in the wild’ lists.). this problem worsens with the rise of social network agregation services, other (legitimate) content agregators, and personal content aggregating software on mobiles, tablets, etc.

idea: i am thinking of writing a script/plugin/rule to do smart lookup of ip against good bots list, & to automatically maintain that (collective) list. ideally, this is a service that someone like spamhause, or projecthoneypot should offer, since they already have the infrastructure. but, we’ll see. the script will detect traffic ‘purporting to be a SE bot, of any kind and to ban it via iptables if it isnt in the approved list/doesnt check out. the risk is in false positives and harming ones SEO. anyone any thought in this area?

b) probes & sniffers hunting out wp/bp forms, ajax ports, plugin files, forms, etc – in advance of main attack by penatration/spamming bots. typically always use swiftly rotated ip’s. many many variants out there. usually they have no luck on our sites, but that does not stop them trying in vast numbers (bot-nets, collectives? hives?) and harming out response times, etc.

idea: url obfuscation has been brought up on this forum before, particularly for eg: login, registration, admin url’s, etc. i am thinking of creating a plugin to dynamically hash encode links of choice using someething based on wp forms nonce system. not only useful for causing probes & hackers pain, but also to help thwart media thieves. obviously, scripters will soon respond by just snanning for link titles in html, so not bullet proof in any way, but they will at least be on 1-time request code, so causing them page reload every request & less sophisticted scripts will be totally wasting their own time.

anyway. these have been my thought so far. would love to hear experience/insights of others.

unfortuntely wordpress & buddypress sites in particular represent the richest of prizes for hackers, content scrapers, spammers, etc – & they r really on our case. furthermore, there is some BIG money involved, from porn to pharma to credit card fraud; that means some very smart programmers being paid excellent rates, to hack our systems, full time. add to that, the 10’s of millions of infected machines out there (often unknowingly) operating as botnet drones, trying to pernetrate our servers 24×7, steal our machine resources and steal our members personal data. it is a war of attrition.

all further experience, ideas welcome, here.

I have just created a short video to show BuddyForms in action:

http://youtu.be/n0yv0n_e91o

@bb-help
The form is working fine. The problem is that, as you can see in the screenshot, the form should be included in that white box. ( Registering for this site is easy …..)
Ok, for you guys to understand better what I want to mean:
HOW IT IS NOW:
HOW I WANT IT TO BE:(here is zoomed out to see the whole page)
P.S.: In the second screenshot (how i want) I inserted an height:500px style in my browser so I could make a screenshot. (that isn’t real, it’s only me that I can see it, so it doesn’t really fix the problem).
My wp version:3.5.1
Buddypress version: Version 1.8-beta1 (I also tried the 1.7.2 from the wordpress>plugins but has the same problem)
Register link: roleague.tk/inregistrare
Activate link: roleague.tk/activare
Members: ../membrii
Activity:../activitate
And, as you can see, this problem is just on the register page..
Are these details enough? If not, tell me what to add. Thanks. Waiting for asnwers.

I’ve posted a ticket about this issue:

https://buddypress.trac.wordpress.org/ticket/5052

– Updated from what WP/BP version to what version?

This isn’t a “real” update, it’s a new theme laid over an existing site. I began by porting the existing database over to a test server. I then updated WP/BP and all plugins used from there.

– How does new registration “break” the site? White screen or 500 error? What shows up in your error logs?

As stated above, when a new user registers, as soon as the form goes through, most pages of the site break. They are truly random. Sometimes its the activity page, member directory, or even a simple contact us page that’s not tied to BuddyPress.

On the test server the page serves a blank index.php template (no content in the content area) with a title bar that says “Not Found”. On the production server, it goes straight to the typical GoDaddy 404 with the silhouettes.

– What random pages show up 404? Pages created in Pages > Add New or BuddyPress pages?

Both

– How did you install WordPress – via webhost one-click install or did you upload WordPress

As stated in this post, the database was ported over. Home and Site URLs were changed and recommended WP script for find/replace to change URLs was used.

I’m less concerned with the production server, since both serve the same error. What I’d like to know is if porting over the database may have screwed things up. To further explain, I basically took the WP user and BP tables and merged them into a virgin WP database. I continued building the site and it was “good to go” for launch, and then realized this bug.