I’ve been working even harder to make my ModSecurity ruleset as strong as possible without causing too many false positives. With the current git master I’m sure I can reject most of the spam sources before they hit at all… but.
But I’m not sure if I made it a bit too strong. So please, leave a comment on this post, with as many browsers as you usually use, and if it doesn’t work, drop me an email with your browser’s version (and if you can give me an IP address it’ll be easier to find it in the logs).
Thanks!
Testing using w3m on Linux. w3m is my fallback when I don’t have a GUI or GUI browser on the machine I need to browse from. (If, for example, I can’t just paste a URI to wget…)
Testing from Firefox on Win7 Ultimate 64-bit.
Test with links.
Testing using some version of IE on Win7 Ultimate 64-bit.
Firefox 3.6.13 – default/linux/x86/10.0
Chromium 9.0.597.94 (0) – default/linux/x86/10.0
Test FF4 / Win7
Android 2.3.3 browser (nexus s)
Microsoft Internet Explorer 9 … don’t ask! >_<[And this required the rules to be fixed!]
Safari on Windows [Please, don’t ask]
I can’t access your site with Opera on my mobile phone since a couple of weeks now. User Agent is “HTC_Touch_Pro2_T7373 Opera/9.7 (Windows NT 5.1; U; de)”
I think the SecRule in line 38 of “flameeyes_60_fake_browsers.conf”:https://github.com/Flameeye… is responsible for my problem: “^.+opera[ /][0-9]” -> “Fake Opera browser (not starting with Opera)”
Google Chrome 11 for MacI currently use your ruleset on my website (updated to the master, yesterday afternoon).Thanks for your job 🙂
Safari on iPhone running iOS 4.3
Orca Browser (version 1.2 build 6) on Windows XP
Konqueror from kde 4.6.1, with OS name added, OS version, platform name, machine and language info omitted, in konqueror’s ID config.
Firefox 3.6.9 SystemRescueCd (Gentoo Linux)
ELinks 0.11.7 – SystemRescueCd (Gentoo Linux)
Trying out with Midori, (Gentoo)Linux
Testing with Chrome 10.0.648.151 on Windows 7
Test with Chrome 10.0.648.127 on Gentoo Linux 64bit
nokia 5800 browser
Opera mini 6
Gentoo / Chromium 12.0.711.0 (78924)
Test with Firefox 3.6.15 on FreeBSD 8.2
Unfortunately Epiphany (gnome webbrowser, v2.30.6) gives access forbidden when trying to access your blog.I guess you can see the email from this post using Opera on FreeBSD
rekonq 0.6.85 on gentoo
Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20110322 Firefox/4.0 – default/linux/amd64/10.0/
chromium 10.0.648.151 (0) – default/linux/amd64/10.0/
403 – Access Denied using Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0 (portableapps version)IE 7 on same machine is ok
FF4 on gentoo 😀
Dolphin Browser HD 4.5.0 cyanogenmod 6.1.1-N1Default User AgentMozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83D) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1Desktop user agent emulationMozilla/5.0 (Windows; U; Wind hrome/4.1.249.1045 Safari/532.5iPhone user agent emulationMozilla/5.0 (iPhone; U; CPU iPhone cko) Version/4.0 Mobile/7A341 Safari/528.16iPad user agent emulationMozilla/5.0 (iPad; U; CPU OS 3_2 like Version/4.0.4 Mobile/7B367 Safari/531.21.10Built in browser that comes with Cyanogen.Mozilla/5.0 (Linux; U; Android 2.2.1; en-us Gecko) Version/4.0 Mobile Safari/533.1
Looks odd on Arora on Gentoo…Click name for link.
Thanks to everybody! Keep the comments coming! :)germantoo → thanks, yes that was the problem, it should be all fine now; funky, Opera Mini is very different from one device to the next, so everybody who has an Opera Mini at hand are definitely welcome to come posting here!moesasji → Epiphany is indeed not behaving like other WebKit browsers and sends very few headers: no Accept-Language on requests; I had to explicitly whitelist it.richard77 → Thanks! Looks like Accept-Language in Firefox is optional, so I had to avoid that validation… it upsets me a bit honestly, but I’ll live with that for now.Arora → “Bogus Browser of the Year” award goes to Arora indeed… it’s not even a matter of Accept-Language like for Epiphany or Firefox, which are optional on protocol level… Arora doesn’t send the *Accept* header, which is required by the protocol. But it does so only when requesting images, it does send the *Accept* header when requesting the pages, stylesheets and, I guess, scripts. I’m not sure if I want to whitelist such a stupid behaviour.
one would use a “honey-pot” to test this,firefox 3.6.13 Gentoo
A honeypot wouldn’t give me any information about false positives, which is what I’m interested in right now 🙂
DolphinHD from archos tablet and lg optimus one OK
*moesasji → Epiphany is indeed not behaving like other WebKit browsers and sends very few headers: no Accept-Language on requests; I had to explicitly whitelist it.*Retrying with Epiphany still fails with an “access forbidden” message?
Opera 11.01.1190 Gentoo 32bit default/linux/x86/10.0
IE 7.0.5370.13WinXP SP3 (workplace pc) Flattr buttons do not appear. 32bit will test some more boxes at home later
Firefox 4.0 AMD64 linux
Epiphany Web Browser 2.30.6
Firefox 4, AMD64, Kubuntu 10.10.
Konqueror, AMD64, Kubuntu 10.10. (Not very often, though.)
Symbian BrowserNG v7.2.8.10, from a Nokia N8
Firefox 4 β12, Windows 7 32-bit, Silverlight plugin installed. (I need to upgrade this one…)
With ‘lynx’ from terminal window
N900 running MicroB 3.5
Opera 11.1 on Windows 7…
Latest Chromium on Gentoo..
Plain firefox here
gentoo, firefox-bin-9.0.1
Default Android browser
ff beta, Android
opera Android
Links 🙂
Opera Gentoo
Gentoo, Chrome
ii chromium-browser 15.0.874.106~r107270-0ubuntu0.11.10.1 Chromium browser
Gentoo, Firefox
Gentoo, Chromium
win vista cz, chrome
Firefox 9.0 gentoo linux amd64
Android 2.3 (evo 4g)
Prova
FF 18.0.1 on Gentoo amd64
Firefox ~arch on Gentoo amd64
www-client/lynx-2.8.8_pre12 on Gentoo amd64
Firefox 18.0.2. Ubuntu 12.10 64 bit
rekonq 1.1. Ubuntu 12.10 64 bit
I was forced to test :-(FF 18.0 on openSUSEPreview does not seem to work
Firefox 18.0.2 for android
Now without a website
Firefox on CM10.1 (Kibd
Chrome on CM10.1 (Kindle Fire)
Android Browser on CM10.1 (Kindle Fire)
Opera on OSX.
Firefox 17.0.1 on Gentoo amd64.
Some more testing with a new set of rules.
Working here Opera/9.80 (X11; Linux x86_64; Sabayon) Presto/2.12.388 Version/12.14
Works her Firefox 18.0.1 on Sabayon
Opera on OSX with Opera Turbo enabled.
Works here chromium Versjon 24.0.1312.56 (177594) on Sabayon
Safari on OSX Mountain Lion
Chrome on OSX
Firefox 15 on OSX
Chrome on Windows 7
IE 9 on Windows 7
IE9 (64-bit) on Windows 7
Arch Linux i686, Firefox 18.0.2
IE9 (InPrivate) on Windows 7
Firefox 18 on OSX
Firefox 18 on Fedora 18
Iceweasel 20.0a2 (2013-02-08) on Debian 7.0
Chrome on iPad
Safari on iPad
Firefox on CM7.2
Puffin on Android.
Opera Mobile on CM10.1
since i don’t see it: Seamonkey 2.15.1 on Gentoo amd64
Glad to help. 18.0.1 on gentoo unstable.
Glad to help. 18.0.1 on gentoo unstable. Retry with NoScript enabled but whitelisted flameeyes.eu.
Fedora18 with firefox, seems to work great.
K-Meleon 1.5.4 on Windows Vista
Safari 5.1.7 on Windows Vista
Internet-Explorer 9.0.13 on Windows Vista
Opera 11.61 on Windows Vista
Firefox with NoScript enabled.
Testing a ModSec isssue.
testing hp touchpad with webOS 3.0.5
and with webOS 2.2.4 on a hp pre 3
Testing
And with noscript now.
With firefox on OSX.
Opera (with Turbo) now.
Test comment from Opera/Linux.
Firefox/Something on Gentoo.
Opera on Windows.
Firefox without AJAX
Opera without ajax
IE with ajax
IE without Ajax.
IE without Ajax.
test from PS4 broweser 😀
Testing from my office.
Test
Ttest
Test
Yes.
Test from Windows 10 TP and IE11 with Spartan engine enabled