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" 사용자로 4개의 nginx 프로세스가 실행되고 "루트 사용자"로 하나가 실행되는 이유가 궁금합니다.
답변1
눈에 띄는 프로세스는 다른 모든 nginx 프로세스를 시작하는 기본 프로세스입니다. 이 프로세스는 nginx를 시작하는 init 스크립트에 의해 시작됩니다. 프로세스가 루트로 실행되는 이유는 단순히 루트로 시작했기 때문입니다! 다른 사용자로 시작할 수 있지만 해당 사용자가 nginx에 필요한 모든 리소스에 액세스할 수 있는지 확인해야 합니다. 일반적으로 최소한 /var/log/nginx 및 /var/run/ 아래의 pid 파일입니다.
가장 중요한 점은 루트 프로세스만 1024 미만의 포트를 수신할 수 있다는 것입니다. 웹 서버는 일반적으로 포트 80 및/또는 443에서 실행됩니다. 이는 루트로 시작해야 함을 의미합니다.
요약하자면, 루트가 실행하는 마스터 프로세스는 완전히 정상적이며 대부분의 경우 정상적인 작동에 필요합니다.
편집: 무엇이든 루트로 실행하면 암묵적인 보안 위험이 발생합니다. 일반적으로 이러한 소프트웨어 개발자는 공격 벡터에 대해 많은 것을 알고 있으며 루트 실행을 가능한 한 적게 수행하도록 세심한 주의를 기울입니다. 결국, 소프트웨어의 품질이 좋다는 것을 신뢰하면 됩니다.
그래도 불안하다면 다른 사용자로 nginx를 실행하고 1024 미만의 포트를 계속 사용하는 방법이 있습니다. iptables를 사용하여 포트 80에서 들어오는 모든 트래픽을 8080과 같은 다른 포트로 리디렉션하고 nginx가 해당 포트에서 수신하도록 할 수 있습니다.
답변2
대부분의 서버(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 메서드 이외의 입력을 허용하지 않습니다.
답변3
이것이 애플리케이션이 패키징되는 방식입니다. 대부분의 *nix에서 기본값은 권한이 없는 사용자가 포트 < 1024에서 수신 대기할 수 없고 웹 서버는 80 및 443을 사용하는 것입니다.
Linux 2.2+, Solaris 10+ 및 FreeBSD에서는 모두 루트가 아닌 사용자가 1024보다 낮은 포트에서 수신 대기할 수 있도록 허용하지만 기본적으로는 그렇지 않습니다. 대부분의 사람들이 그 사용을 승인했기 root때문에 여전히 사용되고 있습니다.
액세스 권한이 있는 포트에 바인딩되는 것 외에도 nginx를 실행하는 사용자가 필요한 모든 파일에 액세스할 수 있는지 확인해야 합니다. 당신은 할 수있다여기까지 갈 필요는 없어하지만 파일/디렉토리에 올바른 권한을 설정하면 됩니다. 또한 시작 스크립트가 비열한 변경을 수행하지 않는지 확인하고 싶을 것입니다 ulimit(예를 들어 mysql은 항상 이렇게 하는 것 같습니다).
리눅스 기능
setcap그리고getcapcap_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는 사용자 수준에서 세분화된 권한 제어를 제공합니다. 이는 Apache에 대한 권한이지만 nginx에도 적용될 수 있습니다.
/usr/sbin/usermod -K defaultpriv=basic,proc_exec,proc_fork,net_privaddr nginx
답변4
다른 사람들의 답변에 추가하고 싶습니다. nginx는 루트로 시작되지만 실제로는 루트로 실행되지 않습니다. 실제로 실행되는 사용자(nginx, www-data 등)는 일반적으로 제한되거나 감옥에 갇힌 로그인입니다(이 계정으로는 로그인할 수 없으며 특정 파일에만 액세스할 수 있습니다). 이는 Windows에 비해 Linux를 웹 서버로 사용하는 장점 중 하나입니다. 이 프로세스를 fork(이 Wikipedia 기사에서 자세한 내용을 확인할 수 있습니다.) 그리고 또한 setuid및/또는 setgid(이는 Wikipedia 기사에도 설명되어 있습니다.) 사용자 및/또는 그룹을 변경합니다. 보안 설정에서는 해커가 상위 프로세스에 액세스하거나 루트 계정을 악용할 수 없습니다. 그러나 이것이 항상 사실인 것은 아닙니다. 해커가 루트 액세스 권한을 얻기 위해 악용할 수 있는 취약점이 있기 때문입니다(nginx 1.4.0 이하 버전에는 해커가 루트 액세스 권한을 얻을 수 있는 취약점이 있습니다).