Viewing 15 replies - 1 through 15 (of 20 total)
  • I will check the code. The TLD list should work for this. I will see if it is working correctly or if something I did broke it.

    Keith

    I can “me-too” that issues. At https://www.swapyourmama.com we’ve had a heavy flood of spammers registering and posting bogus ads. It appears they all are using [email protected], so I put hotmail.com on the list.

    While they may be getting blocked, the new user still gets created. I tested this with a bogus hotmail account. Naturally I never got a confirming email, but the user WAS created. It would see that if any entity on your blacklist is found, their user should not even be created.

    The site is using the Classipress theme/addon for ad-creation, but they offer no help in this area. thanks for having SOMETHING to address this.

    =Alan R.

    More input on this: I checked the MySql database and the new users ([email protected]) not only get created, but get their default password generated. Dunno they are getting this and can log in again, or if your blocking prevents the email from going out. I have gone in and simple cleared the password column on bogus users – that def keeps them from getting in again! Wonder if you could add that sort of feature?

    =Alan R.

    photoman856,
    There is a check on email sends that should prevent anyone from getting an email confirmation, even if their registration was not blocked.

    I don’t know why registrations are not blocked on some sites. I wrote the Stop Spammer Fix plugin for bbPress that I think fixes some problems with bbPress, but some registration plugins and some themes find alternate ways to register users, so that the plugin can miss them.

    I will google Classipress and see if there is something there that I can do something about.

    Keith

    Hi Keith

    Am using V 4.0 (latest) of your plugin with WP 3.4.2 (latest) + BP 1.6.1 (latest).

    Tested (via a proxifier), having added hotmail.com to ‘blacklisted email domains’ in plugin setup.

    Can confirm:
    – ‘403 Forbidden’ returned from BP registration page upon submit – OK
    – NO confirmation email received at my hotmail.com acct – OK
    – thus (forbidden) user cannot login – OK

    BUT – user id is STILL registerd on wp backend (admin, users).

    Q: is there any way to get your plugin to PREVENT the actual registration itself – we get shed loads of spammers registering and they clutter up the system making it hard to manage. As currently written, your otherwise excellent plugin doesnt really help.

    Any thoughts?

    Best regards

    Rob

    Try latest beta test. I added another test for registrations and login. I also fixed a bug in the 4.0 version (non fatal).

    One interesting thing is that I am checking more login attempts and I am seeing large numbers of dictionary attacks on the ‘admin’ user id. I am now getting rid of all my admin user ids. I have a good password, but if I keep admin, someone will figure it out.

    I think WordPress should enforce that user id admin must be changed to something else.

    Keith

    Thanks for swift reply Keith,

    Will try the 4.1 beta – though suspect it will still not PREVENT Buddpress/Wordpress registrations themselves.

    Have been digging through latest Buddypresss code and think I have found the hooks you might need to get that working:

    Take a look at:

    file: plugins/buddypress/bp-members/bp-members-screens.php
    function: bp_core_screen_signup

    2/3 ways to acheieve it I think – either:

    1) completely remove and replace add_action( ‘bp_screens’, ‘bp_core_screen_signup’ ) with your own registration func based on it
    OR
    2) add_action( ‘bp_signup_validate’, ‘your_func’ ) – this is called in the above func JUST before user regisratation details are saved, etc
    OR
    3) bp_core_validate_user_signup() func (in bp-members-functions.php) called from above func near top – also has hooks/filters which could be used – eg: apply_filters( ‘bp_core_validate_user_signup’, $result ).

    Of these options 2 would be my fave. Just need to return your own (spammer) error message in $bp->signup->errors and bp/wp will do rest.

    This way, the method of spammer (registration) rejection becomes much more logivcal and inline with existing wp/bp user validation process.

    Seems from your code you might need to put some sort of simple switch in/around end of your kpg_sfs_checkfunc – to make sure it plays nice (returns) with wp/bp hook rather than simply dying/redirecting – ubt thats about it i think.

    Was literally about to attempt a patch to your plugin myself, but I think you might be able to achieve it much faster/more reliably.

    Any chance of sometthing like this? Is it sensible suggestion do you think?

    All best

    Rob

    In the 4.0 version I got rid of all the special actions in comment and login forms. The only one left is the send email hook. This makes the plugin simple and much more stable. It is less likely to misbehave and lock out users. It is also more efficient in the use of resources as it doesn’t load up much of itself until actually needed.

    I don’t want to start hooking bbpress forms unless there is no other way.

    Instead I use an early hook (in bbpress it is ‘bbp_loaded’, otherwise ‘init’) and check the $_POST array for the fields that might be a comment or a login. I was not checking “log”, until the 4.1 beta so I was missing the login and registration attempts.

    The current version now sees all of these, but I am concerned that bbPress grabs the POST before my plugin gets to it. I had a complicated set of routines that reordered the plugins and ran the checks even before all other plugins were loaded, but I gave that up as too dangerous.

    bbpress is very aggressive about loading first, I don’t know why this should be, but it makes for a complicated environment. My limited tests show that I am getting to the the POST now before bbpress hits it.

    I do not seem to able to attract spammers to my two bbPress installs. They are wide open and allow anonymous posts, so I am not sure what is going on.

    Keith

    Thanks for the explanation Keith – your code makes much more sense to me now. I’ll give the new 4.1 beta a go and let you know how it fares.

    All best

    Rob

    My code makes sense???????

    I am a stream of consciousness programmer and I am well aware that my code reads like Finnegan’s Wake.

    This plugin grew organically over the years and was not planned or designed, it just got bigger and more complicated.

    Recently I have started an attempt to clean it up.

    I just moved the spam checking to its own include because 99% of the time it is not needed. This breaks out 38k and only loads it on form submission. The core is still 40k.

    Keith

    ‘stream of conciousness programming’ – dont think i wamnt to go there – bad enough when i find myself ‘dreaming code’. simple clases/objects for me any day. small is beautiful.

    just tested your latest 4.1 beta downloaded from https://www.blogseye.com/beta-test-plugins/ – repeated test above – same problem i’m afraid: (although rejects it now due to cached badip as expected (so that bit works ok)). but user still gets registerd.

    will trace through & see what i can determine.

    Rob

    FIXED!

    after tracing through plugin + buddypress signup the problem was actually quite simple – plugin was NOT recognising the form fields used by my (buddypress) signup form.

    Solution is:

    file: stop-spammer-registrations.php
    function: kpg_load_all_checks
    lines: around 56 – add following lines:

    !array_key_exists('signup_email',$_POST) &&
    		!array_key_exists('signup_username',$_POST) &&

    lines: around 99 – add following lines:

    } else if (array_key_exists('signup_username',$_POST)) {
    		$author=$_POST['signup_username'];

    complete new file (based on V4.1 beta – though would be similar fix for earlier versions), is here:

    https://pastebin.com/pZH9jx1M

    – see my mod marks ‘mod jrc 171112’

    (not sure is the ‘signup_username’ is really required but i added it for completeness/consistency anyway.

    All now seems to work fine – proper checks are performed on all new buddypress registrations AND anyone failing those checks does NOT get registerd. HURRAH!

    Thanks for a great plugin Keith. Happy days! ??

    Rob

    Thanks Rob,

    I knew about that one, but somehow it did not make it into the code. I think this is the final fix needed for bbPress. Registrations, signups and logins are now filling the log.

    I am amazed at the dictionary attacks on all of my blogs that are now showing up. The plugin is blocking hundreds per hour. I am bumping up the delay time in the deny section to 10 seconds to slow them a bit.

    Everyone! Your blog is under assault – change you login and get rid of the admin user. Change your password to mixed upper and lower case and be sure to throw in a few numbers and some punctuation.

    Keith

    Hi Keith,

    No worries, pleased to help.

    It would be good to have it confirmed whether this also fixes the original problem of jmorrow and photoman856 above also.

    Re: ‘Dictionary Attacks’ – I know what you mean – our BP sites (also WP, in fact our servers generally) are constantly under attack, have been for a long time. (the numbers can get so high in fact that they consttitute as DOS attack in their own right, slowing performance).

    Its one of the reasons why I think your plugin is so CRITICAL.

    I installed Fail2Ban on our servers a few years ago to help combat SSH, FTP and Mail attacks and it does reduce those numbers greatly – though not altogether. Have been wondering about trying to extend it’s config to cover WP/BP attacks also – since it is pretty efficient.

    I am assuming your attackers are mostly using bots/rootkit probes and rotating proxy IP’s?

    I am loath to suggest adding an (anti-robot) capture field on ALL WP/BP forms, but it might have to be the next move.

    I have also found it necessary to ban all hotmail, gmail, aol, yahoo email addresses also – (as well as the usual .ru and .cn, etc) since these are INVARIABLY (in fact almost exclusively) used by hackers. Luckily our main sites are for professional users only who should have their own legitimate company email domains (we make manual exceptions for VIP’s who insist on using gmail). I realise such a blanket ban is not suitable for other sites aimed at general public.

    We have also made it MANDATORY for registrants to fill in additional extended profile fields INCLUDING a special one asking for ‘Reasons why you would like to become a member of this site?’ – which we inspect manually and ONLY if its well written do the users get activated by admin. (Though this doesnt catch all since many SEO blackhat operators employ real humans in Philipines, elsewhere, to mass-register – but it does help at the cost of extra admin)

    (Long term i think we need better legal enforcement internationally and stiff sentences for script kiddies/hackers – but i dont see that happenning anytime soon – unless you are the US DOD or Mossad).

    Couple of suggestions to improve your plugin perhaps:

    1) the ‘time-out’ parameter(s) – could you make these settable via admin options?
    2) additional filters or actions to make it possible to add EXTRA fields for validation – this would help future plugin developers utilise your plugin functionality without having to mod the code its self.
    3) space for bigger list of blacklisted IP addresses supported – separated from email addresses – including support for wildcards/ip adress ranges – (i have noticed that bot proxies often eventually start to rotate their lists, (within limited time frames), so gives you a fighting chance so long as you keep on top of it).

    Anyway, sorry about slight thread-drift – maybe we need a new thread for this subject.

    All best

    Rob

    Great ideas. I will put in the time-out parameter in the next few days, since that is easy. I am also going to make the sleep parameter an option. I notice that it does slow the spammers down when they have to wait before they can try the next password.

    The extra fields for logins or comments should be a separate plugin. It is a useful idea in its own right, and is not necessarily a stop spam thing. I think there must be a dozen or so plugins already that do this.

    I try to keep the bad ip list short because it is loaded every time you check and could possibly cause resource issues. I will make the size a separate option. I regret even including emails in the checks because the spammers rotate them and IP is a much better way of identifying the culprits.

Viewing 15 replies - 1 through 15 (of 20 total)
  • The topic ‘Not working to block email domains’ is closed to new replies.