왜 nginx가 루트로 프로세스를 시작합니까?

nginx 서버를 설치했습니다. 방금 청취 포트를 확인하고 다음을 보았습니다.

$ 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)
.
.
.

그리고 왜 'www-data'사용자로 실행되고 네 개의 nginx 프로세스가 '루트 사용자'로 실행되는지 관심이 있습니까?

당신이 알아 차린 프로세스는 다른 모든 nginx 프로세스를 시작하는 프로세스 인 마스터 프로세스입니다. 이 프로세스는 nginx를 시작하는 init 스크립트에 의해 시작됩니다. 이 프로세스가 루트로 실행되는 이유는 루트로 시작했기 때문입니다. 다른 사용자로 시작할 수 있지만 nginx에 필요한 모든 리소스를이 사용자가 사용할 수 있는지 확인해야합니다. 일반적으로 최소한 / var / log / nginx이고 / pid / file은 / var / run /입니다.

가장 중요한 것은; 루트 프로세스 만 1024 미만의 포트를 수신 할 수 있습니다. 웹 서버는 일반적으로 포트 80 및 / 또는 443에서 실행됩니다. 즉, 루트로 시작해야합니다.

결론적으로, 루트로 실행되는 마스터 프로세스는 완전히 정상이며 대부분의 경우 정상 작업에 필요합니다.

편집 : 루트로 아무것도 실행하면 암시 적 보안 위험이 따릅니다. 일반적으로 이러한 종류의 소프트웨어 개발자는 공격 경로에 대한 많은 지식을 가지고 있으며 가능한 한 적은 루트를 실행하도록 세심한주의를 기울입니다. 결국 소프트웨어 품질이 좋다는 것을 믿기 만하면됩니다.

여전히 불안한 경우 다른 사용자로 nginx를 실행하고 1024 미만의 포트를 계속 사용하는 방법이 있습니다. iptables를 사용하여 포트 80에서 들어오는 모든 트래픽을 다른 포트 (예 : 8080)로 리디렉션하고 nginx가 해당 포트에서 수신 대기하도록 할 수 있습니다.

대부분의 서버 (Apache, Nginx 등)에는 루트가 소유 한 상위 프로세스가 있으며 덜 권한이있는 사용자를 사용하여 작업자 노드의 사본을 포크합니다. 이 경우에는 www-data입니다.

예

nginx의 구성 파일을 살펴보면 다음 /etc/nginx/nginx.conf과 같은 줄을 알 수 있습니다.

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

대부분의 서버에는 슬레이브 노드를 실행할 사용자 및 서버 수를 지정하는 이와 유사한 옵션이 있습니다.

보안

루트 액세스 권한이있는 서비스를 노출하는 것은 잠재적으로 불안전 한 것으로 종종 언급됩니다. 그러나 종종 1-1024 범위의 포트에 바인딩하려면 루트 여야하므로 서버가 포트 80 또는 443에서 수신 대기하도록하려면 실제로 수행 할 수있는 작업이 없습니다.

또한 서비스가 제대로 작성되고 제대로 구성되어 있어도 보안 상태에 해를 끼치는 것은 아닙니다. Apache & Nginx 위에서 실행되는 응용 프로그램은 실제로 버퍼 오버플로 또는 SQL 서버 주입 공격의 진정한 소스입니다. 응용 프로그램은 잘못된 데이터가 서버 스택에 주입 될 수있는 진입 점을 노출시키는 서비스이기 때문입니다.

Apache & Nginx 자체는 일반적으로 GET / POST 메소드 이외의 입력을 허용하지 않습니다.

응용 프로그램이 패키지되는 방식입니다. 대부분의 * nix에서 기본 설정은 권한이없는 사용자가 1024 미만의 포트에서 청취 할 수 없으며 웹 서버는 80 및 443을 사용합니다.

Linux 2.2 이상, Solaris 10 이상 및 FreeBSD는 모두 루트가 아닌 사용자가 기본적으로가 아니라 1024보다 낮은 포트에서 청취 할 수 있도록합니다. 대부분의 사용을 받아 들여 사용 중 root입니다.

권한있는 포트에 바인딩하기위한 액세스 외에, nginx를 실행하는 사용자가 필요한 모든 파일에 액세스 할 수 있는지 확인해야합니다. 아마도 이것까지는 갈 필요는 없지만 파일 / 디렉토리에 대한 올바른 권한을 설정하십시오. 또한 시작 스크립트가 ulimit변경과 같은 부적절한 행동을하지 않는지 확인해야합니다 (mysql은 항상 그렇습니다).

리눅스 기능

setcap및 getcap변경하거나 볼 수 있도록 cap_net_bind_service실행을위한 기능. 바이너리를 실행하는 모든 사람에게 적용됩니다.

setcap cap_net_bind_service=+ep /usr/sbin/nginx

SELinux는 사용자 수준에서 기능을 구성하고 제어 할 수있는 기능을 제공합니다.

Freebsd 시스템 설정

예약 된 포트 설정은 시스템 전체에 적용됩니다

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

솔라리스 특권

Solaris는 사용자 수준에서 세밀한 권한 제어를 제공합니다. 이것들은 아파치의 특권이지만 nginx에서도 작동합니다.

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

다른 사람의 답변에 추가하고 싶습니다. nginx가 루트로 시작되었지만 실제로 루트로 실행되지는 않습니다. 실제로 실행중인 사용자 (nginx, www-data 등)는 일반적으로 제한 / 자유 로그인 (로그인 할 수 없으며 특정 파일 만 액세스 할 수 있음)입니다. 이것은 Windows와 달리 웹 서버에 Linux를 사용하는 전문가 중 하나입니다. 이 과정은이라고합니다 fork( 당신이 더 많은이 Wikipedia 기사에서 자세한 찾을 수 있으며 또한 용도) setuid및 / 또는 setgid( 또한 위키 백과 문서에 설명되어)를 사용하여 사용자 및 / 또는 그룹을 변경하십시오. 보안 설정에서 해커는 상위 프로세스에 액세스하고 루트 계정을 이용할 수 없습니다. 해커가 루트 액세스 권한을 얻기 위해 일종의 익스플로잇을 이용할 수 있기 때문에 항상 사실이 아닙니다 (nginx 1.4.0 이하의 취약점으로 인해 해커가 루트 액세스 권한을 얻을 수 있음).