실제 침해사고로 본 서버 보안 설정 — 피해를 키운 건 기본 설정이었다

---

🖥️ 피해를 키운 건 공격 기법이 아니었습니다

 

여러 업종의 침해사고를 대응하면서 확인된 공통점이 있습니다.

 

공격 기법 자체보다 기본적인 서버 보안 설정의 미흡함이 피해를 키웠다는 것입니다.

 

업로드 경로에 남아 있던 실행 권한, 통제되지 않은 공유 폴더,

패치되지 않은 소프트웨어, 부족한 로그 보관.

 

사고 하나하나를 들여다보면 예방이 가능했던 지점이 분명히 있었습니다.

 

📌 이 글의 성격

실제 사고 대응에서 확인된 내용을 유형별로 재구성한 일반 안내입니다.
온프레미스 서버 환경을 중심으로 작성했으며,
클라우드는 서비스 유형과 공동 책임 범위에 따라 별도 기준이 필요합니다.

 

1. 공격은 달라도 흐름은 같았습니다

다섯 단계

공격 전개 흐름 [01]

 

최초 침투 경로는 제각각이었지만, 전개되는 흐름은 대부분 유사했습니다.

 

단계	내용
1. 최초 진입	웹쉘 · 취약점 · Brute Force · 계정 탈취
2. 권한 상승	관리자 권한 확보, 내부 정보 수집
3. 수평 이동	공유 폴더·내부망을 타고 확산
4. 실질적 피해	랜섬웨어 · 채굴 · 정보 유출
5. 증거 인멸	로그 삭제

 

🔗 한 단계만 끊어도 됩니다

다섯 단계를 모두 막을 필요는 없습니다.

어느 한 단계라도 차단하면 피해 규모가 크게 줄어듭니다.
실제 사고 대응 경험에서 반복적으로 확인된 사실입니다.

 

2. 최초 침투는 다섯 유형

무엇으로 들어왔나

침투 유형 분류 [02]

 

유형	내용
웹쉘 업로드	업로드 취약점으로 웹쉘 삽입 후 거점화
SMB·공유 폴더	Pass the Hash · 공유 드라이브로 확산
소프트웨어 취약점	패치가 나왔는데 적용하지 않은 RCE
계정 탈취	SSH·RDP 무작위 대입 · VPN 계정 유출
원격 관리 도구	TeamViewer · mRemote 등 통제 밖 도구

 

📭 그리고 여섯 번째가 있습니다

로그가 없어 원인 자체를 밝히지 못한 사례입니다.

공격자가 지웠거나, 애초에 남지 않았던 경우입니다.
가장 대응이 어려웠던 유형으로 꼽힙니다.

 

3. 가장 많았던 건 웹쉘

업로드 경로 하나가 문을 열었습니다

웹쉘 사례 [03]

 

사례	내용
DB 접근·유출 시도	웹쉘 업로드 후 포트 포워딩과 리버스 텔넷
피싱 경유지 악용	여러 경로에 웹쉘이 반복 생성
웹방화벽 우회	NullByte 우회 패치 미적용
웹 에디터 취약점	SmartEditor 파일 업로드 취약점
가상화 관리 서버	외부에 노출된 관리 서버의 취약점

 

경로는 달랐지만 공통 권고는 하나로 모입니다.

 

업로드 경로에서 스크립트가 실행되지 않게 하는 것.

다수의 웹쉘 사고가 이 설정 하나의 미비에서 비롯됐습니다.

 

⭐ 4. 업로드 경로, 이렇게 막습니다

가장 효과가 큰 조치

업로드 경로 보안 설정 [04]

 

항목	내용
경로 분리	업로드 디렉터리를 웹 루트 바깥으로 분리
권한 최소화	웹 서버 프로세스 계정의 쓰기·실행 권한 축소
IIS	처리기 매핑 비활성화 + 요청 필터링 함께 점검
Apache·Nginx	CGI/FastCGI 연동과 스크립트 핸들러 비활성화
서버측 검증	Magic Byte · MIME 타입 · 파일명 난수화
불필요 파일 제거	웹 에디터 샘플, 테스트용 업로드 경로

 

⚠️ IIS의 '읽기 전용' 설정만으로는 부족합니다

스크립트 실행 권한을 제거하는 것과 별개로,
처리기 매핑(Handler Mappings) 비활성화와
요청 필터링(Request Filtering)을 함께 확인해야 합니다.

읽기 권한만 조정하고 끝내면 실행 차단이 완성되지 않습니다.

 

확장자 차단 목록(.jsp, .jspx, .php, .asp, .aspx, .cer 등)은 출발점일 뿐입니다.

실제 적용 대상은 운영 중인 WAS와 웹 서버의 처리기 매핑을 기준으로 정해야 합니다.

 

그리고 확장자만 보고 안전성을 판단하지 않는 것이 핵심입니다.

 

5. 내부는 왜 그냥 열려 있을까

수평 이동의 통로

내부 접근 제어 [05]

 

흔한 구성	권고
외부 접근만 통제	필요한 포트만 허용
내부 통신은 전부 허용	WEB→WAS, WAS→DB
한 대 뚫리면 전부	관리 접근은 점프 서버 경유

 

DB 서버는 WAS 서버 IP만 허용하고 나머지는 차단해야 합니다.

관리용 SSH/RDP는 운영망 또는 점프 서버를 통해서만 접근하도록 구성합니다.

 

▶ 공유 폴더와 SMB는 목적이 다릅니다

 

대상	권고
외부 SMB	인터넷에서 TCP 445 접근 차단
내부 SMB	서버 역할별 접근 제어, 허용 IP 제한
불필요한 공유	제거 또는 사용 중지
필요한 공유	최소 권한, 계정별 접근, 쓰기 제한
기본 공유	ADMIN$ · C$ · IPC$ 는 필요 여부를 검토

 

SMB 포트 차단은 외부 노출 방지에 효과적이지만
내부 확산까지 모두 막지는 못합니다.

기본 공유도 무조건 삭제하기보다
필요성·접근 권한·관리 목적을 함께 검토하는 편이 적절합니다.

 

그리고 Everyone 권한이 없다고 안전한 게 아닙니다. 공유 권한과 NTFS 권한을 함께 확인해야 합니다.

 

6. 그밖에 짚어둘 것

자주 놓치는 지점

 

▶ 관리자 페이지

조치	내용
접근 제어	특정 IP만 허용
VPN 경유	VPN 접속 후 접근하도록 구성
MFA	다중 인증 적용

 

URL만 바꾸는 것으로는 충분하지 않습니다.

 

▶ 원격 관리 도구

TeamViewer, AnyDesk, VNC, mRemote 등 승인되지 않은 도구는 관리 사각지대를 만듭니다.

 

조치	내용
승인 도구만 사용	사용 가능 목록을 정해둡니다
자산으로 관리	설치 현황을 파악합니다
정기 제거	미사용 프로그램을 주기적으로 정리

 

실제 사례에서 TeamViewer에 서버 정보를 등록해둬 패스워드 없이 접근이 가능했던 경우가 있었습니다.

게다가 서버들이 같은 패스워드를 쓰고 있어 피해가 단기간에 확산됐습니다.

 

▶ MachineKey

ASP.NET 환경에서 인터넷에 공개된 예제 MachineKey를 쓰면 ViewState 위변조나 토큰 위조가 가능할 수 있습니다.

운영·개발·스테이징 환경별로 고유한 키를 사용하고, 소스 저장소나 CI/CD에 저장하지 않아야 합니다.

 

7. 로그 — 가장 아쉬웠던 부분

없으면 아무것도 못 합니다

권장 로그 보관 기간 [06]

 

사례 분석 결과 가장 큰 대응 애로사항은 로그 부족이었습니다.

 

구분	권장 기간(예시)
OS 시스템 보안 로그	6개월 이상
웹 접근 로그	6개월 이상 (개인정보 시스템은 1년 이상)
웹 오류 로그	6개월 이상
DB 감사 로그	1년 이상
VPN 접속 로그	1년 이상
백신 탐지 로그	6개월 이상

 

📏 공통 최소 기준은 아닙니다

위 수치는 일반적인 권고 예시입니다.

서비스 특성, 위협 환경, 법적·규제 요구사항에 맞춰
따로 산정하는 것을 권합니다.

개인정보 처리 규모(5만명 이상, 고유식별·민감정보 등)에 따라
기간이 더 길어질 수 있습니다.

 

▶ 중앙 로그 서버가 중요한 이유

원본 서버에서 로그가 삭제되거나 변조되는 경우에도 분석할 수 있어야 합니다.

별도 저장소로 전송하고 로그 접근 권한을 통제하는 구성이 필요합니다.

 

▶ 시스템별 설정

환경	설정
Windows	보안 로그 1~4GB 이상 · 감사 정책 활성화
Linux	journald 영구 저장 · logrotate 6개월 이상
웹	IP · 시간 · Method · URI · 응답코드 · User-Agent · XFF
DB	로그인 이력 · DDL 실행 · 대량 조회·변경 이력

 

8. 먼저 할 세 가지

우선순위를 정한다면

우선 적용 항목 [07]

 

순위	항목
①	업로드 경로 실행 권한 제한
②	불필요한 접속 차단 및 인증·권한 통제
③	중요 로그의 충분한 보관과 별도 관리

 

① 업로드된 파일이 서버에서 실행되지 않도록 권한을 제한하고, 확장자·실제 파일 형식·크기를 검증합니다. 가능하면 웹 서비스 경로와 분리된 위치에 저장합니다.

 

② 업무상 필요한 접속 주체·IP·포트·서비스만 허용합니다. RDP/SSH/VPN에는 강력한 인증을 적용하고, 관리자 계정 분리와 미사용 계정 비활성화를 병행합니다.

 

③ 주요 로그를 적정 기간 보관하고, 임의 삭제·변조를 방지할 수 있도록 접근 권한과 보관 위치를 관리합니다.

 

한 줄 정리

 

보안은 고가의 솔루션만으로 완성되지 않습니다.

실행 권한 제거, 접근 제어, 로그 보관.

이런 기본 설정을 충실히 적용하는 것이
침해사고 예방과 신속한 대응의 출발점입니다.

 

대응 경험상 가장 아쉬운 상황은 이것이었습니다.

 

"공격은 발생했지만 로그가 남아 있지 않아 무엇이 일어났는지 확인할 수 없는 경우."

 

그리고 일부 사고는 기본 설정만 제대로 돼 있었어도 예방하거나 피해를 크게 줄일 수 있었습니다.

 

※ 이 글은 실제 침해사고 대응 과정에서 확인된 내용을 유형별로 재구성한 일반 안내이며 특정 제품·업체를 평가하지 않습니다. 권고 사항은 참고 기준이며, 실제 적용은 운영 환경과 서비스 특성에 따라 검토가 필요합니다. 본 내용은 온프레미스 서버 환경을 중심으로 작성됐으며, 클라우드 환경은 서비스 유형 및 제공업체별 공동 책임 범위에 따라 별도 점검 기준을 적용해야 합니다.