애플리케이션 계층 방화벽 테스트
상태바
애플리케이션 계층 방화벽 테스트
  • Network Computing
  • 승인 2003.06.27 00:00
  • 댓글 0
이 기사를 공유합니다

애플리케이션 프록시로 “경계선을 보호하라”
성능 대가 각오해야 … ‘시큐어컴퓨팅’ 방어능력 우수
적절히 구성된 방화벽이 주변 경계를 방어해 주리라고 생각하는 바로 그 순간, 공중 서버를 두드리고 공격자를 현관으로 맞아들이는 취약성이 나타난다. 이런 공격을 막기 위해서 방화벽을 산 게 아니었냐고? 글쎄, 한 가지 비밀을 이야기하자면, 당신이 구입한 것은 아마도 네트워크 계층의 공격을 막는 데는 효율적이지만, 어떠한 서버든 애플리케이션 계층 공격에는 극도로 취약한 상태로 남겨두는 스테이풀(stateful) 패킷 필터링 방화벽일 것이다. 경계선 보호를 위해서는 또 하나의 방어막인 애플리케이션 계층 방화벽(Application Level Firewall)이 필요하다.

애플리케이션 계층 방화벽은 스테이트풀 패킷 필터링(Stateful Packet Filtering)이나 회선 계층 게이트웨이(circuit-level gateway)와 몇 가지 면에서 차이가 난다. 첫째, 애플리케이션 계층 방화벽은 하나의 방화벽에서 여러 개의 애플리케이션 프록시들을 지원한다. 프록시는 클라이언트와 서버 사이에 놓여 두 개의 종단 지점들 사이로 데이터를 전달해준다. 의심스러운 데이터는 떨어져 나가며, 클라이언트와 서버는 결코 직접적으로 서로 소통하지 않는다.

애플리케이션 계층 방화벽은 애플리케이션 인식이기 때문에, 프록시는 화상회의와 VoIP(Voice over IP)용으로 사용되는 H.323 및 오라클 SQL쪱Net과 같은 복잡한 애플리케이션들을 보다 쉽게 처리할 수 있다.

복잡한 애플리케이션 쉽게 처리

애플리케이션 프록시는 클라이언트와 서버에 투명할 수 있으며(클라이언트나 서버에서 어떠한 구성도 필요치 않다), 혹은 비투명으로 되어 클라이언트와 서버가 프록시 서버를 직접 처리하도록 할 수 있다. 투명성 대 비투명성은 이행의 문제며, 보안이 아니라 은폐를 다루는 것이다.

둘째, 애플리케이션 계층 프록시는 프로토콜에 대해 클라이언트와 서버, 두 가지 모두로 작동하기 때문에 프로토콜 순응을 강행할 수 있다. 예를 들어, 헤더 필드에 있는 비 ASCII 데이터를 전송하는 것과 같은 프로로콜을 위배하는 HTTP 상의 공격은 비순응성(nonconformance)으로 인해 유실될 것이다. 일례로 IIS 프린터 ISAPI 버퍼 범람인 버그트랙 ID 2674(Bugtraq ID 2674)가 있는데, 이것은 호스트 필드에 비 ASCII 문자와 함께 지나치게 긴 문자열(string)을 삽입시킨다. 하지만 HTTP를 위배하지 않는 오용(exploit)은 애플리케이션 프록시를 통과해 갈 것이다. 애플리케이션 프록시는 동적 포트를 개방하는 H.323이나 SQL쪱Net과 같은 복잡한 프로토콜들을 처리한다.

마지막으로, 애플리케이션 프록시는 세션을 보다 깊이 들여다보며, 애플리케이션 프로토콜 헤더와 애플리케이션 페이로드(payload)에 있는 정보를 기반으로 전달/유실 결정을 내릴 수 있다. 예를 들어, SNTP 애플리케이션 프록시는 helo, mail from: 및 rcpt to:와 같이 필요한 SMTP 명령어만 방화벽 통과를 허용하고, expn이나 vrfy와 같은 다른 명령어는 막도록 구성될 수 있다.

expn과 vrfy는 각각 확장을 시도하고 각기 계정이 존재하는지를 점검하는 것으로, 공격자와 스패머들이 e메일 계정을 계산하는 데 사용된다. MIME 종류나 메시지 크기와 같은 다른 프로토콜 항목들도 또한 트래픽을 필터링하는 데 사용될 수 있다. 방화벽에 사용되는 애플리케이션 프록시가 프로토콜 페이로드로 들어가서 전달/누락 결정을 내리는 일은 거의 없다. 하지만 HTTP 데이터와 폼/필드를 검토하는 HTTP 전용 프록시들은 있다.

다섯 업체 제품들 테스트

이번 테스트에서는 애플리케이션 방화벽들이 제공하는 보호 메커니즘에 초점을 맞추었다. 또한 애플리케이션 계층 보호와 스테이트풀 패킷 필터링 사이의 성능 저하 수준도 검토해 보았다. 업체들에게는 HTTP, SMTP, POP3, IMAP, SQL쪱Net, DNS, FTP, H.323 등과 같은 일반적인 프로토콜에 대한 애플리케이션 계층 보호 기능을 제공하는 방화벽을 보내줄 것을 요청했다. 그리고 성능 테스트를 위해서는 업체측에 최고 1Gbps의 트래픽을 처리할 수 있는 하드웨어를 공급해줄 것을 요청했다.

다섯 개 업체들 중 네 곳에서 우리의 요청에 응했지만 워치가드 테크놀로지즈(WatchGuard Technologies)는 패스트 이더넷 솔루션을 보내왔다. 우리는 OEM 제품은 전혀 받지 않았는데, 그 이유는 방화벽 소프트웨어에 어떠한 보안 값도 추가되지 않을 것이기 때문이다. 우리에게 OEM이 OS를 스트리핑하기 때문에 당신의 OEM 업체가 더 나은 방화벽 보호를 제공한다고 얘기하기 전에 우리가 테스트한 모든 방화벽들은 범용 OS의 강화된 버전에서 실행된다는 사실을 주목하기 바란다.

테스트한 제품은 체크포인트 소프트웨어 테크놀로지즈의 파이어월-1 넥스트 제너레이션 피처 팩 3(FireWall-1 Next Generation Feature Pack 3), 마이크로소프트의 ISA(Internet Security & Acceleration) 서버 2000, 시큐어컴퓨팅(Secure Computing Corp.)의 사이드와인더 G2(Sidewinder G2), 시만텍(Symantec Corp.)의 VPN 7.0이 있는 엔터프라이즈 파이어월(Enterprise Firewall), 그리고 워치가드(WatchGuard)의 파이어박스 4500(Firebox 4500) 등이었다. 시스코시스템즈와 넷스크린(NetScreen), 그리고 소닉월(SonicWall)은 제품이 테스트에 맞지 않는다는 이유로 참가를 거부했다. 놀라운 불참객은 가트너 조사에 따르면 12%의 시장 점유율을 확보하고 있는 사이버가드(CyberGuard Corp.)였다. 이 회사 대변인은 체크포인트(노키아와 합하면 29.7%의 시장 점유율을 확보하고 있음)의 애플리케이션 계층 방화벽 지원에 신용을 보태주고 싶지 않다고 말했으며, 그렇다면 어쩔 수 없는 일이다.

애플리케이션 계층 방화벽 테스트 방법

테스트는 방화벽이 애플리케이션 계층의 트래픽을 얼마나 잘 보호하고 얼마나 좋은 성능을 내는지를 파악하기 위한 것이었다. POP나 IMAP에 대한 지원은 놀랄 만큼 부족했으며, H.323에 대한 지원은 필요한 UDP 포트를 개방하는 것에 한정됐다.

가장 관심이 갔던 프로토콜들(DNS, FTP, H.323, HTTP, IMAP, POP3, SMTP)에 대해서는 방화벽이 프로토콜 계층에서 어떠한 신택스 점검이든 수행해내는지 여부를 알아내려 했다. 특정 TCP 및 UDP 포트로 명령어 셸을 바인딩하는 데는 앳스테이크(@Stake)에서 개발한 넷캣(Netcat)을 사용했으며, 그런 다음 포트로 텔넷 접속을 했다. 명령어 셸을 받았을 경우에는 프로토콜이 강행되지 않고 있음을 알고 이동할 수 있었으며, 그리고 셸을 받을 수 없었을 때는 방화벽이 보호 기능을 강행하고 있음을 알 수 있었다. 그런 다음에는 두 가지 경로로 강행 기능이 얼마나 잘 작동됐는지를 확인했다.

처음 것은 잘 알려진 오용(exploit) 방안으로, 프로토콜을 위배하여 트래픽을 방화벽에 통과시킬 수 있는지 확인했다. 방화벽에서 나오는 패킷을 모너터링하는 데는 네트워크 어쏘시에이츠의 스니퍼 디스트리뷰티드 s4000 모델 EG2S(Sniffer Districuted s4000 Model EG2S)가 사용됐다. 공격이 방화벽을 통과하지 못하면 방화벽이 차단하고 있음을 알 수 있다. 센직의 헤일스톰 2.0(Hailstorm 2.0은 주로 HTTP, IMAP, POP3 및 SMTP 프로토콜에 대해 변칙적인 패킷을 만들어내는 데 사용됐다. 우리는 헤일스톰을 이용해 긴 문자열이 있는 헤더 문자열과 비 ASCII 문자들을 헤더로 통과시키 보내려는 시도를 했으며 이것은 보통 허용되지 않았다.

대규모 사용자 기반과 웹 팜을 만드는 데는 각각 스파이런트 테크놀로지즈(Spirent Technologies)의 웹애벌랜치(WebAvalanche)와 웹리플렉터(WebReflector)를 사용했다. 웹애벌랜치와 웹리플렉터는 함께 HTTP gets를 수행하는 많은 사용자를 시뮬레이팅한 폐쇄형 루프 테스트베드를 만들어냈다. 그리고 우리는 각 방화벽이 높은 접속 및 접속해제 속도, 높은 동시 접속 수, 그리고 얼마 안 되는 동시 접속 수에서의 높은 트래픽 부하를 처리할 수 있는 능력을 테스트하기 위해 세 가지 시나리오를 고안했다. 모든 시도의 구성은 각각의 방화벽은 유사한 수준의 보호 기능을 제공하도록 조절했다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.