PHP2Shell 기업 서버 대응 순서 정리

서버실에서 여성이 랙 서버의 네트워크 포트 앞에 파란 랜 케이블 커넥터를 들고 있다.

 

당신이 관리하는 서버에서 웹셸이나 의심스러운 연결을 발견했다면, 업데이트보다 네트워크 격리와 증거 보존이 먼저입니다. 침해 징후가 없는 서버는 호환성을 확인한 뒤 PHP를 업데이트하고 실행 서비스를 재시작하세요. 재시작은 수정 코드를 실행하는 데 필요하지만, 침해가 의심될 때는 메모리에 남은 공격 흔적을 없앨 수 있어 순서가 달라집니다.

 

설치 완료 뒤에도 확인할 작업이 있습니다

인조이스의 원문 기사는 서버 상태에 따라 조치 순서를 나누고, 패치 이후 확인할 작업까지 안내합니다. 설치 완료를 판단하려면 설치 파일 교체 여부뿐 아니라 실제 웹 요청을 처리하는 PHP에 수정 내용이 반영됐는지도 확인해야 합니다. 컨테이너 환경에서는 수정된 이미지로 다시 배포해야 합니다.

명령줄에서 확인하는 php -v 결과는 웹 서비스가 사용하는 PHP와 다를 수 있습니다. 서버에 PHP 실행 환경이 여러 개라면 각각 확인하세요. 설치 완료 메시지와 실제 서비스의 반영 여부를 구분하면, 담당자에게 어떤 확인 결과를 요청해야 하는지 분명해집니다.

패치는 이미 발생한 침해나 정보 유출을 되돌리지 못합니다. KISA는 최소 2026년 10월 20일 이후 기록을 점검하고, 가능하면 이전 기록도 확인하도록 권고합니다. 패치 전 인터넷에 노출된 서버는 인증정보 교체가 권고되며, 침해 흔적이 발견됐다면 반드시 교체해야 합니다.

 

서버 사용 현황 확인부터 침해 여부별 대응, 패치, 서비스 재시작, 로그 점검과 인증정보 교체까지 정리한 흐름도

 

PHP2Shell 세부 점검표와 버전 확인 자료

인조이스의 원문 기사에는 서버 상태별 대응표, 임시 설정의 적용 조건, 외주·호스팅 업체에 요청할 확인 항목이 정리돼 있어 작업 목록을 만드는 데 참고할 수 있습니다. 다만 PHP 8.5 계열의 수정 버전은 본문과 표·문답의 표기가 서로 달라, 적용 버전은 인조이스의 원문 기사에서 안내하는 PHP 공식 릴리스 공지와 KISA 공지로 확인할 필요가 있습니다.

 

인조이스에서 전체 내용 확인하기

 

홈페이지와 테스트 서버의 상태가 다를 때

당신이 공개 홈페이지와 테스트 서버를 함께 관리하고, 테스트 서버에서만 의심스러운 연결을 발견한 상황을 가정해 볼 수 있습니다. 두 서버를 같은 순서로 재시작하기보다, 각 서버의 상태에 맞춰 작업을 나누는 방식입니다.

• 침해 징후가 없는 공개 홈페이지는 호환성 검토와 패치 적용 뒤 재시작하고, 실제 웹 실행 환경을 확인합니다.
• 침해가 의심되는 테스트 서버는 네트워크에서 격리한 뒤 신고하고, 로그·실행 중인 프로그램 목록·현재 연결 정보를 보존합니다. 증거를 확보한 다음 업데이트와 재시작을 진행합니다.

작업 기록에도 두 서버의 진행 상태를 따로 남기는 편이 좋습니다. 홈페이지의 패치가 끝났다는 사실만으로 테스트 서버의 사고 대응까지 완료된 것은 아니기 때문입니다. 로그 점검과 인증정보 교체도 각각 확인하세요.

즉시 업데이트하기 어렵다면 공식 임시 설정과 앞단 요청 제한을 검토할 수 있습니다. 다만 임시 조치는 일부 공격 경로를 줄이는 수단이며 전체 취약점을 해결하지는 못합니다. 임시 조치도 어렵다면 외부 접속 차단이나 일시 중단을 검토하도록 안내합니다.

 

외주 사이트와 장비까지 점검 범위에 포함합니다

당신의 점검 목록에는 대표 홈페이지뿐 아니라 외주 제작 사이트, 오래된 사이트, 이벤트·테스트 서버, 관리자 페이지도 포함할 필요가 있습니다. 장비 관리화면과 솔루션에 PHP가 들어 있는지, 컨테이너 이미지와 실행 중인 컨테이너는 어떤 상태인지도 확인하세요. 내부 시스템도 대상이지만 인터넷에 공개된 서버부터 조치하도록 안내합니다.

호스팅 환경에서는 관리 업체에 서비스별 패치 적용 근거와 실행 환경의 확인 결과를 요청할 수 있습니다. 장비에 포함된 PHP의 경우 제조사 업데이트를 확인합니다. 외부 업체가 관리한다는 이유만으로 점검을 마쳤다고 판단해서는 안 됩니다.

PHP 8.2의 보안 지원 종료일은 2026년 12월 31일이며, KISA는 PHP 8.3 이상으로 전환할 것을 권고합니다. PHP 8.1 이하는 정규 보안 지원이 끝난 상태이므로 배포판이나 장기지원 업체의 패치를 별도로 확인해야 합니다. 상위 계열로 옮기기 전에는 애플리케이션 호환성 테스트가 필요합니다.

 

공장에서 중년 기술자가 열린 네트워크 장비함 옆 태블릿의 상태 화면을 확인하는 모습

 

비밀번호와 버전 표시에서 남는 궁금증

PHP2Shell은 비밀번호 변경만으로 막을 수 있습니까?

아닙니다. 로그인 없이 악용될 수 있어 PHP 보안 업데이트가 필요합니다. 인증정보 교체는 유출 가능성에 대응하는 별도 작업입니다.

패치했는데 버전 번호가 같으면 실패한 것입니까?

버전 번호가 같다는 이유만으로 실패했다고 판단할 수는 없습니다. 배포판이나 제조사 패키지는 기존 버전에 수정 내용을 반영할 수 있으므로, 패키지 변경 이력에서 두 취약점의 CVE 수정 여부를 확인하세요.

 

오늘 시작할 작업으로 인터넷에 공개된 서비스 목록을 만들고, 각 서비스의 PHP 버전과 관리 담당자를 기록해 두는 방법을 제안합니다. 침해가 의심되는 국내 기업이라면 먼저 네트워크에서 격리하고 보호나라의 침해사고 신고 메뉴를 이용하세요. 인조이스의 원문 기사에서 상태별 순서와 필요한 증거 항목을 확인할 수 있습니다.

 

PHP2Shell 기업 서버 보안 대응 방법 - Injoys

 

이 글은 인조이스(injoys.com)가 운영하는 채널의 도움을 받아 작성했습니다. 원문과 출처는 위 링크에서 확인할 수 있습니다.