1.Securing Web Apps with NGINX Stephan Ilyin,

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)!

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