다기능보다 안정성·편이성 우선… 지속적 관심·노력 ‘필수’
서버 레벨에서의 보안 작업이 가정의 각 방마다 문을 설치하고 자물쇠를 설치하는 것이라면 네트워크 관문에 침입차단시스템(Firewall)을 설치하는 것은 대문을 다는 것에 비유될 수 있다. 중앙 집중화된 접근 제어를 할 수 있는 침입차단시스템은 보안을 위해 필수적 요소라고 할 수 있다. 이번 호에서는 이러한 침입차단시스템 초기 도입을 위해 사전에 고려해야 할 점과 도입한 후에 효율적으로 관리하기 위한 방안에 대해 다루고자 한다.
<편집자>
이미 보안 솔루션을 도입한 대부분 업체에서는 침입차단시스템을 구축해 사용하고 있으며, 아직 보안 솔루션을 도입하지 않고 향후 계획을 가지고 있는 업체에서도 가장 우선적으로 구축하고자 하는 솔루션으로 침입차단시스템을 고려한다. 기업의 관문에 설치돼 보안의 3대 요소인 AAA(Authentication, Authorization, Accounting)를 네트워크에 대해 적용한 침입차단시스템은 필수적인 보안 솔루션 중의 하나다.
아무리 서버 하나 하나에 대해 불필요한 서비스를 모두 제거하고 패치를 완벽히 수행한다 하더라도 사소한 인적 실수는 있을 수 있기 마련이다. 이런 사실을 잘 반영하는 필자가 경험한 한 예를 소개하자면, 침입차단시스템을 아직 구축하지 않았지만 보안에 대한 기본 개념이 있는 전산 관리자가 있었다. 그는 최신 보안 패치를 발표될 때마다 적용하고 불필요한 서비스 제거 등의 하드닝 작업을 수행해 1년이 넘는 기간 동안 보안상 아무런 문제도 없이 지내왔다.
그러던 어느 날 기술지원 차 방문한 타 업체 엔지니어가 잠시 연결한 시스템이 마침 유행하는 인터넷 웜에 감염돼 기업의 네트워크를 마비시킨 경우가 있었다. 원인은 문제의 시스템에 최신 서비스팩이 설치돼 있지 않아 취약한 상태였다. 이와 같은 웃지 못할 에피소드는 현업에 종사하면서 많이 본 적이 있는데 이러한 경우 침입차단시스템이 있었고 유입되는 트래픽에 대해 적절한 보안 정책이 적용돼 있었다면 잠깐의 관리적인 실수에 의한 이런 일은 없었을 것이다.
작년 한 해의 가장 큰 보안 이슈였던 1.25 사태의 경우에 있어서도 이미 침입차단시스템을 도입하고 있었던 기업에서는 큰 피해를 보지 않았다. 이것은 미처 패치를 적용하지 못했더라도 다행히 해당 웜이 이용하던 공격 포트(UDP/1434)가 방화벽 정책에서 보통 개방되지 않는 서비스였기 때문이다.
서버 레벨에서의 보안 작업이 가정의 각 방마다 문을 설치하고 자물쇠를 설치하는 것이라면 네트워크 관문에 침입차단시스템을 설치하는 것은 대문을 다는 것에 비유될 수 있다. 중앙 집중화된 접근 제어를 할 수 있는 침입차단시스템은 보안을 위해 필수적 요소라고 할 수 있다. 이번 호에서는 이러한 침입차단시스템 초기 도입을 위해 사전에 고려해야 할 점과 도입한 후에 효율적으로 관리하기 위한 방안에 대해 다루고자 한다.
침입차단시스템 도입 시 고려사항
국내외적으로 많은 침입차단시스템 솔루션 벤더가 존재하고 있으며 그러한 벤더의 제품 사이에서도 다양한 제품군이 존재하기 때문에 이 중 어떤 침입차단시스템이 적합한지를 선택하는 것은 고민거리다. 몇 가지 체크할 사항과 그러한 판단에 있어서 유념해야 할 점을 정리하면 크게 6가지 정도로 간추릴 수 있다.
·성능과 안정성
침입차단시스템은 보안 장비이기도 하지만 기업의 네트워크 관문에 설치되는 장비인 만큼 성능은 가장 중요한 요소다. 최근에는 계속 고성능의 침입차단시스템이 나옴에 따라 보안 측면의 강화에도 눈을 돌리는 경향이 있지만 보안성 때문에 성능을 포기할 수 없음은 불변의 사실이다. 안정성은 말할 것도 없다. 흔히 침입차단시스템의 성능 평가 요소로 볼 수 있는 것은 다음과 같다.
- 최대 패킷 처리량(Throughput)
- 최대 동시 처리 세션 수
- 최대 초당 처리 세션 수(Session rate)
특히 위에 열거된 사항 중 가장 중요한 것은 최대 패킷 처리량으로 장비가 패킷 손실 없이 처리할 수 있는 최대 트래픽을 말하는데, 초당 처리하는 데이터량을 뜻하는 bps, 혹은 초당 처리하는 패킷의 개수를 뜻하는 pps의 단위로 표현할 수 있다.
여기서 반드시 주의 깊게 짚고 넘어가야 할 점은 pps로 표현한 수치는 평균 패킷 사이즈에 따라 큰 차이가 없지만 bps로 표현한 수치는 큰 차이가 있다는 사실이다. 그것은 현재 대부분의 침입차단시스템이 채택하고 있는 방식인 스테이트풀 패킷 필터링 방식에서 패킷의 통과 여부를 결정하기 위해 패킷 헤더를 검사하기 때문에 256바이트의 패킷 한 개를 처리하는데 걸리는 자원과 512바이트의 패킷 한 개를 처리하는데 걸리는 자원이 크게 다르지 않기 때문이다.
bps 단위의 최대 패킷 처리량은 pps 단위의 최대 패킷 처리량, 평균 패킷 사이즈, 그리고 8을 곱한 값으로 계산될 수 있다. 예를 들어 침입차단시스템이 200,000pps를 처리 가능한 침입차단시스템이고 해당 사이트의 평균 패킷 사이즈가 256바이트라면 그 환경에서의 최대 패킷 처리량은 약 400Mbps로 볼 수 있으며, 평균 패킷 사이즈가 512바이트라면 약 800Mbps로 볼 수 있다.
따라서 벤더의 데이터시트 자료에서 해당 침입차단시스템이 2Gbps를 처리할 수 있다고 한다면 어느 정도의 평균 패킷 사이즈에서 그 정도를 처리할 수 있다는 것인지 반드시 확인해야 한다. 벤더의 마케팅 자료에서는 대개의 경우 이더넷 규약 상 패킷 사이즈가 가장 큰 1,518바이트에서의 처리 성능을 이야기하고 있는 것이기 때문에 자사 실환경에서의 성능과는 매우 큰 차이가 있다.
·관리적인 편이성
침입차단시스템 역시 네트워크 장비면서 보안 장비이기 때문에 지속적인 관리가 필수적인 장비다. 중요한 몇 가지를 보면 다음과 같다.
- 설치 및 업데이트의 용이성
- 지원하는 관리 인터페이스
- 보안 정책 관리의 편이성
- 다양한 관리자 역할 지원
- 로그 관리 기능
- 리포트 기능
- 침입차단시스템 상태 모니터링
다양한 관리자 역할의 지원은 롤 구획화를 실현하는 것이다. 관리자별로 가능한 명령어를 제한해 특정 관리자는 읽기 기능만 가능하도록, 특정 관리자는 쓰기 기능도 가능하도록 할 수 있으며, 아울러 관리자가 수행한 작업에 대한 감사 기능도 제공해야 향후 문제 발생 시 원인 파악을 빠르게 할 수 있다.
로그 관리 기능에 있어서 syslog, SNMP 등의 다양한 로그 포맷을 지원하는지, 중대한 이벤트 발생 시는 별도로 SNMPtrap이나 이메일 등의 수단을 통해 전송이 가능한지 여부를 살펴봐야 한다. 자사 네트워크에 접근한 서비스에 대한 감사와 문제 분석을 위해 다양한 로깅 기능의 지원은 필수적이며 보안상 무의미한 불필요한 로그에 대해서는 남기지 않고, 그렇지 않은 로그는 남길 수 있도록 하는 상세 설정도 가능해야 한다.
침입차단시스템의 CPU, 메모리 사용량은 기본이고 이에 대한 현재의 세션 수, 성립된 세션의 내용과 같은 수치 등 다양한 값에 대한 모니터링 역시 필수 사항이다. 특히 이런 정보에 대한 다양한 SNMP MIB 정보를 제공하면 MRTG와 연동해 히스토리 분석이 가능하다.
·이중화를 통한 고가용성/로드 분산을 통한 고성능
침입차단시스템은 관문의 장비이기 때문에 장애 발생 시 모든 네트워크가 마비되는 특정 지점의 오류(single point of failure)가 될 수도 있다. 따라서 끊김 없는 네트워크 환경을 위해 이중화 방안을 마련해두는 것이 필수적이다.
하나의 침입차단시스템이 장애가 발생해 다른 침입차단시스템으로 페일오버(failover)가 발생될 때 단순히 패킷 처리만 이양되는 것이 아니라 연결중인 세션도 끊기지 않고 이양돼야 한다. 이는 스테이트풀 페일오버(stateful failover)라고 한다. 주된 서비스가 HTTP 프로토콜인 사이트의 경우라면 이는 세션 기반의 프로토콜이 아니기 때문에 크게 중요하지는 않으나, 금융거래가 이뤄지는 사이트나 온라인 게임 사이트와 같은 경우는 매우 중요한 기능이다.
이중화 구성 방안으로는 액티브-스탠바이(Active-Standby), 액티브-액티브(Active-Active) 구성의 두 가지 방안이 있는데 전자는 하나의 침입차단시스템은 다른 침입차단시스템이 장애 발생될 때까지 대기 중인 상태로 있다가 장애 발생 시 활성 모드로 전환해 트래픽을 처리하게 된다. 후자의 경우는 두 침입차단시스템이 모두 활성 모드로 있으면서 로드밸런싱을 하는 것인데 레이어 4 스위치가 추가적으로 필요하다.
이 경우 고려해야 할 점은 스테이트풀 페일오버가 불가능하다는 점과 침입차단시스템 처리 가능한 최대 세션 수가 레이어 4 스위치에 의해 병목현상(bottleneck)이 발생할 수 있다는 점, 그리고 레이어 4 스위치가 또 다른 장애 포인트가 될 수 있다는 점이다. 그 외 일부 침입차단시스템은 레이어 2 스위치만으로 로드밸런싱까지도 수행할 수 있는 기술을 구현하고 있다.
·침입차단시스템 인증 기능
종래의 패킷 헤더 정보에만 기반해 필터링을 수행한 침입차단시스템은 재택 근무자와 같은 유동 IP 사용자에 대한 접근 제어를 하기 위해 그러한 재택 근무 사용자의 작업 시작과 함께 임시로 방화벽 정책을 허용해야 하고 작업 완료 후 해당 정책을 다시 삭제해야 한다는 번거로운 점이 있었다. 이런 과정에서 작업 완료 후 정책을 삭제해주는 과정을 누락했다면 불필요한 정책은 증가돼 성능상의 문제, 보안상의 문제가 야기될 수 있다.
이런 점을 해소하기 위해 추가된 것이 침입차단시스템 인증 기능이다. 재택 근무자가 작업이 필요할 시에 정책을 따로 입력하는 대신, 인증을 요구하는 창에 ID와 패스워드를 입력한다. 이렇게 인증 받은 사용자 IP에 대해 인증 정보가 캐쉬되어 있는 동안 정책은 허용돼 있는 것과 같은 효과를 얻고 작업이 완료되면 인증 정보가 사라지면서 다시 해당 정책은 차단된다. 물론 사용자 인증은 침입차단시스템 정책 라인별로 정의할 수 있어 유연성이 있다.
이 때 제품에 따라 사용자 데이터베이스는 침입차단시스템 자체만으로 충분하기도 하고 TACACS+/래디우스 같은 다른 인증 제품과의 연동이 필수적인 경우가 있다. 침입차단시스템 자체만을 이용한 인증은 설정이 간편하나 ID, 패스워드 관리도 침입차단시스템에서 이뤄져야 하기에 불편할 수 있다는 점인데, 그런 점은 TACACS+/RADIUS 등과 같은 인증 서버와 연동함으로 해결이 가능하다. 또한 시큐어ID와 같은 일회용 패스워드 인증 솔루션과 연동함으로써 이러한 인증 사용자에 대한 접근에 한층 더 보안을 강화할 수도 있다.
·상위 레벨 프로토콜 분석(protocol inspection) 기능
초기 방화벽에서 다루기 힘든 연결 중 하나가 FTP 프로토콜이었다. 이 프로토콜은 FTP 명령어를 전달하는 컨트롤 세션과 실제 데이터를 교환하는 데이터 세션 두개의 세션으로 나뉘며 데이터 세션은 동적으로 개방되는 것이기 때문이다. 침입차단시스템에서는 이러한 동적으로 개방되는 데이터 세션을 처리하기 위해 상위 레벨 프로토콜에 대한 지원이 필요했다. 즉 최근의 대부분 침입차단시스템은 FTP 프로토콜을 지원하기 때문에 동적으로 오픈될 데이터 세션을 별도로 허용해줄 필요가 없다.
이 외에도 H.323, SIP 등의 프로토콜이 자사에서 이용된다면 침입차단시스템에서 지원되는지 확인이 필요하다. 정상적인 서비스 사용을 위한 프로토콜 분석 기능 외에 보안성 향상을 위한 기능도 있는데 URL 필터링, SMTP, FTP 명령어들에 대한 제한 기능 등이다. 이러한 보안성 향상을 위한 프로토콜 분석을 위해서는 자체 제품만으로 가능한 경우가 있고, 웹센스(WebSense) 등과 같은 제품과의 연동이 필요한 경우가 있으니 해당 기능이 필요하다면 그러한 점도 확인돼야 한다.
·VPN 기능
VPN 기능은 지사간의 연결에 있어서 저렴한 비용으로 사설망의 효과를 얻을 수 있기 때문에도 사용되지만, 재택 근무자, 파견자 등과 같이 원격 액세스 사용자로 하여금 안전한 접속 환경을 제공하기도 한다. VPN 장비는 전용 장비 형태로 침입차단시스템과 함께 서로 병렬 구조로 설치되거나 직렬로 설치된다. 또 침입차단시스템의 DMZ에 VPN 장비를 구성하기도 하는데 아예 침입차단시스템에 VPN 기능이 통합돼 나오는 경우도 있다. 따라서 간단한 VPN 기능을 사용할 예정이라면 기능이 통합된 장비를 선택하는 것도 효과적이다. 이 때 별도의 라이선스 구매가 필요한 경우가 있으므로 확인해야 한다.
침입차단시스템의 관리
이러한 침입차단시스템을 도입한 후, 올바른 활용을 위해 알아야 할 점을 몇 가지 제안한다.
·구성 관리
침입차단시스템의 도입 후 구성을 하면서 고려하는 사항 중 하나와 흔히 받게 되는 질문이 DMZ 구성을 할지 여부와 그것의 필요성이다. 간단히 말해서 DMZ는 보안 레벨이 서로 다른 네트워크를 구분하기 위해 구성한다. 예를 들어 웹 서버, DNS, 메일 서버와 같은 경우는 외부의 임의의 클라이언트로부터의 접근이 필요하며, DB 서버와 같은 경우는 웹 서버 등의 일부 서버만 접근하면 되고 외부에서는 접근할 필요가 없으므로 이들은 보안 레벨이 서로 다른 것이다.
이 경우 임의의 클라이언트로부터의 접근이 필요한 서버는 DMZ에, 그렇지 않은 나머지 서버들은 내부 네트워크 쪽으로 배치하며, 이 경우의 보안 레벨을 상대적으로 비교하면 내부 네트워크 > DMZ > 인터넷 순이다. 외부로부터 임의의 클라이언트에 대해 노출돼 있는 DMZ에 있는 서버가 해킹을 당한다 하더라도 훨씬 중대한 정보들이 담겨 있는 내부 네트워크에 접근하기 위해서는 침입차단시스템을 한번 더 통과해야 하기 때문에 침입차단시스템 한 대를 이용해 침입차단시스템을 이중으로 구축한 것과 같은 효과를 얻을 수 있다.
이에 반해 DMZ를 구축하지 않고 메일 서버, DNS 서버들을 그대로 내부 네트워크에 방치할 경우 해당 서버가 침해된다면 그 서버를 통해 내부 네트워크에 있는 다른 서버들로도 모두 접근할 수 있기 때문에 쉽게 전이 공격을 시행할 수가 있게 된다.
·보안 정책 관리
보안 정책 관리는 침입차단시스템에 있어 핵심적인 부분이다. 정책에서 허용돼 있는 서비스가 많으면 많을수록 침입 가능성은 높아지기 때문이다. 초기 디자인부터 세심하게 지속적인 리뷰가 필요하다. 정책 디자인에서는 크게 내부로의 접근, 그리고 외부로의 접근 두 가지로 나눠 생각하도록 한다.
내부로의 접근은 다시 모든 클라이언트로부터의 접근을 허용해야 하는 정책, 그리고 특정 클라이언트로부터의 접근만 허용하면 되는 관리적인 정책의 두 가지로 분류해 관리한다. 모든 클라이언트로부터의 접근을 허용하는 정책은 주기적으로 리뷰를 해야 한다. 아무리 정책을 상세하게 세웠다 하더라도 테스트를 위해 잘못 입력된 단 한 줄의 정책으로 보안상 돌이킬 수 없는 구멍이 될 수 있기 때문이다. 또한 구성을 단순화하기 위해서 외부로의 접근은 모두 허용하도록 설정할 수 있으나, 보안을 고려하기 위해서는 외부로의 접근에 대해서도 철저한 보안 정책이 필요하다.
·로그 관리
로그는 어느 정도 수준까지를 남길 것인지에 대한 회사의 정책부터 결정해야한다. 다음과 같이 크게 세 가지의 분류로 나누어 어떠한 로그를 남길지 판단한다.
- 모든 클라이언트로부터의 서비스 목적의 접근을 허용하는 서비스에 대한 허용 로그
- 특정 클라이언트로부터의 관리적인 접근을 허용하는 서비스에 대한 허용 로그
- 접근 거부 로그
위해서 두 번째와 세 번째는 보안상 의미를 가지기 때문에 남기는 것이 보통이며, 첫 번째는 로그량에 따른 침입차단시스템의 성능과 로그를 저장할 서버의 용량(capacity)을 고려해 남길지 그러지 않을지를 결정해야 한다. 백업 미디어를 통한 이러한 로그의 정기적인 백업이 필수적인 것은 물론이다.
·모니터링
침입차단시스템 장비에 대한 장애여부 체크(Aliveness Check)는 필수적이며, MRTG 등을 통한 트래픽, CPU 사용량, 메모리 사용량, 세션 사용량 등은 주기적으로 모니터링 해야 한다. 또한 MRTG를 통해 조기 경보 기능을 설정할 수 있는데 네트워크 장애에 대한 조기 발견 및 대응에 매우 효과적이다. 예를 들어 침입차단시스템의 CPU 점유율이 50% 이상 올라가면 메일로 관리자에게 오도록 설정할 수 있는데 이것을 잘 활용해 이상 트래픽의 급증에 대한 조기 탐지 및 대응도 가능하다. 설정에 대한 상세한 방법은 MRTG 관련 사이트를 참고하기 바란다.
·운영 절차 관리
막대한 투자 비용을 들여 도입한 침입차단시스템일지라도 그것을 관리할 보안 인력이 없고 절차가 없다면 무용지물이다. 따라서 솔루션 도입과 더불어 그것을 효율적으로 관리할 보안 인력과 적절한 운영 체계 마련이 근간 시 돼야 한다.
결론
이제까지 가장 기본적인 보안 솔루션인 침입차단시스템의 도입 이전에 고려해야 할 점, 그리고 도입 이후 활용에 대한 몇 가지 방안을 알아봤다. 그리고 최근에는 침입차단시스템과 침입탐지시스템의 장단점을 접목한 침입방지시스템(Intrusion Prevention System)도 국내 시장에서 점차 소개되고 있으나 아직 시장이 활성화되지는 않은 상태다.
가장 중요한 것은 복잡한 기능을 구가할 수 있는 솔루션의 도입이 아니라 자사에 적합한 솔루션을 선정해 도입하고 그것을 얼마나 효율적으로 관리하느냐 하는 것이다. 즉, 관리자의 관심과 노력이 무엇보다도 중요한 셈이다.
