Apache Security Hardening: Cấu hình Apache an toàn

Apache Security Hardening là quá trình giảm attack surface và cấu hình Apache HTTP Server theo nguyên tắc least privilege: chỉ load module cần thiết, giới hạn filesystem access, không biến reverse proxy thành open proxy, kiểm soát dynamic content, dùng TLS phù hợp, giới hạn request/resource và luôn test config trước reload. Hardening không thay việc cập nhật package hay sửa lỗ hổng ứng dụng.

Apache HTTP Server Project khuyến nghị theo dõi security updates, bảo vệ ServerRoot/config khỏi user không đặc quyền và review kỹ CGI/dynamic content. Tài liệu Security Tips cũng nhấn mạnh default access, .htaccess, timeout/request limits và log review. Vì vậy workflow nên là inventory → backup → config test → graceful reload → read-back → functional test.

Inventory và change safety

1. Xác định package, version và module đang load

Trước hardening, biết Apache/httpd đến từ distro package hay source/repository khác và module nào đang active:

apachectl -V
apachectl -M

Trên một số distro command có thể là httpd -V. Không coi ServerTokens là patching; version/package phải nằm trong support model và security advisory được theo dõi. Nếu patch state chưa rõ, đóng việc đó bằng Linux Patch Management trước khi xem Apache hardening là PASS.

2. Snapshot effective config trước thay đổi

Apache có include, virtual host và module-specific config. Backup đúng các file đang được include và ghi state trước change. Với Debian/Ubuntu, có thể có sites-enabled/mods-enabled; RHEL-family tổ chức khác.

Không sửa một file “httpd.conf” giả định nếu distro không dùng nó làm source of truth.

3. Bảo vệ ServerRoot và config file

Apache Security Tips cảnh báo file/directory mà root sẽ execute hoặc ghi phải không được sửa bởi user không đặc quyền. Nếu attacker có thể thay httpd binary, config hoặc file mà root process sử dụng, họ có thể tạo privilege escalation.

Audit owner/mode của:

Apache binary và module.
Main config và include directory.
Certificate/private key.
Log directory.
Service unit/drop-in.

Web worker không nên có quyền ghi config hoặc binary.

Filesystem, module và proxy boundaries

4. Deny filesystem access theo mặc định

Apache documentation đưa pattern:

<Directory "/">
    Require all denied
</Directory>

sau đó allow đúng directory cần phục vụ. Ý tưởng là deny filesystem by default, không phải copy nguyên vào production mà bỏ qua existing virtual host/module behavior. Cần test interactions giữa <Directory>, <Location> và alias/proxy rules.

5. AllowOverride và .htaccess

Nếu đội vận hành quản config tập trung và application không cần .htaccess, có thể giữ AllowOverride None rồi đưa rule vào server config. Apache lưu ý điều này ngăn user/content tree override security settings ngoài các path được phép.

Nếu CMS/shared hosting cần .htaccess, chỉ cho phép directive classes cần thiết thay vì AllowOverride All theo thói quen.

6. Options và directory listing

Review Options theo từng directory. Không bật Indexes nếu không cần directory listing. Không bật CGI/ExecCGI hoặc Includes cho cây content chỉ phục vụ static file.

Security Tips cảnh báo SSI/CGI có thể execute dưới quyền web server user. Dynamic execution chỉ nên bật ở path có owner và review rõ.

7. CGI và dynamic content

CGI/script chạy với privilege của identity được cấu hình. Nếu nhiều application dùng chung user, compromise một app có thể ảnh hưởng file của app khác nếu permission cho phép.

Dynamic framework cần patch riêng và security model riêng. Apache hardening không thay PHP/Python/Perl/app security.

8. Reverse proxy: tuyệt đối tránh open proxy

Apache mod_proxy cảnh báo không bật forward proxy trước khi server được bảo vệ. Với reverse proxy thông thường:

ProxyRequests Off

là hướng an toàn phổ biến. ProxyPass vẫn có thể hoạt động khi ProxyRequests Off. Chỉ bật forward proxy khi đó thực sự là business requirement và access control đã thiết kế rõ.

9. Chỉ load module cần thiết

Mỗi module tạo thêm code/config surface. Inventory bằng apachectl -M, rồi disable module không dùng theo cơ chế distro. Không disable hàng loạt production module chỉ vì “ít module an toàn hơn”; cần map dependency của vhost/app.

10. ServerTokens/ServerSignature là control phụ

Giảm version/banner có thể hạn chế một phần information disclosure, nhưng không làm vulnerable server thành an toàn. Patch state, module exposure và access control quan trọng hơn.

TLS, resource controls và observability

11. TLS termination

Nếu Apache terminate TLS, certificate/private key phải được bảo vệ và protocol/cipher policy cần bám version Apache/OpenSSL hiện tại. Không copy cipher list cũ từ blog. Nếu TLS terminate ở CDN/load balancer, origin TLS vẫn cần trust model rõ.

12. Request/resource limits

Apache Security Tips đề cập RequestReadTimeout, TimeOut, KeepAliveTimeout, LimitRequestBody, LimitRequestFields và các giới hạn input khác để giảm resource abuse.

Không đặt timeout/body limit máy móc. Upload/API/long-polling có requirement khác site static. Mỗi limit cần functional test để tránh DoS chính user hợp lệ.

13. MaxRequestWorkers và MPM

Concurrency phải khớp RAM/CPU và application backend. Apache docs lưu ý MPM/threading ảnh hưởng khả năng chịu đồng thời. Cấu hình quá cao có thể làm host cạn memory; quá thấp tạo queue/availability issue.

Đây là capacity/security trade-off, không có con số “hardening chuẩn”.

14. Client IP sau reverse proxy

Nếu Apache đứng sau CDN/load balancer, log/access rule/rate limiting chỉ đúng khi real-client-IP chain được cấu hình với trusted proxy source. Không tin header do Internet client tự gửi.

15. File nhạy cảm và dotfile

Security Tips đưa ví dụ deny dotfile và nhắc exception .well-known. Tư duy quan trọng hơn regex cụ thể: secret, VCS metadata, backup và env file không nên nằm trong public document root; web server rule chỉ là lớp bổ sung.

16. Logging và detection

Apache access/error logs giúp thấy probing, denied request, upstream error và config behavior. Log cần retention, rotation và disk monitoring. Không log credential/header nhạy cảm không cần thiết. Nếu cần gắn web-log events với privileged/config/package/network changes trong cùng incident timeline, xem Server Audit Logging.

Review log sau hardening để phát hiện false positive: denied legitimate path, proxy error, timeout, upload failure.

17. Config validation trước reload

Trước mọi reload/restart:

sudo apachectl configtest

hoặc command distro tương đương. Chỉ khi syntax PASS mới graceful reload. Sau đó kiểm tra service, socket, vhost, TLS và application paths.

Mẫu Apache Hardening Review Record

Đây là template evidence, không phải cấu hình Apache hiện tại của SecureWebOps.

Control	Observed	Expected	Evidence	Result
Package/version	Observed	Supported/patched	Package + security advisory	PASS/FAIL
Modules	Loaded modules	Only needed	`apachectl -M`	PASS/FAIL
Filesystem access	Directory policy	Deny by default + explicit allow	Config test/read-back	PASS/FAIL
Proxy	Forward/reverse	No open proxy	mod_proxy config	PASS/FAIL
Logs	Access/error	Usable evidence	Log sample	PASS/FAIL

Checklist Apache Security Hardening

Package/source/version còn support.
Security advisory được theo dõi.
Config/binary/ServerRoot không writable bởi worker user.
Module inventory đầy đủ.
Filesystem access deny-by-default theo architecture.
AllowOverride tối thiểu.
Options không bật Indexes/ExecCGI/Includes ngoài nhu cầu.
Dynamic content chạy privilege tối thiểu.
ProxyRequests Off nếu chỉ reverse proxy.
TLS termination và private-key access rõ.
Request limits/timeout được test.
MPM/concurrency không vượt capacity.
Trusted proxy/client-IP chain đúng.
Dotfile/secret không public.
Logging/rotation hoạt động.
apachectl configtest PASS trước reload.
Functional test vhost/app sau reload.

Liên hệ với File Permission

Apache docs nhấn mạnh config/binary/log path liên quan root phải được bảo vệ. Với application source, upload và runtime path, xem File Permission & Ownership trên Web Server để tránh worker có write privilege quá rộng.

Nguồn kỹ thuật tham khảo

Kết luận

Apache hardening tốt dựa trên least privilege và explicit access: package được patch, module cần thiết, filesystem deny-by-default, proxy không bị mở ngoài ý muốn, dynamic content có privilege giới hạn và request limits được test theo workload.

Workflow an toàn là snapshot → thay đổi nhỏ → configtest → graceful reload → log/read-back → functional test. Nếu syntax đúng nhưng vhost, upload, proxy hoặc application lỗi thì hardening chưa hoàn thành.