I rearely complain 
but today, I’m going to …
I can not see tickets I submitted … probably because I changed my email long time ago … I already replied with my user id + password as requested by Praveen … and now I lost all my tickets history!
I can not submit anything to my blog or forum … always get 403 Forbidden …
[RS #CUY-98846-883]: 403 Forbidden
[RS #ZKD-74084-437]: can’t see my ticket?
[RS #GVX-15276-939]: test
Ticket ID: IJP-87474-793
please look into this ASAP
I’ve asked Yogesh to look into your issue with Forbidden error.
Also, I’ve fixed your helpdesk issue.
just replied to yogesh’s question. awaiting your resolution.
I am getting the 403 Forbidden errors on many of my sites, I believe across multiple servers. I have a ticket open, I’m just glad it’s not me.
WebFire, it is mostly the updated mod_security rules. We are working hard to create necessary exclusions asap. This is one-time effort and benefits all. Those getting affected are actually carry vulnerable looking execution. You can always see the problem in error log (if enabled in control panel) and if you have coded the site, you must also know the work-around.
This is majorly a preventive measure as most of the customers aren’t being as vigilant on security front and running out-dated/insecure applications.
Some customize them and fear it getting broken with updates, leading to more in-secure environment.
I am sure there is some of that going on. But I use a mixed bag of custom code and commercial apps, some updated to the max. They all get affected, and this isn’t the first time. Even my custom coded sites are simple insert/edit/deletes to a mysql database.
Anyway, let us know the progress. Thanks.
As i see, the issues are mostly taken care of. If not please update your ticket.
i’m still having this problem … this is getting really frustrating …
is it still not resolved?
solved only at the page i sent you in ticket … others still exist (same domain) …
this is totally unacceptable … I can not test all submit button on my websites … really really frustrating … you know what i mean ???
can’t you just undo whatever you’ve done and think of other ways to make the server more secure?
I suggest all clients on linux servers to test your websites, especially submit button to post / edit database or to edit files using web editor such as modifying your wordpress template through theme editor …
I am seeing similar problems with a phpBB support forum that I have. I have already submitted a ticket and researched this issue and suggested that the mod_security configuration might have been changed. In my case the forum is the most up to date version. And no other custom scripts or mods.
The issue that I am curious about is when I first discovered this issue this morning I went in and checked the permissions on the files and directories. Some file permissions were incorrect based on what phpBB says they are supposed to be. Is this part of the mod_security changes as well?
to all other jodo clients,
just in case if anyone interested … my sites are using Wordpress & SMF …
please check whether you can create new post or edit existing post, modify template using theme-editor … post into your SMF forum …
wordpress & smf are very well known and I believe a lot of people using them here …
This has been happening to many of my customers too. They call me upset and I have to contact jodo to fix on a case - by case basis. In the meantime we look bad. And I have no idea how many other customer sites are having this problem as they do not check their sites everyday.. and there is no way I can do so as I did not create the sites to know where to look… or what potentially causes these mod_sec permission problems.
Mod-Sec was enabled.. probably for good reasons I am sure.. BUT a notice and what kinds of problems it could create for us resellers would have been nice so I could have emailed all customers a notice regarding the issue.
I mean, even customers ecommerce sites using oscommerce are affected. I am not too happy about how this went down.. at all. It does not seem like Jodo ?(
QuietCalm
quietcalm,
We are/were/have been seeing automated hack/defacement attempts growing increasingly complex, AND successful of late, this action was required unless we wished for every signle site to have defacements over and over and over on a daily basis nearly(no it would not happen to EVERY site, a bit of exaggeration there, but to a good 50-60% it would)
Hi Stephen
I am quite aware that Jodo does not do things without a good reason.
That is not the complaint here. I agree with you in setting it up as would most resellers. 
It is the way in which it was done and that resellers were not given information about what problems setting up mod-sec would cause so we could inform our customers prior to then contacting us upset because services stopped working etc. Especially forms because ec-commerce sites are affected too.
Even if you needed to just set it up without prior notice for security of websites… an after it was done a mass email to resellers would have gone a long way. :typing:
That is the point.
QuietCalm
I can honestly tell you we did not expect as many issues as came up, the ticket volume about them it quite down now, so if you still have an issue it should be resolved pretty quickly, some sometimes it will take some working with us to get it resolved as well.
I’m afraid I must admit that I’m not submitting tickets. To submit a ticket, I have to give login access to the help desk staff and set of instructions on how to re-create the problem. Sorry, but my clients don’t want your support staff posting fake pages, fake products, or fake posts in their blogs. And I don’t have the time to figure out and document the steps needed to re-create the problem for each and every CMS, cart, etc.
All of my issues seem to stem from form posts that include the string “http” with the “://” included (I can’t post the full string here because the server on which these forums run also block that particular string). I’ve tried using this htaccess directive but it doesn’t always work.
SecFilterSelective “POST_PAYLOAD” “http : //” “allow,nolog” (without the spaces, of course)
If you have a standard fix that doesn’t require me to allow the support desk folks to log onto my client’s sites, then I’ll start submitting tickets.
Tim
In some instances recreating the error is irrelevant since mod_security is also considering the text posted in forms. For example, we can submit a form with no hassles one second and in the next instance we can’t because there’s different wording used in the field.