Ansible을 활용한 PHP2Shell 취약점 일괄 진단 및 조치

오픈소스(OSS) 활용 / 글쓴이

다수의 Linux 서버를 대상으로 취약점 확인부터 보안패치, 적용 여부 재검증까지 Ansible로 자동화하는 오픈소스 활용 사례를 소개한다.

최근 전세계적으로 큰 이슈인 PHP2Shell과 같은 긴급 취약점이 공개되면 기업은 수많은 서버의 영향을 신속하게 확인하고 조치한 후, 적용 결과까지 검증해야 한다. WIKI Security는 자사의 적용 경험을 바탕으로 정보보안 컨설팅과 자동화 기술을 결합하여 반복적인 보안업무를 효율적으로 수행하는 방안을 지속적으로 소개하고 있다.

1. PHP2Shell 취약점, 왜 신속한 대응이 필요한가?

PHP2Shell 관련 CVE-2026-109618 및 CVE-2026-109619는 PHP 메모리 처리와 관련하여 원격 코드 실행 위험이 논의되는 보안 취약점이다. 기업의 실제 위험은 노출된 서비스, PHP 패키지와 배포판의 수정 상태 등에 따라 달라지므로 공식 보안 공지 확인이 필요하다.

  • 영향 대상 식별: 어떤 서버에 관련 PHP 패키지가 설치되어 있는가?
  • 패치 기준 확인: 운영체제별 적용 가능한 수정 버전은 무엇인가?
  • 일괄 조치: 서버별 수동 접속 없이 동일한 기준으로 조치할 수 있는가?
  • 사후 검증: 패치 적용과 서비스 정상성을 어떻게 입증할 것인가?

효과적인 대응 방안은 대상 서버의 조사, 패치, 재검증 및 결과 보고를 하나의 반복 가능한 절차로 표준화하는 것이다.

2. Ansible 기반 진단 및 조치 자동화 구성

2.1 대상 서버과의 통신 등 환경

Ansible은 SSH, WinRM, HTTP(S) API 등 다양한 연결 방식을 지원하지만, 이번 PHP2Shell 취약점 진단 및 조치 사례에서는 SSH를 이용해 Debian 및 Ubuntu 서버에 접속하는 방식을 사용한다.

Ansible Controller는 SSH를 통해 대상 서버에서 PHP 패키지 정보를 수집하고, 취약점 판정과 보안패치 작업을 실행한 후 처리 결과를 회수한다. 실제 적용을 위해서는 다음 사항을 사전에 확인해야 한다.

  • SSH 통신: Controller에서 대상 서버의 SSH 서비스(예: TCP/22)에 접근할 수 있어야 한다.
  • 계정 및 권한: SSH 로그인 계정과 필요한 sudo 관리자 권한이 확보되어야 한다.
  • 실행환경: 대상 서버는 지원되는 Debian/Ubuntu 환경이어야 하며, Python, DPKG, APT 등 필요한 구성요소가 설치되어 있어야 한다.
  • 패치 저장소 접근: 대상 서버에서 보안패치 패키지를 제공하는 외부 또는 내부 APT 저장소에 접근할 수 있어야 한다.
  • 접속 및 실행 검증: 작업 전 SSH 연결, 권한 상승, 패키지 저장소 접근 및 보안패치 제공 여부를 확인해야 한다.

특히 SSH 접속이 제한된 서버나 외부 인터넷이 차단된 폐쇄망 환경에서는 사전에 승인된 접속 경로 또는 내부 패키지 미러 저장소 등을 준비해야 한다. 이러한 사전 점검은 취약점 진단·조치 과정에서 발생할 수 있는 접속 오류와 패치 실패를 줄이기 위한 중요한 준비 절차이다.

2.2 Ansible활용 자동화 구성

Ansible은 Inventory.ini 파일로 대상 목록, 접속 방법, 접속환경 등을 정의하고 Playbook으로 업무처리를 정의함으로써 업무 처리 자동화를 구성할 수 있다.

자동화 처리 흐름: 대상 등록 → 시스템 정보 수집 → CVE별 취약점 판정 → 승인된 패치 적용 → 패치 후 재점검 → 통합 보고서 생성

  • 대상 등록: IP, 접속 계정, 대상 그룹과 sudo 권한 준비
  • 환경 조사: OS 배포판·릴리스·PHP 설치 패키지와 버전 수집
  • 취약점 판정: 패키지 버전과 배포판별 수정 기준 비교
  • 조치: APT를 통한 설치 패키지 업데이트
  • 검증 및 기록: 변경 전후 버전·재시작 필요 여부·실패 사유 확인

3. 적용 사례: PHP2Shell 취약점 일괄 진단 및 자동 조치

Github에 공개된 Ansible Playbook php_cve_audit.yml(https://gist.github.com/tolecnal/c4012a29cd5ae3ea600c00b50a027e77 )은 패키지 관리 체계를 기준으로 PHP2SHELL 취약점 진단과 패치·재검증을 수행한다. 아래 코드는 설명을 위해 일부 핵심 구문을 간략화한 예시이다.

3.1 대상 서버 정의 Inventory.ini

[php_servers]
web01 ansible_host=192.0.2.11
web02 ansible_host=192.0.2.12
web03 ansible_host=192.0.2.13
……

[php_servers:vars]
ansible_user=admin
ansible_become=true
ansible_become_method=sudo
……

Inventory 그룹을 지정하면 여러 서버에 동일한 진단을 수행할 수 있다. SSH 인증과 sudo 권한은 실제 고객사의 통제 정책에 맞게 설정한다.

3.2 PHP 설치 정보 수집과 CVE 판정

Playbook은 dpkg-query로 PHP 관련 패키지와 소스 버전을 수집하고, dpkg의 버전 비교 기능으로 공식 패치 기준 이상인지 확인한다.

# 핵심 비교 명령의 구조 (설명용)
dpkg --compare-versions "${installed_version}" ge "${fixed_version}"
  • PATCHED: 코드에 등록된 수정 버전 이상
  • VULNERABLE: 수정 버전에 미달
  • MANUAL_CHECK: 외부 저장소 또는 판정 근거가 부족해 수동 확인 필요
  • NO_PHP / SKIPPED_OS / ERROR: 대상 없음, 미지원 OS 또는 실행 오류

단순한 PHP 메이저 버전이 아니라 배포판 패키지의 수정 버전을 비교하므로 보안 수정사항이 백포트된 경우도 구분하는 데 도움이 된다.

3.3 보안패치 일괄 적용

ansible.builtin.apt:
  name: "{{ php_audit_upgrade_names }}"
  state: latest
  only_upgrade: true
  lock_timeout: 300

설치된 PHP 패키지의 업데이트를 수행하며, 자동 패치 사용 여부와 업데이트 범위에 따라 실행이 제어된다. 패치는 패키지와 의존 관계에 영향을 줄 수 있어 작업 승인 후 실시해야 한다.

3.4 재검증과 결과 보고

  • 패치 후 PHP 패키지 및 소스 버전 재수집
  • 취약점 수정 기준을 충족하는지 재판정
  • 이전 PHP 파일을 참조하는 실행 중 프로세스 확인
  • 서버별 결과를 Controller의 reports 디렉터리에 TXT·JSON으로 기록

패키지 버전 검증과 서비스 기능 검증은 서로 다르다. 웹 애플리케이션의 정상 작동과 필요한 재시작은 별도로 확인해야 한다.

4. 다수 서버 적용 시 운영상 고려사항

  • 이 사례에서는 소량의 서버를 대상으로 적용하였으나 수십~수백대 서버를 대상으로 적용시에는 몇 가지 고려할 사항들이 있다.
  • 사전 준비: SSH 접속, sudo 권한, OS/PHP 설치 형태 및 저장소 확인
  • 작업 통제: 전체 적용 전 대표 서버에서 시험하고 승인된 범위로 확대
  • 서비스 보호: PHP-FPM/Apache 등 연계 서비스 영향과 재시작·복구 계획 수립
  • 후속 관리: 미접속·판정 불가·패치 실패 서버를 구분하여 재점검
  •  

5. 공개 Playbook 적용 시 꼭 확인할 사항

해당 Ansible Playbook은 신속하게 PHP2SHELL의 진단·조치를 시작할 수 있는 실무 참고 사례이다. 실제 운영환경에서는 아래 네 가지를 우선 확인하는 것이 좋다.

  • 지원 범위: Debian·Ubuntu의 APT/DPKG 기반 PHP 패키지 중심이며, 직접 빌드한 PHP·컨테이너·타 배포판은 별도 점검이 필요하다.
  • 패치 정보: CVE별 수정 버전은 Playbook에 내장되어 있으므로 최신 공식 보안 공지와 대조해야 한다.
  • 실행 안전성: 원본은 자동 패치가 기본 활성화되어 있다. 최초 실행은 반드시 진단 전용 모드를 사용하고, 승인 후 대상과 범위를 제한한다.
  • 조치 완료 기준: 패키지 재점검 외에 PHP 프로세스 재시작 필요 여부, 웹서비스 정상성, 실패 서버 및 복구 가능성을 확인한다.

핵심은 공개된 Ansible Playbook을 그대로 사용하는 데 그치지 않고, 조직의 운영환경에 맞게 사전 검증·승인·재점검 절차를 결합하는 것이다.

6. 자주 묻는 질문(FAQ)

Q1. 여러 서버 중 일부만 진단할 수 있는가?

가능하다. Inventory 그룹이나 –limit 옵션으로 범위를 지정한다. 아래 예시는 php_servers 그룹의 web01만 진단한다.

ansible-playbook -i inventory.ini php_cve_audit.yml \
  -e php_audit_hosts=php_servers --limit web01 \
  -e '{"php_audit_apply_upgrade": false}'

Q2. 실제 패치 없이 진단 결과만 먼저 얻을 수 있는가?

가능하다. php_audit_apply_upgrade를 false로 지정하면 패키지 업데이트 없이 진단을 수행한다. 처음 적용할 때 권장하는 실행 모드이다.

ansible-playbook -i inventory.ini php_cve_audit.yml \
  -e php_audit_hosts=php_servers \
  -e '{"php_audit_apply_upgrade": false}'

Q3. 패치가 필요한 서버에만 업데이트를 적용하려면?

먼저 진단 결과를 검토한 뒤 승인된 서버를 –limit으로 제한한다. 원본은 자동 패치 기본값이 true이므로 아래 명령은 실제 업데이트를 수행할 수 있다.

ansible-playbook -i inventory.ini php_cve_audit.yml \
  -e php_audit_hosts=php_servers \
  --limit web01 -e php_audit_upgrade_scope=php_only

이 실행은 개별 CVE의 최소 수정 버전만 지정해 설치하는 것이 아니라, 선택된 설치 PHP 패키지에 대해 저장소의 최신 적용 가능 버전으로 업데이트한다.

Q4. 다수 서버에 동시에 패치가 적용되는 것을 줄일 수 있는가?

APT 작업의 동시 처리 수를 php_audit_throttle 변수로 제한할 수 있다. 아래 예시는 해당 작업 동시 실행을 2대로 제한한다. 전체 Playbook의 모든 단계가 순차적으로 두 대씩 실행된다는 의미는 아니다.

ansible-playbook -i inventory.ini php_cve_audit.yml \
  -e php_audit_hosts=php_servers \
  -e php_audit_throttle=2

Q5. 패치 후 적용 여부와 보고서는 어디에서 확인하는가?

Playbook이 패치 후 PHP 패키지 정보를 다시 수집하여 판정하며, Ansible Controller의 reports 디렉터리에 타임스탬프가 포함된 TXT 및 JSON 파일을 생성하도록 되어 있다.

ls -lh ./reports/php_cve_report_*.txt ./reports/php_cve_report_*.json
# 최신 보고서 확인 예시
ls -t ./reports/php_cve_report_*.txt | head -1

보고서에 PATCHED로 표시되어도 웹서비스 기능 테스트와 재시작 필요 프로세스 확인은 별도로 수행해야 한다.

Q6. WIKI Security는 어떤 부분을 지원하는가?

WIKI Security는 자동화 대상 분석, Playbook 검토·조정, SSH 및 권한 체계 구성, 안전한 단계별 패치 절차, 재검증과 결과 관리, 기존 보안운영 도구 연계 등을 고객 환경에 맞게 지원한다.

OSS 기반 보안 자동화, WIKI Security와 함께

긴급 취약점 대응에는 신속한 영향 분석과 조치뿐 아니라 결과를 입증할 수 있는 검증체계가 필요하다. WIKI Security는 정보보안 컨설팅과 소프트웨어 개발 역량을 기반으로 공개 OSS를 실제 운영환경에 적합한 자동화 업무로 연결한다.

Ansible을 활용한 대량 취약점 진단·조치·재점검은 반복적인 보안업무를 표준화하고 대응의 일관성을 높일 수 있는 대표적인 사례이다. 고객의 보안정책과 서비스 운영 여건에 맞는 자동화 적용 방안을 검토할 수 있다.