The image and reCaptcha captchas have failed

Discussion in 'General Chat' started by david62311, Jul 24, 2017.

  1. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    Both of the image and reCaptcha captchas have both failed to block a bot from registering on my site.

    capture-20170720-023309.png

    In the Webid admin panel you can go to the settings>spam settings and select none, Image, or reCaptcha for the registration page or to add a captcha to other pages. I've discovered the Image Captcha that looks like what is above is TOTAL garbage and let bots sign up on my site with no problem. We need a better captcha.

    4 Bots joined my site when I used that captcha. They had no problem registering and confirming their user to join.

    capture-20170720-025823.png

    This reCaptcha has blocked more bots from joining my site than the image captcha but, in the last few days, I had about 5 join but, they never confirmed the user via email but, still tried to log in.was using the reCaptcha but, the user bot never confirmed itself. As far as I know, none of them have posted.

    I've sorted these in order that they joined. The two on the top joined using the image captcha. They actually confirmed their users and immediately went to the sell page as I will show you in the logs below this picture. I allowed those two to be active on my site for a few days just to see what they were going to do. It was a risky chance I took too. I decided to suspend them today. The other 5 got passed the reCaptcha. From this morning to this afternoon 2 bots have joined my Webid site. None of the 5 confirmed themselves.

    capture-20170723-184045-vert.jpg

    Code:
    USER ID 112 JaredU66638 Registered with 177.182.101.238 and logged in with 186.220.199.43
    177.182.101.238 - - [18/Jul/2017:17:45:15 -0400] "GET /register.php HTTP/1.1" 200 37892 "SITEHERE/register.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    177.182.101.238 - - [18/Jul/2017:17:45:17 -0400] "GET /register.php? HTTP/1.1" 200 37892 "SITEHERE/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    177.182.101.238 - - [18/Jul/2017:17:45:19 -0400] "GET /includes/packages/captcha/securimage_show.php?4679b3a66ed2981dc62450cc8fdb3eb5 HTTP/1.1" 200 4397 "SITEHERE/register.php?" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    177.182.101.238 - - [18/Jul/2017:17:57:23 -0400] "POST /register.php HTTP/1.1" 200 13273 "SITEHERE/register.php?" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    CONTINUED WITH THIS DIFFERENT IP AFTER IT CONFIRMED ITSELF AND WENT RIGHT FOR THE SELL PAGE BUT DIDN'T POST ANYHING LIKE SPAM BUT, TRIED
    186.220.199.43 - - [18/Jul/2017:18:37:36 -0400] "GET /confirm.php?id=112&hash=b43c89ffacaf017a31b85390c8e050f2 HTTP/1.1" 200 13511 "SITEHERE" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    186.220.199.43 - - [18/Jul/2017:18:37:37 -0400] "POST /confirm.php HTTP/1.1" 200 12891 "SITEHERE/confirm.php?id=112&hash=b43c89ffacaf017a31b85390c8e050f2" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    186.220.199.43 - - [18/Jul/2017:18:37:38 -0400] "GET /user_login.php HTTP/1.1" 200 14650 "SITEHERE/confirm.php?id=112&hash=b43c89ffacaf017a31b85390c8e050f2" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    186.220.199.43 - - [18/Jul/2017:18:37:39 -0400] "POST /user_login.php HTTP/1.1" 302 - "SITEHERE/user_login.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    186.220.199.43 - - [18/Jul/2017:18:37:42 -0400] "GET /user_menu.php HTTP/1.1" 200 17966 "SITEHERE/user_login.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    186.220.199.43 - - [18/Jul/2017:18:37:43 -0400] "GET /select_category.php? HTTP/1.1" 200 15240 "SITEHERE/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    186.220.199.43 - - [18/Jul/2017:18:37:44 -0400] "POST /select_category.php HTTP/1.1" 302 - "SITEHERE/select_category.php?" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    186.220.199.43 - - [18/Jul/2017:18:37:48 -0400] "GET /sell.php HTTP/1.1" 200 28319 "SITEHERE/select_category.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    186.220.199.43 - - [18/Jul/2017:18:37:50 -0400] "POST /sell.php HTTP/1.1" 200 28492 "SITEHERE/sell.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    186.220.199.43 - - [18/Jul/2017:18:37:51 -0400] "POST /sell.php HTTP/1.1" 200 28492 "SITEHERE/sell.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    186.220.199.43 - - [18/Jul/2017:18:37:53 -0400] "POST /sell.php HTTP/1.1" 200 28492 "SITEHERE/sell.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    
    USER ID 113 NidiaHentze Registered and confirmed and logged in with same IP.
    196.16.15.177 - - [19/Jul/2017:00:28:04 -0400] "GET /register.php? HTTP/1.1" 200 37892 "SITEHERE/register.php?" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:28:06 -0400] "GET /register.php? HTTP/1.1" 200 37892 "SITEHERE/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:28:06 -0400] "GET /includes/packages/captcha/securimage_show.php?3313b24fb8ead186d5cad5294de5ba20 HTTP/1.1" 200 4619 "SITEHERE/register.php?" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:28:07 -0400] "POST /register.php HTTP/1.1" 200 13259 "SITEHERE/register.php?" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:31:33 -0400] "GET /register.php? HTTP/1.1" 200 37892 "SITEHERE/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:31:35 -0400] "GET /confirm.php?id=113&hash=8777c93310b8b532efcec17c2848d4e8 HTTP/1.1" 200 13511 "SITEHERE/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:31:36 -0400] "POST /confirm.php HTTP/1.1" 200 12891 "SITEHERE/confirm.php?id=113&hash=8777c93310b8b532efcec17c2848d4e8" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:31:37 -0400] "GET /user_login.php? HTTP/1.1" 200 14650 "SITEHERE/confirm.php?id=113&hash=8777c93310b8b532efcec17c2848d4e8" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:31:37 -0400] "POST /user_login.php HTTP/1.1" 302 - "SITEHERE/user_login.php?" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:31:39 -0400] "GET /user_menu.php HTTP/1.1" 200 17966 "SITEHERE/user_login.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:31:39 -0400] "GET /select_category.php? HTTP/1.1" 200 15240 "SITEHERE/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:31:40 -0400] "POST /select_category.php HTTP/1.1" 200 15846 "SITEHERE/select_category.php?" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:31:41 -0400] "POST /select_category.php HTTP/1.1" 302 - "SITEHERE/select_category.php?" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:31:42 -0400] "GET /sell.php HTTP/1.1" 200 28340 "SITEHERE/select_category.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:34:17 -0400] "POST /sell.php HTTP/1.1" 200 28516 "SITEHERE/sell.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    196.16.15.177 - - [19/Jul/2017:00:34:19 -0400] "POST /sell.php HTTP/1.1" 200 28516 "SITEHERE/sell.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    These two bots below joined but, never confirmed.

    Code:
    USER ID 115 PrinceJervoi did not get on my site but still registered and never confirmed:
    177.183.216.29 - - [19/Jul/2017:15:10:52 -0400] "GET /index.php HTTP/1.1" 200 28451 "SITEHERE/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36"
    177.183.216.29 - - [19/Jul/2017:15:10:55 -0400] "GET /register.php? HTTP/1.1" 200 37892 "SITEHERE/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36"
    177.183.216.29 - - [19/Jul/2017:15:10:58 -0400] "GET /includes/packages/captcha/securimage_show.php?a3bfc83dd368750e3f72a7831760c185 HTTP/1.1" 200 4649 "SITEHERE/register.php?" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36"
    177.183.216.29 - - [19/Jul/2017:15:10:59 -0400] "POST /register.php HTTP/1.1" 200 13276 "SITEHERE/register.php?" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36"
    
    USER ID 114 ElenaFegan01 did not get on my site but still registered and never confirmed:
    115.214.232.141 - - [19/Jul/2017:04:51:10 -0400] "GET /index.php HTTP/1.1" 200 28465 "SITEHERE/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    115.214.232.141 - - [19/Jul/2017:04:51:16 -0400] "GET /register.php? HTTP/1.1" 200 37892 "SITEHERE/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    115.214.232.141 - - [19/Jul/2017:04:51:20 -0400] "GET /includes/packages/captcha/securimage_show.php?f84adbefca8dc8fd684ec25d3c979a79 HTTP/1.1" 200 4759 "SITEHERE/register.php?" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    115.214.232.141 - - [19/Jul/2017:04:51:41 -0400] "POST /register.php HTTP/1.1" 200 38160 "SITEHERE/register.php?" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    115.214.232.141 - - [19/Jul/2017:04:51:43 -0400] "GET /register.php? HTTP/1.1" 200 37892 "SITEHERE/register.php?" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    115.214.232.141 - - [19/Jul/2017:04:51:48 -0400] "GET /register.php HTTP/1.1" 200 37892 "SITEHERE/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    115.214.232.141 - - [19/Jul/2017:04:51:51 -0400] "GET /includes/packages/captcha/securimage_show.php?228d17346240ca9b5c5f9ec53fb3f58d HTTP/1.1" 200 3534 "SITEHERE/register.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    115.214.232.141 - - [19/Jul/2017:04:52:09 -0400] "GET /includes/packages/captcha/securimage_show.php?228d17346240ca9b5c5f9ec53fb3f58d HTTP/1.1" 200 4500 "SITEHERE/register.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    115.214.232.141 - - [19/Jul/2017:04:52:46 -0400] "POST /register.php HTTP/1.1" 200 13261 "SITEHERE/register.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36"
    This below is the ZUIBrandy30 user that tried to join my site today but, failed to confirm it's user. Besides the example of what I am showing after it does when it does not confirm it's user, take a look at the user-agent and which is firefox/52 and the ones listed above are chrome/59. What is relative about these user-agents is they are the last versions that they allowed updates on on the older Operating Systems like Windows XP or Windows Vista.

    ZUIBrandy30.JPG

    These attacks started to happen after I blocked the Jorgee user-agent. Which I spoke about and finally found a block and shared the block in this link here. Jorgee user-agent Block So, in all of my years of experience in blocking user-agents via the .htaccess file, the jorgee user-agent was the hardest one for me to block and it made a mess of my logs. The odd things is my ZB Block did not even catch what was going on there. I didn't know why the Jorgee user-agent wasn't so easily blocked like the other user-agents I blocked but, I finally got them blocked. I cleared out my .htaccess file to see if the ZB Block would catch the Jorgee user-agent and it did not. Even though ZB Block failed at that it's still a great extra security feature to have on my site. It won't let tor browsers on my site and bans them instantly.

    In my experience in blocking user-agents, I've learned that when I block them, the bots always seem to adjust their user-agent to get around my blocks. For about the last 3 years, the bots were using chrome/39 and were easily blocked and made my job of watching my site easy to watch. The user-agent never really changed or went over 40 with the firefox user-agent. They usually use two different user-agent signatures. It is unusual to see the bots using user-agent signatures with the browser versions so, close to the latest version. They used to change and adjust almost weekly whenever there was a newer browser version but, stopped after chrome/39 got updated. It was over two years that they used chrome/39. I know for a fact that I can easily block out the chrome/54 and the firefox/52 but, I could be blocking out real visitors from seeing my Webid site so, I'm going to block them only temporarily to see what happens. I mainly didn't initially block the chrome/54 and the firefox/52 user-agent to see if they could get by the image captcha and the reCaptcha and bot captchas failed. I've never really witnessed bots joining my site because I always blocked them out. For security reasons, I can't discuss in public what those bots are capable of doing once they are member on your Webid site but, I can tell you it's not good. We need a better captcha or better security to block bots from joining through the register page. Until we get that fixed, almost all of you using the Webid script will encounter bots joining their Webid site. I am truly surprised the Google recaptcha has failed because it's used on a lot of Websites. The reCaptcha that was used to joined this forum failed to stop blocks as most of you witnessed if you saw all of the crazy postings they did. I think dahl's captcha worked better than both of the captchas I discussed here because his modification had lines and thin characters in the added to the old Webid captcha and it made it hard for an OCR program to read them.

    I almost forgot to mention something here. If you look at the picture of the listusers you can see the email addresses they used. Some probably were fake and that could be why they never confirmed their user if they never got the e-mail. For me, I don't care if I get any user using an .ru email address or a .asia address because I don't want users from those Countries or using those types of email addresses on my site. I believe I can just go into the admin panel and settings>spam settings and add .ru & the .asia to my email filter list there if I want to block those out. I will give it a try. I actually thought it was funny that my user NidiaHentze entered their Country was Italy and had a .ru email address. That surely put up a red flag...get it...red flag...Russia. The .ru stands for Russia.

    I've gone ahead an added a block to my .htaccess file to block the user-agent shown in the codes below. These are just additions. If you want to see the full list then ask and I will share it with you. These blocks may only be temporary. The bots using these user-agents may stop pinging my Webid site using those user-agents. I will be able to tell. The bots may also change their user-agent signature and then I will have to put up another block. If that happens then I will let you know in a later post. Here's the blocks:

    Code:
    RewriteCond %{HTTP_USER_AGENT} Chrome/59 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Firefox/52 [NC,OR]
    A small usable sample would look something like this. I share the blank user-agent too because it's a good one to block. The Jorge user-agent block is added to this too. The Jorgee block should of just worked with Jorgee added to it but, I had to toss in the Mozilla part. All of these have been tested but, for any block that you add to the .htaccess file you should go to your site and see that it still works in case a mistake in the blocking code was made.

    Code:
    # BLOCK USER AGENTS
    RewriteEngine on
    RewriteCond %{HTTP_USER_AGENT} Chrome/59 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Firefox/52 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} beast [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} curl [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} echo [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} grab [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Java [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Mozilla/5\.0\ Jorgee [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} YandexBot [NC]
    RewriteRule !^robots\.txt$ - [F]
    
    # BLOCK BLANK USER AGENTS
    RewriteCond %{HTTP_USER_AGENT} ^-?$
    RewriteRule ^ - [F]
     
    Last edited: Jul 24, 2017
  2. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    Wow! These bots are definitely more aggressive than I have ever seen. If only you could see what happened after I added my blocks to my .htaccess file for firefox/52. My blocks worked for two hits and then the bots somehow got by and I was seeing about 100 hits to my site from 8pm to 10:40pm. The bots got brutally aggressive and have poked at my register page. I see one new users that got in and they used a Yahoo address but, not activating their accounts. I think I know what's going with why they're not activating their account. I think the activation email is going to their spam box. My hotmail emails I get from my Webid site go to spam. There's the newest user I got at ID 120. These are all bots with fake info.

    capture-20170724-090108.png

    I'm going to have to try a different block or just add a trap page where my register page is now and change the name of the page and teach the search engines that the register page is no longer there. The one issue I see with that is I've done this before and changed the name to join.php and it held the bots off for a while but, they eventually learned about the join.php page.

    The ip is rotating out too much. I will block some of the IPs that I can see are using similar IP numbers but, changing the range at the end. I will just go into the cpanel and do that. I usually just cut off the last digits.

    I'm going to try this .htaccess block. Since I have the same Firefox browser version number, I can test that it's working. My test result came up. It didn't block me out and it should of. My Firefox browser is 52.2.1 and that block for Firefox/52 should of blocked me out and it let me right in. I'm going to try this block code and see what happens. I want those bots off my site or kept at bay. I hope they stay active so, I can keep testing blocking codes on them.

    Code:
    RewriteCond %{HTTP_USER_AGENT} Mozilla/5\.0\ \(Windows\ NT\ 6\.1;\ WOW64;\ rv\:52\.0\)\ Gecko/20100101\ Firefox/52\.0 [NC]
    Forgive me because I am writing this as I am fighting the bots off of my site. I didn't know the bots could sense I was bored with them. They've stepped up their game and got more aggressive with my site. This will be fun.

    This morning as I was writing this, I had put that block in. Now I see another attempt with the Chrome/59.0.3071.86 user-agent. and they got the 200 OK status. USUALLY there is two different user-agent signatures hitting my Webid site. It's not new. That's been their pattern for years. I wonder if they just now changed the user-agent signature because I blocked it. I'm also wondering if I am going to have to put a block up for the full browser user-agent signature for each one. It used to be a block like chrome/5 would every version like 5 or in the versions in the 50s would get blocked out. My version and it's the last version I can get for my Windows Vista OS is Version 49.0.2623.112 m. If chrome is on 59, then blocking out the versions in the 50s won't be a problem soon because browsers update themselves to the next version and they will be in the 60s.

    For the record, I just noticed that my Chrome browser version that I can not longer get updates on and it's 49 and not 59 as I mentioned before. I was wrong about 59 being the last update on Windows Vista and Windows XP operating systems.

    One thing I noticed and I've heard it before that the bots tend to use phone numbers ending in 9999999. I've never witnessed this until now but, I have been told and I have read about it. It's true. Take a look at this. Whoever is programming the bots has improved it's system to make it look like the users are more authentic. Look at the nick name and name. They look like they match up. Too bad they don't do that with the emails and the countries like them using Italy as a Country but, using a .ru Russian email. One other thing I want to point out is the reg_date is coming up as NULL. I will run test to see if that insert is not working right. I have most of my real users showing some kind of reg_date but, the last couple of real people that joined got a NULL under the reg_date. This picture below is of my database and all of these users are all bots that recently. I'm pretty certain none of the information is real. Otherwise I would wouldn't be sharing it.

    capture-20170724-092940.png

    Notice that most of the phone numbers end with 9999999. The amount of numbers here where I am is 10. They show 10 digits here. We should be able to do a match for the 9s or 0s. It seems like it could be a simple fix. I will see if I can come up with something. For now I am using this in the United States. This makes is so, there is 3 digits, then a hyphen, then 3 more digits, then a hyphen, then 4 digits that have to be entered into a phone number that looks for example to have a similar amount of digits as this. 555-555-5555. I got this from an old bookmarked post. My register.php page got updated and I had lost the code when the update happened. I'm so glad I bookmarked this thread link. Phone number format

    Code:
    elseif (!preg_match('/[0-9]{3}-[0-9]{3}-[0-9]{4}/', $_POST['TPL_phone']))
            {
                $ERR = 'phone number not valid';
            }
    I did just test that out and it worked with the hyphens in the right places. It failed without the hyphens. It could use some coding so, phone numbers with or without hyphens would work otherwise we could show an example. This should keep bots from registering on my site for the time being as long as they keep trying to use those phone numbers. I'm thinking I can drop those hyphens but, still would like to make it so, if the numbers match 9999999 or 0000000 numbers to not let them in.
     

    Attached Files:

    Last edited: Jul 24, 2017
  3. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    I meant to share this with you in the last post but, it's probably best to keep it separate. This picture is from post #1. This is what to look for in your visitor log. What I am pointing at is the user_login.php recording coming from the register.php log. It should be a hint that the bot has successfully registered once it's showing the login.php recording. If it's just register.php by itself then they failed their attempt in joining the Webid site. If there is no confirm.php showing then most likely they did not activate their account via email. It should of been register.php, confirmation.php and then login.php. The other hint that it's a bot, is that it repeated quick attempts on trying to join and how fast they are trying to login after registering. If a person fails to attempt to register, it will take a minute to type in the info that they need to type in to fix the their registration problem. I do think some site allow immediate logins but, not Webid sites.
     
    Last edited: Jul 24, 2017
  4. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    Well, now I got good news! Now I know what it feels like to be vulnerable like you guys! I got to find out that both the image captcha and the Google reCaptcha are not bot proof. I got to see multiple attempts on my Webid site with bots trying to register over hundreds of times. I got to see the odd 9999999 phone number the bots add when they do make it past the captcha and I provided a fix for at least the United States people but, you all should be able to see how that works with the hyphens to make your own telephone code for your Country. I hope you all made that phone number a requirement. I don't know that it's set as a requirement by default. That phone number part in the form is a good way to stop some bots. We'll have to work on the code to improve it and make it not to accept numbers like 9999999 or 00000000.

    My mistake that happened and I had personal stuff to take care this past week, was I left my .htaccess file opened all week. I had tried to block out the Jorgee user-agent that started the mess on my Webid site. I had the block for the Jorgee user-agent there forever and it should of blocked and it was a while back but, for some reason it recently made me add the whole string of the user-agent signature and it stopped it when I added it to the public .htaccess file. As soon as I blocked the Jorgee user-agent two other user-agents signatures came into play with my Webid site and tried to register and they were newer browsers not on the block list. I've been working on my .htaccess file wondering what did I do wrong. I checked all of the code for a break in the code and it all looked good. I've left my browser open all of these days and I put my laptop to sleep and just woke it up and started to work on the same pages. My whole cpanel is different now and I hate it. They gave me a different theme and are not giving me any other choice but, to use it. It wasn't until today that I realized I had the wrong .htaccess file open. I the public .htaccess file open. I had to be using the .htaccess that goes with my Webid site. NOW ALL OF MY BLOCKS WORK! Oh well, it's embarrassing but, I got see how vulnerable most of our fellow Webid Users will be .

    If you take my advice then it will help make your Webid Site safer. If you don't then Good Luck! The best defense is with blocks in your .htaccess file to your Webid site. The reCaptcha is okay but, if it gets nailed a bunch of times, the bot is eventually going to get in and register. The image captcha is complete garbage and should be taken off the Webid Script or modified so, it's harder for an OCR program to read it. You don't want bots to even see your site. There are ways to keep them off and keep real users still happy to be able to see your Great Webid site! The bots have to keep up with every time a browser gets update to make the user-agent signature. That's almost all of the time that the browsers get updated. I will be happy to share my blocks to .htaccess file for the user-agent blocks. Please PM me for them. I won't post them in Public. I will show you a piece of it but, I do plan on removing these codes in the near future when the bots most likely will adjust. You can actually use this code and add your own blocks. Just make sure the last line with [NC] or it will cause problems.

    Code:
    # BLOCK USER AGENTS
    RewriteEngine on
    RewriteCond %{HTTP_USER_AGENT} Firefox/53\.0 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Chrome/59\.0\.3071\.86 [NC]
    RewriteRule !^robots\.txt$ - [F]
    
    I'm using these two blocks because that is the bot network that is pegging my Webid site. I had to be specific with what version it was on the Chrome one because I am using an old Windows Vista PC and the last update from Chrome is not that specific version. Chrome won't allow any more updates on the Windows Vista or XP. I know if I try to close a lot of pages using the Chrome browser, I will see a blue screen. They probably gave up trying to fix that. I have to close my pages only a few at a time. The newest chrome browsers for newer PCs is about 69. This is why I am hoping that browser block is only up temporarily.

    I will sleep well with my knowing my blocks are working keeping pesky bots out. I know these work. see the 403 page. That's a block and the green was one that saw the page before the block to that user-agent signature. Here's was my visitor log looks like:

    Bots trying to join.jpg
     
  5. pani100

    pani100 Well-Known Member

    Joined:
    May 9, 2011
    Messages:
    2,327
    Likes Received:
    449
    david62311 , I find you still fighting the bots after so long. You never give up. I deleted over 20.000 emails the other day when I logged into my old site email account. All from the botbuster registration system. All blocked registration attempts. And from what I can see about 109 have managed to pass the registration and never validated their email along with about 300 that have. All in a year and a half. They never stop.
     
  6. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    Hi @pani100 ,

    Golly, 20,000 emails or more. I'm surprised your account didn't get shut down. I think it would of been more if you didn't have the botbuster registration system up. 109 did not validate their email, I am guessing they might not of given a real email account or the email message got sent to their spam as I have witnessed my my hotmail address was putting all of my Webid site emails in the spam folder. There is some kind of email system in the Webid script now @pani100 that I believe whatever you register with is the email that the user has to confirm through. I think I signed up once and it forward from my Website email to my Yahoo email address and it would not let me confirm through that yahoo email. I will have to test and see if what I am telling you is the way that I mentioned. 300 that did join, and you think they are bots. Did your site or server get infected after that? I'm not sure if you mentioned once that it did get infected. They never do stop but, you can keep them from even seeing your site. You would amazed how peaceful it becomes if you can keep the bad bots off your site and good bots on your site and keeping the site operational just by using .htaccess blocks.

    Believe it or not my site laid dormant for a long time with very few attacks. For about two years or when chrome/39 came out and moved up to newer versions, the bot user-agent signature stopped updating at chrome/39. It seemed like whoever made the bot program went to jail or died hopefully or something. They didn't update the signature for the longest time. They used to do that almost weekly. It's just a coincidence with your timing of you coming back that this new issue with me arose. I had just found Jorgee user-agent skimming my site looking for possible database links and it was every so many minutes that it would do it's scan. I would of thought it would of scanned it for a few days or a week or two and then moved on but, it was scanning every so often. When I looked at the raw access logs, I was truly surprised that those scans had gone on more than a month. My block in the .htaccess file should of stopped that Jorgee user-agent as it had in the past. My ZB Block should of caught it and didn't. There was nothing in common with the IP ranges so, it wasn't like I could just block a range of IPs. Once I updated my block in my .htaccess file and finally blocked the Jorgee user-agent, things changed and the bot network(s) made an adjustment to my block and went from what used to be chrome/39 to what I reported here changing it to Chrome/59 and firefox/53. That caught me off guard. I've never seen them go over chrome/39 until about a week or two ago. A while back, I used to see them change user-agent signatures every other week and they would go after my register.php page which at the time I had changed my register.php to join.php and the register.php page that I had there was a trap page that banned them and it emailed me that they were banned showing me their user-agent so, within minutes to an hour, I had a new user-agent block on my .htaccess file. Changing my register.php page to join.php kept the bots away for a long time but, they eventually latched onto it. If it comes down to it, I may change the register.php page to something else and set the trap page again and go into Yahoo, Bing, and Google and remove my register.php from their search engine and put a not in the robots.txt file for bots to stay out of the register.php page as I did in the past. You got to wonder if something like the captcha attracts the bots. I don't think it's the powered by Webid because otherwise the bots would be going to the home page and skip the home page completely but the device running the bot network could be using register.php and powered by Webid in the same search for all I know. They do go direct for that register page.

    I had honestly neglected my Webid site for a while but, the Jorgee user-agent had got my attention when I saw my visitor log had over 1000 hits. I was not pleased with the lantern theme they stuck me with in my cpanel either but, they said that's the only theme that will allow me to see the latest visitor log. My older theme I was using lost the link to the visitor or something. It stopped showing me the log. Now the lantern theme is terrible and the visitor log doesn't let me adjust the columns left or right and I can't see the whole visitor log from left to right without moving the page over. The url column adjust to whatever size our links are and I can't moved the right column over the size of the link. What I am getting at is, it's harder for me to read the visitor log when I have long links in the log and I can't shrink the column sizes. It caused me to lose interest and stop watching it. I'm going to be checking out that visitor log now and will be monitoring it for a couple of weeks and hopefully then I can finally relax.

    This was the first time I ever had bots register, activate, and log in on my Webid site and bombard the register page like that. The first two that successfully registered, activated and logged in recently had gone straight for my sell.php page which I will say mums the word there.

    @pani100 so, this all just came up recently. I'm actually glad I got to witness it to help me make a stronger defense. The bots are so stupid that they won't get by the telephone thing is we make them enter a telephone number a certain way.

    If you look at your visitor log or raw access log look at the user-agents and see if you can see a user-agent that is pegging your site at the time. Then use a code like this below but, change the code to the browser(s) it's showing in your log that's hitting your site. You should see relief.

    Code:
    # BLOCK USER AGENTS
    RewriteEngine on
    RewriteCond %{HTTP_USER_AGENT} Firefox/53 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Chrome/59\.0\.3071\.86 [NC]
    RewriteRule !^robots\.txt$ - [F]
    This is what my log looks like now...hold on a second...LMFAO ROTF. This is a new breed of bots hitting my site. They've already adjusted to my block within hours after. I'm telling you, these are not the same stupid ass bots that have been around for many years. There's a new bot program going around. Somebody's programmed the bots to adjust to user-agent blocks. It's a whole new breed. Here's the new user-agent I see in my visitor log:

    Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/58.0.3029.110 Chrome/58.0.3029.110 Safari/537.36

    I just added this block now:
    RewriteCond %{HTTP_USER_AGENT} Chrome/58\.0\.3029\.110 [NC,OR]

    I use this and have been using this to make my blocks for me for the past 4 years. It works great.

    LINK REMOVED BY MODERATOR PER THE OP's REQUEST

    This is fun! Let's play you bot device users! :p

    I've never seen that one Ubuntu one or chromium one before. I was just going to show you what it looked like to have a peaceful site and went to go take a picture of it and found that. It seems that they won't change their user-agent unless I block them. What I like about this is I'm sure chrome/60 will be out shortly and then I can just block out
    RewriteCond %{HTTP_USER_AGENT} Chrome/5 [NC]
    and it will block out all of the chrome/5 and 50s versions and they can toy around with what 50s version will work for them before for a while before someone figures it out what I did there. All the people with newer browser will automatically get the update to the newer browser version. I'm stuck on a lower one than 50 because my PCs are old and anybody else with older PCs like mine will be stuck here too and not go into the 50s.

    Here's what the new visitor logs look like after they adjusted and changed their user-agent. Ironically the first one went to my index.php page which I just mentioned they never go to the index.php page but, look they should of hit all of my thumbnails on that page but, didn't. How strange that there are no footprints there huh? I think I will block that IP range from the first one since it's the first one to hit the site with a different user-agent.

    capture-20170724-204140.png

    This below is what it should look like when the user-agent is blocked out and no more than one or two of those with and showing a 403 status:
    /

    This is all new to me that they made the adjustment that quickly. They're beyond aggressive now and more aggressive than they were before but, I will knock their asses down to the ground very soon and they will keep trying and not figure what I did to them! This is all a game to me! They're still not going to get by my telephone code adjustment that I created today even if they change their user-agent when I go to sleep.

    I'm going to look into things and see if I can figure what's going to stop the bots on my site and share them with my fellow Webid users. This is a whole new bot network we are dealing with. That Google reCaptcha should of stopped them on my site and in this forum. Something is missing from it. If the reCaptcha senses there's too much activity then it usually makes the user click on pictures. I don't know if it's the same reCaptcha that we are using but, I remember version 2 came out about a year after the first one came out.
     
    Last edited by a moderator: Jul 26, 2017
  7. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    I see now that the latest Chrome is Chrome/60. I may just throw in the block code for Chrome/5 to block the 50s versions and will take down Chrome/5 too with an .htaccess block code like this below:

    RewriteCond %{HTTP_USER_AGENT} Chrome/5 [NC, OR]

    I will wait to see what the next bot user-agent will be if it changes to a different user-agent before deciding to block the ones in the 50s.
     
  8. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    I'm at peace. This is what my blocks do. All these thing see is a 403 page.

    At peace once again.jpg
    All of the / most likely would of been multiple register attempts.

    The one IP that starts 162 tried to skim my site but, got the 403 pages instead.

    I got several .htaccess blocks. The blank user-agent block is a good one. The one IP in this photo is showing a blank user-agent.

    I blocked out zgrab too. If you would like a copy of my .htaccess user-agent blocks just pm me. I don't want to post it here.

    You can bet that I sleep better knowing my blocks are keeping the bots off my site. It would be a good bet.

    The bots haven't changed their user-agent signature since last night. They were at first changing them every time I changed them. I should be good for a while. Hopefully they continue to use the same user-agents that I have made blocks for. I will keep you posted if something changes.
     
  9. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    I checked my logs today and this newer user-agent signature that I am posting below hit my site and was pegging at the register.php page.

    Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/59.0.3071.109 Chrome/59.0.3071.109 Safari/537.36

    I had different IPs hit my site and each IP had a different amount of tries at registering. 3 different IPs attempted to register 11 times each. I believe the bots give up after 11 attempts if they get that far. My ZB Block blocked 33 blocks and banned a few IPs today with a description why it banned them. None of the bots managed to register on my Webid site because I tweaked out my form differently for the mandatory information that they need to add. They probably won't figure it out and I feel confident that at this point that they would never figure out how to register even if I removed my reCaptcha completely. If I didn't have the form set up the way I do now, they may have managed to have registered. I am not sure if they would of confirms their account though. Usually if you see multiple attempts and then the same IP hits the login.php page that they managed to register so, check out the admin users and see if any new users managed to register. It will probably say account never confirmed next to the user that registered.

    Listed below are the browsers I already blocked in my .htaccess file and you can use this code and add your own. The code does work. If you decide to use it and make your own blocks, just make sure for each line you add that there is a [NC,OR] there and for the final line you just have [NC] or the code won't work right..

    Code:
    # BLOCK USER AGENTS
    RewriteEngine on
    RewriteCond %{HTTP_USER_AGENT} Firefox/53 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Chrome/58\.0\.3029\.110 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Chrome/59\.0\.3071\.86 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Chrome/59\.0\.3071\.104 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Chrome/59\.0\.3071\.115 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Chromium/59 [NC]
    RewriteRule !^robots\.txt$ - [F]
    I am running an experiment now and will just block out the Chromium/59 user-agent because it seems like in the last few weeks the bots have been using the user-agent signature but, changing the final part of the version number. Chrome I believe is way more popular than Chromium. When they change out the final version number of the Chromium and they remain at Chromium/59 the block will continue to block any Chromium/59 version out. I could just simply block out all Chromium user-agents and keep an eye on it to see if any real users get blocked out. The way you check if they are real users is to trace their IP and see what their ISP is or where they are located.

    I'm not sure why they would use a Ubuntu Chromium user-agent signature but, maybe their OS is Ubuntu or that's what they want us to think. I can tell you from what I see that the Chromium/59.0.3071.109 is the latest version released on 7-7-17. I can't download it but, it's not mentioning what OS it's for.
     
  10. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    I just noticed in the past few days that some Websites are finally showing a message at the top recommending to update the browser. They've detected that I am using an older browser with my Google Chrome because Chrome doesn't give updates to Windows Vista users.

    I've been saying it for years now to block older browsers because they are unsafe. The browsers these days update themselves and usually without letting the user know they're being updated. I know what version of Chrome won't update on Windows XP and Vista machines but, I have made an exception to allow them to be on my site. If you see old Chrome versions in the 30s or older then they most likely have been infected and compromised. The bots I've seen on my site now are being tricky and are showing their user-agent as being close to the latest chrome browsers at chrome/59.

    The page connected to the link that I clicked on had this on it:

    capture-20170809-144441.png
     
  11. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    This cracks me up. The user-agents that I had to block this week started using:
    Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10)
    So, I added a block for it.
    Code:
    RewriteCond %{HTTP_USER_AGENT} OS\ X\ 10\.10 [NC,OR]
    That blocked them for a day but, I could still see their user-agent attempting to hit my site. Then another bot with a different user-agent came the next day to 10_11 and it was between the 10.10 and 10_11 bots that were rotating. Usuaully when a bot network hits a site there's usually a 2nd one tagging along. They network don't rotate out their user-agent for most of the day. You got to realize the device that is attacking your site with it's bots, is not only attacking your site. They're usually multiple sites. If a bot network starts attacking your site, there's not much you can do except for block them out. They won't go away and will always be lurking even after being blocked out. The only way they will stop pegging at your site is if someone pulls the plug on the device that's controlling their bots.

    I had previously blocked all of these before in my .htaccess panel.

    Code:
    RewriteCond %{HTTP_USER_AGENT} OS\ 8_0_2 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} OS\ 8_1_2 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} OS\ X\ 10_7_5 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} OS\ X\ 10_8_4 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} OS\ X\ 10_8_5 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} OS\ X\ 10_10_1 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} OS\ X\ 10_10_5 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} OS\ X\ 10\.10 [NC,OR]
    I like to keep track of what's hitting my site. Now today the bot are rotating between user-agents.

    Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7
    Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/602.4.8 (KHTML, like Gecko) Version/10.0.3 Safari/602.4.8

    What do all of the OS X strings I blocked I blocked have in common? The new code I put up removes 5 of those lines on the 10 and just keeps one. They can use all of the OS X 10 signatures that they want. They are blocked. Thanks for making it easier for me.

    Code:
    RewriteCond %{HTTP_USER_AGENT} OS\ X\ 10 [NC,OR]
    I personally hate the fact that people think their MACs are safe. MACs are just as vulnerable as any other PC. If it comes down to it then I will just block the:
    Code:
    RewriteCond %{HTTP_USER_AGENT} OS\ X[NC,OR]
    The bots also used to try to hit my register page 12 times before rotating their IP out. Now that they realized I have my ZB Block banning them if they try 8 times that they will get blocked so, they are trying to register now 3 times before trying a different IP. They won't get by registration form even if I took the reCaptcha down. I have another block up beside ZB Block and they won't figure it out. I'm not too worried about them when they change their user-agent signature because that block will keep them out. Their user-agent will be blocked within a few hours once they rotate it out to a newer one when I find it. They won't rotate their user-agent out right away because they are hitting more than just my site. They usually wait until the next day to change out their user-agent.
     
  12. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    So, today the spam bots trying to register are using this user-agent.
    Code:
    Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
    
    The latest Firefox is Firefox/55. This is kind of a problem. The latest Firefox Version is Firefox/55.0.3. The bots that I am seeing on my Webid site are trying to update their user-agent and keep up with the latest browser versions. I can keep blocking each time it updates to a newer user-agent signature. The block last usually lasts a few days up to a week or so. Anybody with a newer PC should be getting the latest Firefox version. My version is 52 because I'm on a rigged Windows XP system that still gets security updates because I tricked the registery out to make it think my PC was using a different operating system that still will get updates until 2019. That's a different story though. So what I am getting at is most people using a newer operating system should get an automatic update when they go to use their Firefox Browser and it should update to Firefox/55.0.3 . Everybody else using an older operating system will probably be stuck at Firefox/52. Any visitors to a site between Firefox/52 and Firefox/55 at this time should be a spam bot. I'm not to worried because the phone number on register form is mandatory and if they don't register with a U.S. phone number then they will never get on. All it mentions is that it needs to be a valid phone number...I think. It's not specific of what the phone number should look like.

    My block is now added to my .htaccess file with the rest of them. This will keep them out for a day or so.
    Code:
    RewriteCond %{HTTP_USER_AGENT} Firefox/54 [NC,OR]
    Here's a thought. I don't know why we would need a good search bot to even look at the register.php page. The bots seem to go right for the register.php page. If go into our robots.txt and we disallow good search bots to index the register.php page then it will make the spam bots have to work to find it. They spam bots would have to use a skimmer to find it. Thinking back, I think that one time I renamed my register.php to join.php that I did add the disallow for the join.php in the robots.txt but, the spam bots eventually but, still were pegging my register.php page when all that was there was a trap page that banned them. Anyways, I've put a disallow in my robots.txt for the register.php page now and I am going to remove the register.php page from the search engines in a minute. I will keep you all posted later if this helps me or not. We still don't know what exactly attracts the spam bots to our Webid sites. I don't think it's the Powered By Webid as some of us suspected. It should of come up in the search referral if it was. As I mentioned, we don't know what attracts them initially. We only know that once they are attached to the site that they don't go away. We just got to keep them out.

    I've gone into my Bing and Google Webmaster tools and removed blocked Bing from my Register Page. Well, what I am seeing is very ironic. The Google Webmaster Analytic shows the register.php page has Zero clicks to it but, I am getting several visits from spam bots per day. That means the spam bot program is program to go directly to the register.php page. Why bother even add a register.php page link to the site if all they are going to do is surf to it and not click the link to it? LOL. I checked the links to my site on the Google Webmaster site and it shows 2 but, the only one it displays is the link I share on Facebook but, I never get clicks from that Facebook link. It would of shown up in the link referrals. Okay, so now, I've gone to the Google Index tab>Remove URLs and removed my register.php page but, it says it will temporarily hide the page from search results. I've done all I can do now to hide that register.php page from search results and I've put up a .htaccess block to block out the spam bots until they update their user-agent signature. I will let you know if it helps any. If it does then that would be good.
     
  13. MarcK

    MarcK New Member

    Joined:
    Aug 16, 2015
    Messages:
    6
    Likes Received:
    0
    I think is better choose, to add a active main layer with opacity 50% with <a href=''>Do you realy want to register</a>
     
  14. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    I'm not sure what you are talking about here. Please clarify. Are you talking about making the characters less visible?

    Not related to your post but, I am still surprised that the Google ReCaptcha hasn't been improved. Maybe they don't know there ReCaptcha is broken. I will contact them when I get a chance.
     
  15. hhavatar

    hhavatar Donor Donor

    Joined:
    Jul 28, 2014
    Messages:
    748
    Likes Received:
    74
    Sounds like they're talking about a honeypot @david62311
     
  16. Gustiawan Ouwawi

    Gustiawan Ouwawi New Member

    Joined:
    Feb 14, 2019
    Messages:
    3
    Likes Received:
    0
    theres a video in youtube a robot just verified in using google captcha
     
  17. david62311

    david62311 Well-Known Member

    Joined:
    Aug 29, 2013
    Messages:
    2,165
    Likes Received:
    251
    99.9% of the captchas are not bot proof. Google's recaptcha give a false sense of security. Many bots got by my Google Recaptcha and registered on my Webid site.

    Dahl had modified the original captcha Webid had and it fooled a lot of bots. It had a grid of lines on it and it would cover some of the characters. The Human Eye could make out what it was but, a bot couldn't. We should try to bring that captcha back. I think I have a backup of it somewhere. I will look. We could use it as a 3rd option for captchas.
     

Share This Page