서버 로그에 찍힌 의문의 'PROPFIND', 온프레미스 서버를 지키기 위한 고군분투기
평화롭게 서버 로그를 확인하던 중, 한 번도 본 적 없는 낯선 에러가 제 눈을 사로잡았습니다.
운영 중인 서버 로그에 평소라면 보이지 않아야 할 IP와 생소한 HTTP 메서드가 기록되어 있더군요. 바로 이런 내용이었습니다.
(그동안 회사 내부망에서만 테스트하던 프로젝트를 드디어 운영 환경으로 전환하고, 외부망에 공개했습니다. 이제 본격적인 운영인가 싶어 설레는 마음으로 로그를 확인하던 차에, 평소 보지 못했던 기괴한(?) 에러가.. )
org.springframework.security.web.firewall.RequestRejectedException:
The request was rejected because the HTTP method "PROPFIND" was not included within the list of allowed HTTP methods [HEAD, DELETE, POST, GET, OPTIONS, PATCH, PUT]
자세히 보니 만든 적도 없는 PROPFIND라는 메서드로 요청이 들어왔고, Spring Security가 이를 거부(Reject)한 상황이었습니다.
"이 IP는 누구지? 그리고 PROPFIND는 또 뭐야?"
이 질문이 이번 공부의 시작점이 되었습니다.
(메서드 자체를 처음 봐서, 처음에는 접속 IP 에 집중을 하지는 않았고, 메서드를 찾아보니 서버에 있는 파일을 조회할 수 있는 메서드더라구요.. 그래서 IP 를 확인해보니 외국으로 나와서 처음에 당황했습니다...실제 실무에서 처음 겪는 일이었어요..
당황해서 선임님께 여쭤보니 신경 안써도 된다고 하셔서.. 한숨 놓았습니다..)
1. 'PROPFIND'의 정체
조사해 보니 PROPFIND는 웹상에서 파일을 관리하는 WebDAV 프로토콜의 메서드였습니다. 서버에 어떤 파일이 있는지 목록을 조회하거나 속성을 파악할 때 쓰이죠.
중요한 건, 현재 서버는 WebDAV 서비스를 운영하지 않는다는 점!!,,
즉, 누군가(혹은 자동화된 봇이) 제 서버의 파일 구조를 캐내기 위해 던진 거입니다. 소위 말하는 '취약점 스캔 공격'의 흔적..
(수업시간에만 듣던걸 경험해보니 신기했습니당.)
클라우드 컴퓨팅이라는 수업 시간 때 보안과 관련된 수업을 들으면서, 보안 공격에 종류를 배웠었는데...
다음에 다시 상기시키며 글로 기록해보려 합니다.
우리가 웹 통신에서 사용하는 HTTP 메서드는 보통 7~8가지 내외입니다. 하지만 HTTP는 확장성이 뛰어난 프로토콜이라, 특정 목적을 위해 추가된 메서드들이 존재합니다. 그중 하나가 바로 WebDAV(Web Distributed Authoring and Versioning) 이라고 하네요.
- WebDAV란? 웹 서버를 마치 원격 드라이브(HDD)처럼 사용할 수 있게 해주는 프로토콜입니다. HTTP를 통해 파일을 생성, 수정, 이동, 복사할 수 있도록 설계되었습니다.
- PROPFIND의 역할 'Property Find'의 약자로, 서버에 있는 파일이나 디렉토리의 속성(이름, 크기, 생성 시간, 권한 등)을 조회할 때 사용합니다. 윈도우 탐색기에서 폴더를 더블클릭했을 때 파일 목록이 쫙 뜨는 기능을 웹에서 수행하는 메서드라고 이해하면 쉽습니다.
인터넷상에는 24시간 내내 전 세계 IP 주소를 무작위로 훑고 지나가는 '취약점 스캔 봇'들이 돌아다닙니다. 이 봇들이 PROPFIND 요청을 보내는 이유는 다음과 같습니다.
- 정보 수집(Enumeration) 서버에 설정 오류가 있어서 PROPFIND 요청에 응답할 경우, 서버 내부의 파일 구조와 디렉토리 리스트가 공격자에게 고스란히 노출됩니다.
- 취약한 서버 탐색 많은 공유기, NAS, 구버전 IIS 서버 등이 WebDAV를 사용합니다. 공격자는 이를 통해 보안 패치가 되지 않은 서버를 찾아내고, 다음 단계의 정밀 공격을 수행합니다.
- 관리자 페이지 탐색 /admin, /.env, /backup 같은 민감한 경로에 PROPFIND를 던져 파일의 존재 여부를 확인하기도 합니다.
누군가 내 서버 대문을 발로 툭 차보면서 "혹시 문 열려 있니? 안에 뭐 있는지 좀 보여줄래?"라고 물어본 상황
Spring Security의 핵심 방어 기제인 HttpFirewall 덕분에 공격이 통하지 않았던 것!
Spring Security는 요청이 내 비즈니스 로직(Controller)에 도달하기 훨씬 전인 필터 체인 앞단에서 위험한 요청을 걸러내는데
그중 기본 구현체인 StrictHttpFirewall은 아주 보수적인(?) 정책을 가집니다.
- 화이트리스트(Whitelist) 방식: "안전하다고 검증된 것 외에는 모두 차단한다."
- 표준 메서드만 허용: 기본적으로 GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS만 통과시킵니다. PROPFIND는 이 목록에 없으므로, 우리 서버의 소중한 리소스를 건드리기도 전에 입구 컷을 당한 것입니다.
해당 에러 코드는 보안 시스템이 정상적으로 공격을 방어했다는 '성공 보고서' 라 생각하면 되더라구요!
하지만 여기서 의문! 클라우드를 이용할 때는 보안 공격에 대한 대처 방안으로 IPS (Intrusion Prevention System, 침입 방지 시스템) 를 배웠었습니다. 하지만, 현재 환경은 온프레미스여서 아마 개별적으로 구현을 해야된다는 생각이 들더라구요..
(security 딴에서 보안을 성공했다고 하더라도, 해당 수업을 들었을 때 배웠던 점은 단지 "보안" 을 위해서 뿐이 아니라 서버의 자원 고갈(부하)을 방지 하기 위해서! 그렇기 때문에 온프레미스에서도 필요하지 않을까? 싶어요. )
이걸 내가 일일이 IP를 확인해서 차단해야 하나? 그건 너무 비효율적인데..."라는 고민이 시작돼서 좀 공부를 해봤습니다.
따로 구현해두면 되지않나? 라는생각을 하면서요..
2. 클라우드 보안 서비스의 부재와 나의 고민
예전에 보안 관련 강의를 들을 때나 클라우드 환경을 다룰 때는 이런 고민이 크지 않았습니다.
- AWS WAF나 Shield 같은 유료 서비스를 쓰면, 이런 비정상적인 패턴을 시스템이 알아서 감지하고 "이건 공격이네" 싶으면 입구에서 차단해 버리니까요.
- 하지만 지금 제가 운영하는 환경은 그런 화려한 옵션을 탑재하기 어려운 온프레미스(자체 서버) 환경입니다.
클라우드라면 '딸깍' 한 번에 해결될 일이지만, 온프레미스에서는 공격자가 초당 수십 번씩 요청을 던질 때마다 우리 서버의 자원이 낭비되는 것을 지켜봐야 합니다. "이걸 내가 일일이 IP를 확인해서 차단해야 하나? 그건 너무 비효율적인데..."라는 생각이 들었습니다.
3. 온프레미스에서 찾은 '가성비' 자동화 방어 전략
지속 가능한 운영을 위해, 비싼 서비스 대신 개발자가 직접 구축할 수 있는 방어 체계들을 공부하기 시작했습니다. 이번 장에서는 그 대안들의 개념을 정리해 보려 합니다.
① Fail2Ban: 로그를 감시하는 자동 차단기
가장 먼저 눈에 들어온 도구입니다. 서버 로그를 실시간으로 스캔하다가, 짧은 시간 내에 RequestRejectedException 같은 특정 에러를 반복적으로 발생시키는 IP를 발견하면 서버 방화벽(iptables)에 즉시 등록해 차단합니다.
- 공부한 점: "사람이 직접 막지 않아도 시스템이 로그를 보고 스스로를 보호하게 만들 수 있구나"라는 자동화의 가치를 배웠습니다.
② Nginx 레벨의 메서드 화이트리스트
Spring Security(Tomcat)까지 요청이 들어오기 전에, 웹 서버인 Nginx 단계에서 미리 쳐내는 방법입니다.
- 공부한 점:
if ($request_method !~ ^(GET|POST)$ ) { return 444; }같은 설정을 통해, 허용되지 않은 메서드는 응답조차 주지 않고 연결을 끊어버릴 수 있습니다. 애플리케이션 자원을 아끼는 가장 효율적인 단계임을 확인했습니다.
③ ModSecurity (오픈소스 WAF)
클라우드 WAF가 부럽다면 사용할 수 있는 오픈소스 대안입니다. 요청의 내용을 분석해 SQL 인젝션이나 비정상적인 접근을 차단합니다.
- 공부한 점: 설정은 다소 복잡하지만, 온프레미스에서도 엔터프라이즈급 보안을 구현할 수 있는 강력한 도구라는 점을 알게 되었습니다.
4. 왜 이 공부를 지속해야 하는가?
처음에는 단순히 "로그가 거슬려서" 시작한 공부였습니다. 하지만 파고들수록 보안은 단순히 에러를 없애는 작업이 아니라, 서버의 한정된 자원을 효율적으로 관리하고 잠재적인 위험을 사전에 차단하는 '설계'의 영역이라는 것을 느낍니다.
단순히 "Spring Security가 잘 막아줬으니 끝!"이라고 생각할 수도 있지만, 공격이 거세지면 그 방어 과정조차 서버에 부담이 됩니다. 그래서 더 효율적으로, 더 앞단에서 막는 법을 고민하게 되었습니다.
5. 마치며: 실전 적용 해보자!!
지금까지는 로그 한 줄에서 시작된 호기심과, 온프레미스 환경에서 선택할 수 있는 대안들을 이론적으로 훑어보았습니다.
다음 포스팅에서는 제가 공부한 이 개념들을 바탕으로, 실제로 Nginx 설정과 Fail2Ban을 서버에 연동하여 공격 IP를 자동으로 격리하는 과정을 실습해 보고 그 결과를 공유하겠습니다.
클라우드라는 편안한 울타리는 없지만, 내 손으로 직접 방어선을 구축해볼 생각을 하니 설레용..ㅎㅎ