네트워크 구간에 설치시 장애에 대한 다양한 대비책 세워야

고객사들은 모든 웹 서버에 보안서비스를 도입하기를 원한다. 그 중에는 잘 쓰이지 않는 작은 웹 서버부터 메인 포털서버까지 다양하다. 그러나 한정된 자원을 가장 효율적으로 산정하려면 꼭 보호해야 할 서버를 먼저 선정하고 웹 방화벽 도입 사업을 진행하는 것이 맞다. 또한 보안팀에서 웹 방화벽을 도입하려 한다고 웹서비스 담당자들이 다 선호하는 것은 아니다.

웹 보안 솔루션으로는 소스분석 툴, 취약점분석 툴 그리고 웹 방화벽이 있다. 그 중 웹 방화벽은 기존 애플리케이션을 수정하지 않고 이미 존체하는 취약점에 대한 능동적인 방어기술로 웹 보안 시장에서 가장 큰 관심을 받고 있다. 웹 방화벽은 크게 공개용과 상용으로 나뉜다. 공개용으로 가장 폭넓게 쓰이는 두 가지 제품이 있다.

1. Aqtronix사의 WebKnight (www.aqtronix.com)

IIs 웹 서버의 ISAPI 필터 형태로 설치된다. 기능을 보면 룰 기반으로 다양한 웹 공격을 막을 수 있고 Log Only 및 차단모드 선택이 가능하다. 그리고 White List 필터링 방식 지원으로 허용할 URL/폴더에 대해 키워드 등록할 수 있어 간단한 포지티브 정책을 세울 수도 있다.

2. BreachSecurity사의 ModSecurity (www.modsecurity.org)

Apache 웹 서버의 공개용 웹 방화벽으로 소스를 컴파일 하거나 동적공유객체(DSO)로 설치가 가능하다. 최근 V2.5가 공개되어 좀더 많은 기능을 제공하고 있다. SQL Injection, CGI 공격, Directory Traversal 같은 다양한 웹 공격 차단을 할 수 있다.

이러한 공개용 웹 방화벽은 허용(Positive) 정책에 대해서는 일부 가능하지만 그 기능이 미미하고 대부분 비허용(Negative) 정책에 의해 웹 공격을 방어하게 된다. 비허용 룰셋은 여러 보안커뮤니티들에서 보급하고 있다. 그러나 공개 웹 방화벽의 단점은 아무도 룰셋에 대해 보장해 주지 않고 그 책임을 사용자가 진다는 것이다.

한편 상용 웹 방화벽 탐지기술의 장점은 HTTP 프로토콜 속성 값의 작은 단위까지도 자세한 정책설정이 가능하다. 웹서비스 개발 시점에 미처 고려하지 못했던 보안상의 문제점들을 보완 할 수 있어 웹서비스를 보다 안전하게 사용자들에게 제공할 수 있다. 또한 상용 웹 방화벽은 부가적으로 웹 가속기능이나, SSL 가속기능, 개인정보 필터링 기능들을 지원한다.

상용 웹 방화벽은 국내 제품과 외산 제품이 다양하게 출시되어 시장에서 경합 중이다. 외산은 글로벌 마켓쉐어(Market share)와 뛰어난 성능을 강점으로 진출하였으나 CC인증문제와 국내 웹 환경의 적응부족으로 제품 출시 기간에 비해 크게 퍼지고 있지는 못하고 있다. 외산 웹 방화벽 중에는 테로스, F5, 넷컨티넘, 시큐어스피어 등이 보안 시장에서 간간히 보이는 정도이다.

반면 국산 웹 방화벽은 CC인증을 기반으로 공공시장에서 각광을 받고 있다. 또한 해외보다 복잡한 국내 웹 환경에 최적화되어 외산 대비 훨씬 높을 보급율을 가지고 있다.

WAF 도입시 고려사항

웹 애플리케이션 도입시 고려 사항은 웹 방화벽 보호 대상 서버 선정과 웹 방화벽 트래픽 용량산정, 그리고 웹 방화벽 설치구간 선정이다.

고객사의 웹 보안을 컨설팅하다 보면 모든 웹 서버에 보안서비스를 걸기를 원한다. 그 중에는 잘 쓰이지 않는 작은 웹 서버부터 메인 포털서버까지 다양하다. 그러나 한정된 자원을 가장 효율적으로 산정하려면 꼭 보호해야 할 서버를 먼저 선정하고 웹 방화벽 도입 사업을 진행하는 것이 맞을 것이다. 또한 보안팀에서 웹 방화벽을 도입하려 한다고 웹서비스 담당자들이 다 선호하는 것은 아니다. 이미 침해사고를 경험한 담당자는 당연히 선호할 것이고 아무런 보안이슈가 없던 담당자는 귀찮음을 표시 하는 것이 일반적 이였다.

보호 대상 웹 서버를 선정하였다면 해당 웹 서버의 트래픽 용량을 산정해야 한다. 여기서 이슈가 발생한다. 용량을 어떻게 선정할 것인가에 대해 네트워크 관점으로 접근해버리면 단순 트래픽의 대역폭(Bandwidth) 만을 고려하게 되는데 웹에서의 부하는 네트워크에서 접근하는 것과는 조금 다른 웹서비스 관점에서 접근하는 것이 옳다. 얼마나 많은 대역폭(Bandwidth)을 점유하느냐는 사실 절대적인 수치에서 보면 중요하지 않다. 1Gbps 전용선 라인을 쓰더라도 웹서비스의 접속량(HTTP Request/ Response)이 미미하다면 작은 사양의 웹 방화벽 장비로도 충분할 것이다. 이에 반해 대역폭은 2~300Mbps 남짓 되더라도 엄청나게 많은 User들이 동일시간에 접속하는 서비스라고 하면 이것은 웹에서 보면 엄청난 트렌젝션이 될 수 있다. 일례로 필자가 컨설팅 한 제품이 납품된 국가 자격증을 관리하는 사이트는 자격증 발표 날에 약 40만 명 이상이 9시 정각에 접속한다. 이는 대역폭으로 보면 단순 HTTP Packet이기 때문에 크지 않지만 웹 접속량으로만 보면 웬만한 웹 방화벽으로는 감당하기조차 힘든 어마어마한 부하이다. 따라서 웹 방화벽을 도입하기 전에 우리 웹서비스에 시간당 최대 부하율 (hits/hours)을 알고서 용량을 산정한다면 장비를 공급하는 업체에서도 적정 용량을 산정하기가 쉽다.

보호대상 웹 서버도 선정하였고 해당 웹 서버의 트래픽에 의거한 웹 방화벽 용량도 산정하였다면 웹 방화벽의 설치구간을 정하는 것이 그 다음 이슈가 된다. 초기 웹 방화벽은 웹 서버 하나를 막기에도 역부족일 정도로 성능이 부족한 적도 있었으나 현재는 여러 벤더의 경쟁과 비약적인 하드웨어의 발전으로 웹 방화벽 하나가 적게는 몇 개에서 많게는 백여 대 정도의 웹 서버까지 보호할 수 있게 되었다. 그래서 웹 방화벽 설치구간이 좀더 다양해지게 되었다. 웹 방화벽을 설치하는 데는 크게 Host 방식(SW제품), Reverse Proxy 방식, In-Line 방식으로 나뉜다. 최근에는 90% 이상이 구성상의 편이점 때문에 In-Line 방식을 선호한다. 각 기관의 예산이나 보안정책에 따라 단수 웹 방화벽을 도입할 것인지, 또는 이중화를 위해 복수의 웹 방화벽을 구축할 것인지 정해진다.

단수이든 복수이든 웹 방화벽은 웹 서버 바로 앞에 설치되는 것이 가장 좋다. 다른 구간의 서비스 이슈에 영향을 최소화 하고 장애 포인트를 줄여 웹 방화벽 운영 담당자로 하여금 여러 가지 스트레스 상황을 줄여줄 수 있다. 그러나 웹 서버가 여러 구간에 분산 설치되어 있다고 하면 이도 쉽지 않은 선택이다. 결론은 단수 웹 방화벽은 DMZ 구간과 같이 웹 방화벽 하나가 모인 구간에 웹 방화벽을 설치하고 하단에 L2 스위치를 추가하여 웹 서버 이외의 서비스에 대한 영향을 최소화 하는 것이 최선의 선택이라 본다.

복수 웹 방화벽은 이중화 방식에 따라 Active-Active/Active-Standby로 달라진다. 최근에는 몇몇 선두 업체들을 중심으로 이중화된 장비간 정책동기화와 세션 동기화가 완성되어 장비간 Async Path(Request와 Response가 다른 경로를 경유)도 지원하고 있어 L4 스위치 없이 Active-Active 구간에 설치가 가능해졌다. 이런 장비를 도입한다면 네트워크 앞단의 Back-bone 망에 설치가 용이 하다.

웹 방화벽 구축 시 고려사항

1. 장애상황 대책

웹 방화벽을 소프트웨어 방식이 아닌 네트워크 구간에 설치시 장애에 대한 다양한 대비책을 세워야 할 것이다. 초기 하드웨어 웹 방화벽은 앞에서도 언급했듯이 Reverse Proxy 형태로 설치되었고 이때는 L4에서 웹 방화벽의 서비스 Port 를 Health check 하여 장애상황이라 판단되면 바로 웹 서버로 넘길 수 있도록 하였다. 최근에는 In-Line 형태로 설정되기 때문에 장비자체에 하드웨어 Bypass 모듈이 설치되고 내부에는 소프트 Bypass 기능을 넣어 웹 방화벽의 내부 기능에 문제가 생겨도 bypass 될 수 있도록 하고 있다.

2. 탐지(모니터링) / 차단 일정 수립

웹 방화벽은 탐지(학습) 기간을 갖는다. 이는 포지티브 정책을 만들고 그에 따른 오탐에 대한 예외조치를 하기 위에서 이다. 가장 이상적인 것이 대부분의 벤더가 지원하는 자동학습이나 이는 실 사이트 환경에서 쓰기기 힘든 부분이 많은 것이 또한 공공연한 비밀이다. 지속적으로 변하는 사이트를 학습하기란 이론적으로 불가능하고 정적인 사이트라 하더라도 학습한 결과에 대해 다시 보안담당자가 점검해야 하는 번거로움이 발생한다. 이에 포지티브 정책을 수동으로 설정하는 것이 현실적이다. 그리고 보안정책을 건 상태에서 혹시 모를 장애상황이나 오탐들을 예외 처리하여 실 보안 서비스(차단)에 들어가서 정상적인 업무 프로세스가 차단되는 것을 미연에 방지하는 과정이다.

3. 웹 애플리케이션에 맞는 보안정책 설정 및 기존 취약점 보안 권고

탐지기간을 갖고 예외처리를 진행 하다보면 종종 너무 위험한 취약점이 드러나는 경우가 있다. 이 부분은 해당 사이트를 컨설팅하면서 반드시 빠른 시간 내에 수정하기를 권고한다. 예를 들면 URL 상에 SQL이 그대로 드러나는 경우이다.

WAF 운영시 고려사항

WAF 운영시 고려해야하는 사항은 우선 웹 방화벽에 대한 보안 담당자의 이해와 새로운 보안 이슈에 대한 웹 방화벽 패치, 추가되는 웹 애플리케이션에 맞는 보안정책 설정, 그리고 침해 사고 발생시 대응이다.

웹 방화벽은 기존 보안담당자들이 제일 어려워하는 보안장비이다. 네트워크뿐만 아니라 애플리케이션에 대한 지식을 같이 가지고 있어야 하기 때문이며 실 사이트에서는 이것 때문에 운영부서끼리 서로 미루는 일이 상당수 발생한다. 가장 좋은 상황은 동일 부서에서 웹서비스와 보안관리를 같이 운영할 때다. 그러나 이것이 여의치 않거나 웹서비스와 보안부서가 분리되어 있는 기관이라면 상당수 트러블은 각오해야 해야 한다. 웹서비스 운영 팀에서는 무조건 서비스를 Open 하라고 요청하고 보안팀에서는 장비에 걸린 차단 로그를 일일이 확인 후 대응방법을 찾은 후 웹서비스를 Open 하려고 하기 때문이다. 이는 두 부서 간에 사전조율 후 웹 방화벽이 도입되기 전에 이런 문제가 발생할 가능성에 대해 미리 업무협조라인을 만들어 놓는 것이 나중에 부서간의 싸움으로 번지지는 사태를 예방 할 수 있다.

한편, 보안 컨설팅을 하면서 염두에 두는 주 적은 해커다. 또한 그들은 가장 고마운 친구이기도 하다. 그들은 매번 새로운 공격기법을 만들어 보안 컨설턴트들을 긴장하게 만들고 보안엔지니어가 사회에서 꼭 필요한 사람이라는 것을 알게 해준다. 따라서 새로운 공격기법이 나올 때 마다 간단하게는 룰셋을 업데이트하거나 새로운 공격패러다임이 나오게 되면 웹 방화벽의 일부모듈을 패치해야 하는 상황이 발생하기도 한다. 이에 따라 보안 담당자는 웹 방화벽 벤더의 패치를 잘 이해하고 수행해야 할 것이다.

아울러 모 대기업 보안 담당자의 말을 빌리자면 침해사고는 기존에 잘 정돈된 애플리케이션 보다는 새로 개편되거나 추가되는 웹 페이지들에서 발생한다고 한다. 웹 방화벽도 별반 다르지 않다. 새로 추가되는 애플리케이션에 대한 보안정책을 잘 새우지 않으면 결국 지금까지 잘 운영해 왔던 공이 허수로 돌아가는 불상사가 생길 수 있으므로 새로 개설되어 추가되는 사이트에 대해서도 좀더 철저한 분석을 통해 잘 정의된 보안 정책을 설정할 필요가 있다.

침해 사고, 발생시 대응이 관건

아무리 잘 구축된 보안장비와 잘 훈련된 보안 엔지니어가 있다고 해도 침해사고에서 자유로울 수는 없다. 먼저 사이트가 변조되던가 하는 공격의 흔적이 있다면 계약한 웹보안 업체에 알려 추가공격에 대비하고 해당 공격을 분석하여 새로운 보안정책을 새워야 할 것이다. 침해 사고시 당황하지 않고 절차에 의해 분석과 대응을 한다면 반복되는 침해를 막을 수 있고 경영진의 문책을 조금이라도 약화 시킬 수 있을 것이다.

<글 : 안종찬 트리니티소프트 기업부설연구소 과장>

[월간 정보보호21c 통권 제107호 (info@boannews.com)]

<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>