Debian + Nginx/Unicorn 권한

Debian + Nginx/Unicorn 권한

Unicorn과 같은 웹 서버를 루트로 실행하면 보안 위험이 있습니까?

Nginx 마스터 프로세스는 루트로 실행되고 Nginx 작업자 프로세스는 제한된 www-data 사용자로 실행되지만 www-data의 PATH.

답변1

Unicorn과 같은 웹 서버를 루트로 실행하면 보안 위험이 있습니까?

Thomas가 sec.se 채팅에서 말했듯이,아무것루트에는 숨겨진 보안 위험이 있기 때문입니다. 루트에 대해 이해해야 할 한 가지는 커널이 기본적으로 자신이 수행하는 모든 것을 신뢰하고 불평하지 않는다는 것입니다.

이 문제는 nginx 또는 unicorn에 취약점이 있는 경우 발생합니다. 이런 일이 발생하면가능한악용 및 남용 프로세스를 수행할 수 있습니다.

그러나 악용 벡터가 무엇인지 이해하려면 이러한 서버의 작동 방식을 이해하는 것이 중요합니다. 이론적으로 루트 권한을 보유하려면 구성 읽기와 bind()작동(서버 포트 < 1023이라고 가정)이라는 두 부분을 수행해야 합니다.

unicorn은 사전 포크된 모델로 작동합니다(gunicorn이 유사하다고 가정). 각 클라이언트 요청은 별도의 프로세스에서 처리됩니다. 루트로 실행되는 프로세스의 작업은 필요한 포트에 바인딩한 다음 연결을 작업자 프로세스에 전달하는 것입니다. 작업자 모델은 스레드와 프로세스를 혼합합니다. 내가 이해한 바에 따르면 nginx는 매우 비슷한 방식으로 작동하지만 비동기 IO에 더 큰 편향이 있습니다. epoll// 나는 믿습니다 kqueue. accept당신이 보면c10k 문제를 해결하기 위한 전략그렇기 때문에 디자인은 그런 식으로 작동합니다.

이론적으로 대부분의 작업자 프로세스는 루트 권한을 포기할 수 seteuid()있고 포기해야 합니다. seteguid()이러한 프로세스가 모든 트래픽을 루트로 처리하지 않으면 문제가 발생합니다. 대부분의 프로세스는 루트 권한을 포기합니다. 나는 또한 두 가지 분명한 진술을 해야 합니다:

  1. 1024 미만의 포트에 바인딩하지 않는 경우 루트가 아닌 다른 것으로 실행되도록 nginx 데몬을 구성할 수 있습니다.
  2. 제 경우에는 유니콘(gunicorn)을 구성하여 소켓 파일을 생성할 수 있습니다. 즉, 루트로 실행할 필요가 없습니다. nginx는 웹 요청을 Unix 소켓으로 프록시할 수 있습니다. 즉, gunicorn은 절대로 TCP 연결을 노출하지 않습니다.

코드의 "취약한 부분"~해야 한다따라서 이는 구성 파일을 구문 분석하고 연결을 전환하는 것과 같습니다.이론적으로따라서 이 방법이 효과가 있고 엄격한 테스트를 거쳤다고 가정하면 루트에 걸릴 위험은 매우 적습니다.

POSIX 기능루트 기능 중 일부를 다른 프로세스에 위임하는 다른 방법입니다( CAP_NET_BIND_SERVICE예를 들어 setuid 비트 제외). 프로세스가 루트가 아니더라도 1024 미만의 포트에 바인딩할 수 있습니다. 나는 그들이 속성을 확장함으로써 작동한다고 믿습니다. Fedora는 최근(f16?) 모든 패키지가 고정 비트 대신 기능을 사용하도록 보장하기 시작했습니다.

주목할만한 또 다른 점은 긍정적인 점입니다. 유니콘은 제가 올바르게 이해했다면 루비 프로세스입니다(군니콘은 확실히 파이썬 프로세스입니다). 해석된 언어를 사용하면 문자열 처리가 확실히 안전하고 포인터를 사용할 수 없으므로 개발자가 버그를 도입할 위험이 줄어듭니다. 그러나 인터프리터 버그는 모든 인터프리터에게 보안 위험을 초래할 수도 있습니다.

그러나 불행한 현실은 손상된 프로세스가 www-data여전히 문제가 될 수 있다는 것입니다. 공격자가 데이터베이스를 덤프하고 웹 사이트를 손상시킬 수 있습니다. 루트가 안전하다는 것을 아는 것은 좋지만 웹사이트가 고객에게 주요 광고 지점인 경우 루트가 손상되는 것은 여전히 ​​비즈니스에 위협이 될 수 있습니다.

일반화하다

예, 유니콘을 루트로 실행하는 것은 위험합니다. 그러나 루트로 실행되는 코드의 측면에서는 공격 표면이 상대적으로 작습니다. 또한 루트로 실행 중인 작업을 최소화하는 옵션이 있을 수도 있습니다. 또한 SELinux와 같은 MAC 시스템도 다루지 않았지만 배울 준비가 되었다고 가정하면 실행 가능한 옵션과 기능입니다. 이해해야 할 중요한 점은 위험은 균형이라는 것입니다. 서비스가 얼마나 민감하고 중요한지에 따라 이를 보호하기 위해 얼마나 많은 노력을 기울여야 하는지가 결정됩니다. 은행 웹사이트를 운영하고 있다면 시스템을 강화하는 방법을 심각하게 고려할 수 있습니다. Lollcat 이미지를 호스팅하는 사이트라면(무슨 말인지 아시겠지만) 현재 설정이 괜찮다고 생각할 수도 있습니다.

관련 정보