짧은 대답 : 예
이 질문에 대한 대답은 명백한 예 이며, 그렇지 않으면 완전히 책임을지지 않습니다 .
긴 대답 : 실제 사례
wp-config.php웹 루트 외부 로 이동 하면 컨텐츠가 캡처되지 않는 실제 서버에서 실제로 실제 예제를 제공 할 수 있습니다.
버그 :
Plesk의 버그에 대한이 설명을 살펴보십시오 (11.0.9 MU # 27에서 수정 됨).
Plesk가 구독 계획과 구독을 동기화 한 후 하위 도메인 전달을 재설정합니다 (117199).
무해한 소리 지?
글쎄, 여기이 버그를 유발하기 위해 한 일이 있습니다.
- 다른 URL로 (예를 들어, 리디렉션 하위 도메인을 설정
site.staging.server.com하는 방법에 대해 site-staging.ssl.server.com).
- 구독 서비스 계획을 변경했습니다 (예 : PHP 구성).
이 작업을 수행했을 때 Plesk는 하위 도메인을 기본값으로 재설정했습니다 ~/httpdocs/.
그리고 나는 몰랐다. 몇 주 동안.
결과:
- 으로
wp-config.php웹 루트에, 요청이하는 /wp-config.php워드 프레스 구성 파일을 다운로드 한 것입니다.
- 으로
wp-config.php웹 루트 외부 요청이하는 /wp-config.php완전히 무해한 파일을 다운로드. 실제 wp-config.php파일을 다운로드 할 수 없습니다.
따라서 wp-config.php웹 루트 외부로 이동 하면 실제 환경에서 실질적인 보안 이점을 얻을 수 있습니다 .
wp-config.php서버의 임의의 위치 로 이동하는 방법
WordPress는 자동으로 WordPress 설치 위의 wp-config.php파일 중 하나의 디렉토리를 자동으로 찾게 되므로 파일이 이동 한 위치가 완성되었습니다!
하지만 다른 곳으로 옮겼다면 어떨까요? 쉬운. wp-config.php다음 코드를 사용하여 WordPress 디렉토리에 새 파일 을 작성하십시오 .
<?php
/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');
/** Location of your WordPress configuration. */
require_once(ABSPATH . '../phpdocs/wp-config.php');
위의 경로를 재배치 된 wp-config.php파일 의 실제 경로로 변경 하십시오.
에 문제가 발생하면 PHP 구성 open_basedir의 open_basedir지시문에 새 경로를 추가하십시오 .
open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"
그게 다야!
반대로 논쟁을 따기
wp-config.php웹 루트 외부로의 이동에 대한 모든 주장 은 잘못된 가정에 달려 있습니다.
인수 1 : PHP가 비활성화되어 있으면 PHP는 이미
누군가가 [ wp-config.php]의 내용이 서버를 우회하는 경우에만 PHP 인터프리터 를 볼 수있는 유일한 방법입니다 ... 이런 일이 발생하면 이미 문제가있는 것입니다.
FALSE : 위에서 설명한 시나리오는 침입이 아니라 잘못 구성된 결과입니다.
인수 2 : 실수로 PHP를 비활성화하는 것은 드물기 때문에 중요하지 않습니다.
공격자가 PHP 처리기를 변경할 수있는 충분한 액세스 권한이 있다면 이미 문제가있는 것입니다. 내 경험상 우발적 인 변경은 매우 드물기 때문에이 경우 암호를 쉽게 변경할 수 있습니다.
FALSE : 위에서 설명한 시나리오는 일반적인 서버 구성에 영향을주는 일반적인 서버 소프트웨어 버그의 결과입니다. 이것은 거의 "드물다"(그리고 보안은 드문 시나리오를 걱정하는 것을 의미한다).
WTF : 침입 후 비밀번호를 변경하면 침입 중에 민감한 정보를 수집 한 경우 거의 도움이되지 않습니다. 실제로 WordPress는 일반적인 블로그 작업에만 사용되며 공격자는 훼손에만 관심이 있다고 생각합니까? 누군가가 들어온 후 복원하는 것이 아니라 서버를 보호하는 것에 대해 걱정합시다.
인수 3 : 접근을 거부하는 wp-config.php것만으로 충분합니다
가상 호스트 구성 .htaccess을 통해 파일에 대한 액세스를 제한 하거나
문서 루트 외부로 이동하는 것과 같은 방식으로 파일에 대한 외부 액세스를 효과적으로 제한 할 수 있습니다.
FALSE : 가상 호스트의 서버 기본값이 PHP 없음 .htaccess, 아니오 , allow from all프로덕션 환경에서는 거의 드문 경우입니다. 예를 들어, 패널 업데이트와 같은 일상적인 작업 중에 구성이 재설정되면 모든 것이 기본 상태로 돌아가고 노출됩니다.
설정이 실수로 기본값으로 재설정 될 때 보안 모델이 실패하면 더 많은 보안이 필요합니다.
WTF : 왜 아무도 보안 계층을 더 적게 추천할까요? 비싼 자동차에는 자물쇠 만있는 것이 아닙니다. 알람, 이모빌라이저 및 GPS 트래커도 있습니다. 보호 할만한 가치가 있다면 올바르게하십시오.
인수 4 : 무단 액세스 wp-config.php는 별 문제가되지 않습니다
데이터베이스 정보는 실제로 [ wp-config.php] 에서 유일하게 민감한 정보입니다 .
FALSE : 인증 키와 솔트는 여러 가지 잠재적 인 하이재킹 공격에 사용될 수 있습니다.
WTF :의 데이터베이스 자격 증명이 유일하다고해도 공격자가 데이터베이스 자격 증명을 얻는 것에 대해 두려워wp-config.php 해야 합니다.
인수 5 : wp-config.php웹 루트 외부로 이동 하면 실제로 서버의 보안 수준이 떨어집니다
여전히 WordPress에 [ wp-config.php] 액세스를 허용 해야하므로 open_basedir문서 루트 위에 디렉토리를 포함 하도록 확장해야 합니다.
FALSE : 가정 wp-config.php에있는 httpdocs/단지로 이동, ../phpdocs/및 설정 open_basedir만을 포함 httpdocs/하고 phpdocs/. 예를 들어 :
open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"
(항상 /tmp/, 또는 사용자 tmp/디렉토리 (있는 경우)를 포함해야합니다.)
결론 : 구성 파일은 항상 항상해야 항상 웹 루트 외부에 수
보안에 신경 쓰면 wp-config.php웹 루트 외부 로 이동 합니다.