[인프라보안 프로젝트5] WAF(Nginx + ModSecurity)를 활용한 애플리케이션 계층(L7)보안 강화

1. 개요 및 기획 의도 

 현대 웹 서비스는 단순한 정보 전달을 넘어 복잡한 비즈니스 로직을 수행함에 따라, 기존 네트워크 방화벽(L3/L4)만으로는 탐지하기 어려운 애플리케이션 계층(L7) 공격에 노출되어 있습니다. 특히 SQL Injection, XSS과 같은 공격은 유효한 HTTP 패킷으로 위장하여 침입하기 때문에,, 이를 전문적으로 필터링할 수 있는 WAF의 도입이 필수적이라 판단하여 WAF를 도입했습니다.

 

 해당 프로젝트에서는 인프라의 경제성과 보안성을 동시에 확보하기 위해 오픈소스 기반의 WAF 솔루션을 구축하였습니다.

• 산업 표준의 보안성 : ModSecurity는 WAF 분야의 사실상 표준으로, 전 세계적으로 검증된 OWASP Core Rule Set(CRS)을 활용하여 강력한 탐지 기능을 제공합니다.
• 유연한 아키텍처: 구성도와 같이 Reverse Proxy 환경(Nginx)에 ModSecurity를 모듈 형태로 통합 함으로써, 실제 웹 서버의 자원 소모를 최소화하고 보안 기능을 전면에서 집중 관리할 수 있습니다.

따라서 ModSecurity는 단순히 오픈소스 WAF이기 때문에 사용된 것이 아닌, 경제성과 보안성, 호환성까지 챙길 수 있기 때문에, 선택하게 되었습니다.

 

2. WAF 동작 메커니즘

사용자가 GUI에서 입력한 Custom Nginx Configuration은 실제 서버 내부의 Nginx 가상 호스트 설정 파일에 동적으로 삽입됩니다.

1. 사용자 요청 : 클라이언트가 www.esa.com 으로 로 접속을 시도합니다.

2. 심층 패킷 검사 (L7 Inspection) : ModSecurity 엔진이 요청 패킷을 가로채서 OWASP CRS 규칙과 대조합니다.

3. 필터링 결과 :
정상 : 요청을 백엔드 웹서버 (10.10.1.3)으로 전달합니다.
공격감지 : 요청을 즉시 차단하고 사용자에게 403 Forbidden 응답을 반환합니다.

 

3. 환경 설정 및 인터페이스

Nginx Proxy Manager의 웹 GUI

 1. Nginx Proxy Manager를 접속합니다. 그다음, Proxy Host를 클릭합니다.

2. Proxy Host 에서 운영하고 있는 서버에 Edit을 누릅니다.

3. Custom Nginx Configuration에 쿼리 스트링 차단문(SQL 인젝션 방어)을 넣고 그다음, 클라이언트 실제 정보 전달을 위한 프록시 설정값을 넣어주었습니다. 

 

쿼리 스트링 차단

• ~* : 대소문자를 구분하지 않고 정규표현식과 일치하는지 확인함
• ' | -- | # : SQL 구문 오류를 유발하거나 뒷부분의 쿼리를 주석 처리해버리는 대표적인 특수문자들
• union | select | insert | delete | update | drop : 데이터베이스의 정보를 빼내거나 조작하는 주요 SQL 명령어들
• or.*1=1: " 항상 참(True)"을 만들어 인증을 우회하는 가장 고전적인 SQL 인젝션 패턴을 잡아냅니다. 
• return 403; : 위 패턴 중 하나라도 발견되면,, 백엔드 서버로 요청을 보내지 않고 Nginx 단에서 즉시 403 Forbidden(접근 금지) 에러를 반환하여 공격을 차단합니다.

프록시 설정

• Host $host :  사용자가 원래 요청한 도메인 주소를 그대로 전달합니다.
• X-Real-IP $remote_addr : WAF를 거치기 전, 클라이언트(접속자)의 진짜 IP 주소를 헤더에 담아 전달합니다.
• X-Forwarded-For $proxy_add_x_forwarded_for; : 클라이언트가 여러 대의 프록시를 거쳐왔을 경우, 거쳐온 모든 IP 목록을 쉼표로 구분하여 기록합니다. 이를 통해 서버 로그에 실제 해커(혹은 정상 사용자)의 IP가 남게 됩니다.

4. 하지만, 이러한 세팅값은 modsecurity를 사용하는 것은 아닙니다. 따라서, modsecurity를 사용하려면, 설정값이 바뀌어야겠죠,

modsecurity on; 으로 modsecurity를 껐다 켜면 참 편리하겠지만, Nginx에는 기본적으로 modsecurity을 내장하고 있지 않기 때문에 아래와 같은 작업이 이루어져야 합니다.

 

4-1. 설정 파일

ModSecurity를 켰다면, "어떤 기준"으로 검사하고 차단할지 규칙이 적힌 파일을 지정해 주어야 합니다.

제가 아는 방식으로는 2가지 방식이 존재하고, libmodsecurity와 modsecurity-nginx 두 개를 git clone으로 가져와 nginx 소스코드와 함께 빌드(컴파일)를 해서 ngx_modsecurity_module.so라는 동적 모듈 파일을 직접 만들 것이냐,

아니면 Docker를 이용하여 적용할 것이냐 두 가지입니다. 저는 docker를 이용하여, modsecurity와 OWASP CRS를 적용하였습니다.

docker-compose.yml

 해당 도커 컴포즈 파일은 image 줄을 읽자마자, 기본적으로 도커 허브에 있는 클라우드 저장소로 가서, OWASP 공식 저장소에서 배포하는 검증된 이미지(owasp/modsecurity-crs)의 nginx 태그 버전을 당겨오는 컴포즈 파일입니다.

docker compose ps 명령어를 통해 확인한 docker의 상태

해당 명령어를 통해 docker가 up상태라면, Custom Nginx Configuration내용을 전부 삭제해도 됩니다.

Docker가 그 역할을 대신 수행할 테니까요!

4. 공격 시뮬레이션 및 차단 결과 확인

간단한 인젝션 테스트를 진행해 보았습니다.

리눅스의 패스워드 파일을 훔쳐보려는 해킹 시도

이 공격 방식의 원리는 아래와 같습니다.

• LFI(Local File Inclusion, 로컬 파일 포함 공격)
  • 원리 : Path Traversal 기법(../)으로 경로를 뚫어낸 뒤, 파라미터(?file=)를 조작해 서버 시스템 내부에 존재하는 특정 로컬 파일의 내용을 웹 페이지 화면에 강제로 불러와 읽어버리는 공격
  • 타겟 (/etc/passwd) : 리눅스 시스템 계정 정보가 담겨 있는 파일입니다.

위와 같이 차단된 로그를 WAF서버에서 sudo docker logs -f waf-gate를 통해 실시간으로 확인할 수 있습니다.

WAF서버에서 차단시킨 로그

 

5. 성과 및 배운 점

• 성과
  • 성과라고 한다면, WAF(ModSecurity)와 리버스 프록시(NPM)라는 두 개의 독립적인 컨테이너를 조합하여, 
    하나의 보안 게이트웨이를 만들었다는 점입니다. 하나의 프로그램에 방어와 길 안내를 다 때려 넣지 않고, 각자 특기만 살리도록 분리한 점이라고 생각합니다.
  • OWASP ModSecurity(방패) : 오직 '보안' 하나만 파고듭니다. 외부에서 들어오는 패킷을 뜯어보고 앞서 날렸던 SQL 인젝션이나 LFI(../../etc/passwd) 같은 해킹 공격을 막는 순수 WAF 역할을 담당합니다.
  • Nginx Proxy Manager(길안내): 보안 검사를 무사히 통과한 깨끗한 트래픽만 넘겨받습니다. 복잡한 방어 룰은 신경 쓸 필요 없이 SSL(HTTPS) 인증서를 달아주고 사용자가 원하는 백엔드 서버로 트래픽을 전달하는 프록시 본연의 임무에만 집중합니다.
• 배운 점
  • 이 시스템을 구축하면서 배운 점이라면 크게 두 가지였습니다.
    • 설정 한 줄 넣는다고 Modsecurity가 작동하는 게 아니었습니다.
      처음엔 단순히 NPM 웹 GUI에서 Custom Nginx Configuration 칸에 modsecurity on; 한 줄만 넣으면 OWASP CRS가 방어를 시작할 줄 알았습니다. 하지만 진짜 문제는 도커 컨테이너 그 자체에 있었습니다.
      프록시 역할을 하는 NPM 컨테이너만 살아있었고, 정작 필요한 waf-gate 컨테이너는 뻗어있는 상태였었습니다.
      waf-gate를 정상적으로 Up 시키고, NPM의 수동 설정값들을 싹 지웠습니다. 그제야 불순물 하나 없이, 
      ModSecurity의 OWASP CRS가 인젝션 공격을 방어하는 로그를 볼 수 있었습니다. 
    • 두 번째는 WAF 우회 현상입니다. 
      생각보다 간단한 문제이긴 한데, 테스트 과정에서 계속해서 인젝션 방어에 실패하고, 또한, 로그 또한 캡처하지 못해서 무언가가 잘못되었다고 생각은 했으나 정확한 원인을 전혀 찾아볼 수 없었습니다. 
      알고 보니, WAF가 지키고 있는 대문(10.10.1.10)을 무시한 채 웹 서버(10.10.1.3)에 다이렉트로 공격을 꽂아 넣고 있었습니다. 
      당연히 WAF 입장에서는 구경도 못한 트래픽이니 막을 수도, 로그를 남길 수도 없었던 거였죠,
      보안 장비가 아무리 좋아도 트래픽이 그 장비를 무조건 거치도록 네트워크 길목을 통제하지 않으면 아무 소용이 없다는 교훈을 얻었습니다.

정상적으로 waf-gate와 nginx-proxy-manager의 docker가 up상태

 

다음 단계는 SIEM(Splunk)와 AI를 이용한, 보안 로그 수집 및 이벤트 분석 및 실시간 보안 알림 자동화 시스템에 대하여 살펴 보실 수 있으실 겁니다. SIEM에 AI를 이용한 지능형 보안 관제 시스템을 다음 파트에서 설명드리겠습니다.