모두
모두콘텐츠
얼마 전 사이트가 느려졌다는 연락을 받고 서버를 확인했는데, 트래픽은 평소와 같았다. 대신 업로드 폴더에 처음 보는 서버 실행 파일이 하나 생겨 있었다. 이런 경우를 겪고 나면 웹쉘탐지시스템을 찾게 된다. 다만 제품을 설치하는 것보다 먼저, 어떤 파일이 바뀌면 위험한지와 경고를 받았을 때 누가 확인할지를 정해야 한다.
웹쉘은 어디에 남고 무엇을 감시해야 하나
웹쉘은 공격자가 서버에 심어 두는 실행 가능한 파일이다. 취약한 업로드 기능이나 오래된 플러그인, 탈취한 관리자 계정을 통해 들어올 수 있다. 파일 하나로 서버 명령을 실행하거나 다른 파일을 읽을 수 있어 피해 범위가 사이트 화면에만 머물지 않는다. MITRE ATT&CK도 웹쉘을 서버에 지속적으로 접근하는 수단으로 분류한다.
첫 감시 대상은 웹에서 접근할 수 있는 실행 파일 경로다. 운영 중인 코드 디렉터리의 새 파일과 수정 파일, 업로드 폴더에 생긴 실행 가능한 확장자, 웹서버 설정과 예약 작업의 변경을 본다. 파일 이름이 낯설다는 이유만으로 침해를 확정하면 안 된다. 반대로 이름이 평범하다고 안전한 것도 아니다. 배포 기록과 파일 해시를 대조해야 판단이 빨라진다.
로그도 함께 봐야 한다. 새 파일이 생긴 직후 그 파일에 요청이 몰렸는지, 웹서버 프로세스가 평소 실행하지 않던 명령을 호출했는지 확인한다. 파일 변화만 보는 도구는 메모리에서 실행된 행위나 정상 파일을 악용한 경우를 놓칠 수 있다. 탐지는 파일, 접근 기록, 프로세스 기록을 이어서 볼 때 쓸모가 커진다.
서버 규모에 맞춰 탐지 방식을 고르는 기준
월 방문자 수만으로 비싼 요금제를 고를 필요는 없다. 먼저 서버에 탐지 프로그램을 설치할 권한이 있는지 확인한다. 공용 웹호스팅은 운영체제 접근이 제한되는 경우가 많아 호스팅 업체가 제공하는 검사와 파일 변경 알림, 접속 로그가 현실적인 출발점이다. 자체 VPS라면 파일 무결성 검사와 로그 수집을 직접 구성할 수 있다. 여러 서버에 같은 코드를 배포한다면 정상 배포본과 각 서버의 파일 차이를 자동으로 비교하는 편이 관리하기 쉽다.
규모보다 중요한 것은 변경 빈도다. 하루에도 여러 번 배포하는 사이트에서 모든 수정 파일을 즉시 위험으로 알리면 경고가 금세 묻힌다. 배포 시각과 배포 계정을 기록하고, 배포 대상 밖에서 생긴 실행 파일에 우선순위를 준다. 반대로 한 달에 한 번만 수정하는 작은 사이트라면 매일 한 차례 파일 목록과 해시를 비교하는 것만으로도 의심스러운 변화를 찾는 데 도움이 된다. 즉시 탐지가 필요한지, 하루 단위 확인으로 충분한지는 사이트가 다루는 정보와 운영 대응 시간을 함께 보고 결정한다.
- 공용 웹호스팅: 제공되는 검사 범위, 경고 전달 방법, 로그 열람 기간을 확인한다.
- 단일 VPS: 코드와 업로드 폴더를 구분해 감시하고, 경고가 서버 장애 중에도 전달되는지 점검한다.
- 서버 여러 대: 정상 배포본을 기준으로 비교하고, 서버별 경고를 한곳에서 확인한다.
탐지 도구의 CPU 사용량과 디스크 읽기량도 살펴야 한다. 이미지와 캐시 파일까지 매번 훑으면 작은 VPS에서는 검사 자체가 부담이 된다. 자주 바뀌는 캐시는 감시 범위를 조정하되, 업로드 폴더를 통째로 제외해서는 안 된다. OWASP는 업로드된 파일이 서버에서 실행될 수 있을 때 웹쉘 위험이 생긴다고 설명한다. 그래서 업로드 폴더에서는 실행을 막는 설정과 의심 파일 감시가 함께 필요하다.
경고가 울렸을 때 확인하는 순서
경고를 받자마자 파일부터 지우면 조사할 단서가 사라진다. 먼저 발생 시각, 파일 경로, 해시, 파일 소유자와 최근 배포 기록을 보존한다. 다음으로 해당 파일에 접근한 요청과 같은 시각의 로그인·업로드 기록을 확인한다. 웹서버 계정이 평소와 다른 프로세스를 실행했거나 외부로 예상 밖의 연결을 만들었다면 침해 가능성을 높게 봐야 한다.
의심이 강하면 해당 서버의 외부 접근을 제한하고 깨끗한 환경에서 조사한다. 파일 하나를 삭제한 뒤 다시 공개하는 방식은 위험하다. 공격자가 관리자 계정이나 다른 파일에도 접근했을 수 있기 때문이다. 최초 진입에 쓰인 취약점이나 계정을 찾아 막고, 노출 가능성이 있는 비밀번호와 접근 키를 교체한 뒤 검증된 정상본에서 복구한다. 복구 뒤에는 같은 경로에 다시 파일이 생기는지 감시해야 한다.
백업도 이 단계에서 성패가 갈린다. 감염 이후에 만들어진 백업만 있다면 그대로 복원할 수 없다. 운영 서버와 분리해 보관한 백업, 복원 가능한 날짜, 실제 복원 시험 기록이 있어야 한다. 탐지 경고가 정확해도 되돌릴 정상본이 없으면 서비스 재개가 길어진다.
도입 전에 작은 점검부터 해보는 방법
우선 최근 한 달 배포 내역과 현재 파일 목록을 맞춰 정상 기준을 만든다. 그다음 테스트 파일을 감시 대상 폴더에 추가해 경고가 언제, 누구에게 도착하는지 확인한다. 테스트는 실행 기능이 없는 일반 파일로도 충분하다. 경고에 경로와 변경 시각이 빠져 있다면 실제 사고 때 확인 시간이 늘어난다.
운영자가 혼자라면 매일 확인할 수 있는 경고 수로 규칙을 좁히는 게 낫다. 새 실행 파일, 배포 시간 밖의 코드 수정, 업로드 폴더의 실행 권한 변화부터 잡는다. 이후 실제 경고를 보며 범위를 넓힌다. 웹쉘탐지시스템의 값은 화면에 표시되는 탐지 건수보다, 의심 파일을 발견하고 정상 서비스로 돌아가기까지 걸리는 시간을 줄이는 데서 드러난다. 작은 사이트라도 그 흐름이 준비돼 있으면 사고에 훨씬 차분하게 대응할 수 있다.
