I am using mod-security V3 on a centos machine with Openlitespeed.
My php file access.php create cookie: honey_bot_trap with value : 16 character [0-9a-zA-z]. - dynamic: ex: au4abbgjk190Bl
in modsecurity create rules:
SecRule REQUEST_HEADERS:Cookie "#contains honey_bot_trap" "chain,id:'990014',phase:1,t=none,block,msg:'fake cookie'"
i want create rules :
All request to my domain will redirect to access.php (the cookie create by file: honey_bot_trap: au4abbgjk190Bl)
Modsecurity check if no cookie honey_bot_trap: au4abbgjk190Bl is block.
if request has honey_bot_trap: au4abbgjk190Bl add to check rate.
if rate of IP over 2 click /s is block (or redirect to https://m ydomain.com/verify.php)
Please help me. Thank for all.
OpenLiteSpeed is not a creator of rules, but a consumer of them. We generally recommend the use of pre-created rules like OWASP or Comodo. If you wish to create rules you should check out the rules guide: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v3.x)https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v3.x)
The rule you are attempting to create is very, very complicated. It may sound simple, but I've written the 2nd edition of the ModSecurity Handbook and trust me, I would take me 2-3 hours to get this working.
With that being said, ModSec is probably not the best tool for what you have in mind. If you want to push through, try to put your hands on a copy of the ModSecurity Handbook (instead of the reference linked above) and use mod_qos or something along those lines for rate limiting and not ModSec.
#CRSDevOnDuty
P.S. Hat tip to Robert Perper.
Related
I have installed modsecurity on Nginx and as well as the owasp rules,
i have check SecRequestBodyAccess to on,
but when i send a request with a malicious post data, it pass ok with no problem
Can anyone help me?
Modsecurity by default has parameter "SecRuleEngine" set to "DetectionOnly" and work in monitor mode. Must be set to "On".
Modsecurity must have enabled a rule that discovers malicious code - audit_log will tell you if the malicious post data was found. Most of CRS rules find malicious using regex expressions. More fancy attacks require special configuration or new rules, some of them would never be discovered.
Blocking or not later depends on the settings if your're using Anomaly Scoring mode or Self-Contained mode.
For Self-Contained (older way) it is enough to have configuration line like (for POST data = phase 2):
SecDefaultAction "phase:2,log,auditlog,deny,status=403
And that's all, if post data violates any rule - attacker gets 403.
For AnomalyScore mode (newer way, more flexible) line looks like:
SecDefaultAction "phase:2,log,auditlog,pass"
Then all rules for which anomalies were found are countend and their scores are summed up. Depends on the rule it can be "critical_anomaly_score", "error_anomaly_score", "warning_anomaly_score" and "notice_anomaly_score". By default their counts as 5,4,3,2.
If the counted score equals or is greater than "inbound_anomaly_score_threshold" (default 5) then request is blocked.
Thats why by default a one rule with critical_anomaly_score (counted as 5) can block traffic. A single rule with "error_anomaly_score" (counted as 4) is not enough to stop the request.
Im currently working on a more or less RESTful webservice, a type of content api for my companys articles. We currently have a resource for getting all the content of a specific article
http://api.com/content/articles/{id}
will return a full set of article data of the given article id.
Currently we control alot of the article's business logic becasue we only serve a native-app from the webservice. This means we convert tags, links, images and so on in the body text of the article, into a protocol the native-app can understand. Same with alot of different attributes and data on the article, we will transform and modify its original (web) state into a state that the native-app will understand.
fx. img tags will be converted from a normal <img src="http://source.com"/> into a <img src="inline-image//{imageId}"/> tag, samt goes for anchor tags etc.
Now i have to implement a resource that can return the articles data in a new representation
I'm puzzled over how best to do this.
I could just implement a completely new resource, on a different url like: content/articles/web/{id} and move the old one to content/article/app/{id}
I could also specify in my documentation of the resource, that a client should always specify a specific request header maybe the Accept header for the webservice to determine which representation of the article to return.
I could also just use the original url, and use a url parameter like .../{id}/?version=app or .../{id}/?version=web
What would you guys reckon would be the best option? My personal preference lean towards option 1, simply because i think its easier to understand for clients of the webservice.
Regards, Martin.
EDIT:
I have chosen to go with option 1. Thanks for helping out and giving pros and cons. :)
I would choose #1. If you need to preserve the existing URLS you could add a new one content/articles/{id}/native or content/native-articles/{id}/. Both are REST enough.
Working with paths make content more easily cacheable than both header or param options. Using Content-Type overcomplicates the service especially when both are returning JSON.
Use the HTTP concept of Content Negotiation. Use the Accept header with vendor types.
Get the articles in the native representation:
GET /api.com/content/articles/1234
Accept: application/vnd.com.exmaple.article.native+json
Get the articles in the original representation:
GET /api.com/content/articles/1234
Accept: application/vnd.com.exmaple.article.orig+json
Option 1 and Option 3
Both are perfectly good solutions. I like the way Option 1 looks better, but that is just aesthetics. It doesn't really matter. If you choose one of these options, you should have requests to the old URL redirect to the new location using a 301.
Option 2
This could work as well, but only if the two responses have a different Content-Type. From the description, I couldn't really tell if this was the case. I would not define a custom Content-Type in this case just so you could use Content Negotiation. If the media type is not different, I would not use this option.
Perhaps option 2 - with the header being a Content-Type?
That seems to be the way resources are served in differing formats; e.g. XML, JSON, some custom format
If I define url like "^optional/slash/?&" - and so web-page to which it bound will available by both url versions - with slash and without - will I violate any conventions or standards by doing that?
Wouldn't a redirection be more appropriate?
If I remember correctly, trailing slashes should be used with resources that list other resources. Like a directory that lists files, a list of articles or a category query (e.g http://www.example.com/category/cakes/). Without trailing slashes the URI should point to a single resource. Like a file, an article or a complex query with parameters (e.g http://www.example.com/search?ingredients=strawberry&taste=good)
Just use the HTTP code 302 FOUND to redirect typos to their correct URIs.
EDIT: Thanks to AndreD for pointing it out, a HTTP code 301 MOVED PERMANENTLY is more appropriate for permanently aliasing typos. Search engines and other clients should stop querying for the misspelled URL after getting a 301 code once, and Google recommends using it for changing the URL of a page in their index.
According to RFC 3986: Uniform Resource Identifier (URI): Generic Syntax:
Section 6.2.4. Protocol-Based Normalization -
"Substantial effort to reduce the incidence of false negatives is
often cost-effective for web spiders. Therefore, they implement even
more aggressive techniques in URI comparison. For example, if they
observe that a URI such as
http://example.com/data
redirects to a URI differing only in the trailing slash
http://example.com/data/
they will likely regard the two as equivalent in the future. This
kind of technique is only appropriate when equivalence is clearly
indicated by both the result of accessing the resources and the
common conventions of their scheme's dereference algorithm (in this
case, use of redirection by HTTP origin servers to avoid problems
with relative references)."
My interpretation of this statement would be that making the two URIs functionally equivalent (e.g. by means of an .htaccess statement, redirect, or similar) does not violate any standard conventions. According to the RFC, web spiders are prepared to treat them functionally equivalent if they point to the same resource.
No, you are not violating any standards by doing that you can Use this Optional trailing slash in URL of websites
but you need to stay on the safe side, because there are different ways servers handle the issue:
Sometimes, it doesn't matter for SEO: many web servers will just re-direct using 301 status code to the default version;
Some web servers may return a 404 page for the non-trailing-slash address = wasted link juice and efforts;
Some web servers may return 302 redirect to the correct version = wasted link juice and efforts;
Some web servers may return 200 response for both the versions = wasted link juice and efforts as well as potential duplicate content problems.
I just played with ember routing example. It looks quite interesting. Especially if you are going to build all your application on Ember framework.
But parameters in url follows after '#'. That means you can't copy and send a link to someone if client has to login with postback (if only to set a cookie with login parameters). Is there a better option - maybe use '?' instead of '#'?
You may also have a look at Ember.Router.
There are two good start points # https://gist.github.com/2679013 and https://gist.github.com/2728699
A lot of fixes have been made the last couple of days.
EDIT
A brand new guide is now available # https://emberjs-staging-new.herokuapp.com/guides/outlets#toc_the-router
Here is a full example courtesy of https://github.com/jbrown
http://jsfiddle.net/justinbrown/C7LrM/10/
I am working on a DotNetNuke application using the iFinity URL Master module. (that may be irrelevant, as a solution may be platform independent)
What I have is a site with addresses based on language.
so
www.thesite.com/en/products/towels/redtowel
is the english version and
www.thesite.com/de/products/towels/redtowel
is the german version.
What I need to do is allow a user (who has already visited the site and set a cookie with their language) to be able to go to www.thesite.com/products/towels/redtowel and get to www.thesite.com/en/products/towels/redtowel if their cookie is set to english, and /de/products/towels/redtowel if it is set to german.
How would I do this?
if it was me and i didnt want to spend a lot of time programming I would look at something like this
http://www.snowcovered.com/snowcovered2/Default.aspx?tabid=242&PackageID=10059
then it could do a redirect based on the cookie - otherwise with iFinity I think you can do that sort of but not exactly. (I may be wrong on that - not a fan of iFinity url rewriter)