1.Securing Web Apps with NGINX http://wallarm.com Stephan Ilyin, si@wallarm.com 

2.How many of you have your websites hacked? 

3.Each application probably has vulnerabilities 

4.… and someday it can be hacked 

5.How to harder/secure your application? 

6.How deal with attacks to your application? Chapter 1. 

7.Tip #1. mod_security can be a good choice 

8. Mod_security rocks! • Open-source. Finally available for NGINX • It works! It can be quite efficient in detecting attacks • Supports virtual patching • It is incredible customisable 

9.server { listen 80; server_name localhost; location / { ModSecurityEnabled on; ModSecurityConfig modsecurity.conf; ModSecurityPass @backend; } location @backend { proxy_pass http://localhost:8011; proxy_read_timeout 180s; } } 

10. but mod_security is not so good! • Relies on regex • It is expensive in performance prospective • If you use default rulesets, you will get a huge number of false-positives • Rules tuning is a hard job (difficult to maintain) • Signatures never covers all the attacks • REGEXs can be bypassed 

11. What rules look like # ShellShock virtual patch (Bash attack) SecRule REQUEST_HEADERS 
 "^\(\s*\)\s+{" "phase:1,deny,id: 1000000,t:urlDecode,status: 400,log,msg:'CVE-2014-6271 - Bash Attack'" 

12. Good practice (imho) • Use public ruleset — for monitoring mode • Craft rules from scratch specifically for your application — for blocking mode 

13. More rules = More overhead! 

14.Using phases is good idea 1. Request headers (REQUEST_HEADERS) 2. Request body (REQUEST_BODY) 3. Response headers (RESPONSE_HEADERS) 4. Response body (RESPONSE_BODY) 5. Logging (LOGGING) 

15. SecRule phase 2 SecRule REQUEST_BODY "/+etc/+passwd" "t:none,ctl:ResponseBodyAccess=On,msg:'- IN- PASSWD path detected', phase: 2,pass,log,auditlog,id:'10001',t:urlDeco de,t:lowercase,severity:1" 

16. SecRule phase 4 SecRule RESPONSE_BODY "root\:x\:0\:0" "id:'20001',ctl:auditLogParts=+E, msg:'- OUT- Content of PASSWD detected!',phase: 4,allow,log,auditlog,t:lowercase,severit y:0" 

17.Handbook by Ivan Ristic. Must read! 

18.Tip #2. Give a chance to naxsi (another WAF for NGINX) 

19. Why naxsi? • NAXSI means Nginx Anti Xss & Sql Injection 
 (but do more) • Naxsi doesn't rely on a signature base (regex)! https://github.com/nbs-system/naxsi 

20. naxsi rules • Reads a small subset of simple scoring rules (naxsi_core.rules) containing 99% of known patterns involved in websites vulnerabilities. • For example, '<', '|' or 'drop' are not supposed to be part of a URI. 

21. This rule triggers on select or other SQL operators MainRule "rx:select|union|update|delete| insert|table|from|ascii|hex|unhex|drop" "msg:sql keywords" "mz:BODY|URL|ARGS| $HEADERS_VAR:Cookie" "s:$SQL:4" id:1000; 

22. naxsi setup http {
 include /etc/nginx/naxsi_core.rules;
 include /etc/nginx/mime.types;
 [...]
 } 

23.But! Ruleset is not enough! • Those patterns may match legitimate queries! • Therefore, naxsi relies on whitelists to avoid false positives • Nxutil tool helps the administrator to create the appropriate whitelist • there are pre-generated whitelists for some CMS (e.g. WordPress) 

24. LearningMode; #Enables learning mode
 
 SecRulesEnabled; #SecRulesDisabled;
 
 DeniedUrl "/RequestDenied"; 
 ## check rules CheckRule "$SQL >= 8" BLOCK;
 CheckRule "$RFI >= 8" BLOCK;
 CheckRule "$TRAVERSAL >= 4" BLOCK;
 CheckRule "$EVADE >= 4" BLOCK;
 CheckRule "$XSS >= 8" BLOCK; 

25.naxsi ruleset 

26.naxsi whitelist 

27. Naxsi pros and cons Pros: • Pretty fast! • Update independent • Resistant to many waf-bypass techniques Cons: • You need to use LearningMode with each significant code deployment 

28. Tip #3. Try repsheet (behaviour based security) 

29.Watch Aaron Bedra’s talk http://getrepsheet.com/