Mod Security Session. Mumbai Null Meet 11 November 2017.

1. MUMBAI NULL MEET 11TH NOVEMBER 2017

2. Content
Web application firewall.
What is ModSecurity.
Compare ModSecurity and other waf.
Configure with apache server.
ModSecurity rules.
Attack.

3. Web application firewall
A firewall is the first line of defence for our web server.
It protect our web server on the application level or we can say on the application layer of the
osi model.
Example of web application firewall.
1. ModSecurity(open source).
2. Cloudflare(paid).
3. Incapsula (paid).

4. What is ModSecurity
ModSecurity was first developed by Ivan Ristić, who wrote the module with the end goal of
monitor application traffic on the Apache HTTP Server.
ModSecurity is a free and open source web application firewall
ModSecurity has the capabilities to prevent all the application level attack like sql, xss , dos etc.
Spider lab created paid rules set for ModSecurity.
ModSecurity is available for the apache , IIS, Nginx server.

5. The platform itself provides a rule configuration language known as 'SecRules' for
real-time monitoring, logging, and filtering of Hypertext Transfer Protocol
communications based on user-defined rules.

6. Compare ModSecurity and other waf
ModSecurity is open source and free.
Easy to configure with apache and IIS and nginx.
Owasp create a core rules(owasp-modsecurity-crs-3.0-master) set for the ModSecurity.
Very easy to configure.

7. Configure with modules
Download from here https://www.apachehaus.com/cgi-bin/download.plx
Copy mod_security2.so to your Apache 2.4.x modules folder.
 Copy libcurl.dll and yajl.dll to your Apache 2.4.x bin folder.
 Copy the minimal configuration file to your Apache 2.4.x conf/extra folder.
 modsecurity-minimal.conf or we can copy owasp core rules set file into extra folder.

8. Configure with httpd.conf
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule security2_module modules/mod_security2.so
# OWASP ModSecurity Core Rule Set Project
# Include conf/extra/modsecurity.conf-recommended
Include conf/owasp-modsecurity-crs-3.0-master/crs-setup.conf.example
Include conf/owasp-modsecurity-crs-3.0-master/rules/*.conf
# Include conf/owasp-modsecurity-crs-3.0-master/optional_rules/*.conf

9. ModSecurity rules
Every rule defined by SecRule conforms to the same format, as below:
SecRule VARIABLES OPERATOR [ACTIONS]

10. Variable
The VARIABLES specify which places to check in an HTTP transaction. Examples of variables
include ARGS (all arguments including the POST Payload), REQUEST_METHOD (request method
used in the transaction), REQUEST_HEADERS (can be used as either a collection of all of the
request headers or can be used to inspect selected headers) etc.
The full list of variables is available under
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Variables.

11. Operator
The OPERATOR specifies a regular expression, pattern or keyword to be checked in the
variable(s). Operators begin with the @ character.

12. Actions
The ACTIONS specify what to do if the rule matches. Actions are defined into seven categories
Disruptive (used to allow ModSecurity take an action e.g. allow, block etc), Flow (affect the flow
e.g. skip), Meta-data (used to provide more information about rules), Variable (used to set,
change and remove variables), Logging (used to influence the way logging takes place) and
Special (used to provide access to another class of functionality) and Miscellaneous (contain
actions that don’t belong in any of the other groups) actions. If no ACTIONS are provided,
default actions apply as per SecDefaultAction (phase:2,log,auditlog,pass).
The full list of actions is available under
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Actions.

13. Attack
SQL Injection (SQLi)
Cross Site Scripting (XSS)
Local File Inclusion (LFI)
Remote File Inclusion (RFI)
Remote Code Execution (RCE)
PHP Code Injection

14. XSS Rule
The following rule is used to avoid XSS attacks by checking for a <script> pattern in the request
parameters and header and generates and ‘XSS Attack’ message with a 404 status response.
SecRule ARGS|REQUEST_HEADERS “@rx <script>” id:101,msg: ‘XSS
Attack’,severity:ERROR,deny,status:404
VARIABLES
ARGS – Request Parameters
REQUEST_HEADERS – All of the request headers
OPERATOR
“@rx <script>” – Performs a regular expression match of the pattern (in this case <script>)
provided as parameter

15. XSS Rule
ACTIONS
id, msg, severity, deny, status – These are all of the actions to be performed if the pattern is
matched
id:101 – The unique id that is assigned to this rule (or chain) in which it appears.
msg:”XSS Attack” – The custom message (i.e. XSS Attack) assigned to the rule (or chain) in which
it appears.

16. XSS Rule
Severity:ERROR – The severity of the rule. Severities include EMERGENCY (0), ALERT (1),
CRITICAL (2), ERROR (3), WARNING (4), NOTICE (5), INFO (6) and DEBUG (7).
deny – This stops rule processing and intercepts transaction. This is a disruptive action.
status:404 – This specifies the response status code (404) with actions deny and redirect.

17. DEMO

18. Game over
THANK YOU VERY MUCH
MUMBAI NULL
11 NOVEMBER 2017