it-swarm-ko.tech

Wp-config를 웹 루트 외부로 옮기는 것이 정말 유익한가요?

요즘 가장 보편적 인 보안 베스트 프랙티스 중 하나는 가상 호스트의 문서 루트보다 한 디렉터리 wp-config.php만큼 이동하는 것 같습니다 . 필자는 그것에 대한 좋은 설명을 찾지 못했지만 웹 루트 내에서 악성 또는 감염 스크립트가 데이터베이스 비밀번호를 읽지 못하도록하는 위험을 최소화한다고 가정합니다.

그러나 WordPress에 액세스 권한을 부여해야하므로 문서 루트 위에 디렉토리를 포함하려면 open_basedir를 확장해야합니다. 그렇게하면 전체 목적을 달성하지 못하고 잠재적으로 서버 로그, 백업 등을 공격자에게 노출시킬 수 있습니까?

아니면 wp-config.php가 PHP 엔진으로 구문 분석되는 대신 http://example.com/wp-config.php을 (를) 요청하는 모든 사람에게 일반 텍스트로 표시되는 상황을 방지하기위한 기술입니까? 매우 드물게 발생하는 것으로 보입니다. 로그/백업/etc를 HTTP 요청에 노출시키는 단점을 능가하지는 않습니다.

어쩌면 다른 설정이 아닌 다른 파일을 노출하지 않고 일부 호스팅 설정에서 문서 루트 외부로 이동할 수 있습니까?


결론 :이 문제에 대해 많은 논의가 있은 후에 권위있는 것으로 생각되어야한다고 생각하는 두 가지 대답이 나타났습니다. Aaron Adams는 wp-config를 움직이는 것이 좋을 것입니다. chrisguitarguy는 좋은 경우입니다. 당신이 스레드에 익숙하지 않고 전체 내용을 읽지 않으려는 경우 두 가지 대답을 읽어야합니다. 다른 답변은 중복되거나 부정확합니다.

131
Ian Dunn

짧은 대답 : 예

이 질문에 대한 답은 명백한 yes이며, 그렇지 않으면 완전히 무책임한입니다.


긴 대답 : 실제 사례

웹 루트 외부로 _wp-config.php_을 이동시키는 실제 서버에서 매우 실제적인 예를 제공하겠습니다. 특히 내용이 캡처되지 않음.

버그 :

Plesk의 버그에 대한이 설명을 살펴보십시오 (11.0.9 MU # 27에서 수정 됨).

Plesk가 구독 계획과 구독을 동기화 한 후 하위 도메인 전달을 재설정 함 (117199)

무해한 소리 지?

글쎄, 여기이 버그를 유발하기 위해 한 일이 있습니다.

  1. 다른 URL로 리디렉션하도록 하위 도메인을 설정하십시오 (예 : _site.staging.server.com_에서 _site-staging.ssl.server.com_).
  2. 구독 서비스 계획을 변경했습니다 (예 : PHP 구성).

내가 이것을했을 때, Plesk는 서브 도메인을 기본값으로 재설정했다 : 통역사 (예 : PHP)가없는 _~/httpdocs/_의 내용을 제공.

그리고 나는 몰랐다. 몇 주 동안.

결과:

  • 웹 루트에 _wp-config.php_가 있으면 _/wp-config.php_에 대한 요청이 WordPress 구성 파일을 다운로드했을 것입니다.
  • 웹 루트 외부에 _wp-config.php_를 사용하면 _/wp-config.php_에 대한 요청이 완전히 무해한 파일을 다운로드했습니다. 실제 _wp-config.php_ 파일을 다운로드 할 수 없습니다.

따라서 _wp-config.php_을 (를) 웹 루트 외부로 이동하면 실제 보안의 실질적인 이점이 있음이 분명합니다.


_wp-config.php_를 서버의 임의의 위치로 이동하는 방법

WordPress는 _wp-config.php_ 파일에 대한 WordPress 설치 위에 하나의 디렉토리를 자동으로 표시하므로 파일이 이동 한 위치입니다.

그러나 다른 곳으로 옮겼다면 어떨까요? 쉬운. 다음 코드를 사용하여 WordPress 디렉토리에 새 _wp-config.php_을 작성하십시오.

_<?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_ 파일의 실제 경로로 변경하십시오.)

_open_basedir_에 문제가 발생하면 PHP 구성에서 _open_basedir_ 지시문에 새 경로를 추가하십시오.

_open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"
_

그게 다야!


반대로 논쟁을 따기

웹 루트 외부로 _wp-config.php_ 이동에 대한 모든 주장은 잘못된 가정에 달려 있습니다.

인수 1 : PHP가 비활성화 된 경우 이미

누군가가 [_wp-config.php_]의 내용이 귀하의 서버 PHP 인터프리터를 우회하는 경우임을 알 수있는 유일한 방법은… 이미 이런 일이 발생하면 이미 문제가있는 것입니다. 섬기는 사람.

FALSE : 위에서 설명한 시나리오는 침입이 아니라 잘못 구성된 결과입니다.

인수 2 : 실수로 PHP를 비활성화하는 경우는 드물기 때문에 중요하지 않습니다.

공격자가 PHP 처리기를 변경할 수있는 충분한 액세스 권한이 있으면 이미 문제가있는 것입니다. 내 경험상 실수로 인한 변경은 매우 드물기 때문에이 경우 암호를 쉽게 변경할 수 있습니다.

FALSE : 위에서 설명한 시나리오는 일반적인 서버 소프트웨어의 버그로 인해 일반적인 서버 구성에 영향을줍니다. 이것은 거의 "드물다"(그리고 보안은 드문 시나리오를 걱정하는 것을 의미한다).

WTF : 침입 후 암호를 변경하면 침입 중에 민감한 정보를 수집 한 경우 거의 도움이되지 않습니다. 실제로, 우리는 여전히 WordPress가 일반 블로그에만 사용되며 공격자들은 훼손에만 관심이 있다고 생각합니까? 누군가가 들어온 후 복원하는 것이 아니라 서버를 보호하는 것에 대해 걱정합시다.

인수 3 : _wp-config.php_에 대한 액세스 거부가 충분합니다

가상 호스트 구성 또는 _.htaccess_를 통해 파일에 대한 액세스를 제한 할 수 있습니다. – 문서 루트 외부로 이동하는 것과 같은 방식으로 파일에 대한 외부 액세스를 효과적으로 제한합니다.

FALSE : 가상 호스트의 서버 기본값이 PHP 없음, _.htaccess_, _allow from all_ (생산 환경에서는 거의 발생하지 않음)이라고 상상해보십시오. 일상적인 작업 중에 구성이 재설정되면 – like, 예 : 패널 업데이트 – 모든 것이 기본 상태로 돌아가고 노출됩니다.

실수로 설정을 기본값으로 재설정 할 때 보안 모델이 실패하면 보안이 더 필요합니다.

WTF : 왜 보안 계층을 더 적게 권장하는 사람이 있습니까? 비싼 자동차에는 자물쇠 만있는 것이 아닙니다. 알람, 이모빌라이저 및 GPS 트래커도 있습니다. 보호 할만한 가치가 있다면 올바르게하십시오.

인수 4 : _wp-config.php_에 대한 무단 액세스는 중요하지 않습니다

데이터베이스 정보는 실제로 [_wp-config.php_]에서 유일하게 민감한 정보입니다.

FALSE : 인증 키와 솔트는 여러 가지 잠재적 인 하이재킹 공격에 사용될 수 있습니다.

WTF : 데이터베이스 자격 증명이 _wp-config.php_에있는 유일한 경우에도 공격자가 자신의 손을 잡는 terrified 이어야합니다.

인수 5 : _wp-config.php_를 웹 루트 외부로 이동하면 실제로 서버가 less 안전합니다.

여전히 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/_ 디렉토리 (있는 경우)를 포함해야합니다.)


결론 : 구성 파일은 항상 always 웹 루트 외부에 있어야합니다.

보안에 관심이 있다면 _wp-config.php_를 웹 루트 외부로 옮기십시오.

126
Aaron Adams

가장 큰 것은 wp-config.php는 데이터베이스 사용자 이름/암호 등과 같은 민감한 정보를 포함하고 있다는 것입니다.

따라서 아이디어는 문서 루트 외부로 옮기면 아무것도 걱정할 필요가 없습니다. 공격자는 외부 소스에서 해당 파일에 액세스 할 수 없습니다.

그러나 문제는 다음과 같습니다. wp-config.php은 실제로 화면에 아무것도 인쇄하지 않습니다. WP 설치 전체에서 사용되는 다양한 상수 만 정의합니다. 따라서 누군가 파일의 내용이 서버를 우회하는 경우 PHP 인터프리터 인 경우에만 .php 파일을 일반 텍스트로 렌더링합니다. 이런 일이 발생하면 이미 문제가있는 것입니다. 서버에 직접 액세스 할 수 있고 루트 권한이있을 수 있으며 원하는대로 할 수 있습니다.

계속해서 라고 말할 것입니다. 보안상의 관점에서 문서 루트 밖으로 wp-config을 이동하면 이점이 없습니다 - 위와 이것들 :

  1. 가상 호스트 구성 또는 .htaccess를 통해 파일에 대한 액세스를 제한하여 문서 루트 외부로 이동하는 것과 같은 방식으로 파일에 대한 외부 액세스를 효과적으로 제한 할 수 있습니다
  2. wp-config에서 파일 권한이 엄격한 지 확인하여 충분한 권한이없는 사용자가 SSH를 통해 서버에 액세스 할 수있는 경우에도 파일을 읽지 못하게 할 수 있습니다.
  3. 중요한 정보, 데이터베이스 설정은 단일 사이트에서만 사용됩니다. 따라서 공격자가 해당 정보에 액세스 할 수있는 경우에도 wp-config.php 파일이 속한 WordPress 설치 만 영향을받습니다. 더 중요한 것은 해당 데이터베이스 사용자는 해당 WP 설치 데이터베이스를 읽고 쓸 수있는 권한 만 있고 다른 사용자에게는 권한을 부여 할 수있는 권한이 없다는 것입니다. 다시 말해, 침입자가 데이터베이스에 액세스 할 수있는 경우 이는 단순히 백업에서 복원하고 (포인트 4 참조) 데이터베이스 사용자를 변경하는 것입니다.
  4. 자주 백업합니다. 종종 상대적인 용어 인 경우 : 매일 20 개의 기사를 게시하면 매일 또는 며칠마다 백업하는 것이 좋습니다. 일주일에 한 번 게시하는 경우 일주일에 한 번 백업하면 충분합니다.
  5. 사이트는 버전 관리 ( like this ) 상태에 있습니다. 즉, 공격자가 액세스 권한을 얻은 경우에도 코드 변경을 쉽게 감지하고 롤백 할 수 있습니다. 공격자가 wp-config에 액세스 할 수 있으면 다른 것으로 엉망 일 수 있습니다.
  6. 데이터베이스 정보는 실제로 wp-config에서 유일하게 민감한 정보이며,주의해야하기 때문에 (3 및 4 참조) 큰 문제가되지 않습니다. 소금 등은 언제든지 변경할 수 있습니다. 발생하는 유일한 일은 로그인 한 사용자의 쿠키를 무효화한다는 것입니다.

나에게, wp-config를 문서 루트에서 모호하게 보안을 제거하는 것은 밀짚 꾼입니다.

40
chrisguitarguy

나는 맥스가 지식이 풍부한 대답이라고 생각한다. 그리고 그것은 이야기의 한면이다. WordPress Codex에는 더 많은 조언이 있습니다 :

또한 사용자 (및 웹 서버)만이이 파일을 읽을 수 있는지 확인하십시오 (일반적으로 400 또는 440 권한을의 L합니다).

.htaccess가있는 서버를 사용하는 경우이 파일 (맨 위)에이 파일을 넣으면 서버를 서핑하는 모든 사용자의 액세스를 거부 할 수 있습니다.

<files wp-config.php>
order allow,deny
deny from all
</files>

Wp-config.php에 대해 400 또는 440 권한을 설정하면 플러그인이 플러그인에 쓰거나 수정하지 못할 수 있습니다. 예를 들어, 플러그인 캐싱 (W3 Total Cache, WP Super Cache 등)과 같은 경우가 있습니다.이 경우 600 (/home/user 디렉토리에있는 파일의 기본 권한)과 함께 갈 것입니다.

25
its_me

누군가 우리에게 빛나라고 부탁했고, 나는 여기서 대답 할 것입니다.

예, 사이트의 루트 디렉토리에서 wp-config.php를 격리하면 보안상의 이점이 있습니다.

1- PHP 핸들러가 어떤 식 으로든 손상되거나 수정되면 DB 정보가 노출되지 않습니다. 그리고 예, 서버 업데이트 중 공유 호스트에서이 문제가 몇 번 발생한다는 것을 알았습니다. 예, 해당 기간 동안 사이트가 손상되지만 비밀번호는 손상되지 않습니다.

2- 모범 사례는 항상 데이터 파일에서 구성 파일을 분리하는 것이 좋습니다. 예, WordPress (또는 웹 앱)로는 그렇게하기가 어렵지만이를 위로 옮기는 것은 약간의 고립감을줍니다.

누구나 파일에? -s를 전달하고 소스를 볼 수있는 PHP CGI 취약점을 기억하십시오. http://www.kb.cert.org/vuls/id/520827

결국 세부 사항은 적지 만 위험을 최소화하는 데 도움이됩니다. 특별히 공유 환경에 있다면 누구나 데이터베이스에 액세스 할 수 있습니다 (필요한 모든 것은 사용자/패스입니다).

그러나 사이트의 보안을 제대로 유지하는 데 필요한 작은주의 집중 (조기 최적화)이 실제로 필요하지 않도록하십시오.

1 - 항상 최신 상태로 유지

2- 강력한 암호 사용

3- 액세스를 제한합니다 (권한을 통해). 여기에 대한 게시물이 있습니다.

http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html

감사,

17
Sucuri

분명하게 예입니다.

wp-config.php public 디렉토리 외부로 이동하면 PHP 처리기가 악의적으로 (또는 실수로!) 변경 될 때 브라우저를 사용하여 읽지 못하도록 보호합니다.

DB 로그인/비밀번호를 읽는 것은 절름발이 관리자의 실수로 서버가 거의 감염되지 않은 경우 가능합니다. 관리자에게 벌금을 부과하고 더 나은 서버 호스트를 제공합니다. 그게 더 비싸지 만.

15
Max Yudin

논쟁의 여지가 있기 때문에 wp_config.php 파일을 옮기는 것이 반드시 상위 디렉토리로 이동해야한다는 것을 의미하지는 않습니다./root/html과 같은 구조를 가지고 있다고 가정 해 봅시다. 여기서 html에는 WP 설치 및 모든 HTML 내용이 포함되어 있습니다. wp_config.php를/root로 이동하는 대신/root/secure ...와 같이 html 디렉토리 외부와 서버 루트 디렉토리가 아닌 다른 곳으로 이동할 수 있습니다. 물론 php가이 보안 폴더에서도 실행될 수 있는지 확인해야합니다.

WP는/root/secure와 같은 형제 폴더에서 wp_config.php를 찾도록 구성 할 수 없으므로 추가 단계를 수행해야합니다. 나는/root/html에 wp_config.php를두고 민감한 부분 (데이터베이스 로그인, 소금, 테이블 접두사)을 잘라내어 config.php라는 별개의 파일로 옮겼다. 다음과 같이 wp_config.php에 PHP include 명령을 추가하십시오 : include('/home/content/path/to/root/secure/config.php');

이것은 본질적으로 내가 설정 한 것입니다. 지금, 위의 토론을 기반으로, 나는 그것이 필요하거나 심지어 좋은 생각인지 여전히 평가하고있다. 그러나 위의 구성이 가능하다는 것을 추가하기를 원했습니다. 백업 및 다른 루트 파일을 노출시키지 않으며 보안 폴더가 자체 공용 URL로 설정되지 않은 한 찾아 볼 수 없습니다.

또한 보안 폴더에 .htaccess 파일을 생성하여 보안 폴더에 대한 액세스를 제한 할 수 있습니다.

order deny,allow
deny from all
allow from 127.0.0.1
8
Michael

Atatckers가 코드를 삽입 할 수있는 많은 나쁜 주제와 플러그인이 있습니다 (Timthumb의 보안 문제를 기억하십시오). 내가 공격자가된다면 왜 wp-config.php를 검색해야합니까? 이 코드를 삽입하기 만하면됩니다.

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Wp-config.php를 숨길 수 있습니다. WordPress가 모든 민감한 정보를 글로벌하게 액세스 할 수있는 한 wp-config.php를 숨길 수는 없습니다.

Wp-config.php의 나쁜 부분은 민감한 데이터를 가지고 있다는 것이 아닙니다. 나쁜 부분은 민감한 데이터를 전역 접근 가능한 상수로 정의하는 것입니다.

업데이트

나는 define()의 문제점을 명확히하고 민감한 데이터를 전역 상수로 정의하는 것이 나쁜 생각 인 이유는 무엇입니까?.

웹 사이트를 공격하는 데는 여러 가지 방법이 있습니다. 스크립트 삽입은 웹 사이트를 공격하는 유일한 방법입니다.

서버에 공격자가 메모리 덤프에 액세스 할 수있는 취약점이 있다고 가정합니다. 공격자는 메모리 덤프에서 모든 변수의 모든 값을 찾습니다. 글로벌 액세스 가능 상수를 정의하면 스크립트가 종료 될 때까지 메모리에 남아 있어야합니다. 상수 대신 변수를 생성하면 변수가 더 이상 필요하지 않으면 가비지 수집기가 메모리를 덮어 쓸 (또는 해제) 좋은 기회가됩니다.

중요한 데이터를 보호하는 더 좋은 방법은 사용 후 즉시 삭제하는 것입니다.

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->Host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

민감한 데이터를 사용한 후 null에 할당하면 메모리의 데이터를 덮어 씁니다. 공격자는 $db_con에 중요한 데이터가 포함되어있는 순간 메모리 덤프를 가져와야합니다. 그리고 위의 예제에서 (Database_Handler 클래스가 복사본을 저장하지 않는 경우) 매우 짧은 시간입니다.

4
Ralf912