用Ngnix打造安全网站
展开查看详情
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/