워드프레스 관리 화면에는 테마와 플러그인 파일을 브라우저에서 고칠 수 있는 편집기가 들어 있습니다. 급할 때 편리한 기능이고, 그래서 오래 남아 있었습니다. 그런데 운영 관점에서 보면 이 기능은 관리자 세션 하나를 코드 실행으로 바꾸는 가장 짧은 경로입니다.
취약점이 하나도 없어도 성립합니다. 비밀번호가 어디선가 재사용됐거나, 노트북이 잠기지 않은 채 자리를 비웠거나, 관리 화면에서 스크립트가 실행되는 문제가 하나 있으면 그것으로 충분합니다. 공격면을 줄인다는 것은 이런 경로를 하나씩 없애는 일입니다.
DISALLOW_FILE_EDIT — 잃는 것과 얻는 것
wp-config.php 에 상수 하나를 정의하면 편집기 메뉴가 사라지고, 편집 요청 자체가 거부됩니다.
// wp-config.php — "That's all, stop editing!" 줄 위에 둡니다
define( 'DISALLOW_FILE_EDIT', true );잃는 것은 브라우저에서 코드를 고치는 편의입니다. 그런데 그 편의는 애초에 쓰지 않는 편이 나은 종류입니다. 브라우저에서 고친 코드는 어디에도 기록이 남지 않고, 되돌릴 수 없고, 다음 배포나 업데이트에서 조용히 덮어써집니다. 실제로 “고쳤는데 다음 날 원래대로 돌아가 있다” 는 문의의 상당수가 여기서 나옵니다.
즉 이 상수는 보안을 위해 운영 편의를 내주는 거래가 아닙니다. 하면 안 되는 작업 방식을 막는 김에 공격 경로가 함께 닫히는 쪽에 가깝습니다.
DISALLOW_FILE_MODS — 한 걸음 더, 프로덕션 전용
DISALLOW_FILE_MODS 는 편집기뿐 아니라 플러그인 · 테마의 설치와 업데이트 화면 전체를 없앱니다. 코드가 사이트에 들어오는 경로가 배포 하나로 좁아지므로, 관리 화면에서 시작되는 코드 추가는 성립하지 않게 됩니다.
define( 'DISALLOW_FILE_MODS', true ); // 프로덕션에서만⚠ 순서를 지켜야 합니다. 이 상수를 켜면 보안 업데이트도 관리 화면에서 할 수 없습니다. WP-CLI 나 배포 파이프라인으로 업데이트하는 절차가 먼저 자리 잡은 뒤에 켜야, 보안을 위해 켠 설정이 보안 패치를 막는 일이 생기지 않습니다. 절차가 아직 없다면 이번 회차에서는 DISALLOW_FILE_EDIT 만 켜고, 업데이트 루틴을 세운 다음에 돌아옵니다.
켠 뒤에 확인할 것
마지막 항목을 특히 봅니다. 서버에 접속해 파일을 손으로 고쳐 켠 설정은 다음 이전이나 재구축에서 사라집니다. 그리고 사라진 사실은 아무 화면에도 나타나지 않습니다. 상수는 wp-config.php 에 두고, 그 파일이 배포 대상에 포함되는 구조를 만들어 두는 편이 안전합니다.
워드프레스 코어와 배포 구조에 관한 글은 서버 · 인프라 아카이브에 더 있고, 우리가 실제 작업에서 어떤 순서로 설정을 적용하고 검증하는지는 작업 과정에 공개돼 있습니다.
다음 회차
관리 화면 쪽 경로를 닫았으니 다음은 밖에서 들어오는 문입니다. 다음 회차는 XML-RPC 와 REST — 그리고 필터만으로는 왜 파일이 계속 응답하는지입니다.