최근에는 웹 서버나 애플리케이션 플랫폼, 혹은 애플리케이션 코드에 간단한 버그 하나만 있어도 큰 일이 터질 수 있다. 웹 서버를 막아두기는 쉽지만(바라건대) 이런 써드파티 웹 애플리케이션을 보안하는 것은 어떨까? 아마도 당신에게는 변경을 하기 위해 소스 코드로 액세스할 수 있는 권한이 없을 것이며, 있다고 하더라도 보안을 아는 코더들로 이루어진 스탭이 필요할 것이다. 다행히도 있을지 모르는 공격자들에 대항해 벌이는 끝없는 싸움에서 도움을 줄 수 있는 제품들이 있는데, 이들이 바로 웹 보안 프록시(Web security proxy)들이다.

웹 보안 프록시는 보통 웹 애플리케이션 방화벽이라 불리며, 웹 서버의 앞에 배치되어 자신을 통과하는 모든 트래픽을 점검 및 검증함으로써 공격자가 웹 서버나 애플리케이션에 도달하기 이전에 이들을 잡아내는 것이 그 목표다. 프록시 구조상 이런 제품들은 서버 종류에 관계가 없으며, 심지어 SSL 암호화 부하를 덜어줄 수도 있다.

네트워크 방화벽보다 훨씬 더 복잡

여기까지 보면 완벽해 보이는데, 과연 정말일까? 구매 결정을 내리기 이전에 먼저 이런 제품들이 우리의 테스트 공격을 막는 데 얼마나 도움이 되었는지를 살펴보는 게 나을 것이다.

우리는 어레이 네트웍스(Array Networks), 사이퍼트러스트(CipherTrust), 커베이두(Kavado), 멀티넷 시큐리티(MultiNet Security), 넷컨티늄(NetContinuum), 생텀(Sanctum), 스피어헤드(Spearhead), 테로스(Teros: 구 생텀8), 유비전(Ubizen), 웹스큐리티(WebScurity) 및 웨일 커뮤니케이션즈(Whale Communications) 등의 업체들을 초대했다.

어레이 네트웍스와 웨일 커뮤니케이션즈는 자사 제품 테스트를 거절했으며 사이퍼트러스트는 이번 분석기 사용으로 제품이 적합하지 못하다는 이유를 댔다. 넷컨티늄은 여분의 제품이 없다고 말했으며, 스피어헤드는 진행 중인 아키텍처 개선 작업 때문에 자사 제품인 넷갭(NetGap) 어플라이언스를 다시 가져갔다. 그리고 유비전은 초대에 아무 대답이 없었다.

다른 두 업체인 길리언(Gilian)과 넷스케일러(NetScaler)는 여기 포함시키지 않았는데, 그 이유는 길리언에서는 우리의 테스트가 끝날 때까지 애플리케이션 보안 모듈을 내놓지 않고 있었으며, 넷스케일러 제품의 경우는 기사를 작성할 때까지 우리가 알지 못했다. 또한, 이아이 시큐어IIS(eEye SecureIIS)나 마이크로소프트 유알퍼스트스캔(Ur1Scan) 등 많은 호스트 기반 웹 보안 제품들이 있지만 우리가 중점을 둔 것은 프록시 기반 웹 애플리케이션 방화벽이었기 때문에 이들은 테스트하지 않았다.

커베이두의 인터두(InterDo), 멀티넷의 아이시큐어웹(iSecureWeb), 생텀의 앱실드(AppShield), 테로스의 APS 및 웹스큐리티의 웹앱닷시큐어(webApp.Secure) 등의 제품들이 시카고 네오햅시스 파트너 랩에 수거되었으며, 우리는 이들에게 보안 상태가 끔찍한 테스트 웹 사이트 두 개를 보호하라는 임무를 내렸다.

성공적인 공격 방어만이 우리의 비교 범주는 아니었다. 제품 구성의 유연성 또한 매우 중요한 부분이다. 이론적으로 이런 제품들은 일반적인 네트워크 방화벽과 유사하다. 너무 적게 열면 트래픽에 영향이 미치며, 너무 많이 열면 보안 위험에 네트워크가 노출이 된다. 하지만 실제로 웹 보안 프록시는 네트워크 방화벽보다 훨씬 더 복잡하며, 이들의 구성도 까다로울 수 있다. 프록시는 웹 애플리케이션의 내부 작동을 이해하고 있어야 한다. 보안 구성이 웹 애플리케이션과 공생관계이지 못하면, 취약점이 노출된 채 내버려지는 위험에 처하게 되므로, 자신의 사이트에 적용시키기 쉬운 제품일수록 보안 효과는 강해진다.

미리 계획하라

수 개월의 테스트 작업을 거친 후, 우리는 웹 보안 프록시를 추가하는 데 있어서는 구성이 완벽하게 튜닝되어야만 방어 효과를 얻을 수 있다는 사실을 알게 되었다. 어떤 보안 프록시를 배치할 것인가의 결정 여부는 보호하고 있는 웹 애플리케이션에 따라 크게 좌우된다. 사실 가장 높은 수준의 보안을 얻기 위해서는 선택한 보안 프록시의 뉘앙스와 조화를 이루도록 웹 사이트와 애플리케이션을 만들어야 한다. 이를 위한 몇 가지 팁을 소개하자면 다음과 같다:

>> 웹 애플리케이션을 분리하라

글로벌 구성의 한계란 하나의 애플리케이션을 포함시킴으로써 다른 것의 생산성이 떨어지는 것을 말한다. 여기에 대한 해결책은 크고 복잡한 웹 애플리케이션을 따로 분리시키고 각각 그 애플리케이션의 보안 필요에 맞게 튜닝된 여러 개의 보안 프록시를 배치하는 것이다.

>> 클라이언트 측 폼 필드 필터링을 이행하라

많은 보안 프록시들이 비 보안 HTML 양식 데이터 등록을 갑작스럽게 중단함으로써 뜻하지 않게 제한된 문자를 포함시킨 사용자를 혼란스럽게 하거나 두렵게 할 수 있다. 능동적인 스크립팅을 통한 클라이언트 측 폼 필드 필터링(form-field filtering)을 이행함으로써 사용자들이 악성 문자 경보를 우발적으로 트리거링하는 일이 없도록 해야 한다.

>> 전용 데이터 포맷을 조심하라

마이크로소프트 RDS(Remote Data Service)나 자바 RMI(Remote Method Invocation)와 같은 전용 데이터 포맷을 HTTP를 통해 터널링하는 애플리케이션에게는 도움될 게 거의 없다. 보안 프록시가 전용 데이터를 통과하게 할 수는 있겠지만, 그것을 보안하는 프록시가 혼자서 그것을 이해할 것이라고는 기대하지 말라. 예를 들어 테스트한 제품들 중 우리의 취약한 프론트페이지(FrontPage) 웹사이트를 지킬 수 있었던 제품은 하나도 없었는데, 그 이유는 제품들이 프론트페이지에서 사용된 RPC(Remote Precedure Call) 메커니즘을 이해하지 못했기 때문이다.

>> HRML을 점검하라

어떤 프록시들은 클라이언트로 보내질 때 HTML 페이지를 파싱(parsing)한다. 잘 짜여진 양식의 HTML을 사용하고 클라이언트 측 자바스크립트 폼 조작을 피한다면 프록시가 애플리케이션을 보다 잘 이해하고, 따라서 보다 잘 보호해줄 수 있을 것이다.

>> 보안 테스트를 실시하라

구성이 검토되도록, 혹은 구성이 잘 됐는지를 확인하기 위해 보안 침해 테스트가 수행되도록 하라. 정식 표현 규정이 하나만 잘못돼도 사이트의 취약성이 방치될 수 있지만, 이것은 쉽게 확인되는 게 아니다. 시중에 있는 수많은 보안 서비스 회사들 중 하나와 표준 웹 애플리케이션 보안 평가 계약을 맺는 것이 출발점이며, 보호되는 웹 사이트에서 이들이 어떤 취약점을 발견한다면(아마도 그렇겠지만) 보안 프록시가 적절히 구성되지 않았다는 사실을 알 수 있다. 게다가 일부 보안 프록시 업체들은 구성 교육과 온라인 이행 리뷰를 실시하고 있으며, 테로스 같은 업체들은 심지어 초기 구매가에 이것까지 포함시켰다.

>> 서버를 패치하라

마지막으로 보안 프록시가 있다고 해서 서버를 패치해야 할 필요가 없어지는 것은 아니다. 단순히 거기에 대한 액세스를 거부하는 것보다 취약성을 제거하는 것이 언제나 보다 나은 해결책이다.