웹 서버가 전통적으로 수퍼유저로 시작되는 이유는 무엇입니까?

POSIX에는 CAP_NET_BIND_SERVICE를 포함하는 기능 표준이 있지만 이는 유용하지 않습니다.일관성그리고 어떤 면에서는 그럴 수도 있다호환되지 않는Linux와 같은 플랫폼에서 구현됩니다.

Apache와 같은 웹 서버는 단일 플랫폼용으로 작성되지 않기 때문에 루트 권한을 사용하는 것이 가장 이식성이 뛰어난 방법입니다. 나는 이것이 Linux와 BSD(또는 지원이 감지되는 모든 곳)에서 특별히 수행될 수 있다고 생각하지만 이는 동작이 플랫폼 등에 따라 달라질 수 있음을 의미합니다.

내 생각에는 모든 웹 서버가 이런 방식으로 사용될 수 있도록 시스템을 구성할 수 있는 것 같습니다. 다음은 이 WRT 아파치에 대한 몇 가지(아마도 서투른) 제안 사항입니다.루트가 아닌 포트 바인딩.

그렇다면 그들은 왜전통적으로나중에 관련된 암묵적인 보안 문제를 제거하기 위해 모든 작업이 완료되면 루트로 부팅하시겠습니까?

일반적으로 권한 있는 포트에 대한 액세스가 필요하기 때문에 루트로 시작합니다.전통적으로이것이 유일한 방법입니다. 나중에 다운그레이드하는 이유는 권한이 필요하지 않고 서버에서 일반적으로 사용되는 수많은 타사 추가 기능으로 인한 잠재적 피해를 제한하기 때문입니다.

권한 있는 활동은 매우 제한되어 있고 관례에 따라 다른 inet 데몬(예: sshd)을 포함하여 다른 많은 시스템 데몬이 루트로 계속 실행되기 때문에 이는 무리한 일이 아닙니다.

CAP_NET_BIND_SERVICE를 사용하여 권한 없는 사용자로 실행할 수 있도록 서버를 패키지화한 경우어느HTTP(S) 서비스를 시작하는 권한이 없는 사용자는 더 큰 위험을 초래할 수 있습니다.

Unix 기반 시스템에서 권한 있는 포트를 수신하는 서비스에는 시스템 관리자 권한이 필요합니다. 이는 신뢰할 수 있는(적어도 관리자) 사용자가 서비스를 실행하고 있음을 나타냅니다. 이러한 서비스의 사용자는 서버 응용 프로그램에 대한 일부 관리 감독이 있음을 신뢰할 수 있습니다. 이 신뢰의 가치는 지난 수십 년 동안만큼 크지 않을 수도 있습니다.

많은 웹 서버는 권한 없는 사용자로 시작하고 실행하는 데 필요한 기능을 지원하지 않는 이전 운영 체제 커널에서 실행됩니다. 필요한 커널 변경 사항은 비교적 새로운 것이며 운영 체제 커널 전반에 걸쳐 표준화되지 않았습니다. 이러한 환경에서는 소프트웨어를 조건부로 컴파일할 수 있습니다. 그러나 이러한 변경 사항은 대부분의 플랫폼에서 작동하지 않으며 완전히 테스트되지 않았거나 예상만큼 안전하지 않을 수 있습니다.

데몬은 일반적으로 루트 액세스가 필요한 모든 작업을 수행하기 위해 루트로 실행된 다음 권한이 없는 UID로 전환합니다. 이렇게 하면 프로그램이 실행된 후 너무 많은 피해를 입히는 것을 방지하면서 리소스를 보호할 수 있습니다. 웹 서버의 경우 악성 서버 애플리케이션이 SSL 키를 읽지 못하도록 보호해야 하지만, SSL 리스너를 구성하려면 SSL 키를 읽어야 합니다. 분할 권한을 사용하면 리소스에 대한 분할 브레인 액세스가 가능해 보안을 크게 향상시키는 데 사용할 수 있습니다.

웹 서버를 감옥에 가두는 것이 가능하더라도 많은 시스템에서 감옥에는 파일 시스템의 상당 부분이 포함될 수 있습니다. 이는 구성하기 어렵고 오류가 발생하기 쉬울 수 있습니다. 애플리케이션을 감옥에 넣는 것은 일반적으로 더 안전한 구성을 의미합니다. 이 경우 잘못된 교도소 구성의 위험으로 인해 이 신뢰가 잘못 배치될 수 있습니다. 감옥이 없더라도 접근 문제를 진단하는 것은 어려울 수 있습니다. 대규모 파일 시스템을 감옥에서 보호하는 것은 훨씬 더 어렵습니다.

웹 서버를 루트로 시작하는 데는 여러 가지 이유가 있습니다.

• 포트 80에 바인딩합니다(1024 미만의 포트는 루트용으로 예약되어 있으므로 원격 사용자가 낮은 포트의 서비스에 연결하면 해당 서비스가 루트에서 승인되었음을 알 수 있습니다).
• chroot와 같은 제한 사항을 설정합니다.
• 해당되는 경우 사용자의 웹페이지를 읽고 제공합니다.

가장 덜 중요한 이유는 부적절한 설정입니다. 이러한 설정을 보호하는 가장 쉬운 방법은 사용자에게 페이지를 공개하도록 요구하는 것입니다. 이는 사용자가 액세스 제어가 가능한 개인 웹 페이지를 원할 때 작동하지 않습니다(예를 들어 교수는 네트워크를 통해 시험 텍스트를 공유하고 싶지만 학생들이 대학 컴퓨터에서 볼 수 없도록 하려는 경우). 이 경우에는 보다 정교한 접근 방식이 필요합니다(예: 웹 서버가 해당 페이지를 읽을 수 있도록 허용하는 ACL이 웹 페이지에 있어야 함).

루트로 시작된 웹 서버는 일반적으로 루트로만 시작된 후 전용 사용자로 권한이 축소됩니다. 권한을 포기하기 전에 포트 80을 바인딩하고 일부 파일(예: SSL 개인 키 파일)을 읽고 다른 억제를 수행할 수도 있습니다.

[왜 안되나요] 실행 중인 바이너리에서 with를 사용합니까 setcap(8)?CAP_NET_BIND_SERVICE

이는 가능하지만 해당 기능을 지원하는 시스템이 필요합니다. 이는 Unix의 역사와 관련하여 비교적 새로운 것이며, 심지어 웹 서버의 역사와 관련하여서도 그렇습니다.

[왜 안되나요] (루트가 아닌) 사용자가 거기에 쓸 수 있도록 로그 폴더를 설정합니까?

일반적으로 이 작업은 수행됩니다. 그렇지 않으면 웹 서버 프로세스는 Unix 또는 인터넷 소켓을 통해 로깅 데몬에 기록합니다.

[안되는 이유] chroot가 도움이 된다면 chroot나 lxc를 사용하여 웹 서버를 "감금"하시겠습니까?

이는 웹 서버가 SSL 개인 키와 같은 모든 구성 파일을 읽을 수 있음을 의미합니다. 때때로 취약점으로 인해 원격 공격자가 임의의 파일을 검색할 수 있습니다. 서버가 구성 파일에 액세스하지 못하도록 제한하면 이러한 상황에서 노출을 피할 수 있습니다.

대부분의 UNIX 시스템의 한 가지 약점은 권한이 없는 프로세스가 벗어날 수 없는 제한 영역을 설정하는 것을 허용하지 않는다는 것입니다. Linux에서는 이것이 가능합니다.커널 3.8의 네임스페이스 개선, 아직 널리 사용되지는 않습니다.