neuvector / neuvector

Apache License 2.0
1.07k stars 202 forks source link

Import of OWASP WAF Core Rules #187

Open nycnewman opened 2 years ago

nycnewman commented 2 years ago

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Ability to import complete set of OWASP WAF Rules

Describe the solution you'd like A clear and concise description of what you want to happen.

Utility to allowe taking all or a subset of the OWASP Core WAF Ruleset and convert into Neuvector WAF configurations.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Manually converting rules

Additional context Add any other context or screenshots about the feature request here.

OWASP CoreRuleSet: https://github.com/coreruleset/coreruleset

gfsuse commented 2 years ago

I will investigate https://github.com/coreruleset/coreruleset and see how big effort is needed.

haolipeng commented 2 years ago

The rules used by Neuvector are regular expressions, if I convevt coreruleset,how can i do?

DilanUA commented 2 years ago

Any update on this? This is a very useful feature to have.

udith6415 commented 2 years ago

Having the ability to setup OWASP CoreRuleSet as part of WAF without manually writing regexes would take away the adminstative burden of manually adding regexes to address any application level attacks. Solutions like NGINX WAF [1], AWS WAF [2], Azure WAF [3][4] uses the core rulesets allowing customers to use those rulesets to protect resources.

[1] https://docs.nginx.com/nginx-waf/ [2] https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-baseline.html#aws-managed-rule-groups-baseline-crs [3] https://docs.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-rulegroups-rules?tabs=owasp32 [4] https://docs.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-tuning

gfsuse commented 2 years ago

It is difficult to parse CRS rule set and translate into our internal syntax, still needs more study.

Clearly, if this was all there was to SecRules it wouldn’t be very powerful. In fact, there is a lot more. So much more that it is in fact a full fledged language. The best place to find out about all the possible capabilities is via the ModSecurity Manual. The following is just a glimpse of its capabilities:

There are ~105 variables in 6 different categories, some examples include:

Request Variables - ARGS, REQUEST_HEADERS, REQUEST_COOKIES Response Variables - RESPONSE_HEADERS, RESPONSE_BODY Server Variables - REMOTE_ADDR, AUTH_TYPE Time Variables - TIME, TIME_EPOCH, TIME_HOUR Collection Variables - TX, IP, SESSION, GEO Miscellaneous Variables - HIGHEST_SEVERITY, MATCHED_VAR There are ~36 operators in 4 different categories, some examples include:

String Operators - rx, pm, beginsWith, contains, endsWith, streq, within Numerical Operators - eq, ge, gt, le, lt Validation Operators - validateByteRange, validateUrlEncoding, validateSchema Miscellaneous Operators - rbl, geoLookup, inspectFile, verifyCC There are ~35 transformation functions in 6 different categories, some examples include:

Anti-Evasion Functions - lowercase, normalisePath, removeNulls, replaceComments, compressWhitespace Decoding Functions - base64Decode, hexDecode, jsDecode, urlDecodeUni Encoding Functions - base64Encode, hexEncode Hashing Functions - sha1, md5 There are ~47 actions in 6 different categories, some examples include:

Disruptive Actions - block, drop, deny, proxy Flow Actions - chain, skip, skipAfter Metadata Actions - phase, id, msg, severity, tag Variable Actions - capture, setvar, initcol Logging Actions - log, auditlog, nolog, sanitiseArg Miscellaneous Actions - ctl, multiMatch, exec, pause, append/prepend While there are a lot of options available there are a few basic things to remember.

Every SecRule must have a VARIABLE Every SecRule must have an OPERATOR, if none is listed @rx is implied. Every SecRule must have an ACTION. The only required action is id, however, several actions are implied by SecDefaultAction (default phase:2,log,auditlog,pass) Every SecRule must have an phase ACTION, this tells the rule when to fire. If no phase is included the default is phase:2. Every SecRule must have a disruptive ACTION. This is an action that describes what to do with the transaction if triggered. If no disruptive action is included the default is pass Transformations are optional but should be used to prevent your rule from being bypassed

Slacking0564 commented 1 month ago

Any news on this?