When entering the advanced blocking patterns, did you complete any of the other fields, aside from the user agent and the reason?
I tried entering the first pattern and visiting from a browser tweaked to report itself as “Chrome version 0.0 running on Win7”, and it was successfully blocked.
Live Traffic will still show the attempts to visit pages, even though the visitor does not see the actual content of the site, but you should see the counter increasing on the Advanced Blocking page when the blocking happens.
-Matt R
@wfmattr
As mentioned I tried a couple of patterns for “browser match” field.
In all cases I left the other fields generic. I only complete the Browser Pattern and Reason.
Eg.
IP Range: Allow all IP addresses
Hostname: <empty nothing set>
Browser Pattern: Block visitors whos browsers match the pattern: Chrome version 0.0 *
Source website: Allow visitors arriving from all websites
Reason: Invalid browser
I have never seen counter change, despite various attempts at defining a pattern that *should work*. (My logic says should work).
Objective to block all 0.0 browser versions regardless of manufacturer and OS
Matt,
It may be an issue with the block counter not working ???
From what you said, the live traffic log will still show their visit ?? Is this only for first visit or will all activity (although blocked as you say it is) show in log?
Although the counter shows no blocks I can see a hacker randomising the browser type and OS, effectively showing one entry in live traffic for each “browser 0.0” type they attempted to use.
I can only hope the pattern match is working as the block counter isn’t changing one bit 😉
Yeah, using the first pattern that you mentioned definitely worked for me, if I visited a test site with a browser with a fake user-agent. It’s possible that another plugin is causing a conflict somewhere, either preventing the blocking, or the count.
It might also be that one of your database tables is damaged, so the count isn’t changing — if you know how to use phpmyadmin, you can try repairing tables that start with “wp_wf…” (changing the “wp_” prefix if needed>)
If you have a second IP you can try connecting from (so your current IP doesn’t get blocked), you can try setting the user agent on your browser to match that string. Safari has an option on the menu, “Develop->User Agent->Other”, where you can enter any user agent, and for Chrome and Firefox there are add-ons/extensions you can get that will let you change it. (That would let you test whether it works if other plugins are disabled temporarily.)
-Matt R
Hey Matt.
Thanks for info. I ran a check on all tables in my database and all said ‘ok’.
Lots of juicy stuff to read at table level.
The block count is working for other blocking fields just not browser… so I will create another browser one using a pattern of a more general nature and see what happens.
I will try the plugin angle. I don’t have heaps so should be straightforward.
Will let you know if I find source so you can advise others.
Still having no success with blocking BROWSER AGENTS Version 0.0
I tried again with setting string for Browser agent to “Chrome version 0.0 running on Win7”. This was the exact text shown in Live View so I am trusting this is complete and correct???
Can’t auto block nor is the counter incrementing despite Live view showing numerous bot visits with Browser agent 0.0.
No issue with database tables I can see.
Has anyone had success with this type of match string? ANYONE??
Really need to block this as now repetitive attacks are varying by IP so only chance I have is blocking invalid browser agents.
-
This reply was modified 9 years, 4 months ago by
snaphappyme.
