데스크톱 방화벽

‘악성 코드·침입자’ 차단 … 기능 고급일수록 관리도 까다로워

“더 이상 주변경계만을 위한
방화벽이 아니다”

데스크톱 방화벽은 악성 코드와 침입자들이 랜이나 원격 사무소, 혹은 길에서 사용자의 클라이언트 기계를 감염시키지 못하게 도울 수 있다. 이것이 바로 여러 조직에서 재택근무자와 랩톱, 그리고 인터넷에 직접적으로 연결된 기계용으로 데스크톱 방화벽을 사용하는 이유다.

이렇듯 널리 퍼진 기계들은 특히 취약할 수 있는데, 그 이유는 이들이 종종 엔드유저에게 관리자 액세스를 줌으로써 트로이 목마와 스파이웨어, 그리고 허가받지 않은 서비스들에게 문을 열어주는 경우가 많기 때문이다.
그러나 데스크톱 방화벽은 기업의 네트워크화된 PC도 보호를 해줄 수가 있는데, 특히 민감한 데이터를 보관하고 있는 인사, 총무 및 관리 부서처럼 민감한 데이터를 보관하고 있는 사무실의 컴퓨터일 경우 더욱 그러하다. 이런 컴퓨터에서 방화벽 정책 파일을 유지보수하는 데는 많은 돈이 들 수 있지만, 장기적으로 볼 때는 공격자가 기밀 문서나 커뮤니케이션을 확보하거나, 키 그래버(key grabber)를 설치하거나, 혹은 거래 기밀을 캐내기 위해 이런 클라이언트를 이용하지 못하게 함으로써 비용을 절감할 수 있을 것이다. 방화벽은 심지어 내부의 범죄를 막는 데도 도움이 될 수 있다.

작동 방법
소프트웨어 기반 데스크톱 방화벽은 네트워킹 하드웨어 장비와 IP 스택간의 중요한 이음새 역할을 하고 있으며, 이것은 모든 네트워크 트래픽을 가로채 검사를 한다. 트래픽은 ACL(Access Control List)과 비교돼 서명 스캐너를 통해 돌아간다. 승인이 된다면 트래픽은 통과를 한다. 거부된 트래픽은 유실되거나, 파일로 로깅이 되며, 경보는 사용자에게 전송이 된다(일부 데스크톱 방화벽은 버퍼 범람과 비정상적 코드도 탐지하려는 시도를 하지만, 전용 호스트 침입방지시스템이 이 부문에서는 더 나을 것이다).
하드웨어 데스크톱 방화벽은 특수화된 PCI 혹은 PCMCIA 카드다. 이들은 온보드 CPU를 통해 자체 운영시스템을 갖고 있으며, 스탠드얼론 하드웨어 방화벽인 것처럼 작동한다. 트레이드 오프는 소프트웨어 방화벽이 할 수 있는 것과 같은 시스템 정책 확인이나 애플리케이션 차단 기능을 할 수 없다는 것이다. 그러나 소프트웨어 방화벽과 달리 하드웨어 방화벽은 의도적으로 운영시스템에서나 멀웨어에 의해 기능이 정지될 수가 없다.

접근 제한
중앙 정책 관리 기능을 지원하는 데스크톱 방화벽 스위트를 선택해야만 정책을 구성, 혹은 확인하기 위해 각 사용자의 기계에 접근할 필요가 없다. 그리고 어떤 포트가 개방되는지, 그리고 어떤 프로그램에 네트워크로 액세스하는지 등과 같은 방화벽 상의 보안 정책을 사용자들이 중단하거나 설정할 수 있게 해서는 안 된다. 예를 들어 사용자가 게임을 다운로드하기 위해 방화벽을 중단시키고 싶을 수 있는데, 슛 오사마(Shoot Osama)와 같은 일부 파일들은 게임을 가장한 트로이 목마 바이러스들이다. 방화벽 기능 중단은 곧 조직의 문을 공격자에게 활짝 연다는 것을 의미한다.
게다가 사용자들은 보통 적법한 프로그램이나 행동과 멀웨어의 차이를 알기가 힘들다. 예를 들어 마이크로소프트 윈도에는 알 수 없는 수많은 사운딩 파일들이 시스템 디렉토리 안에 있으며, 어떤 것들은 네트워크 액세스를 필요로 한다. 위조 ‘MSNetConnect.exe’는 보통의 사용자들에게는 적법한 것처럼 보여서 방화벽에서 이것을 허용할 수 있다. 프로그램 문자의 미묘한 차이도 또한 사용자들을 속일 수 있다. 예를 들어 윈도에서 소문자 ‘L’은 숫자 ‘1’과 같아 보이기 때문에 사용자가 소문자로 IEXP10RE.EXE로 쓰여진 잘못된 프로그램을 iexplore.exe로 착각해 돌리게 될 수 있다. 가장 안전한 방법은 사용자들을 모든 방화벽 구성으로부터 멀리 떼어 놓는 것이다.

다양한 크기와 모양들
가장 간단하고 단순한 데스크톱 방화벽은 포트 블로커(port blocker)다. 이 방화벽은 소스나 목적지 포트를 기반으로, 그리고 IP 어드레스에 따라 트래픽을 차단해 준다. 원래 윈도 XP에 내장된 방화벽과 오픈소스 IP테이블(IPTables) 프로그램들은 둘 다 포트 블로커들이다.
포트 블로커를 구성할 때는 모든 수신 접속의 블랭킷 블록(blanket block)을 설정해야 한다. 공격자들은 분명히 로컬이나 원격으로 초기화될 수 있기 때문에, 모든 수신 TCP SYN 접속을 차단함으로써 원격 공격의 성공 가능성을 낮출 수 있다.
원격 공격에서는 보통 패치되지 않은 웹이나 FTP 서버 등과 같은 실행 서비스를 악용하고자 하는 시도를 한다. 이런 서비스를 데스크톱에서 돌리면서 동시에 네트워크 외부로부터 여기로의 액세스를 거부할 수가 있다. 자신의 네트워크에서 이들을 제외한 모든 IP 어드레스로부터의 들어오는 접속을 차단하라.
뿐만 아니라 목적지 포트를 차단함으로써 사용자가 접속할 수 있는 서비스를 제한할 수 있다. DNS와 웹 액세스만을 허용하고 목적지 포트 53과 80을 제외한 모든 것을 차단하라. 디렉토리 공유를 위해 윈도 파일 셰어링(Window File Sharing) 등과 같은 네트워크 서비스를 돌려야 하는 사용자들은 예외가 되기 때문에, 어떤 경우에는 이 포트들을 열어둘 필요도 있을 것이다. 이러한 순수 포트 차단 방안은 또한 랜덤 듣기 포트를 개방하거나, 혹은 다양한 포트를 사용해야 하는 프로토콜에서도 적합치 못하다.
놀랄 일도 아니지만, 포트 차단은 네트워크 액세스 제어 수단으로서 그 인기가 줄어들고 있는데, 그 이유는 바로 포트 80을 허용한다고 해서 웹 트래픽만을 허용하는 것은 아니기 때문이다. 어떠한 프로토콜이든 어느 포트에서나 실행될 수 있다. 예를 들어 우리는 시러큐스 리얼월드 랩에서 특별히 보안 제품에 내재된 한계나 결함을 증명하기 위한 목적으로 포트 80에 FTP 서버를 셋업했다. 그 결과 많은 제품과 프로토콜들이 게이트웨이 방화벽을 피하기 위해 포트 80으로 다시 떨어지는 것을 발견했으며, 포트 블로커는 악성 프로그램이 민감한 데이터를 언제 전송하는지를 알리지 못했다.

네트워크 액세스 지원
보다 나은 방화벽 모델은 애플리케이션 제어로, 여기서는 어떤 포트가 열리거나 차단될지가 아니라 어떤 애플리케이션이 네트워크로 액세스를 할 수 있는지를 지정한다. 불량 트로이 목마가 올 경우 이것은 인터넷에 액세스를 하거나 청취자 포트를 셋업할 수 없다. 존랩(Zone Labs)의 존알람(ZoneAlarm)은 가장 유명한 애플리케이션 블로커며, 사이게이트 시큐어 엔터프라이즈(Sygate Secure Enterprise)와 인포익스프레스 사이버아모르(InfoExpress CyberArmor)도 또한 이 기능을 제공하고 있다.
하지만 애플리케이션을 제어하려면 얼마간의 관리적 부담을 각오해야 한다. 기본적인 윈도 OS 컴포넌트와 인터넷 익스플로러, 그리고 아웃룩 등과 같이 사용자가 필요로 하는 모든 프로그램 목록을 확보하고, 이들을 승인해야 한다. 존알람과 같은 일부 방화벽 제품들은 처음에는 수동 학습 모드에서 작동하며, 이 동안에 이들은 일정 기간 사용된 모든 네트워크 프로그램의 목록을 수집한다. 드물게 사용되는 프로그램들도 또한 반드시 승인을 해야 한다.
또 다른 애플리케이션 제어로 무결성 점검이 있다. 체크섬(checksum)은 각각의 승인된 실행 프로그램용으로 계산이 된다. 엔드유저의 실행 파일에 정책에 지정된 것과 다른 체크섬이 있다면, 이것은 거부된다. 이는 중요한 툴인데, 그 이유는 바이러스와 기타 공격들이 가끔씩 실해 파일에 올라 타서(piggyback), 이들의 기능을 삽입하고, 이것으로 코딩을 하기 때문이다. 공개된 깨끗한 시스템과 대조해 언제나 체크섬을 계산해야 한다.
한편 컴포넌트 무결성 점검은 고급 애플리케이션 제어 기능으로, 시게이트, 존알람 및 인포익스프레스 모두 이것을 사용하고 있다. 프로그램에서 액세스하는 모든 DLL(Dynamic Link Library)은 기록이 되며, 체크섬으로 확인이 된다. DLL이 변경됐을 때는 프로그램이 거부된다.
무결성 점검의 약점은 체크섬을 최신 것으로 유지해야 한다는 것이다. 각 사용자가 필요로 하는 모든 프로그램을 추적해야 할 뿐만 아니라 그 프로그램의 모든 버전에 대한 체크섬 목록을 관리해야 한다. 간단한 패치가 체크섬을 바꿔놓을 수 있으며, 이로 인해 거부 상황이 야기될 것이다. 관리 가능한 상황으로 유지하기 위해 포괄적이고 질서정연한 변화, 혹은 패치 관리 프로세스를 진행해 나가도록 하라. 사용자들이 패칭과 시스템 고장을 연관시킬 경우에 이들은 소프트웨어 패칭 작업을 중단하게 된다. 소프트웨어를 전체 조직으로 내보내기 전용의 깨끗한 테스트 기계나 환경을 이용해 체크섬을 만들어 내라.

계층적 지원 관리 편리
물론 그렇다고 조직의 모든 데스크톱에 같은 보안 정책이 있는 것은 아니다. 그룹뿐만 아니라 개별 사용자용으로도 예외는 있을 것이다.
방화벽 스위트가 LDAP이나 액티브 디렉토리와 같은 인증 디렉토리와 연결이 된다면, 이것을 사용하라. 그러면 승진이 되거나 부서간 이동하는 사용자들이 새로운 보안 정책으로 업데이트가 될 것이다.
계층적 관리 지원도 또한 데스크톱 방화벽에서 편리하다. 이것은 부서장이 사용자의 부서나 그룹의 모든 정책 요청과 업데이트를 처리할 수 있도록 해준다. 하지만 방화벽 관리 콘솔과 인증 디렉토리간에 별도의 사용자 및 그룹을 돌려야 한다는 사실을 명심하라. 새로운 직원이 고용되거나, 승진, 이동, 혹은 해고당하는 직원이 있을 때 이들은 동기화가 되지 않을지도 모른다. 따라서 IT와 HR간 커뮤니케이션 통로를 언제나 개방해 두고 사용자 액세스 정책이 최신 상태를 유지하도록 해야 한다.
데스크톱 방화벽 관리는 그다지 재미난 일은 아닐지 모르지만, 조직의 보안에 있어 매우 중요한 일이다. 배치하는 보안 사양이 고급이 될 수록 관리도 그만큼 힘들어지기 때문에, 변화 관리 프로세스를 제대로 정립시키고, 일상적인 불만들을 처리하고 사용자들에게 보안 정책에 대해 주지시키도록 헬프데스크를 교육시켜야 한다. 호스트 중심적인 보안 모델의 이점은 여기에 드는 비용을 충분히 넘어서며, 특히 보안 구멍과 공격으로 고통받는 데스크톱의 수가 늘어나고 있다는 점을 감안해 보면 이 말은 더욱 실감이 난다.

올인원 데스크톱 보안

데스크톱 방화벽 스위트는 단순한 액세스 제어 목록이 아니다. 이런 툴에는 이제 침입 탐지, 서비스 거부 공격 방지 및 기타 보안 기능들이 함께 수반된다. 네트워크 ICE(현재 ISS 소유)는 방화벽으로서 판매되었던 ISS를 반드는 데 사용된다. 시간이 흐르면서 점점 더 많은 방화벽 기능들이 추가되었다. 한편 다른 방화벽 업체들은 제품에 IDS 기능을 추가했으며, 안티바이러스와 VPN 업체들도 또한 협력 관계를 맺고 있다.
이러한 통합 데스크톱 제품들은 필시 얼마간의 비용과 관리 부담을 덜어줄 것이다. 한 세트의 사용자, 그룹 및 정책만 유지보수를 하면 되기 때문이다. 이들은 또한 예를 들어 방화벽과 VPN과의 호환성을 보장하기 때문에 인터넷에 접속되는 사용자를 위한 방화벽 규정을 만들고, 사용자가 VPN 접속을 초기화할 때 이런 규정을 변경하거나 완화시킬 수 있다. 방화벽은 안티바이러스 엔진이 가동되고 있는지를 확인할 수 있으며, 만약 안티바이러스가 꺼져 있으면 방화벽이 모든 트래픽을 차단할 수 있다.

모르는 게 약이다(?)

사용자들이 데스크톱 방화벽에서 경보를 받는 게 얼마나 효과가 있을까?
소비자용 데스크톱 방화벽은 팝업 경고 메시지들로 악명이 높다. 이들은 디폴트 게이트웨이에 호스트 기계 핑 시도가 있었다고 통보하지만, 이는 그리 유용한 정보가 아니다. 이런 데이터는 사용자를 혼란스럽게 하며, 사용자가 이런 정보를 가지고 할 수 있는 일도 많지 않다.
따라서 차단된 보안 공격의 고리 밖으로 사용자를 떼어 두는 게 최상이다. 대신 보안이나 네트워크 관리자만이 시도된 공격들을 계속 건드릴 수 있는 집중화된 보고 및 경보 시스템을 제공하라.
사용자는 특정 애플리케이션이나 프로토콜로의 접근이 거부되었을 때만 데스크톱 방화벽에서 정보를 받게 돼 있어야 한다. 예를 들어 사용자가 프로그램을 열었는데, 이것이 네트워크로 연결되지 않으면, 그는 시스템에서 무엇인가 잘못된 것이라고 생각할 것이다. 그런 다음 헬프데스크에서 문제를 진단해 보면 사실상 방화벽 규정 문제였음이 드러난다.
사용자에게 필요한 메시지는 애플리케이션이 거부됐으며, 이것이 거부된 이유와 승인될 수 있는 방법에 대한 것뿐이다. 아마도 경보에는 헬프데스크에게 이것이 시스템 문제가 아니라 액세스 제어 위반임을 설명하는 특정 에러 코드를 사용하고 싶을 것이다. 하지만 체크섬에 맞지 않는 애플리케이션은 즉각적인 주의를 요하는데, 그 이유는 이들은 사용자 기계에서 악성 코드가 돌아가고 있음을 나타내기 때문이다.
경보 정보가 중앙으로 로깅이 되도록 하라. 모든 것을 로깅할 필요 없이 직접적인 공격과 차단된 애플리케이션만 하면 된다. 예를 들어 인터넷으로 직접 연결되는 데스크톱은 일반적이고 해가 없는 포트 스캔에 대한 보고서를 보낼 필요가 없다. 그리고 데스크톱이 마이크로소프트 IIS나 아파치를 돌리고 있지 않으면, 웹 서버 공격 시도에 대한 보고서도 또한 보낼 필요가 없다.
그러나 차단되는 애플리케이션은 모두 로깅을 해야 한다. 그래야만 사용자들에게 수용 가능한 사용 정책을 설명하고 트로이 목마가 있을 법한 기계들을 계속 추적할 수 있다. 또한 헬프데스크에게 이런 보고서들로의 접근 권한이 있는지도 반드시 확인해야 한다.