Nginx Server Security: Nginx Hardening Tips

Mở đầu

Chắc hẳn mấy anh em theo nghiệp ops hay dev nói chúng không lạ gì với Nginx nữa – nó là web server top 1 phổ biến, nhẹ, nhanh và khả năng chịu tải cao. Do đó, để dựng ngay một ẻm “En-din-ích” phục vụ ứng dụng web thì dễ hơn ăn kẹo, chỉ cần cào nhẹ vài phím là xuất hiện cả trăm bài viết hướng dẫn trên Google.

Nginx là một mã nguồn mở (vẫn có phiên bản enterprise) cung cấp nhiều module và khả năng tùy biến rất cao. Chính vì vậy, cấu hình như nào cho best practice để tối ưu hiệu suất và tăng cường bảo mật thì không phải anh em nào cũng rành. Do cũng có chút ít kinh nghiệm trong môi trường web hosting và lăn lộn với nó nhiều nên hôm nay mình chia sẻ với mấy bác một số mẹo để hardening Nginx.

Nginx hardening

1. Tắt nginx server_tokens

Theo mặc server_tokens được bật để hển thị phiên bản Nginx đang chạy trên server, một người dùng bình thường có thể dễ dàng xem được thông tin này từ HTTP response như bên dưới:

Từ đây attacker có thể tận dụng thông tin này để khai thác lỗ hổng bảo mật của phiên bản. Do đó khuyến nghị nên vô hiệu hóa server_tokens bằng  cách thêm server_tokens off vào block http {} trong file cấu hình chính /etc/nginx/nginx.conf.

Bây giờ, HTTP response sẽ không còn hiển thị version của Nginx nữa.

2. Vô hiệu hóa các module không cần thiết

Lưu ý: Nội dung này không có áp dụng được với Nginx được cài từ package (.rpm hoặc .deb) hoặc từ trình quản lý gói (repository). Tuy nhiên anh em có thể liệt kê ra các module được cài kèm theo Nginx bằng lệnh sau:

nginx -V

Đối với Nginx được cài đặt từ source, mặc định cũng sẽ bao gồm nhiều module kèm theo. Do đó để giảm thiểu rủi ro cũng như hạn chế lỗ hổng để attacker khai thác, chúng ta nên tắt những module không sử dụng.

Để disable bất kỳ module nào có trong danh sách trên, anh em cần phải stop Nginx và tiến hành recompile không bao gồm module đó.

3. Kiểm soát và giới hạn resource

Để bảo vệ Nginx khỏi các cuộc tấn công DoS (hoặc DDoS), anh em cần phải giới hạn lại các cấu hình buffer size sau cho tất cả client kết nối đến webserver:

• client_max_body_size: sử dụng tham số này để xác định kích thước tối đa được chấp nhận cho cho một request từ client. Best practice nên thiết lập 1k là đủ, nếu website của anh em có sử dụng tính năng upload file qua giao thức HTTP POST thì có thể cân nhắc tăng lên cho phù hợp.
• client_body_buffer_size: sử dụng tham số này để chỉ định kích thước bộ đệm cho body request từ client. Giá trị mặc định là 8k hoặc 16k, nhưng khuyến nghị nên thiết lập dưới mức 1k.
• client_header_buffer_size: sử dụng tham số này để chỉ định kích thước bộ đệm cho header của request từ client. client_header_buffer_size 1k là đủ cho hầu hết các request.
• large_client_header_buffers: tham số này để chỉ định số lượng và kích thước tối đa của bộ đệm dùng để đọc các client request header lớn. Một large_client_header_buffers 2 1k thiết lập số lượng tối đa của buffer là 2, mỗi buffer có kích thước tối đa là 1k. Do đó, cấu hình này sẽ chấp nhận 2 kB data URI.

Lưu ý: Các bạn có thể cấp hình các tham số trên trong cấu hình chính của Nginx (/etc/nginx/nginx.conf) hoặc có thể tùy biến vào các file vhost bên trong /etc/nginx/conf.d

4. Vô hiệu hóa các HTTP method không cần thiết

Thêm một best practice nữa để tăng cường bảo mật cho Nginx của anh em là tắt những HTTP method không an toàn và không cần thiết trên web server. Trong hầu hết các trường hợp chúng ta chỉ sử dụng các phương thức GET, POST, PUT và HEAD. TRACE, OPTION hoặc DELETE thì không an toàn có thể bị acttacker lợi dụng để tấn công dạng cross-site tracking.

Khuyến nghị anh em nên cấu hình trong block server của từng file nginx virtual host như sau:

if ($request_method !~ ^(GET|HEAD|POST|PUT)$ ) {

    return 444;

}

Hoặc cách cấu hình khác đặt trong block location của từng file nginx virtual host:

location / {

    limit_except GET HEAD POST PUT { deny all; }

}

5. Cấu hình SSL và Cipher Suites

Vô hiệu hóa giao thức SSL/TLS yếu

Theo mặc định, nginx chấp nhận sử dụng các giao thức SSL phiên bản cũ (tính bảo mật yếu) như: TLS 1.0, TLS 1.1. Điều này có thể dẫn đến bị tấn công BEAST attack. Vì vậy, best practice vẫn là loại bỏ các giao thức TLS cũ và thay bằng các phiên bản TLS mới hơn được hỗ trợ như: TLS 1.2, TLS 1.3.

Điều chỉnh cấu hình sau vào block server trong file cấu hình Nginx:

ssl_protocols TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE

Vô hiệu hóa cipher suite yếu

Các bộ mã hóa (cipher suite) yếu có thể dẫn đến lỗ hổng, theo khuyến nghị chúng ta phải đảm bảo chỉ cho phép sử dụng những bộ mã hóa mạnh và mới.

Thêm hoặc cập nhật giá trị của dòng sau trong block server của file cấu hình nginx:

ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA HIGH !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !SSLv2 !SSLv3";

Best practice cho giao thức SSL và Cipher Suite tương tự như minh họa bên dưới:

6. Cấu hình Security Headers

Phần cuối cùng mà mình chia sẻ đến mọi người để tăng cường bảo mật cho Nginx đó là harden cho HTTP header.

X-Frame-Options

Tham số X-Frame-Options áp dụng cho HTTP response header cho biết trình duyệt web tại phía client (Google Chrome,…) có được phép hiển thị nội dung một trang web tại thẻ <frame> hoặc <iframe> hay không. Do đó để ngăn chặn các tấn công clickjacking khai thác vào hai thẻ HTML này, best practice sẽ là bật và cấu hình X-Frame-Options chỉ cho phép hiển thị nội dung các trang của cùng một nguồn website.

Để làm được điều đó, anh em thêm dòng bên dưới vào block server của file cấu hình nginx:

add_header X-Frame-Options "SAMEORIGIN";

Strict-Transport-Security

HTTP Strict Transport Security (HSTS) là một phương thức cho phép các kết nối từ client đến website chỉ sử dụng HTTPS, không cho phép kết nối không an toàn HTTP. Sau khi website được kích hoạt HSTS, trình duyệt web sẽ chặn tất cả các kết nối HTTP và không cho người dùng tiếp tục truy cấp đến các website có chứng chỉ SSL không an toàn.

Để kích hoạt HSTS, bạn cần thêm nội dung sau vào file cấu hình Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";

CSP và X-Content-Type-Options

Content Security Policy (CSP)

Tạm dịch là chính sách an toàn nội dung :lol:, CSP bảo vệ web server chống lại các cuộc tấn công Cross-site Scripting (XSS) và data injection.

Theo best practice, anh em chỉ nên thêm tham số add_header Content-Security-Policy vào block server cho từng file cấu hình nginx virtual host có nội dung tương tự như sau:

add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;

Nội dung trên chỉ là cấu hình CSP chung nhất, tùy thuộc vào kiến trúc kết nối cũng như độ phức tạp của mỗi website mà anh em tùy biến nội dung CSP cho phù hợp.

Theo kinh nghiệm thực tế mình có được khi cấu hình CSP lên Nginx theo đúng chính sách mà đội security yêu cầu là ban đầu chỉ nên áp dụng CSP base nhất có thể (như ví dụ trên). Bước tiếp theo là phải work với đội Dev để có được chính xác danh sách các external resource mà website sử đang sử dụng, từ đó mới thiếp lập cấu hình CSP “mạnh” nhất có thể. Và tất nhiên là phải apply trên môi trường UAT trước nhé anh em, vì chỉ 1 cấu hình CSP không đúng có thể dẫn đến lỗi tính năng nào đó của website liền

Sau khi thiết lập, anh em có thể kiểm tra cấu hình CSP của website bằng công cụ sau: https://cspvalidator.org/

X-Content-Type-Options

X-Content-Type-Options hay còn được gọi là “Browser Sniffing Protection“, nó yêu cầu trình duyệt web tuân thủ theo các MIME type được chỉ định trong header request. Nó giúp bảo vệ trình duyệt như IE, Google Chrome không thể “sniffing a response” khỏi các Content-Type đã khai báo

Để cấu hình X-Content-Type-Options cho Nginx server, anh em thêm dòng sau vào block server của file cấu hình Nginx mặc định:

add_header X-Content-Type-Options nosniff;

Về các tiêu chuẩn security cho header trong phần cuối này (ngoại trừ CSP), các bạn có thể đặt chung trong một file tương tự như minh họa bên dưới:

Lời kết

Như vậy là mình đã hoàn thành bài viết Nginx Server Security: Nginx Hardening Tips. Hy vọng với những mẹo nhỏ này có thể giúp tăng cường bảo mật cho Nginx trên server của anh em.

Nếu có bất kỳ thắc mắc, góp ý về nội dung bài viết hoặc có thêm tip nào hay hơn, các bạn có thể để lại phản hồi ngay bên dưới.

Chúc các bạn thành công!

Nguồn:

https://www.acunetix.com/blog/web-security-zone/hardening-nginx/

https://beaglesecurity.com/blog/article/nginx-server-security.html