웹 보안과 웹 방화벽



현대사회는 정보화 사회다. 이러한 정보화 사회를 이끌어 온 주역은 웹(인터넷)이다.
수많은 정보가 웹(인터넷)을 통해 제공되면서, 누구나 손쉽고 편리하게 다양한 정보들을 접할 수 있게 되었다. 인터넷이 연결되는 곳이라면 어디에서나 클릭 몇 번만으로 생활에 필요한 다양한 물건을 구매하기도 하고, 메신저나 싸이월드, 블로그 등을 통해 친구나 지인들의 안부를 확인 하기도 한다. 직접 은행에 가는 것보다 인터넷뱅킹 이용이 더 익숙한 시대에 살고 있다.
웹은 끊임없이 발전하며 새로운 변화를 만들어내고 있고, 우리에게 다양한 편리성과 유용성을 제공하고 있다.
그러나 이러한 편리성의 이면에는 각종 정보보호 관련 사고들이 도사리고 있다.
최근 국내에서 급증하는 대량의 개인정보 유출사건, 개인 홈페이지 해킹사건, 금융권의 인터넷뱅킹 해킹사건은 개인 및 기업, 공공기관의 정보 유출을 넘어 직접적인 금전적 피해를 끼치게 되면서 웹 보안에 대해 사람들의 관심이 증가하게 되었다. 기업의 정보보호관련 침해사건은 기업의 신뢰도 하락으로 기업 이미지에 악역향을 끼치는 건 물론, 집단소송으로 이어져 기업의 존폐위기까지 치닫는 등 정보보안의 중요성은 그 어느 때보다 중요하게 인식되었다.

그렇다면 각종 보안 위협으로부터 개인 및 기업이 안정적인 웹 보안환경 마련을 위해 할 수 있는 방법이 무엇일까,
개인 사용자가 웹 보안에 가장 신경 써야 할 부분은 자신이 사용하는 개인 PC를 깨끗한 상태로 유지 하는 것이다. 인터넷 사용자의 해킹유형을 살펴보면, PC에 설치된 악성 프로그램이 PC 내부에 있는 사용자의 개인정보(주민번호, 계정, 아이디/패스워드, 공인 인증키 등)를 해커에게 전송하게 되고, 해커의 의해 다른 PC를 공격하는데 이용되기도 한다. 이러한 부분을 방지하기 위해서는 개인 PC용 백신 프로그램을 설치하고, 항상 최신버전을 유지하면서 시스템을 감시할 수 있게 해야 한다. 또한 인터넷 서핑 중 신뢰할 수 없는 사이트에서는 ActiveX 프로그램을 다운로드 받지 않는 것도 중요하다.
웹 사이트를 운영하는 기업에서는 사용자들이 안전하게 서비스를 이용할 수 있도록 제공하여야  한다. 이를 위해서는 안전한 웹 서비스를 구축하는 것이 중요하다. 안전한 웹 서비스 구축을 위해서는 설계 단계에서부터 보안을 고려하여 설계하고, 개발 단계에서는 소스검증 도구를 이용하여 지속적인 개발소스 검증이 필요하다. 서비스 개발이 완료되면 오픈하기 전에 반드시 보안 전문가의 컨설팅을 통해 서비스 취약점을 점검하고 보완하여야 한다.
하지만 대부분의 기업들은 운영중인 웹 사이트를 두고, 보안을 고려하여 처음부터 다시 웹 사이트를 개발하기에는 분명 어려움이 있다. 이러한 경우 웹 방화벽 (Web Application Firewall)을 도입하여 웹 사이트를 보호하고 고객들에게 안전한 서비스를 제공하는 방법이 있다.  

2. 웹 방화벽의 개념과 원리
 웹 방화벽(Web Application Firewall)을 알기 위해서는 먼저 Web Application에 대해 알아야 한다.  Web Application은 우리 생활에서 늘 접하는 것이라고 할 수 있다. 인터넷을 통해서 우리들이 사용하는 홈페이지나 대부분의 서비스들이 Web Application 이라고 생각하면 된다.
사용자들이 사용하는 웹 사이트의 구조는 보통 아래와 같다.

그림 1 Web Application 전형적인 아키텍처

 웹 공격의 대부분은 Web Application을 구축할 때 생겨나는 취약점을 이용해서 Web Server를 공격하거나 DB 내용을 악용하는 방법이 대부분이다. 공격자는 HTTP Request에 특정 공격코드 또는 특정 Web Application만이 가지고 있는 취약점을 우회는 코드를 삽입하여 Web Server에 전송하게 된다. 결국 Web Application은 의도하지 않은 동작을 하게 되고, 그 결과를 HTTP Reply 통해 공격자게 다양한 정보들을 전송하게 되는 것이다.
웹 방화벽에서 Web Server쪽으로 전송되는 모든 HTTP Request Packet을 검사하여 Web Application에게 의도하지 않은 내용들은 전송되지 못하도록 하는 역할을 한다. 또한 Web Server에서 통과하는 HTTP Reply Packet 내용을 감시하여 특정 정보의 유출을 막는 역할도 하게 된다.
웹 방화벽에서 Web Server쪽으로 HTTP Request/Reply Packet을 검사한다고 했는데, 이것은 어떤 방법으로 가능한지 살펴 보겠다. 중간에서 Packet을 검사하는 원리는 Proxy Server의 원리에서 가지고 온 것이다. Proxy Server는 Client와 Server간의 통신을 중계하고 Relay 하는 역할을 한다.
웹 방화벽의 원리란 웹 서버로 들어오고 나가는 모든 Packet을 Proxy 원리를 적용하여 Packet의 내용을 검사하고 차단 하는 것이다.

그림 2 Proxy Server Relay

웹 방화벽(Web Application Firewall)이 대두되기 전에는 F/W(Fire Wall), IDS(Intrusion Detection System), IPS(Intrusion Prevention system) 가 네트워크 보안을 책임 지고 있었다. 그러나 네트워크 보안제품의 한계로 인한 각종 침해사고가 발생하면서 웹 해킹을 전담으로 차단하는 웹 방화벽에 대해 이슈화 되기 시작하였다.
웹 방화벽은 기존의 네트워크 보안 제품(F/W, IDS, IPS)들과 어떠한 차이점이 있는지 알아보자.
그림 3 Simple Network/Application Layer

F/W은 네트워크 Packet중 Network Protocols 의 TCP/IP Layer에서 IP와 Port 정보를 가지고 방어를 하는 개념을 가지고 있다. IDS, IPS는 Network Protocol에서 Application Protocols의 Packet 내용을 문자열 비교에 의해 침입시도를 감시하고 차단하는 역할을 한다. 웹 방화벽은 Application Protocols 중에 HTTP의 내용만을 문자열 비교에 의해 침입시도를 감시하고 차단하는 역할을 한다.
얼핏 보면 IDS, IPS, 웹 방화벽은 그다지 큰 차이점을 찾아 보기 힘들다. 다른 점이라면  문자열을 비교할 때, 비교하는 DATA의 종류가 다르다는 것이 가장 큰 차이점이다.
IDS, IPS에서 검사하는 문자열은 Application Protocols 에 쌓여 있는(encapsulation) 상태의 DATA이고, 웹 방화벽에서는 Application 에서 직접 사용하게 되는 풀려진(Demultiplexing) 상태의 DATA 문자열 비교를 하게 되는 것이다.
이러한 차이는 Application Protocols에서 암호화된 DATA를 IDS, IPS에서는 기존의 문자열 비교를 통해서는 침입패턴들을 검출해 낼 수 없다. 하지만 웹 방화벽에서는 이미 하위 Layer에서 복호화를 마친 DATA로 문자열 비교를 하기 때문에 침입패턴을 검출해 낼 수 있게 되는 것이다.
또한 웹 방화벽은 HTTP 프로토콜만을 감시하기 때문에 단순한 문자열 비교만을 이용한 침입패턴 탐지가 아닌 HTTP의 프로토콜 속성값들을 통해서 효율적인 방어를 할 수 있다.




 웹 방화벽은 HTTP의 Request/Response 메시지 내용을 분석, Positive 정책과 Negative 정책을 혼용하여 탐지 기능을 수행하게 된다. 먼저 Request 메시지를 이용한 탐지 기능을 알아보자.
가장 큰 특징이라고 할 수 있는 것은 URL 단위의 탐지 기능이다. 해당 사이트는 서비스를 제공할 URL을 Positive 정책으로 설정하면, 등록된 URL외의 다른 URL을 사용자가 요청할 경우 탐지하여 요청거부 메시지를 보내는 것이다. 이러한 경우에는 악의적인 사용자가 정상적인 URL외의 다른 URL로 접근하는 것을 원천적으로 봉쇄할 수 있다.  Negative 정책에서는 정상적인 URL에서 악의적인 공격 패턴(XSS, SQL Injection, OS Command Injection 등)을 검출해 내는 문자열 비교정책을 추가할 수 있다.
Request Method(GET, POST, OPTION) 까지도 Positive 정책에 설정할 수 있다. 특정 URL에서만 사용하는 Cookie/Hidden 필드나 Parameter 값들을 설정하여 보다 정교한 탐지 기능을 제공하게 된다.

파일 업로드 제어기능과 파일 검사기능을 지원한다.
사용자들이 웹 서버로 업로드하는 파일에 대해 파일의 종류에 따라 업로드를 허용 또는 차단 여부를 지정할 수 있다. 업로드 파일의 내용을 검사하여 악의적인 공격 형태의 파일들은 파일 필터를 통해 업로드가 차단된다. 이러한 기능은 웹 사이트를 악용하려는 사용자로부터 안전하게 보호하는 역할을 한다.
앞의 탐지 기능이 Request 메시지를 이용한 것이라면, 이번에는 Response 메시지를 이용한 탐지 기능을 알아 보겠다.
가장 대표적인 기능은 바로 웹 서버의 에러 또는 오류 정보를 차단하여, 악의적인 사용자가 웹 서버에 대한 정보를 알 수 없게 하는 것이다. 그러나 요즘은 주요정보를 차단하는데 더 많이 이용되고 있다. 사용자의 주민번호, 핸드폰번호, 집 주소, E-mail 주소, 카드번호 등의 개인 정보들이 다른 사용자들에게 노출 되는 것을 방지하는 것이다.

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



2 장. 웹 방화벽 구축
A.    공개 웹 방화벽 솔루션 소개
웹 보안 솔루션으로는 소스 분석 툴, 취약점 분석 툴 그리고 웹 방화벽이 있다. 그 중 웹 방화벽은 기존 어플리케이션을 수정하지 않고 이미 존재하는 취약점에 대한 능동적인 방어기술로 웹 보안 시장에서 가장 큰 관심을 받고 있다. 웹 방화벽은 크게 공개용과 상용으로 나뉜다. 공개용으로 가장 폭넓게 쓰이는 두 가지 제품이 있다.
Aqtronix 사의 WebKnight (www.aqtronix.com)
IIs 웹 서버의 ISAPI 필터 형태로 설치된다. 기능을 보면 룰 기반으로 다양한 웹 공격을 막을 수 있고, Log Only 및 차단모드 선택이 가능하다. 그리고 White List 필터링 방식 지원으로 허용할 URL/폴더에 대해 키워드 등록할 수 있어 간단한 포지티브 정책을 세울 수도 있다.
 BreachSecurity사의 ModSecurity (www.modsecurity.org)
Apache 웹 서버의 공개용 웹 방화벽으로 소스를 컴파일 하거나 동적 공유객체(DSO)로 설치가 가능하다. 최근 V2.5가 공개되어 좀더 많은 기능을 제공하고 있다. SQL Injection, CGI 공격, Directory Traversal 같은 다양한 웹 공격 차단을 할 수 있다.
위 공개용 웹 방화벽은 허용(Positive) 정책에 대해서는 일부 가능하지만 그 기능이 미미하고 대부분 비 허용(Negative) 정책에 의해 웹 공격을 방어하게 된다. 비 허용 룰셋은 여러 보안커뮤니티들에서 보급하고 있다. 그러나 공개 웹 방화벽의 단점은 아무도 룰셋에 대해 보장해 주지 않고 그 책임을 사용자가 진다는 것이다.

그림 1 공개 웹 방화벽 동작원리








B.     상용 웹 방화벽 시장 분석
상용 웹 방화벽 탐지기술의 장점은 HTTP 프로토콜 속성값의 작은 단위까지도 자세한 정책설정이 가능하다. 웹 서비스 개발 시점에 미처 고려하지 못했던 보안상의 문제점들을 보완 할 수 있어 웹 서비스를 보다 안전하게 사용자들에게 제공할 수 있다. 또한 상용 웹 방화벽은 부가적으로 웹 가속기능이나, SSL 가속기능, 개인정보 필터링 기능들을 지원한다.
 상용 웹 방화벽은 국내 제품과 외산 제품이 다양하게 출시되어 시장에서 경합 중이다. 외산은 글로벌 마켓 쉐어와 뛰어난 성능을 강점으로 진출하였으나 CC인증문제와 국내 웹 환경의 적응부족으로 제품 출시 기간에 비해 크게 퍼지고 있지는 못하고 있다. 외산 웹 방화벽 중에는 테로스, F5, 넷컨티넘, 시큐어스피어 등이 보안 시장에서 간간히 보이는 정도이다.
 반면 국산 웹 방화벽은 CC인증을 기반으로 공공시장에서 각광을 받고 있다. 또한 해외보다 복잡한 국내 웹 환경에 최적화되어 외산 대비 훨씬 높을 보급율을 가지고 있다.
 아래 표는 국내에서 CC인증을 받은 제품 목록이다 이중 초기부터 지속적으로 시장의 마켓 쉐어를 넓이는 제품이 있는 반면 CC인증은 받았지만 시장에서의 반응이 미미한 제품도 다수 있다.

인증일
제품유형
제품명
개발사
보증등급
2007-0511
웹 방화벽
WEBS-RAY V2.0
트리니티소프트
EAL4 (국제)
2008-0130
웹 방화벽
WAPPLES V2.0
펜타시큐리티시스템
EAL4
2008-0424
웹 방화벽
TUTELA WebFirewall V1.3
토리넷
EAL4
2008-0430
웹 방화벽
SNIPER WAF V2.0
나우콤
EAL4
2008-0829
VPN+웹 방화벽
SECUREWORKS TRUiN V1.0
어울림정보기술
EAL4
2008-0919
웹 방화벽
WEBFRONT v1.4
파이오링크
EAL4
2008-0919
웹 방화벽
WAPP SAFER v2.5
이지서티
EAL4
2008-1222
웹 방화벽
SECUI NXG W V1.0.1
시큐아이닷컴
EAL4 (국제)
2008-1222
웹 방화벽
WEBS-RAY V2.5
트리니티소프트
EAL4 (국제)
2009-0114
웹 방화벽
WebCON V1.0
엘앤디시스템
EAL2
2009-0420
 웹 방화벽
WEB Insight SG V2.1
모니터랩
 EAL4
표 1 국내 웹 방화벽 CC인증 현황 (출처 : 국가정보원/IT보안인증사무국)

2.    WAF 도입 시 고려 사항
A.    웹 방화벽 보호 대상 서버 선정
고객사의 웹 보안을 컨설팅 하다 보면 모든 웹 서버에 보안서비스를 걸기를 원한다. 그 중에는 잘 쓰이지 않는 작은 웹 서버부터 메인 포탈서버까지 다양하다. 한정된 자원을 가장 효율적으로 산정하려면 꼭 보호해야 할 서버를 먼저 선정하고 웹 방화벽 도입 사업을 진행하는 것이 맞을 것이다. 또한 보안 팀에서 웹 방화벽을 도입하려 한다고 웹 서비스 담당자들이 다 선호하는 것은 아니다. 이미 침해사고를 경험한 담당자는 당연히 선호할 것이고 아무런 보안이슈가 없던 담당자는 귀찮다는 표시를 하는 것이 일반적이다.
B.     웹 방화벽 트래픽 용량산정
보호 대상 웹 서버를 선정하였다면 해당 웹 서버의 트래픽 용량을 산정해야 한다. 여기서 이슈가 발생한다. 용량을 어떻게 선정할 것인가에 대해 네트워크 관점으로 접근해버리면 단순 트레픽의 대역폭(Bandwidth) 만을 고려하게 되는데 웹에서의 부하는 네트워크에서 접근하는 것과는 조금 다른 웹 서비스 관점에서 접근하는 것이 옳다. 얼마나 많은 대역폭(Bandwidth)를 점유하느냐는 사실 절대적인 수치에서 보면 중요하지 않다. 1Gbps 전용선 라인을 쓰더라도 웹 서비스의 접속량(HTTP Request/ Response)이 미미하다면 작은 사양의 웹 방화벽 장비로도 충분할 것이다. 이에 반해 대역폭은 2~300Mbps 남짓 되더라도 엄청나게 많은 User들이 동일시간에 접속하는 서비스라고 하면 이건 웹에서 보면 엄청난 트렌젝션이 될 수 있다. 예로 필자가 컨설팅 한 제품이 납품된 국가 자격증을 관리하는 사이트는 자격증 발표날 약 40만 명 이상이 9시 정각에 접속한다. 이는 대역폭으로 보면 단순 HTTP Packet이기 때문에 크지 않지만 웹 접속량으로만 보면 웬만한 웹 방화벽으로는 감당하기조차 힘든 어마어마한 부하이다. 따라서 웹 방화벽을 도입하기 전에 우리 웹 서비스에 시간당 최대 부하율 (hits/hours)을 알고서 용량을 산정한다면 장비를 공급하는 업체에서도 적정 용량을 산정하기가 쉽다.
C.     웹 방화벽 설치구간선정
보호대상 웹 서버도 선정하였고 해당 웹 서버의 트래픽에 의거한 웹 방화벽 용량도 산정하였다면 웹 방화벽의 설치구간을 정하는 게 그 다음 이슈가 된다. 초기 웹 방화벽은 웹 서버 하나를 막기에도 역부족일 정도로 성능이 부족한 적도 있었으나 현재는 여러 벤더의 경쟁과 비약적인 하드웨어의 발전으로 웹 방화벽 하나가 적게는 몇 개에서 많게는 백 여대 정도의 웹 서버까지 보호 할 수 있게 되었다. 그래서 웹 방화벽 설치구간이 좀더 다양해 지게 되었다. 웹 방화벽을 설치하는 데에는 크게 Host 방식(SW제품), Reverse Proxy 방식, In-Line 방식으로 나뉜다. 최근에는 90%이상이 구성상의 편리 때문에 In-Line 방식을 선호한다.
그림 2 웹 방화벽 설치 방식

 각 기관의 예산이나 보안정책에 따라 단수 웹 방화벽을 도입할 것인가 이중화를 위해 복수의 웹 방화벽을 구축할 것인지 정해진다. 단수이든 복수이든 웹 방화벽은 웹 서버 바로 앞에 설치되는 것이 가장 좋다. 다른 구간의 서비스 이슈에 영향을 최소화 하고 장애 포인트를 줄여 웹 방화벽 운영 담당자로 하여금 여러 가지 스트레스 상황을 줄여줄 수 있다. 그러나 웹 서버가 여러 구간에 분산 설치되어 있다고 하면 이도 쉽지 않은 선택이다. 결론은 단수 웹 방화벽은 DMZ 구간과 같이 웹 방화벽 하나가 모인 구간에 웹 방화벽을 설치하고 하단에 L2 스위치를 추가하여 웹 서버 이외의 서비스에 대한 영향을 최소화 하는 것이 최선의 선택이라 본다
 복수 웹 방화벽은 이중화 방식에 따라 Active-Active / Active-Standby로 달라진다. 최근에는 몇몇 선두 업체들을 중심으로 이중화된 장비간 정책동기화와 세션동기화가 완성되어 장비간 Async Path(Request와 Response가 다른 경로를 경유)도 지원하고 있어 L4 스위치 없이 Active-Active 구간에 설치가 가능해졌다. 이런 장비를 도입한다면 네트워크 앞 단의 Back-bone 망에 설치가 용이 하다.
   
그림 3 웹 방화벽의 구성 방식 (단수 웹 방화벽/ 이중화 구성된 웹 방화벽)

3.    웹 방화벽 구축 시 고려 사항
A.    장애상황 대책
웹 방화벽을 소프트웨어 방식이 아닌 네트워크 구간에 설치 시 장애에 대한 다양한 대비책을 세워야 할 것이다. 초기 하드웨어 웹 방화벽은 앞에서 도 언급했듯이 Reverse Proxy 형태로 설치되었고 이때는 L4에서 웹 방화벽의 서비스 Port 를 Health check 하여 장애상황이라 판단되면 바로 웹 서버로 넘길 수 있도록 하였다. 최근에는 In-Line 형태로 설정되기 때문에 장비자체에 하드웨어 Bypass 모듈이 설치되고, 내부에는 Soft Bypass 기능을 넣어 웹 방화벽의 내부 기능에 문제가 생겨도 bypass 될 수 있도록 하고 있다.
B.     탐지(모니터링) / 차단 일정 수립
웹 방화벽은 탐지(학습) 기간을 갖는다. 이는 포지티브 정책을 만들고 그에 따른 오탐에 대한 예외조치를 하기 위에서 이다. 가장 이상적인 것이 대부분의 벤더가 지원하는 자동학습이나 이는 실 사이트 환경에서 쓰기기 힘든 부분이 많은 것이 또한 공공연한 비밀이다. 지속적으로 변하는 사이트를 학습하기란 이론적으로 불가능하고 정적인 사이트라 하더라도 학습한 결과에 대해 다시 보안담당자가 점검해야 하는 번거로움이 발생한다. 이에 포지티브 정책을 수동으로 설정하는 것이 현실적이다. 그리고 보안정책을 건 상태에서 혹시 모를 장애상황이나 오탐들을 예외 처리하여 실 보안 서비스(차단)에 들어가서 정상적인 업무 프로세스가 차단되는 것을 미연에 방지하는 과정이다.
C.     웹 어플리케이션에 맞는 보안정책 설정 및 기존 취약점 보안 권고
탐지기간을 갖고 예외처리를 진행 하다 보면 종종 너무 위험한 취약점이 드러나는 경우가 있다. 이 부분은 해당 사이트를 컨설팅 하면서 반드시 빠른 시간 내에 수정하기를 권고한다. 예를 들면 URL 상에 SQL이 그대로 들어나는 경우이다.





4.    WAF 운영 시 고려 사항
A.    웹 방화벽에 대한 보안 담당자의 이해
웹 방화벽은 기존 보안담당자들이 제일 어려워하는 보안장비이다. 네트워크뿐만 아니라 어플리케이션에 대한 지식을 같이 가지고 있어야 하기 때문이며 실 사이트에서는 이것 때문에 운영부서끼리 서로 미루는 일이 상당수 발생한다. 가장 좋은 상황은 동일 부서에서 웹 서비스와 보안관리를 같이 운영할 때 이다. 그러나 이것이 여의치 않거나 웹 서비스와 보안부서가 분리되어 있는 기관이라면 상당수 트러블은 각오해야 해야 한다. 웹 서비스 운영 팀에서는 무조건 서비스를 Open 하라고 요청하고 보안 팀에서는 장비에 걸린 차단 로그를 일일이 확인 후 대응방법을 찾은 후 웹 서비스를 Open 하려고 하기 때문이다. 이는 두 부서간에 사전조율 후 웹 방화벽이 도입되기 전에 이런 문제가 발생할 가능성에 대해 미리 업무협조라인을 만들어 놓는 것이 나중에 부서간의 싸움으로 번지는 사태를 예방 할 수 있다.
B.     새로운 보안 이슈에 대한 웹 방화벽 패치
보안 컨설팅을 하면서 생각하는 주 적은 해커이다. 또한 그들은 가장 고마운 친구이기도 하다. 그들은 매번 새로운 공격기법을 만들어 보안 컨설턴트들을 긴장하게 만들고 보안 엔지니어가 사회에서 꼭 필요한 사람이라는걸 알게 해준다. 따라서 새로운 공격기법이 나올 때 마다 간단하게는 룰셋을 업데이트하거나 새로운 공격 패러다임이 나오게 되면 웹 방화벽의 일부 모듈을 패치해야 하는 상황이 발생하기도 한다. 이에 따라 보안 담당자는 웹 방화벽 벤더의 패치를 잘 이해하고 수행해야 할 것이다.
C.     추가되는 웹 어플리케이션에 맞는 보안정책 설정
모 대기업 보안 담당자의 말을 빌리자면 침해사고는 기존에 잘 정돈된 어플리케이션 보다는 새로 개편되거나 추가되는 웹 페이지들에서 발생한다고 한다. 웹 방화벽도 별반 다르지 않다. 새로 추가되는 어플리케이션에 대한 보안정책을 잘 세우지 않으면 결국 지금까지 잘 운영해 왔던 공이 허수로 돌아가는 불상사가 생길 수 있으므로 새로 개설되어 추가되는 사이트에 대해서도 좀더 철저한 분석을 통해 잘 정의된 보안 정책을 설정할 필요가 있다.
D.    침해 사고 발생시 대응
 아무리 잘 구축된 보안장비와 잘 훈련된 보안 엔지니어가 있다고 해도 침해사고에서 자유로울 수는 없다. 먼저 사이트가 변조되던가 하는 공격의 흔적이 있다면 계약된 웹 보안 업체에 알려 추가공격에 대비하고 해당 공격을 분석하여 새로운 보안정책을 세워야 할 것이다. 침해 사고 시 당황하지 않고 절차에 의해 분석과 대응을 한다면 반복되는 침해사고를 막을 수 있고 경영진의 문책을 조금이라도 약화 시킬 수 있을 것이다.



3장. 웹 방화벽 New Trend
웹 2.0 시대의 새로운 보안 위협
인터넷의 존재와 함께 접속이 가능한 모든 형태의 웹 사이트는 공격받고 있다.  언론 보도를 통해 알려진 QuickTime XSS 웜으로 손해를 본 MySpace, Yamanner 웜 공격에 최근 부딪힌 Yahoo 메일, 그리고 구글의 Gmail도 XSS 공격에 취약한 문제를 가지고 있었다. 이러한 거대 기업들도 많은 비용을 들여 새로운 취약점에 대비하고, 웹 해킹 침해가 발생했을 때 손해발생비용은 기업의 규모만큼 커진다.
사용자의 참여, 정보의 공유 등, 기존의 패쇠적인 웹1.0에서 웹2.0으로 발전하면서 진화된 웹 세상을 경험하게 되었다. 사용자가 인터넷에 손쉽게 접속 할 수 있는 환경에서 모든 사람이 주도적으로 쉽게 정보를 올리고 함께 공유하는 환경으로 발전하면서 보다 많은 혜택과 이득을 접하게 된 것이다. 하지만 웹 2.0 시대를 노리는 새로운 보안 위협이 등장하여 이에 대한 대비가 필요하게 되었다.
 과거의 웹은 정적 HTML 페이지를 전송하여, 사용자 관여가 거의 불가능한 일방적인 정보를 제공하는 하였다. 하지만 웹 2.0에 이르러 다양한 AJAX 애플리케이션, 소셜네트워킹(싸이월드, MySpace), 개인블로그, RSS 피드와 같은 다양한 참여 지향적인 환경을 선보이며 전문가가 아닌 누구라도 직접 웹 세상에 참여할 수 있게 되었다.
[그림] 웹2.0 대표적인 사이트인 Wikipedia
따라서 일방적인 정보제공에서 다양한 사용자의 참여로 기존의 단편적인 보안정책만으로는 보호하기 힘든, 새로운 보안 위협이 대두됨에 따라 기업은 웹 2.0 시대 이전과 비교할 수 없는 새로운 보안 위협에 노출되고 있다. 웹 2.0은 사회적이고 상호 의존성이 높은 특성을 가지고 있다. 또한 단순한 정보 공유뿐만 아니라 폭넓은 정보 공유도 가능해졌다. 하지만 이러한 개방성은 많은 취약점을 가지고 있고 이는 공격자에게 많은 허점을 들어낸다.
웹 2.0과 같은 열린 환경에서 중요 정보 유출을 막는다거나 유해 콘텐츠를 모니터링하는 일은 매우 어려운 일이다. 웹 활용이 확대됨에 따라, 이를 위협하는 수준 또한 높아졌기 때문이다. 블로그 등의 개인 웹 공간을 통한 정보의 유출은 장기적으로 심각한 영향을 미칠 수 있다. 블로그는 검색 사이트를 통한 검색이 가능하기 때문에 관심 있는 누군가에 의해 다른 사이트로 전달될 가능성이 높다.
많은 기업이 ERP, CRM, MIS 같은 중요한 애플리케이션을 웹 기반으로 전환하고 있다. 이러한 애플리케이션은 접속 및 사용의 편의성으로 IT 관리 비용을 절감하게 해준다. 그러나 해커들은 복잡한 웹 애플리케이션에 도사리고 있는 잠재적 취약점을 노리고 있는 실정이다.
특히, 웹 2.0은 피싱 공격에 취약하다. 피싱 사이트들은 RIA를 이용, 합법적인 사이트로 가장하여 중요한 사용자 정보들을 유출하는데, 피싱에 대한 지식이 있는 전문가도 속일 수 있고, 기존의 보안 솔루션도 우회할 있다. 이런 무작위 피싱 공격은 해커를 추적하는 것 조차 힘들게 하고 있다.
안전하다고 생각되는 사이트들도 해커들은 실행 가능한 XML 악성코드를 유명 사이트에 심어둘 수도 있다. 실제로 미국의 대표적인 웹 2.0 서비스 사이트인 MySpace에 심어져 있던 악성 코드가 발견되기도 했다. 아울러, 스트리밍 비디오도 새로운 악성 코드 매개체로 급부상했다. Youtobe 같은 수백만 명이 시청하는 유명 UCC 사이트의 동영상 속에 악성코드가 숨겨져 있을 때 피해는 기하급수적으로 늘어날 것이다.
웹2.0 시대의 보안은 Ajax, XML, RSS등에 특히 주시해야 한다. 웹2.0이라고 새로운 위협이 존재하는 것은 아니다. 단지 공격이 개방형 환경에 맞춰 다양한 형태로 진화하는 것이다. 웹2.0은 XML 기반 서버사이드 XML 기반 웹서비스가 분산된 애플리케이션에 대한 접근을 제공한다. 반면 클라이언트 사이드에서는 Ajax와 RIA가 인터페이스를 지원하는 구조가 일반적이다. Ajax가 취약한 이유는 XSS공격에 노출되기 때문이다. 이는 특정 사이트의 악의적인 자바코드가 브라우저에 실행되어 개인정보를 유출하는 공격이다. 특히 개인 쿠키의 유출문제는 심각하다. Ajax는 또한 사용자 모르게 공격자가 악의적인 목적으로 silent call을 통해 쿠키를 재전송 할 수 있다. 웹2.0 애플리케이션은 클라이언트 사이드에서 Ajax가 많은 일을 담당하고 있어, Data Type, Data Filed, Data내용 등에 대한 검사를 서버사이드에서도 함께 해야 한다.

2.웹 보안의 ASP(SaaS) 사업
어플라이언스 타입의 하드웨어 웹 방화벽은 도입가격 및 설치 비용 때문에 ASP(SaaS) 사업에 불리하다. 필자가 컨설팅 진행한 다양한 사이트에서 웹 방화벽의 구매 비용에 대해 부담스러워 하고 있고 이 때문에 저렴한 소프트웨어 방식이나 공개용 웹 방화벽을 고려하는 경우가 종종 있다.
 중소 웹 호스팅 업체들이 공개 웹 방화벽으로 최소의 관리비용만 받고 웹 보안 서비스를 제공하는 경우가 많다. 이는 비싼 상용 웹 방화벽을 도입할 자금이 없는 웹 사이트에는 단비와 같은 존재이나 최적의 보안서비스를 받기 힘든 게 사실이다. 이러한 경우, 공개 웹 방화벽을 사용하다가 침입사고가 발생하여 상용 웹 방화벽을 검토하거나 도입하는 업체를 상당히 많이 보아왔다.
 최상의 ASP(SaaS) 서비스라면 하드웨어 웹 방화벽을 일정비용을 내고 빌려쓰고, 24시간 보안관제 서비스까지 받는 것이고 이것에 대한 서비스를 하는 보안회사도 있다. 자금의 여유만 있다면 이 방법이 보안에 최선이라고 말할 수 있다.
[그림] ASP(SaaS) 웹보안 구성도
3.고성능 10G급 웹 방화벽 개발
10G급은 많은 네트워크 장비 및 보안장비들이 준비하거나 초기 제품들이 출시되어 조만간 대규모 시장이 형성될 예정이다.
PCI Express x16 1.1 은 초당 8GB/, PCI Express x16 2.0 은 초당 16GB/S의 전송속도를 가지고 있습니다. 10G라는 Bandwidth는 일반적인 CPU와 Memory 간의 데이터 처리흐름 보다 빠른 속도이다.
따라서 기존의 방식대로 인터페이스만 바꿔서는 10G 급 성능을 낼 수 없을 것이다.
 그런데 요즘 출시되거나 준비하는 제품을 보면 단지 인터페이스만 10G로 바꾸는 황당한 경우가 있다. 따라서 하드웨어 백플레인이 10G를 처리 할 수 있게 개선되어야 할 것이다. 이 부분은 구매 시 충분히 고려하여 정말 10G급의 제품인지 충분히 검토하여야 할 것이다. 그리고 완벽한 하드웨어가 셋팅 된 다음에는 웹 방화벽 Packet Filter 모듈이 10G급 데이터를 처리 할 수 있어야 한다.
웹 방화벽에서 가장 많은 부하를 주는 Packet Filter 모듈의 최적화를 통해 대용량 데이터를 처리 할 수 있게 개선되어야 할 것이다.
 최근에 10G급 LAN-bypass 모듈이 검증이 완료 되었다고 하니 다양한 In-Line 보안장비에서 10G 인터페이스를 지원할 것이다.

4.웹 스캐너와 웹 방화벽 연동
 다양한 고객들을 컨설팅 하다 보면 웹스캐너를 통해 나온 취약점을 보안 솔류션과 연계하여 바로 보안하기를 원하는 고객들이 많다. 안타깝게도 이 부분은 아직 웹 스캐너와 웹 방화벽을 같이 개발하여 연계한 사례가 없다. 외산 및 국산 업체 중 동일 벤더가 웹 스캐너와 웹 방화벽을 같이 개발한 경우는 있지만 연동이나 보안정책 설정의 편의성 관련해서는 별로 큰 이점이 없고 시장에서도 크게 빛을 보지 못하고 있는 상황이다.
기존의 메이저 웹 스캐너 업체와 웹 방화벽 업체가 기술 제휴를 맺어 스캔 후 바로 취약점이 보완 될 수 있기를 기대해 본다.

5.이종 보안장비간의 통합
 네트워크뿐만 아니라 보안 시장도 비용절감 및 운용의 편의성 때문에 이기종 장비간의 통합이 요즘 상당이 이슈화 되어 있다. 대표적으로 세계적인 네트워크 업체인 CISCO 역시 자시 스위치에 L3, L4 Switch를 모듈화 시켜 탑재하고 여기에 FW, IPS까지 포함시켜 시장에 공급하고 있다.
 사내 자원통합으로 인해 설치공간도 절약할 수 있고 예산 절감과 운용의 편의성까지 얻을 수 있는 최적의 모델이 될 수 있다.
 웹 보안장비도 기존 보안장비 업체들의 영역확장으로 UTM이라는 시장에 일부 편입되어 있다.
대표적으로 방화벽, IPS, VPN과 같은 기존 네트워크 보안장비 플랫폼에 안티바이러스, 안티스팸, 개인정보 보호 솔루션, 웹 애플리케이션 필터링까지 통합되어 단일 장비도입으로 모든 Layer에 대한 보안을 완성할 수 있다.
 그러나 초기에 시장에서 각광받던 UTM 시장이 성능이슈 때문에 급격히 냉각되었다. 네트워크 Layer 기반의 장비에 무리하게 Application Layer의 보안 필터링을 걸어서 전체 기능을 다 올리기 힘들 정도로 문제가 많았다.
 최근 이러한 문제를 해결하고 많은 부하를 주는 Application Layer를 일부 포기하고 시장이 요구하는 성능을 갖춤 제품들이 새롭게 출시되고 있다. 이 역시 성능문제에서 완전히 자유로울 수  없어 중소규모의 사이트에만 적용되고 있다.
 결국 웹 애플리케이션을 보호해 줄 수 있는 통합보안장비는 아직까지 웹 방화벽이 가지는 부하 때문에 다른 장비와 연동되기 힘든 부분이 있다. 향후 보안장비의 하드웨어가 더욱 발전하여 모든 Layer의 보안이슈를 단일 장비로 해결 할 수 있는 날이 조만간 오지 않을 까 생각한다.





댓글

댓글 쓰기