멀티 사이트 호스팅-서로 사이트를 보호하기 위해 중요한 취약점이 누락 되었습니까?

편집 # 2 2015 년 7 월 23 일 : 아래 설정에서 누락 된 중요한 보안 항목을 식별하거나 모든 내용이 포함되어 있다고 믿을만한 이유를 제시 할 수있는 새로운 답변을 찾고 있습니다.

편집 # 3 2015 년 7 월 29 일 : 특히 보안 제한을 우회하거나 악의적이지만 오픈 된 채로 남길 수있는 것을 실수로 허용하는 것과 같은 잘못된 구성을 찾고 있습니다.

이것은 다중 사이트 / 공유 호스팅 설정이며 공유 Apache 인스턴스 (예 : 하나의 사용자 계정으로 실행)를 사용하지만 다른 사이트의 파일에 액세스 할 수있는 사이트가 없도록 PHP / CGI가 각 웹 사이트의 사용자로 실행되도록하고 싶습니다. 빠뜨린 부분이 없는지 확인하십시오 (예 : 심볼릭 링크 방지에 대해 알지 못한 경우).

여기까지 내가 가진 것입니다 :

• PHP 스크립트가 웹 사이트의 Linux 사용자 계정 및 그룹으로 실행되고 감옥 (예 : CageFS 사용)이거나 최소한 Linux 파일 시스템 권한을 사용하여 올바르게 제한되어 있는지 확인하십시오.
• suexec를 사용하여 CGI 스크립트를 Apache 사용자로 실행할 수 없도록하십시오.
• shtml 파일과 같은 서버 측 포함 지원이 필요한 경우 Options IncludesNOEXECCGI가 예상하지 못한 상태에서 실행될 수 없도록 CGI를 실행할 수 없도록합니다 (suexec를 사용하는 경우 큰 걱정거리는 아니지만).
• 해커가 Apache가 다른 웹 사이트의 파일을 일반 텍스트로 제공하고 DB 암호와 같은 악용 가능한 정보를 공개하도록 속일 수 없도록 symlink 공격 보호 기능을 갖추십시오.
• 해커가 악용 할 수없는 지시문 만 허용하도록 AllowOverride/ AllowOverrideList를 구성하십시오 . 위의 항목을 올바르게 수행하면 걱정할 필요가 없습니다.

MPM ITK가 느리지 않고 루트로 실행되지 않으면 MPM ITK와 함께 갔지만 공유 Apache를 사용하고 싶지만 안전하게 완료되었는지 확인하고 싶습니다.

http://httpd.apache.org/docs/2.4/misc/security_tips.html을 찾았 지만이 주제에 대해서는 포괄적이지 않았습니다.

도움이된다면 CageFS 및 mod_lsapi와 함께 CloudLinux를 사용할 계획입니다.

확인하거나 알아야 할 다른 것이 있습니까?

2015 년 7 월 20 일 편집 : 사람들은 일반적으로 가치있는 대체 솔루션을 제출했지만이 질문은 공유 Apache 설정의 보안에만 관한 것입니다. 특히 한 사이트에서 다른 사이트의 파일에 액세스하거나 다른 사이트를 손상시킬 수있는 위에 포함되지 않은 내용이 있습니까?

감사!

지금까지 가지고 계신 아이템에 전적으로 동의합니다.

나는 몇 년 전에 그런 다중 사용자 설정을 실행했으며 기본적으로 동일한 절충점을 발견했습니다 .mod_php는 빠르며 (부분적으로 모든 것이 동일한 프로세스 내에서 실행되기 때문에) suexec는 느리지 만 안전합니다 (모든 요청이 새로운 포크를 가지기 때문에) 방법). 사용자 격리가 필요했기 때문에 suexec와 함께갔습니다.

현재 고려해야 할 세 번째 옵션이 있습니다. 모든 사용자에게 고유 한 php-fpm 데몬을 제공하십시오. 이것이 가능한지 여부는 사용자 수에 따라 달라집니다. 모든 사용자는 자신의 사용자 계정을 사용하여 하나 이상의 php-fpm 프로세스를 가져와야합니다 (데몬은 프리 포크와 같은 메커니즘을 사용하여 요청의 규모를 조정하므로 프로세스 수와 메모리 사용량이 제한 요인 일 수 있습니다. 또한 자동 구성 생성이 필요하지만 몇 가지 셸 스크립트를 사용하여 수행 할 수 있습니다.

대규모 환경에서는이 방법을 사용하지 않았지만 IMHO는 프로세스 수준에서 사용자를 격리 시키면서도 우수한 PHP 웹 사이트 성능을 제공하는 좋은 솔루션입니다.

지금까지 가지고있는 모든 것이 잘 생각 된 것 같습니다. 내가 문제로 볼 수있는 유일한 것은 대부분의 익스플로잇이 어떤 방식 으로든 루트 액세스 권한을 얻으려고한다는 사실입니다. 따라서 각 사이트와 해당 프로세스 및 스크립트가 올바르게 감옥에 있고 모든 사용자가 자신의 사용자를 가지고 있고 루트를 가진 해커가 덜 신경 쓰지 못하는 권한이 있어도 설정 한 모든 것을 회피 할 수 있습니다.

내 제안은 일종의 VM 소프트웨어 (VMware, VirtualBox, Qemu 등)를 사용하여 각 사이트에 자체 OS 감옥을 제공하는 것입니다. 이를 통해 시스템 관리자는 하나의 손상된 사이트에 대해 걱정할 필요가 없습니다. 해커가 사이트 VM에서 PHP (또는 다른 소프트웨어)를 악용하여 루트를 얻는 경우 VM을 일시 중지하고 나중에 해부하거나 수정 사항을 적용하거나 중단되지 않은 상태로 롤백합니다. 또한 사이트 관리자는 특정 소프트웨어 또는 보안 설정을 특정 사이트 환경 (다른 사이트를 손상시킬 수 있음)에 적용 할 수 있습니다.

이것에 대한 유일한 제한은 하드웨어이지만 괜찮은 서버와 올바른 커널 확장으로 처리하기 쉽습니다. 호스트와 게스트가 모두 매우 희박하다는 점을 감안할 때 Linode에서 이러한 유형의 설정을 성공적으로 실행했습니다. 내가 생각하는 명령 줄에 익숙하다면 아무런 문제가 없어야합니다.

이 유형의 설정은 모니터링해야하는 공격 경로의 수를 줄이고 Host Machines 보안에 중점을두고 사이트별로 다른 모든 항목을 처리 할 수 ​​있습니다.

각 사이트를 자체 Apache 데몬으로 실행하고 Apache를 chrooting하는 것이 좋습니다. Apache chroot 환경에 / bin / sh에 대한 액세스 권한이 없으므로 모든 시스템 PHP 기능이 실패합니다. 이것은 또한 php의 mail () 함수도 작동하지 않는다는 것을 의미하지만, 외부 메일 공급자를 사용하여 전자 메일 응용 프로그램에서 메일을 발송하는 경우 문제가되지 않습니다.

SELinux가 도움이 될 수 있습니다 mod_selinux. 빠른 하우투가 여기에 있습니다 :

SELinux를 사용하여 PHP 스크립트를 제한하려면 어떻게해야합니까?

지침이 약간 오래되어서 RHEL 7.1에서 작동하는지 확인했습니다.

내가 사용했습니다 페도라 19의 버전 및 RHEL 7.1 + EPEL에 대한 모의 컴파일.

기본 epel 구성 모의 선박을 사용하는 경우 YMMV :

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

대상 시스템을 먼저 업그레이드하여 selinux-policy최신 상태 인지 확인하십시오 .

대상 상자에 설치하거나 로컬 미러에 먼저 설치하십시오.

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

이제 아파치의 각 가상 호스트에 카테고리를 지정해야합니다. 아래 예제와 같이 행을 추가하면됩니다 selinuxDomainVal.

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

그런 다음 각 호스트의 문서 루트에서 문서 루트의 레이블을 httpd 구성에 레이블이 지정된 것과 동일한 범주로 다시 지정하십시오.

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

시스템 레이블을 다시 지정하여 레이블을 적용하려면 로컬 정책도 업데이트하는 것이 좋습니다!

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

이미 제공된 좋은 기술 답변이 많이 있습니다 ( https://security.stackexchange.com/q/77/52572 및 LAMP 서버 보안을위한 팁 ). 여기서 여전히 언급하고 싶습니다. 보안에 대한 중요한 관점 (또 다른 관점에서) : 보안은 프로세스 입니다. 나는 당신이 이것을 이미 고려했다고 확신하지만, 나는 때때로 그것을 다시 생각하는 것이 유용 할 수 있기를 바랍니다 (다른 독자들에게도).

예를 들어, 귀하는 주로 기술적 조치에 집중합니다. "이 질문은 공유 된 Apache 설정의 보안에만 초점을 맞추고 있습니다. 특히 공유를 실행할 때 수행해야하지만 위 목록에서 누락 된 보안 단계가 있습니까? 아파치와 PHP. "

여기에 언급 된 거의 모든 답변과 내가 언급 한 다른 두 가지 질문에도 순수한 기술적 인 것으로 보입니다 (업데이트 유지 권장 사항 제외). 그리고 제 관점에서 이것은 독자에게 오해의 소지가있는 인상을 줄 수 있습니다. 일단 모범 사례에 따라 서버를 구성하면 영원히 보안을 유지할 수 있습니다. 따라서 답변에서 놓친 요점을 잊지 마십시오.

1. 우선, 보안은 프로세스 이며 특히 ISO 27001 ( http://www.isaca.org/ Journal / archives / 2011 / Volume-4 / Pages / Planning-for-and-Implementing-ISO27001.aspx ). 기본적으로 이는 보안 조치를 정기적으로 수정하고 업데이트 및 테스트해야 함을 의미합니다. .

2. 시스템을 정기적으로 업데이트하십시오. 이는 제로 데이 취약점을 사용한 표적 공격에는 도움이되지 않지만 거의 모든 자동 공격에 대해서는 도움이됩니다.

3. 시스템을 모니터링하십시오. 나는 대답 에서이 요점을 정말로 놓쳤다. 내 관점에서 볼 때 시스템의 문제에 대해 가능한 빨리 알리는 것이 매우 중요합니다.

   통계에 따르면 "침입에서 발견까지의 평균 시간은 173.5 일"( http://www.triumfant.com/detection.html ), "감지 전 205 개의 중앙 일 수"( https : // www2)입니다. .fireeye.com / rs / fireye / images / rpt-m-trends-2015.pdf ). 그리고이 숫자가 우리 모두가 원하는 것이 아니기를 바랍니다.

   서비스 상태 (Nagios 등)를 모니터링 할뿐만 아니라 침입 탐지 시스템 (OSSEC, Snort) 및 SIEM 시스템 (OSSIM, Splunk)을위한 많은 솔루션 (무료 포함)이 있습니다. 너무 복잡해지면 적어도 'fail2ban'과 같은 것을 활성화하거나 로그를 별도의 syslog 서버에 전달하고 중요한 이벤트에 대한 전자 메일 알림을받을 수 있습니다.

   여기서 가장 중요한 점은 어떤 모니터링 시스템을 선택 하는가가 아니라 가장 중요한 점은 "플랜-도-조치-조치"주기에 따라 모니터링하고 정기적으로 수정하는 것 입니다.

4. 취약점에주의하십시오. 모니터링과 동일합니다. Apache 또는 설정에 중요한 기타 서비스에 대한 일부 중요한 취약점이 발견되면 알림을 받으려면 일부 취약점 목록을 구독하십시오. 목표는 다음 계획 업데이트 전에 나타나는 가장 중요한 사항에 대한 알림을받는 것입니다.

5. 사고 발생시해야 할 일을 계획하십시오 ( "계획 점검 행위"주기에 따라 정기적으로 업데이트하고 수정하십시오). 보안 구성에 대한 질문을하면 시스템 보안이 중요하다는 의미입니다. 그러나 모든 보안 조치에도 불구하고 시스템이 해킹당한 경우 어떻게해야합니까? 여기서도 "OS 재설치"와 같은 기술적 조치 만 의미하는 것은 아닙니다. 해당 법률에 따라 사고를 어디에보고해야합니까? 서버를 즉시 종료 / 연결 해제 할 수 있습니까 (회사 비용은 얼마입니까)? 주요 책임자가 휴가 / 병에 걸린 경우 누구에게 연락해야합니까?

6. 백업, 아카이브 및 / 또는 교체 / 복제 서버가 있어야합니다. 보안은 또한 서비스 가용성을 의미합니다. 백업 / 아카이브 / 복제를 정기적으로 점검하고 정기적으로 복원 절차를 테스트하십시오.

7. 침투 테스트? (다시 "계획 점검 행위"주기를 참조하십시오.) 너무 많이 느껴지면 최소한 무료 온라인 도구를 사용하여 웹 서비스에서 맬웨어 및 보안 문제를 검사 할 수 있습니다.

사용 사례는 도커 컨테이너에 이상적입니다.

각 컨테이너는 보안을 강화하기 위해 각 Apache 컨테이너 그룹에 고유 한 사용자 ID가 할당 된 고객 또는 클라이언트를 나타낼 수 있습니다. 핵심은 아파치 스택을 시작하기 전에 컨테이너 시작에 대한 루트 권한을 삭제하는 것입니다. 각 고객은 수십 개의 가상 머신을 세워야하는 번거 로움없이 고유 한 비밀번호를 사용하여 고유 한 DB 서비스를받습니다. 각 가상 머신에는 고유의 특수 눈송이 커널 및 기타 오버 헤드가 필요합니다. 결국, 도커의 중심에는 chroot가 있습니다. 제대로 관리하면 매일 일반적인 가상 클러스터를 넘어 섭니다.

여기에 좋은 제안이 많이 있습니다. 그러나 지금까지 토론에서 놓친 것들이 있습니다.

웹 페이지 제공의 일부로 실행되는 프로세스 이외의 프로세스에주의하십시오. 즉, 신뢰할 수없는 데이터를 건 드리는 모든 cron 작업이 해당 작업이 사용자에 의해 정의되었는지 여부에 관계없이 적절한 사용자 및 적절한 교도소에서 실행되고 있는지 확인하십시오.

내 경험에 따르면 호스팅 서비스에서 제공하는 로그 분석과 같은 것은 거의 루트로 실행되지 않으며 로그 분석 소프트웨어에는 원하는만큼 보안 감사가 제공되지 않습니다. 이 작업을 수행하는 것은 약간 까다 롭고 설정에 따라 다릅니다. 한편으로, 루트 소유 (즉, 부모 프로세스) 아파치 프로세스가 사용자가 손상시킬 수있는 디렉토리에 쓰는 것을 원하지 않습니다. 아마도 감옥에 직접 글을 쓰지 않는 것입니다. 반면에 분석을 위해 감옥에서 프로세스에 해당 파일을 사용할 수 있도록해야하며 가능한 한 실시간에 가깝게 만들어야합니다. 로그로 파일 시스템의 읽기 전용 마운트에 감옥에 액세스 할 수 있다면 좋을 것입니다.

PHP 앱은 일반적으로 자체 정적 파일을 제공하지 않으며 공유 아파치 프로세스가있는 경우 아파치 프로세스가 호스트 환경에서 감옥에서 물건을 똑바로 읽고 있다고 추측하고 있습니까? 그렇다면 다양한 우려가 제기됩니다.

.htaccess파일은 당신이 허용하는 것을 매우 조심해야하는 명백한 것입니다. 대부분의 실질적인 PHP 앱은 계획된 계획을 어지럽히 지 않고는 허용 할 수없는 .htaccess 파일 배열에 크게 의존합니다.

아파치가 어쨌든 정적 파일을 결정하는 방법은 덜 분명합니다. 예를 들어, 그것이 무엇을 할 않는 *.php.gif또는*.php.en 파일로 무엇을합니까? 이 메커니즘이나 다른 메커니즘이 정적 파일이 무엇인지에 대한 차별을 속이는 경우 아파치가 감옥 밖에서 PHP를 전혀 실행할 수 있습니까? 정적 콘텐츠에 대해 별도의 경량 웹 서버를 설정했는데, 동적 콘텐츠를 실행하기위한 모듈로 구성되지 않았으며 정적 서버로 보낼 요청과 동적 서버로 보낼 요청을 결정하는로드 밸런서가 있습니다.

Stefan의 Docker 제안과 관련하여 컨테이너 외부에 있고 하나의 웹 서버가 동적 콘텐츠를 위해 각 컨테이너의 php 데몬과 대화하는 동시에 Docker 컨테이너에있는 두 번째 웹 서버가 있으며 이는 각 콘텐츠에 사용하는 볼륨을 공유하므로 정적 콘텐츠를 제공 할 수 있으며 이는 이전 단락과 거의 동일합니다. 다양한 교도소 유형 접근 방식 중 도커를 추천하지만,이 또는 다른 교도소 유형 접근 방식을 사용하면 다른 많은 문제가 발생합니다. 파일 업로드는 어떻게 작동합니까? 각 컨테이너에 파일 전송 데몬을 넣습니까? PAAS 스타일 git 기반 접근 방식을 취하십니까? 컨테이너 내부에서 생성 된 로그에 액세스 할 수있게하려면 그들을 롤오버? 크론 작업을 어떻게 관리하고 실행합니까? 사용자에게 모든 종류의 셸 액세스 권한을 부여 하시겠습니까? 그렇다면 컨테이너 내의 다른 데몬입니까? 등

내가 보지 못하는 첫 번째 프로세스는 프로세스 관리이므로 한 프로세스는 다른 프로세스의 CPU 또는 RAM (또는 그 문제에 대한 I / O를 굶주릴 수는 없지만 파일 시스템이이를 방지하도록 설계되었지만)을 굶주릴 수는 없습니다. PHP 인스턴스에 대한 "컨테이너"접근 방식의 한 가지 주요 이점과 하나의 "OS"이미지에서 모두 실행하려고하면 리소스 사용률을보다 효과적으로 제한 할 수 있다는 것입니다. 나는 그것이 당신의 디자인이 아니라는 것을 알고 있습니다.

어쨌든, 기본적으로 Apache로 작동하는 PHP의 유스 케이스로 돌아가서 프록시로 작동합니다. suexec는 아파치 사용자로 무언가가 실행되는 것을 막지 않으며 다른 사용자로 실행할 수있는 기능 을 제공합니다 . : 그것에 대한 문서 페이지는 위험이 있음을 호출 - 그래서 하나 개의 관심사는 모두 제대로 확인하십시오하게 될 것입니다 https://httpd.apache.org/docs/2.2/suexec.html . 알다시피, 소금 알갱이와 그 모든 것.

보안 관점에서 그들이 다르게 또는 다른 라이브러리에 대해 컴파일하는 경우 특히, (공급 cagefs)와 작업에 대한 사용자 바이너리의 제한된 집합을하는 것이 도움이 될 수 있습니다 (예 : 원치 않는있는 기능을 포함하지 않는 한) 하지만 그 시점에서 더 이상 알려진 업데이트 배포판을 따르지 않고 PHP 설치에 대해 다른 배포판 (cagefs)을 따르고 있습니다 (적어도 사용자 공간 도구와 관련하여). 아마도 이미 클라우드 리눅스로 특정 배포판을 따르고 있기 때문에 점진적으로 위험하지만 반드시 흥미로울 필요는 없습니다.

AllowOverride를 의도 한 위치에 그대로 두겠습니다. 심층 방어의 핵심 아이디어는 전체 스택을 보호하기 위해 하나의 단일 계층에 의존하지 않는 것입니다. 항상 무언가 잘못 될 수 있다고 가정하십시오. 그럴 때 완화하십시오. 사이트 앞에 울타리가 하나만 있어도 완화 할 때까지 반복하십시오.

로그 관리가 핵심이 될 것입니다. 격리 된 파일 시스템에서 여러 서비스를 실행하는 경우 문제가있을 때 상관 관계를 통합하는 활동을 통합하면 처음부터 설정하지 않은 경우 약간의 고통이 될 수 있습니다.

그건 내 뇌 덤프 야 거기에 막연한 유용한 것이 있기를 바랍니다. :)