오호라! 이거지!!

PHP Shell 보안 취약점 - 구형 서비스, Docker로 쉽고 빠르게 업그레이드 본문

IT,컴퓨터,게임

PHP Shell 보안 취약점 - 구형 서비스, Docker로 쉽고 빠르게 업그레이드

노네발 2026. 10. 26. 15:08

PHP 5.6을 계속 사용해 왔습니다.

5년? 10년? 전에 개발한 프로젝트입니다.

지금도 한 달에 한두 개씩 기능이 추가되는 형태로 유지보수하며 사용하고 있습니다.

오래된 스크립트 방식으로 작성된 코드가 대부분입니다.

문제가 없다면 업그레이드 잘 안하는 게으른 개발자입니다.

 

지난 26년 10월 22일, php shell 보안 취약점 문제가 발생하면서 상황이 달라졌습니다.

너무 크게 알려진 부분이라 대응을 하지 않을 수 없습니다.

당연히 업그레이드가 가장 확실한 방법이지만, 오래된 프로젝트는 버전만 올린다고 끝나는 일이 아닙니다.

기존 코드도 상당 부분 수정해야 하기 때문에 쉽게 결정하기 어려웠습니다.

우선 임시 대응

먼저 공격 방식을 살펴본 뒤, 1차 대응으로 파일 업로드 기능을 차단했습니다.

당시에는 대량의 파일 업로드를 통한 공격 가능성을 고려했기 때문입니다.

임시 조치일 뿐이지만, 간단하고 다음 대응을 할 시간을 벌기 위해서 했습니다.

결국 근본적인 대응을 위해 업그레이드를 진행하기로 했습니다.

 

기존 환경 한계

운영체제와 Apache도 오래된 환경이었고, 기존 패키지 저장소에서 설치할 수 있는 PHP 버전에도 한계가 있었습니다.

확인한 환경에서는 PHP 7.3까지만 설치할 수 있었습니다.

현재 OS는 AWS의  Amazon Linux AMI 2016.03 입니다.

그래서 선택한 방법이 Docker입니다.

PHP 공식 Docker 이미지 중 Apache가 포함된 `php:8.5-apache`를 사용하기로 했습니다.

공식이미지라서, 취약점 대응이 된 8.5.12버전으로 벌써 올라와있었습니다.

Docker 적용

기존 환경 테스트

Docker를 사용하면 기존 서버 환경을 유지하면서 새로운 PHP 환경을 구성할 수 있습니다.

기존 Apache를 바로 중지할 필요 없이, 우선 다른 포트를 사용해 같은 소스를 테스트하면 됩니다.

docker run -d \ --name php85 \ -p 8080:80 \ -v /var/www/:/var/www/ \ php:8.5-apache

 

이렇게 하면 서버의 8080번 포트로 접속했을 때 Docker 내부의 Apache 80번 포트로 연결됩니다.

기존 Apache는 그대로 실행하면서 새로운 PHP 환경을 테스트할 수 있습니다.

소스 코드를 그대로 활용하고, 기존 데이터베이스에 연결해 확인하는 것도 가능합니다.

이 상태에서 기존 코드가 정상적으로 동작하는지 확인하고, 버전 차이로 발생하는 오류를 수정합니다.

실제 환경 적용

테스트가 끝나고 실제 서비스에 적용할 준비가 되었다면 기존 Apache를 중지하고,

docker run -d \ --name php85 \ -p 80:80 -p 443:443 \ -v /var/www/:/var/www/ \ php:8.5-apache

 

Docker 컨테이너를 `-p 80:80`, `-p 443:443`으로 실행하도록 변경하면 됩니다.

HTTPS 인증서와 Apache 설정, DB 접속 등은 별도로 확인하고 수정해야 합니다.

 

세부적인 Docker이나 APM 사용법은 AI와 대화하며 진행하면 됩니다.

간단하게라도 서버 환경을 직접 관리할 수 있는 분이라면,

Docker를 활용해 이런 식으로 새로운 환경을 구성하고 테스트할 수 있다는 정도로 참고하시면 좋겠습니다.

결국 코드 수정이 제일 큰 일

Docker 환경을 만드는 건 쉽지만, 결국 기존 코드를 최신 PHP에 맞게 수정해야 합니다.

PHP 5.6에서는 별다른 문제 없이 동작하던 코드도 PHP 8.5에서는 오류가 발생할 수 있습니다.

원래 초기 PHP의 장점이자 단점이, null 처리에 관대하다는 것이죠.

 

그러다보니 오래된 함수나 배열 처리 방식 등도 문제가 될 수 있습니다.

오류가 나지는 않더라도 기존과 결과가 달라질 수도 있습니다.

 

이번 작업에서도 이런 오류를 상당히 많이 고쳤습니다.

2~3일 동안 코드를 집중적으로 수정했습니다.

 

문법 오류를 해결한다고 끝나는 것도 아닙니다.

개발 환경에서는 정상적으로 동작하더라도 실제 서비스에서 특정 조건이 발생하면 런타임 오류가 나타날 수 있습니다.

가능한 한 충분히 테스트하고, 실제 운영에 적용한 뒤에도 로그를 확인하면서 추가 오류를 찾아야 합니다.

마무리

저처럼 오래된 개발자들은, 리부팅하다 안켜지고 버전업하다 박살나는걸 많이 봅니다.

그래서 작동한다면 건드리지 말자라는 귀찮음을 상쇄하는 좋지 않은 신념이 생기기도 합니다.

그래도 이렇게 생존이 걸린 문제라면 움직여야죠.

 

또한 의도치 않았지만 같은 서버 같은 로직인데도 실행 속도가 꽤 빨라졌습니다.

분단위가 걸리던 대량 작업은 5~10배까지 빨라졌습니다.

뭐 하나 건진게 있어서 조금 보상받은 기분이네요.

 

AI발전에 따라서 보안에 대한 경각심도 더 높여야 하는 시대가 되었습니다.

사람보다 쉽게 이런 부분을 찾아내기도 하니까요.

 

위험하다는데 어떻게 해야 하나 싶으시다면, 일단 Docker 올려보고 계획을 잡아 최대한 빠르게 진행하시기 바랍니다.