Tại sao nginx bắt đầu quá trình như root?


39

Tôi đã cài đặt máy chủ nginx. Tôi vừa kiểm tra các cổng nghe và thấy như sau:

$ sudo lsof -nP -i | grep LISTEN
sshd       614     root    3u  IPv4   7712      0t0  TCP *:22 (LISTEN)
nginx      822     root    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      827 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      828 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      829 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      830 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
.
.
.

Và tôi chỉ quan tâm tại sao có bốn quy trình nginx chạy dưới dạng 'người dùng dữ liệu www' và một là 'người dùng root'?



Bạn có thể hỏi một câu hỏi khác thay thế.
Braiam

Không. Bởi vì điều này có liên quan đến bài viết này. Vui lòng làm lại những thay đổi của bạn.
Erik

Câu trả lời:


49

Quá trình bạn nhận thấy là quy trình tổng thể, quá trình bắt đầu tất cả các quy trình nginx khác. Quá trình này được bắt đầu bởi tập lệnh init bắt đầu nginx. Lý do quá trình này chạy bằng root đơn giản là vì bạn đã bắt đầu nó với quyền root! Bạn có thể bắt đầu nó như một người dùng khác, nhưng bạn sẽ phải đảm bảo rằng tất cả các tài nguyên nginx cần có sẵn cho người dùng này. Đó thường sẽ là ít nhất / var / log / nginx và tệp pid dưới / var / run /.

Quan trọng nhất; Chỉ các tiến trình root mới có thể nghe các cổng dưới 1024. Một máy chủ web thường chạy ở cổng 80 và / hoặc 443. Điều đó có nghĩa là nó cần được bắt đầu như root.

Tóm lại, quy trình tổng thể đang được chạy bởi root là hoàn toàn bình thường và trong hầu hết các trường hợp cần thiết cho hoạt động bình thường.

Chỉnh sửa: Chạy bất cứ thứ gì khi root đều có rủi ro bảo mật tiềm ẩn. Thông thường các nhà phát triển loại phần mềm này có nhiều kiến ​​thức về các vectơ tấn công và hết sức cẩn thận để thực thi ít nhất có thể như root. Cuối cùng, bạn chỉ cần tin tưởng rằng phần mềm có chất lượng tốt.

Nếu bạn vẫn cảm thấy không thoải mái, có một cách để chạy nginx như một người dùng khác và vẫn sử dụng các cổng dưới 1024. Bạn có thể sử dụng iptables để chuyển hướng tất cả lưu lượng truy cập trên cổng 80 sang cổng khác, ví dụ 8080 và nghe nginx trên cổng đó.


Nhưng những gì về bảo mật? Có ai có thể hack máy chủ thông qua quá trình root này không?
Erik

Cập nhật câu trả lời của tôi.
arnefm

Làm một cái gì đó iptablescó lẽ là quá mức cần thiết. Tôi muốn xem câu trả lời của @ slm.
Bratchley

Các cổng <1024 có thể ở hầu hết các nơi như Joel đã đề cập và chuyển hướng trong iptablescó thể gây nhầm lẫn mọi thứ.
Matt

17

Hầu hết các máy chủ (Apache, Nginx, v.v.) đều có một quy trình mẹ được sở hữu bởi root, sau đó sẽ sao chép các nút công nhân bằng cách sử dụng một người dùng ít thông tin hơn. Trong trường hợp này là nó www-data.

Thí dụ

Nếu bạn xem nginxtập tin cấu hình của /etc/nginx/nginx.conf, bạn sẽ thấy các dòng như thế này:

user nginx;
worker_processes 2; #change to the number of your CPUs/Cores
worker_rlimit_nofile 8192;

Hầu hết các máy chủ đều có các tùy chọn tương tự như điều này quy định người dùng nào sẽ chạy các nút nô lệ và bao nhiêu trong số chúng.

Bảo vệ

Các dịch vụ tiếp xúc có quyền truy cập root thường được đề cập là một sự không an toàn tiềm năng. Tuy nhiên, bạn thường phải root để liên kết với các cổng trong phạm vi từ 1-1024, vì vậy thực sự không có gì bạn có thể làm nếu bạn muốn một máy chủ lắng nghe các cổng 80 hoặc 443.

Ngoài ra, nếu một dịch vụ được viết tốt và được cấu hình đúng, bản thân nó không nhất thiết gây bất lợi cho tư thế bảo mật của bạn. Các ứng dụng chạy trên Apache & Nginx thực sự là nguồn tràn bộ đệm thực sự hoặc các cuộc tấn công tiêm nhiễm máy chủ SQL vì các ứng dụng là các dịch vụ phơi bày các điểm nhập dữ liệu không đúng định dạng được đưa vào ngăn xếp máy chủ của bạn.

Bản thân Apache & Nginx, thường không chấp nhận bất kỳ đầu vào nào ngoài các phương thức GET / POST mà họ chấp nhận.


5
"vì vậy thực sự không có bất cứ điều gì bạn có thể làm nếu bạn muốn một máy chủ lắng nghe trên các cổng 80 hoặc 443." Các khả năng của tệp thực sự có thể cung cấp cho tất cả người dùng của một CAP_NET_BIND_SERVICE thực thi nhưng có lẽ bạn chỉ làm điều đó nếu bạn bị hoang tưởng đặc biệt.
Bratchley

6

Đó là cách ứng dụng được đóng gói. Trên hầu hết * nix, thiết lập mặc định là người dùng không có đặc quyền không thể nghe trên một cổng <1024 và các máy chủ web sử dụng 80 và 443.

Mặc dù vậy, Linux 2.2+, Solaris 10+ và FreeBSD đều cho phép người dùng không root có thể nghe trên các cổng thấp hơn 1024, nhưng không phải mặc định. Hầu hết đã chấp nhận sử dụng rootvì vậy nó vẫn được sử dụng.

Khác với quyền truy cập để liên kết với cổng đặc quyền, bạn cần đảm bảo người dùng đang chạy nginx có quyền truy cập vào tất cả các tệp mà họ cần. Bạn có thể không cần phải đi xa như thế này mà chỉ cần đặt quyền chính xác cho các tệp / thư mục. Bạn cũng cần kiểm tra xem các tập lệnh khởi động không làm bất cứ điều gì lén lút như các ulimitthay đổi (như mysql dường như luôn luôn như vậy).

Khả năng của Linux

setcapgetcapcho phép bạn thay đổi hoặc xem cap_net_bind_servicekhả năng thực thi. Điều này sẽ có hiệu lực cho bất cứ ai thực hiện nhị phân.

setcap cap_net_bind_service=+ep /usr/sbin/nginx

SELinux cung cấp khả năng cấu hình và kiểm soát các khả năng ở cấp độ người dùng.

Cài đặt hệ thống Freebsd

Các cài đặt cổng dành riêng là toàn cầu cho hệ thống

sysctl net.inet.ip.portrange.reservedhigh=0
sysctl net.inet.ip.portrange.reservedlow=0

Đặc quyền Solaris

Solaris cung cấp kiểm soát chi tiết tốt các đặc quyền ở cấp độ người dùng. Đây là những đặc quyền cho apache nhưng chúng cũng có khả năng hoạt động cho nginx.

/usr/sbin/usermod -K defaultpriv=basic,proc_exec,proc_fork,net_privaddr nginx

2

Tôi muốn thêm vào câu trả lời của mọi người. Mặc dù nginx được bắt đầu với quyền root, nhưng nó không thực sự chạy bằng root. Người dùng (nginx, www-data, v.v.) mà nó thực sự đang chạy như thường là một đăng nhập bị hạn chế / bị bỏ tù (bạn không thể đăng nhập với nó, chỉ có thể truy cập một số tệp nhất định). Đây là một trong những ưu điểm của việc sử dụng Linux cho các máy chủ web trái ngược với Windows. Quá trình này được gọi là fork( bạn có thể tìm thêm chi tiết trong bài viết Wikipedia này ) và nó cũng sử dụng setuidvà / hoặc setgid( cũng được giải thích trong một bài viết Wikipedia) để thay đổi người dùng và / hoặc nhóm. Trong một thiết lập an toàn, tin tặc sẽ không thể truy cập quy trình cha mẹ và sử dụng tài khoản root. Điều này không phải lúc nào cũng đúng vì tin tặc có thể sử dụng một số loại khai thác để có quyền truy cập root (có một lỗ hổng trong nginx 1.4.0 trở xuống cho phép tin tặc có quyền truy cập root).


1
> Đây là một trong những ưu điểm của việc sử dụng Linux cho các máy chủ web trái ngược với Windows. Xin lỗi, nhưng tôi không mua lập luận đó. Windows cũng cho phép các tài khoản dịch vụ với đăng nhập tương tác bị vô hiệu hóa và cũng hỗ trợ ACL. Điều đó nói rằng, có những lý do khác mà Apache httpd và Nginx không nên chạy trên Windows (ưu tiên IIS) mà không giảm nhẹ các tình huống, nhưng đó là vấn đề bên cạnh vấn đề ở đây.
Bob
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.