Thực chiến bảo mật VPS Linux chống RCE: Cấu hình WAF và Proxy cách ly an toàn cho GitLab Server (2026)

Một buổi sáng thức dậy, bạn nhận được cảnh báo CPU máy chủ spike lên 100%. Mở terminal SSH vào kiểm tra log, bạn bàng hoàng phát hiện một tiến trình lạ đang chạy ngầm dưới quyền user git, hệ thống CI/CD pipeline tự động chèn mã độc vào bản build, và mã nguồn dự án đang bị đẩy ra một server vô danh. Đó không phải là kịch bản trong phim, mà là hậu quả thực tế khi một hệ thống GitLab Server bị nhắm mục tiêu và khai thác lỗ hổng Remote Code Execution (RCE), điển hình như các đợt tấn công qua CVE-2024-38238 hay lỗi parse file Jupyter Notebook.

Với tư cách là System Admin hay DevOps, chúng ta đều hiểu việc cập nhật bản vá (patching) là bắt buộc. Nhưng khoảng thời gian chờ đợi bản vá chính thức luôn là điểm yếu chí mạng của hệ thống. Đây chính là lúc kỹ thuật bảo mật VPS Linux chống RCE thông qua lớp cách ly Proxy và Web Application Firewall (WAF) phát huy sức mạnh. Bạn đã sẵn sàng xây dựng một phòng tuyến vững chãi để đánh chặn payload độc hại ngay từ ngoài cửa chưa? Cùng mổ xẻ kiến trúc hạ tầng phòng thủ qua bài viết dưới đây nhé.

Nỗi đau mang tên RCE và bài toán Virtual Patching cho GitLab

Remote Code Execution (RCE) là loại lỗ hổng bảo mật vô cùng nghiêm trọng. Nó cho phép kẻ tấn công từ xa thực thi các câu lệnh hệ điều hành thông qua kết nối mạng mà không cần tài khoản truy cập. Khi khai thác thành công, hacker hoàn toàn kiểm soát máy chủ, đánh cắp secret key, token CI/CD và thậm chí leo thang đặc quyền để tấn công sâu vào chuỗi cung ứng (supply chain).

GitLab Server thường xuyên trở thành mục tiêu bị nhòm ngó vì kiến trúc phức tạp và diện tích tấn công (attack surface) rộng lớn. Hệ thống này liên tục phải xử lý các thao tác tải file (upload artifact, ảnh), giải nén project (import/export), và phân tích các định dạng dữ liệu (JSON, YAML). Nếu module giải nén gặp lỗi Path Traversal hoặc lỗi Deserialization, kẻ tấn công có thể chèn mã thực thi một cách dễ dàng.

Vậy chúng ta làm gì khi một zero-day RCE xuất hiện mà hãng chưa tung ra bản vá? Câu trả lời là Virtual Patching (Vá ảo).

Thay vì can thiệp vào source code, Virtual Patching sử dụng WAF đứng trước ứng dụng để soi chiếu giao lượng (Traffic Inspection). Khi một mẫu tấn công RCE được nhận diện (ví dụ: chuỗi lệnh shell hoặc ký tự escape đặc biệt), WAF lập tức chặn request (trả về lỗi 403 Forbidden) hoặc ngắt kết nối. Phương pháp này giúp hệ thống được bảo vệ tức thời, không gây downtime, và mua thêm thời gian quý giá để đội ngũ DevSecOps kiểm thử bản cập nhật ở môi trường Staging.

Minh họa cơ chế Virtual Patching: WAF soi chiếu và chặn đứng payload độc hại trước khi chạm vào mã nguồn GitLab.

Nếu bạn còn nhầm lẫn về các khái niệm hạ tầng mạng, hãy tham khảo hướng dẫn phân biệt VPS, Proxy và VPN để lựa chọn giải pháp phù hợp và củng cố nền tảng trước khi đi sâu.

Kiến trúc Defense in Depth: Đừng để GitLab lộ mặt ra Internet

Để triển khai bảo mật VPS Linux chống RCE mang lại hiệu quả cao, chúng ta phải áp dụng nguyên lý Defense in Depth (Phòng thủ theo chiều sâu). Nguyên tắc cốt lõi: Máy chủ GitLab không bao giờ được phép giao tiếp trực tiếp với Internet. Mọi request đều phải đi qua một người gác cổng (Reverse Proxy + WAF), tương tự như kiến trúc được đề cập trong hướng dẫn cấu hình Proxy Server bảo mật luồng CI/CD cho GitLab trên VPS Linux.

Lựa chọn mô hình: 2 VPS tách biệt hay chung Host?

Việc thiết kế hạ tầng quyết định trực tiếp đến vùng ảnh hưởng (blast radius) nếu hệ thống bị xuyên thủng:

• Mô hình 2 VPS riêng biệt (Dedicated DMZ): Đây là thiết kế bảo mật chuẩn mực cho doanh nghiệp. VPS 1 (Proxy/WAF) đóng vai trò lá chắn ngoài cùng có IP Public. VPS 2 (GitLab) nằm hoàn toàn trong mạng Private (VPC/LAN). Nếu WAF bị khai thác, hacker chỉ dừng lại ở vùng DMZ, không thể chạm tới database hay mã nguồn nội bộ. Đồng thời, tải xử lý rules WAF nặng nề sẽ không làm chậm tiến trình chạy CI/CD của GitLab.
• Mô hình chung Host (qua Docker): Lựa chọn này phù hợp với các team ưu tiên tối ưu chi phí hạ tầng. WAF và GitLab chạy chung trên một VPS thông qua các container. Dù tiết kiệm, nhưng mô hình này tiềm ẩn rủi ro Container Escape. Nếu kẻ tấn công thoát được khỏi container WAF, chúng sẽ chiếm quyền Host OS và kiểm soát toàn bộ dữ liệu.

💡 Lựa chọn tối ưu thời gian với BunkerWeb:

Nếu bạn không muốn tự biên dịch Nginx và cấu hình Coraza WAF thủ công, hãy cân nhắc triển khai BunkerWeb làm Reverse Proxy bảo mật. Đây là một Web Application Firewall thế hệ mới mã nguồn mở (chạy nền Nginx). Công cụ này tích hợp sẵn bộ luật OWASP CRS, cơ chế tự động chặn Bot, tự động cấm IP có hành vi lạ (thay thế chức năng của Fail2ban), và hỗ trợ cấu hình qua Docker labels cực kỳ tiện lợi. Triển khai BunkerWeb giúp tiết kiệm 80% thời gian thiết lập so với việc build tay từng thành phần.

Cách ly Network & giải bài toán Docker Bypass với UFW

Dù chọn mô hình nào, bước đầu tiên là dùng Firewall khóa chặt đường vào, đảm bảo traffic chỉ xuất phát từ IP của Proxy.

Nếu cài GitLab trực tiếp lên OS (Omnibus), việc dùng UFW rất đơn giản qua các lệnh allow cơ bản. Nhưng với môi trường Docker, có một rủi ro kỹ thuật: Daemon của Docker sẽ tự động chèn luật NAT vào iptables trước cả chuỗi INPUT của UFW. Hậu quả là cổng 80/443 của container vẫn mở toang ra Internet dù lệnh ufw status báo đang chặn.

Để xử lý bài toán này triệt để mà không cần gõ các lệnh iptables can thiệp thủ công phức tạp, giải pháp hiệu quả là kết hợp công cụ ufw-docker và cơ chế routing mặc định của UFW:

Bước 1: Tải script ufw-docker và cấp quyền thực thi để can thiệp vào file /etc/ufw/after.rules chặn chuỗi NAT mặc định của Docker:

sudo wget -O /usr/local/bin/ufw-docker https://github.com/chaifeng/ufw-docker/raw/master/ufw-docker
sudo chmod +x /usr/local/bin/ufw-docker

Tiến hành cài đặt vào hệ thống và khởi động lại dịch vụ UFW:

sudo ufw-docker install
sudo systemctl restart ufw

Bước 2: Chỉ cho phép IP của Proxy (ví dụ: 10.0.0.5) truy cập cổng 80 của container GitLab. Lúc này, bạn sử dụng cú pháp route mặc định của UFW để giới hạn IP nguồn một cách chuẩn xác:

sudo ufw route allow proto tcp from 10.0.0.5 to any port 80

Mọi traffic khác từ Internet nã vào cổng của container GitLab giờ đây sẽ bị rớt (drop) hoàn toàn.

Đừng quên khai báo IP của Proxy vào file /etc/gitlab/gitlab.rb để GitLab ghi nhận đúng IP người dùng (Client IP) phục vụ cho Audit Log, tránh việc log lưu toàn bộ là IP nội bộ:

gitlab_rails['trusted_proxies'] = ['10.0.0.5']
gitlab_rails['nginx']['real_ip_trusted_addresses'] = ['10.0.0.5']
gitlab_rails['nginx']['real_ip_header'] = 'X-Forwarded-For'
gitlab_rails['nginx']['real_ip_recursive'] = 'on'

Kiến trúc cách ly mạng nội bộ: UFW Route ép Docker Container từ chối mọi kết nối không đến từ Reverse Proxy.

Hướng dẫn cấu hình bảo mật VPS Linux chống RCE chi tiết

Dưới đây là các bước thực chiến để thiết lập một hàng rào WAF + Proxy vững chắc cho môi trường GitLab, giả định bạn chọn phương pháp cấu hình linh hoạt trên Nginx nguyên bản, tương tự như cách cấu hình Proxy Ubuntu 26.04 hiệu năng cao đã được đề cập trước đó.

Bước 1: Thiết lập Nginx Reverse Proxy & tối ưu Buffering chuẩn hãng

GitLab không phải là một website tĩnh. Nền tảng này xử lý các tệp nhị phân khổng lồ (Git LFS), push source code dài hàng trăm MB và duy trì WebSockets cho luồng log CI/CD. Nginx cần được tinh chỉnh cẩn thận để không làm đứt gãy các tiến trình này.

Trong cấu hình server của Nginx Reverse Proxy, bạn cần thiết lập:

server {
    listen 443 ssl http2;
    server_name git.domain.com;
    
    # Cho phép tải lên file dung lượng lớn để không chặn Git Push
    client_max_body_size 500m; 

    # Tăng timeout cho các tác vụ CI/CD và Clone dự án lớn
    proxy_read_timeout    300s;
    proxy_connect_timeout 300s;
    proxy_send_timeout    300s;

    location / {
        proxy_pass http://<IP_GITLAB_BACKEND>;
        proxy_http_version 1.1;

        # Truyền header để GitLab định tuyến chuẩn xác
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;

        # Hỗ trợ WebSocket cho tính năng stream log CI/CD
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

⚠️ Lưu ý kỹ thuật về Header WebSockets:

Các chỉ thị proxy_set_header Upgrade $http_upgrade; và Connection "upgrade"; được đặt ở khối location / nhằm hỗ trợ luồng WebSockets (như tính năng Action Cable / Web Terminal của GitLab). Tuy nhiên, nếu trong cấu hình Nginx, bạn tách nhỏ thêm các khối location con (ví dụ: location /api/), Nginx sẽ không kế thừa các header từ khối cha. Hậu quả là kết nối WebSocket bị đứt. Hãy đảm bảo bạn sao chép lại các chỉ thị header này vào từng khối location con nếu hệ thống có phân mảnh cấu hình.

Tối ưu Buffering:

Việc cấu hình proxy_request_buffering off; trực tiếp trên proxy sẽ làm giảm hiệu suất khi xử lý các request API nhẹ. Cách làm chuẩn xác là cấu hình trực tiếp trên máy chủ GitLab backend, yêu cầu Nginx nội bộ tự động tắt buffering ở những đường dẫn xử lý file nặng.

Trong file /etc/gitlab/gitlab.rb trên server GitLab, bạn thêm cấu hình Regex sau:

gitlab_rails['nginx']['request_buffering_off_path_regex'] = "/api/v\\d/jobs/\\d+/artifacts$|/import/gitlab_project$|\\.git/git-receive-pack$|\\.git/ssh-receive-pack$|\\.git/ssh-upload-pack$|\\.git/gitlab-lfs/objects|\\.git/info/lfs/objects/batch$"

Sau đó chạy sudo gitlab-ctl reconfigure. Bằng cách này, GitLab sẽ dùng đệm (buffer) cho request thông thường, và thông minh tắt đệm đẩy luồng trực tiếp khi dev thực hiện push code hay upload artifact.

Tối ưu hóa Nginx Buffering: Truyền tải trực tiếp (Stream) giúp luồng Git Push dung lượng lớn không bị đứt gãy.

Bước 2: Loại bỏ ModSecurity, triển khai Coraza WAF + OWASP CRS

F5 NGINX ModSecurity đã chính thức kết thúc vòng đời (End-of-Life từ 31/03/2024). Việc tiếp tục sử dụng engine này tiềm ẩn nguy cơ bảo mật do không còn nhận được các bản vá lõi (bạn có thể tham khảo thêm hướng dẫn cấu hình ModSecurity WAF với Nginx Reverse Proxy để ngăn chặn DDoS Layer 7).

Giải pháp thay thế trực tiếp (drop-in replacement) cho kiến trúc hiện đại là Coraza WAF. Được viết bằng ngôn ngữ Go, Coraza an toàn về bộ nhớ (memory-safe), tương thích hoàn toàn với tập luật OWASP Core Rule Set (CRS) và sở hữu hiệu năng ổn định.

Sau khi biên dịch và nạp thư viện ngx_http_coraza_module.so vào Nginx, bạn khai báo Coraza WAF trực tiếp trong file cấu hình bằng lệnh Include:

server {
    listen 443 ssl http2;
    server_name git.domain.com;

    # Kích hoạt Coraza WAF
    coraza on;
    # Trỏ đến file tổng hợp cấu hình OWASP CRS
    coraza_rules "Include /etc/nginx/coraza/main.conf";
    
    # ...
}

Trong file main.conf, bạn nạp luật theo thứ tự chuẩn:

Include /etc/nginx/coraza/coraza.conf-recommended
Include /etc/nginx/coraza/gitlab-exclusions.conf  # Nạp luật ngoại trừ trước
Include /etc/nginx/coraza/crs-setup.conf
Include /etc/nginx/coraza/rules/*.conf            # Nạp bộ luật phòng thủ CRS

Nguyên tắc vận hành: Đừng vội bật chế độ chặn ngay lập tức trên môi trường Production. Hãy giữ cấu hình SecRuleEngine DetectionOnly trong khoảng 1-2 tuần đầu tiên. Hệ thống sẽ ghi log (Audit) để bạn tìm ra các request bị chặn nhầm (False Positive) trước khi chuyển sang SecRuleEngine On.

Bước 3: Tinh chỉnh Rule WAF: xử lý False Positive cho Git & GraphQL

Hiện tượng False Positive là điều chắc chắn xảy ra. Khi developer gõ lệnh git push, Git gửi các tệp đối tượng nhị phân qua phương thức POST tới /*.git/git-receive-pack. Dữ liệu nhị phân này chứa vô số ký tự đặc biệt trông giống hệt payload SQL Injection hoặc RCE, khiến CRS chặn đứng. Tương tự, các câu query gửi vào /api/graphql cũng dễ bị đánh dấu là mã độc XSS do chứa cấu trúc lồng ghép phức tạp.

Nguyên tắc xử lý: Không dùng SecRuleRemoveById để tắt quy tắc bảo vệ trên toàn cục. Hãy áp dụng kỹ thuật phẫu thuật (Surgical Tuning) vào đúng endpoint cụ thể trong file gitlab-exclusions.conf:

# Bỏ qua kiểm tra XSS/RCE/SQLi cho tiến trình Git Push
SecRule REQUEST_URI "@rx \.git/git-receive-pack$" \
    "id:10001,phase:1,pass,nolog,\
    ctl:ruleRemoveByTag=attack-sqli,\
    ctl:ruleRemoveByTag=attack-rce,\
    ctl:ruleRemoveById=920420"

# Hỗ trợ API GraphQL phân tích JSON và gỡ rule chặn nhầm trên tham số 'query'
SecRule REQUEST_HEADERS:Content-Type "application/json" \
    "id:200001,phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"

SecRule REQUEST_URI "@beginsWith /api/graphql" \
    "id:10002,phase:1,pass,nolog,\
    ctl:ruleRemoveTargetById=941100;ARGS:query,\
    ctl:ruleRemoveTargetById=942100;ARGS:query"

Nhờ sử dụng ctl:ruleRemoveByTag và giới hạn cứng bằng REQUEST_URI, ứng dụng GitLab vẫn được WAF bảo vệ chặt chẽ ở các endpoint khác (như trang đăng nhập hay đường dẫn upload file tĩnh).

Bước 4: Rate-limit kết hợp Fail2ban chặn dò quét tự động

Các cuộc tấn công RCE thường bắt nguồn từ các botnet rà quét lỗ hổng một cách ồ ạt. Sự kết hợp giữa giới hạn truy cập (Rate Limit) ở tầng Layer 7 trên Nginx và khóa IP tự động bằng Fail2ban (nếu bạn không dùng giải pháp tích hợp sẵn như BunkerWeb) ở tầng Layer 3 sẽ bẻ gãy ý đồ dò quét này.

Để hiểu rõ hơn về kỹ thuật này, bạn có thể tham khảo hướng dẫn bảo mật VPS bằng Fail2Ban giúp chống Brute Force toàn diện khi dùng Nginx Reverse Proxy.

Trên Nginx, thiết lập cơ chế Leaky Bucket tại khối http:

limit_req_zone $binary_remote_addr zone=gitlab_limit:10m rate=5r/s;

Và áp dụng vào các vị trí nhạy cảm:

location /users/sign_in {
    limit_req zone=gitlab_limit burst=10 nodelay;
    proxy_pass http://<IP_GITLAB_BACKEND>;
}

Tiếp đó, cấu hình Fail2ban giám sát file /var/log/nginx/error.log. Bất cứ khi nào Nginx báo lỗi limiting requests, excess..., Fail2ban sẽ đếm số lần vi phạm. Nếu một IP cố tình nhồi request vượt ngưỡng maxretry, Fail2ban sẽ tự động chèn luật iptables đẩy IP đó ra đảo (ban) trong vài giờ đồng hồ.

Những lỗ hổng cửa sau cần khóa chặt ngoài WAF

Lớp WAF và Proxy giải quyết bài toán kiểm soát giao lượng HTTP/HTTPS. Tuy nhiên, cấu trúc hạ tầng của GitLab còn nhiều cửa sau cần được gia cố đồng bộ để tránh bị khai thác RCE từ bên trong.

Cách ly hạ tầng CI/CD GitLab Runner

GitLab CI/CD bản chất là một bộ máy thực thi lệnh tự động. Kẻ tấn công có tài khoản Developer có thể viết kịch bản độc hại vào file .gitlab-ci.yml. Nếu không cô lập tốt, Runner sẽ trở thành bàn đạp để hacker đánh chiếm hệ thống.

• Hạn chế dùng Shell Executor: Chạy job CI/CD bằng quyền shell trực tiếp trên host là hành động mạo hiểm. Kịch bản sẽ chạy bằng quyền gitlab-runner và dễ dàng can thiệp cấu hình hệ điều hành gốc.
• Tránh Privileged Container: Khi dùng Docker Executor, hãy hạn chế việc gắn cờ --privileged. Chế độ này cấp quyền root của máy chủ host cho container, cho phép hacker dùng kỹ thuật Container Breakout can thiệp thẳng vào hệ điều hành.
• Bật tính năng dọn dẹp Job (Cleanup): Để ngăn chặn rò rỉ mã nguồn hoặc token giữa các bản build, hãy cấu hình bật Feature Flag FF_ENABLE_JOB_CLEANUP trên môi trường Runner. Khi cờ này kích hoạt, toàn không gian làm việc trên host (bao gồm cả thư mục .git) sẽ tự động được dọn dẹp sạch sẽ ngay sau khi job kết thúc.

Đóng gói SSH: Không quản trị qua Port Public

Quản lý server GitLab và Proxy thông qua cổng SSH (Port 22) mở toang ra Internet là lời mời chào cho các cuộc tấn công Brute-force. Chủ đề này từng được thảo luận chuyên sâu qua tài liệu hardening bảo mật VPS Ubuntu 26.04 LTS bằng cách tàng hình SSH và cách ly AI Agent. Để siết chặt an ninh hạ tầng, bạn nên:

1. Đổi cổng mặc định: Chuyển sang một port ngẫu nhiên trên 1024 (ví dụ 2222). Thao tác này sẽ làm nản lòng phần lớn các botnet quét tự động.
2. Khóa mật khẩu và Root: Trong /etc/ssh/sshd_config, ép buộc xác thực bằng SSH Key chuẩn Ed25519 (PubkeyAuthentication yes, PasswordAuthentication no) và cấm quyền root login (PermitRootLogin no).
3. Giới hạn IP nội bộ: Giới hạn quyền truy cập SSH từ một dải IP tin cậy thông qua danh sách AllowUsers.

Checklist kiểm tra hệ thống trước khi đưa lên Production

Một hệ thống bảo mật VPS Linux chống RCE vận hành trơn tru khi các thành tố bổ trợ nhịp nhàng cho nhau. Trước khi đưa vào sử dụng chính thức, hãy rà soát lại checklist sau:

1. [ ] Kiểm tra Network Isolation: Dùng Nmap quét IP Public của máy chủ GitLab. Đảm bảo cổng 80/443 không thể truy cập trực tiếp từ Internet, mọi giao thức phải báo Filtered/Closed nhờ UFW Route.
2. [ ] Kiểm tra Header định tuyến: Xác nhận Nginx đã truyền đủ các header X-Forwarded-Proto và X-Real-IP. Đăng nhập GitLab, vào mục Audit Log xem hệ thống nhận diện đúng IP thật của bạn hay đang lưu IP nội bộ của Proxy.
3. [ ] Kiểm thử WAF Detection: Gửi một payload vô hại (ví dụ: /?id=1' OR 1=1--) tới GitLab qua Proxy. Phản hồi phải là lỗi 403 Forbidden và Coraza audit log phải ghi nhận sự kiện vi phạm này.
4. [ ] Kiểm thử Git Operations: Thử git clone, commit một file lớn và push lên repo. Nếu tiến trình bị đứt gãy, cần kiểm tra lại tham số Regex cấu hình tắt buffering trong gitlab.rb và các Exclusion Rules của WAF.
5. [ ] Kiểm tra GitLab Runner: Đảm bảo job CI/CD đang chạy trong container phi đặc quyền (non-privileged) và tính năng FF_ENABLE_JOB_CLEANUP hoạt động hiệu quả.

Câu hỏi thường gặp (FAQ)

1. Tại sao máy chủ GitLab thường xuyên bị nhắm mục tiêu RCE?

Vì GitLab xử lý khối lượng lớn các định dạng file phức tạp (upload, nén, import project) và tích hợp sẵn engine chạy CI/CD tự động. Điều này tạo ra một bề mặt tấn công cực kỳ rộng cho tin tặc.

2. Virtual Patching (Vá ảo) là gì và tại sao lại quan trọng?

Là kỹ thuật dùng WAF (như Coraza) để chặn đứng các request chứa mã độc ngay từ vòng ngoài. Nó giúp bảo vệ ứng dụng tức thì, không gây downtime trong thời gian chờ hãng tung ra bản vá lỗi chính thức.

3. Triển khai WAF có làm lỗi hoặc làm chậm tiến trình Git Push không?

Không, nếu bạn cấu hình đúng. Bằng cách thiết lập Rule ngoại trừ (Exclusion Rules) cho endpoint /git-receive-pack và tắt Nginx Buffering qua Regex cho các file lớn, luồng Git Push sẽ hoạt động mượt mà.

4. Tại sao tôi đã bật tường lửa UFW nhưng port của Docker container vẫn bị lộ ra ngoài?

Do daemon của Docker tự động can thiệp vào iptables trước cả UFW. Giải pháp triệt để là cài đặt công cụ ufw-docker kết hợp với luật route của UFW để ép Docker tuân thủ tường lửa.

5. Động cơ ModSecurity v3 có còn an toàn để bảo mật VPS Linux chống RCE trong thời điểm hiện tại không?

Hoàn toàn rủi ro. F5 NGINX đã ngừng hỗ trợ (End-of-Life) ModSecurity từ năm 2024. Hãy chuyển sang sử dụng Coraza WAF (viết bằng Go) để đảm bảo hiệu năng và nhận bản vá bảo mật liên tục.

Kết luận

Việc xây dựng một kiến trúc bảo mật VPS Linux chống RCE cho GitLab Server đòi hỏi sự hiểu biết kỹ thuật sâu sắc về tương tác giữa các tầng mạng. Sự kết hợp giữa Coraza WAF (hoặc giải pháp All-in-one như BunkerWeb), Reverse Proxy, và UFW tạo nên một lá chắn vững chắc, giúp ngăn chặn lượng lớn các cuộc tấn công tự động và mua thêm thời gian quý giá cho đội vận hành.

Tất nhiên, kiến trúc phòng thủ dù nhiều lớp đến đâu cũng không thể thay thế việc thường xuyên nâng cấp phiên bản phần mềm. Hãy duy trì thói quen theo dõi bản tin bảo mật của nhà phát hành, lên lịch patch định kỳ, và biến lớp Proxy cách ly thành tuyến phòng thủ đắc lực bảo vệ tài sản mã nguồn của dự án.

Tài liệu tham khảo

• GitLab Hardening Recommendations | GitLab Docs
• NGINX settings | GitLab Docs
• Introduction | OWASP Coraza
• CRS Documentation
• BunkerWeb documentation