최근 몇 년간 다양한 웜이 창궐하면서 보안에 대한 인식이 높아지고 있다. 특히 MS SQL 웜으로 발생한 1.25 대란은 전 국가적 네트워크 마비로 이어졌기 때문에 시스템 관리자로 하여금 보안의 필요성을 피부로 느낄 수 있는 계기가 됐다. 지금까지 잘 알려진 웜과 그 발표일을 정리해보면 <표 1>과 같다.
| <표1> 웜에 대한 초기 발견일 및 관련 취약성 발견일 | ||||
웜 이름 | 관련 서비스 | 관련 취약성 | 웜 초기 발견일 | 취약성 발견일 |
님다 웜 | HTTP | MS00-078 | 2001년 9월 18일 | 2000년 10월 17일 |
코드레드 웜 | HTTP | MS01-033 | 2001년 7월 16일 | 2001년 6월 18일 |
MS SQL 웜 (슬래머) | MS SQL (UDP/1434) | MS02-039 | 2003년 1월 25일 | 2002년 7월 24일 |
블래스터 웜 | MS RPC (TCP/135) | MS03026 | 2003년 8월 11일 | 2003년 7월 16일 |
MS SQL 웜의 경우 약 7개월 전에 이미 취약성과 그에 대한 패치가 발표된 바 있다. 또한 <표 1>을 보면 취약성 발견 이후 그를 이용한 웜이 개발될 때까지 적어도 약 1개월 정도 소요된 것을 볼 수 있는데, 기간의 차이는 있지만 어떻게 보면 알면서도 그러한 사고를 막지 못했던 셈이다. 취약성이 초기 발표된 지 이미 2년 반이 넘은 코드레드 웜도 <그림 1>과 같이 종종 실제 환경에 운영 중인 침입탐지시스템(IDS)을 통해 탐지되는 것을 보면 아직도 패치에 대한 개념이 없는 곳도 많다. 패치가 제대로 이뤄지지 않은 시스템에 이와 같은 웜이 유입되면 순식간에 감염돼 다른 시스템으로의 전파를 시도한다.
이러한 웜에 의한 피해는 크게 두 가지 부분에서 타격이 될 수 있다. 첫째, 자사의 네트워크 가용성을 파괴할 수 있다. 필자가 일전에 MS SQL 웜 생성기 프로그램으로 고립된 네트워크 구성을 통해 테스트 해본 결과 단 하나의 시스템에서 유선 속도(wire-speed)에 가까운 트래픽을 생성했으며, 이러한 웜에 감염된 시스템은 사내 네트워크 전체를 마비시킬 수 있다.
둘째, 기업의 보안에 대한 신뢰성에 악영향을 끼칠 수 있다. 이러한 웜 감염자 소스IP를 가지고 간단한 후이즈(whois) 쿼리를 통해서도 해당 IP가 어느 소속인지 알 수 있다. 당연히 그 기업 내에 웜 감염된 IP가 존재한다는 것은 신뢰성에 큰 손상을 줄만한 일이 되고 특히 금융권과 같이 보안에 매우 민감한 사이트의 경우 이로 인한 손실은 상상하기 힘든 치명적인 것이다.
패치 미적용으로 인한 피해의 가능성은 웜을 예로 들어 설명했지만, 당연히 모든 보안 위협이 해당된다. 수년간의 모의해킹 경험에서 대상 네트워크에 침해할 수 있는 경우 중 많은 경우가 알려진 보안 취약성을 통해서였고, 그에 대한 패치 또한 이미 존재하는 경우였다.
현업에서 종사하는 관리자가 패치를 소홀히 하는 이유 중 하나는 침입차단시스템을 도입하고 있어서 패치할 필요가 없다는 것인데 이것은 오해다. 왜냐하면 보안 정책에서 허용하는 서비스에 대한 공격은 침입차단시스템이 차단할 수 없고, 침입차단시스템을 경유하지 않는 공격, 예를 들어 내부 서버들간의 공격은 보호할 수 없기 때문이다. 지난 호에서 보안의 우선 순위를 말할 때 패치를 가장 우선해 이야기했던 것도 이 때문이다.
또 하나의 이유는 그간 자사에 패치 미적용으로 인해 보안 사고가 일어난 적이 없고, 오히려 잘 운영되던 시스템에 패치를 적용했을 때 발생할지 모를 문제가 염려되는 것인데, 이는 어쩌면 해킹 당하느냐 마느냐를 놓고 모험을 하는 것과 같다. 이미 해킹 당한 후에 보안 적용을 검토하면 많은 손실을 본 이후가 될 것이다. 이와 같이 패치는 더 이상 수동적인 태도로 대응할 것이 아니며, 하나의 과정으로서 관리돼야 한다.
패치 관리 절차
효율적인 패치 관리를 위해서는 적절한 패치 관리 절차가 수립돼야 한다. 패치 절차는 기업의 특성에 따라 다르지만 일반적인 기업의 패치 관리(Patch Management) 절차는 <그림 2>와 같다.
1. 자산 목록 작성
기업에서 보호하고자 하는 자산 목록(inventory)을 작성한다. 목록에는 OS 및 서비스팩 정보, 사용 애플리케이션 및 버전 정보, 해당 시스템에 대한 관리자 등과 같은 정보는 필수적으로 반영돼야 한다. 이런 과정에서 불필요한 애플리케이션이나 서비스가 실행 중이라면 중지하는 것이 최소 권한의 원칙이라는 측면에서 보안성을 향상시킬 수 있을 것이고, 향후 지속적인 패치 관리의 편이성을 위해서도 바람직할 것이다.
2. 보안 취약성 및 패치 검토
사용하고 있는 시스템에 대한 새로운 취약성의 존재 여부는 관련 시스템 취약성 정보를 받아 볼 수 있는 메일링리스트 가입, 웹사이트 등을 통해 주기적으로 모니터링해야 한다. 그리고 신규 취약성이 발견됐을 경우, 패치 적용의 시급성에 대한 판단도 이 과정에 포함돼야 한다. 시급성에 판단 기준은 기업에 따라 다르겠지만 보통 모든 클라이언트에게 접근을 허용할 필요가 있는 서비스(DNS, HTTP, SMTP 등)인지, 해당 취약성이 기밀성, 가용성, 무결성 측면에서 어떤 위협을 초래할지를 살펴봐야 한다. 특히 모든 클라이언트에게 접근을 허용할 필요가 있는 서비스는 취약한 서비스 차단/중지 등의 임시책(workaround)을 적용하기가 쉽지 않아 시급성을 요한다.
3. 환경 분석
자사에 발견된 취약성에 대한 패치를 적용해야 하는 시스템이 어떤 것이 있는지 확인한다. 보통 앞서 작성한 자산목록과 취약성 분석 툴, 혹은 나중에 이야기할 패치 관리 시스템 등의 자동화 툴에 의한 점검으로 이뤄진다. 이 과정에서 누락된 시스템 하나로 인해 기업의 전체 네트워크에 대한 보안성이 위협받을 수 있다는 점을 유의해 조사해야 한다.
4. 패치 적용 계획
패치 적용 일정과 작업 계획을 수립해야 한다. 이때 패치 실패 시 롤백(roll-back)에 대한 것도 충분히 고려해 백업 등에 대한 일정도 검토해야 한다. 그리고 패치 이후 서버의 정상 가동 여부를 확인하기 위한 체크 리스트도 필요하다.
5. 패치 테스트
실제 테스트 시스템에 패치를 적용해 가능한 문제점을 테스트하는 과정이며, 테스트 시스템은 실제 운영 중인 시스템과 동일한 환경일수록 좋다. 또한 이 과정을 통해 실제 운영 중인 시스템에 대한 패치 적용에 앞서 누락할 수 있는 절차 및 주의 사항을 다시 한번 숙지할 수 있다.
6. 패치 적용
실제 패치 작업을 수행하며, 문제 발생 시 롤백을 수행한다. 패치 적용 이전에 해당 벤더에서 패치에 대해 배포한 문서를 충분히 검토해야 한다.
7. 모니터링
패치 적용 후 서비스에 문제점은 없는지 주의 깊게 모니터링을 해야 한다. 물론 모니터링 대상 항목들은 패치 적용 계획 수립 단계에서 나와 있어야 한다.
패치 매니지먼트 시스템 (Patch Management System)
1인당 1대 패치에 걸리는 시간이 10분, 패치 실패율이 1%, 복구에 걸리는 시간이 1시간, 패치 대상 서버 수가 200대라면 한 사람이 하루 8시간씩의 작업으로 약 4일 간을 패치에 소요해야 한다.
패치 적용 소요 총 자원 = 패치 대상 서버 수 × (한 대 패치에 소요되는 자원 + 패치 실패율 × 한 대 복구에 소요되는 자원)
물론 이는 패치 적용에 드는 자원만 생각한 것이며 총체적인 패치 관리 프로세스인 환경 분석, 패치 테스트, 모니터링 시간 등도 포함하면 훨씬 더 많은 시간이 필요하다. 1년에 대응해야 할 취약성의 수도 고려하고, 보다 서버 대수가 많아지면 이런 작업을 모두 수작업으로 진행하기는 불가능해진다.
따라서 이러한 일련의 패치 관리 작업을 자동화하기 위한 솔루션들이 개발되어 있고 HfNetChk나 MBSA, SUS(So- ftware Update Services) 등과 같은 공개된 툴은 이미 사용해본 관리자도 많을 것이다.
하지만 아직까지 이러한 툴은 중앙관리가 불가능하거나 불편하며, 지원하는 OS 및 애플리케이션이 한정돼 있고, 리포팅 기능 등 또한 미약하다. 이를 보완하기 위한 상용화 툴이 시장에 나와 있지만, 국내에 소개된 제품은 많지는 않다. 따라서 외산 제품의 경우 국내 환경에 맞는 로컬라이제이션(localization)이 필요할 수 있다. 예를 들면 윈도 한글판 등에 대한 패치 관리가 문제없이 지원되는지를 말한다. 이러한 패치 매니지먼트 시스템의 몇 가지 예를 보면 <표 2>와 같다.
| <표2> 패치 매니지먼트 시스템 | ||
분류 | 제품명 | 특징 |
공개 | MS 소프트웨어 업데이트 서비스 | - 윈도 전용 - 윈도 NT, MS오피스, SQL서버, 서비스 팩 등은 지원하지 않음 |
| MS 베이스라인 시큐리티 애널라이저 | - 윈도 전용 - 윈도 98/Me는 지원하지 않으며 SQL서버, 오피스 등에 대한 검사 가능 - 패치 누락 외의 설장 관련된 취약성 점검 | |
| 솔라리스 패치 매니저 베이스 | - 솔라리스 전용(솔라리스 6,7,8) - 썬솔브(Sunsolve) 사이트로부터 다운로드 가능 | |
| 솔라리스 패치프로 | - 솔라리스 전용(솔라리스 9) - 썬솔브 사이트로부터 다운로드 가능 | |
상용 | 패치링크 패치링크 업데이트 | - 에이전트 기반 - 윈도 지원(NT, 98/Me 포함) - 리눅스 지원(레드햇, 데비안, 수세, 맨드레이크 등) - 유닉스 지원(솔라리스, AIX, HP-UX 등) |
| Shavlik HfNetChk 프로 | - 에이전트 없는 구조 - 윈도 전용(NT, 98/Me 포함) - 익스체인지 서버, SQL 서버 등 지원 - 스케줄 작업 지원 | |
| 빅픽스(BigFix) 패치 매니저 | - 에이전트 기반 - 윈도 지원 - 리눅스 지원(레드랫, 수세 등) - 유닉스 지원 (현재 : 솔라리스, 추가예정 : AIX, HP-UX) | |
| 래비티 스톰 서비스 팩 매니저 2000 | - 에이전트 없는 구조 - 윈도 전용(윈도 NT, 2000, XP 등) | |
패치 매니지먼트 시스템 선택 시 고려 사항
현재의 패치 매니지먼트 시스템이 모든 패치 관리 작업을 대행할 수 있는 것은 아니다. 또한 패치 매니지먼트 시스템마다 지원하는 운영체제 및 애플리케이션 목록이 다르며 이러한 한계를 명확히 확인한 후에 사용돼야 한다. 그 외에 패치 매니지먼트 시스템 도입 시 검토되어야 할 사항은 다음과 같다.
- 자사에 사용 중인 OS 및 애플리케이션 지원 여부, 특히 윈도 서버의 경우 한글 버전과 같은 로컬 버전(localized version)도 지원하는지
- 각 대상 서버에 대한 패치 적용/미적용 내역 검토 가능 여부
- 대상 서버에 대한 그룹핑 관리(grouping) 지원 여부
- 대상 서버들로의 패치 적용을 위한 네트워크 대역폭 조절 가능해 패치 배포로 인해 네트워크가 마비되는 일은 없는지
- 에이전트 설치가 필요하다면 에이전트 설치로 인한 필요 리소스는 어느 정도인지
- 패치 적용 필요 내역에 대한 우선 순위를 제공하며 우선 순위 분류 기준은 명확한지
- 예약 작업이 가능하며 예약 작업 결과(성공/실패 등)에 대해 통보 받을 수 있는지
- 서비스 단절을 최소화하며 패치를 적용할 수 있는지
- 문제 발생 시 패치 적용 이전 상태로 롤-백 지원 여부
- 각 구성 요소간의 통신은 암호화를 지원하며 패치 배포 시 배포되는 패치 파일의 조작 위험은 없는지
- 일련의 작업에 대한 보고서를 지원하며 보고서 형식은 적합한지
- 제품에 대한 기술지원 체계
맺음말
보안에 있어서 가장 중요한 것은 복잡하고 다양한 기술이 아니라 지속적이고 체계적인 관리다. 시스템에 대한 패치 관리는 무엇보다 기본적인 작업이 된다. 지난해 1.25 대란이 발생했을 때 그나마 이 웜이 UDP/1434를 대상으로 한 것이라 각 ISP 관리자가 라우터 단에서 해당 포트로의 트래픽을 차단함으로 몇 시간 동안의 장애를 해소할 수 있었던 기억이 난다.
MS SQL 웜은 300바이트 가량의 UDP 패킷을 사용했는데 UDP는 특히 TCP와 달리 연결 지향 프로토콜이 아니기 때문에 네트워크 대역폭이 허용하는 최대 한도에서 짧은 시간 안에 훨씬 더 많은 패킷을 보내면서 공격을 할 수 있기 때문에 기존의 TCP 기반 웜과 달리 전 국가적인 장애를 초래한 것이었다.
필자는 향후 DNS 서비스가 이용하는 UDP/53 포트를 대상으로 한 웜이 나타난다면 어떨까 하는 상상을 종종 하게 되는데 라우터 단에서 쉽게 차단할 수도 없기에 피해는 상상치 못할 수준이 되지 않을까. 준비가 얼마나 잘 되어 있는지에 따라 시스템 관리자의 희비가 엇갈리게 될 것이다. 
※ 필자 사정상 연재 내용이 일부 변경됐습니다. 이 점 양해해 주시기 바랍니다.
