웹 서버 보안 지침

Version 1.0

이 현 우

KAIST ISC 선임연구원

lotus@securitymap.net

www.securitymap.net

I. 개요

II. 웹서버 보안 지침

1. Level I 지침 : 기본 서버 보안 지침

1.1 소프트웨어 업그레이드 및 패치 설치

1.2 단독 목적의 웹 서버 사용

1.3 불필요한 어플리케이션 제거

1.4 백업

2. Level II 지침 : 침입 예방을 위한 지침

2.1 침입차단시스템(Firewall) 사용

2.2 원격 접근 제한

2.3 안전한 웹서버 프로그램

2.4 웹 트랜잭션 보안

2.5 보안 교육

3. Level III 지침 : 침입 탐지 및 대응 지침

3.1 추가적인 접근 통제 시스템 설치

3.2 침입 탐지

3.3 사고 대응

I . 개요

웹사이트는 일반기업 및 정부기관 등에 있어, 매우 중요한 역할을 수행하고 있다. 기업의 마케팅 및 제품 정보를 인터넷 상의 잠재적인 고객에게 알려주는 역할을 비롯하여 e-business를 통한 수익창출 까지 그 역할이 확대되고 있다.

반면, 이러한 중요성 때문에, 해킹의 주요 공격 대상이 되고 있는 것이 사실이다. 특히, 웹 서비스는 대부분의 사이트에서 대중에 제공하는 서비스이며, 따라서 공격자를 포함한 인터넷상의 모든 사용자가 접근할 수 있어 더욱 공격 대상이 되기 쉽다.

웹사이트의 해킹에 의한 피해는 다음과 같이 여러 종류로 나타날 수 있다.

o 첫 번째, 해당 기업 또는 조직, 심지어 한 국가의 명예까지도 손상 할 수 있다. 대부분의 악의적인 공격은 해당 기업, 또는 정부의 정책 등을 비난하는 내용으로 홈페이지를 변조한다.

o 두 번째, 홈페이지를 변조하지 않더라도, 기본적으로 Firewall에서 열어놓은 웹서버가 공격을 당하게 되면 다른 내부의 모든 시스템으로 쉽게 그 공격이 확장될 수 있다.

o 세 번째, 다른 인터넷 사용자들이 웹서비스에 접속하지 못하게 하는 서비스 거부공격은, 전자상거래 기업의 경우 막대한 손실을 입히게 되고, 원하는 정보를 일반 사용자에게 전달하지 못하게 된다.

본 지침은 보다 안전한 웹서버 운영을 위한 보안 대책을 다룬다. 일반적으로 수행되어야 할 보안 활동에 대해서 기술적 능력 및 소요되는 보안비용에 따라 세 단계로 나누어 설명함으로서 각 조직의 보안비용 여건에 따라 적정 수준의 보안을 유지할 수 있도록 한다. 물론 세 단계의 모든 지침이 적용되는 것이 가장 바람직한데, 각 단계들은 □다단계 보안(granularity of security)□, □Defense in Depth□, 또는 □최악의 상황을 고려□한다는 기본적인 보안원칙에 따른 것이다.

각 단계의 지침에서 세부 기술적 내용들은 따로 인터넷상의 자료들을 링크해 주고 있다. 따라서 본 지침은 보안 관리를 위한 일반지침으로 사용하고 세부 기술지침은 각각의 내용 중에 외부 사이트의 링크를 참조하면 된다. 이는 각 조직에서 일반 보안정책 및 보안지침을 작성하기 쉽도록 하기 위함이다.

※ 참고자료 대부분을 www.securitymap.net 사이트에 아카이브하고 있으므로 만약 링크가 끊어진 자료는 이를 참조 바람

II. 웹 서버 보안 지침

1. Level I 지침 : 기본 서버 보안 지침

본 □기본 서버 보안 지침□에서 기술하는 내용은 웹서버 이외의 추가적인 비용이 들지 않으며, 기본적인 서버관리 기술만을 요구하는 최소한의 보안 지침을 다룬다. 따라서 본 문서에서 기술한 모든 내용을 다룰 수 없는 경우에는 최소한 "Level I" 지침은 반드시 적용되어야 한다.

1.1 소프트웨어 업그레이드 및 패치 설치

반듯이 최신버전의 소프트웨어로 업그레이드하고, 보안 패치를 설치한다. 이는 인터넷 공격에 대응하기 위한 가장 간편하고 효과적인 방법이다. 항상 최신 버전의 소프트웨어를 사용하고 보안과 관련된 패치를 설치하여야 한다. 특히, 웹서버의 경우 주기적으로 웹서버에서 사용되는 어플리케이션에 대한 새로운 업데이트 및 보안 패치를 확인하도록 한다. 이러한 어플리케이션으로는 다음과 같은 것들이 포함된다.

o 운영체제

o 웹서버

o 기타 웹서버에서 사용하는 다양한 소프트웨어 들

다음과 같은 절차 및 지침을 정해두고 이를 주기적으로 수행한다.

o 서버에서 사용되는 소프트웨어 목록 및 관련 버전 정보 목록 관리

o 각 소프트웨어를 제공하는 회사의 웹페이지를 확인하여 최신버전 설치 여부 확인

o 각 소프트웨어의 보안과 관련된 보안 패치 확인 및 설치

※ 각 소프트웨어 업체는 보안과 관련된 페이지를 가지고 있으며, 보안 패치를 설치하는 방법 등에 대한 자료를 제공한다.

o 패치 설치 후 서버의 정상적인 운영상태 확인

1.2 단독 목적의 웹 서버 사용

각 기관은 반듯이 웹 서비스만을 위한 단독 서버를 구축하여 운영해야 한다. 많은 경우 예산 절감을 위하여 하나의 시스템에 웹서버, 메일서버, DNS 서버, 데이터베이스 서버를 운영하는 경우가 있는데 이는 웹서버를 포함하여 데이터베이스 서버까지도 위험하게 한다. 일반적으로 하나의 서비스가 추가될 때마다 그만큼 더 위협이 증가하게 된다.

특히, 중요한 정보를 다루는 데이터베이스 서버의 경우 가능한 웹서버와 분리하여 서로 다른 시스템에서 운영하는 것이 바람직하다.

1.3 불필요한 어플리케이션 제거

웹 서버에서 사용되지 않는 모든 불필요한 소프트웨어는 반듯이 제거한다. 디폴트로 시스템을 설치하게 되면 많은 경우 다양한 종류의 소프트웨어들이 설치되고 실행되게 된다. 그리고 이러한 소프트웨어의 취약점으로 인하여 해킹을 당하게 된다. 반면 일반 관리자들은 이러한 소프트웨어들이 자신의 서버에서 실행되고 있는지 조차 모르는 경우가 많다.

1.4 백업

웹 서버에 대한 백업은 만약 해킹을 당한 경우에, 빠르고 효율적으로 웹서버를 복구할 수 있도록 한다. 백업 주기는 웹서버 업데이트 주기에 맞추어 설정하는 것이 좋다.

[참고 자료]

o Windows NT/2K 기본 보안 체크리스트 :

- http://www.securitymap.net/sdm/docs/windows/M$_checklist_V1.1.pdf

o Solaris Minimization

- http://www.securitymap.net/docs/system-sec/solaris-minimization.pdf

o Armoring Solaris

- http://www.enteract.com/~lspitz/armoring.html

o Building HP-UX Bastion Hosts

- http://people.hp.se/stevesk/

o Linux 보호하기

- http://www.securitymap.net/sdm/sdm-index.html

2. Level II 지침 : 침입 예방을 위한 지침

침입 예방을 위한 지침은 "Level I" 지침에 더하여 추가적인 보안도구를 이용하거나, 또는 수준 높은 서버관리 기술을 필요로 한다. 이는 "Level I" 지침보다 보다 안전한 웹서버 운영을 위한 지침을 제공한다. 각 기관의 여건 및 업무 능력에 따라 본 지침은 간과 될 수도 있으나, 가능한 준수해야할 사항들이다.

2.1 침입차단시스템(Firewall) 사용

라우터와 침입차단시스템을 이용하여 DMZ 구간 네트워크를 구성하고, 웹서버를 비롯한 일반 인터넷 서비스(Public Service/System)를 제공하는 시스템을 이곳에 설치하도록 한다.

[그림 1]

[그림 2]

※ 주의 : DMZ은 Firewall을 이용하여 구성[그림 1]할 수도 있으며, Screening 라우터를 이용하여 구성[그림 2]할 수도 있는데, Screening 라우터를 이용할 경우, 라우터에서 DMZ 구간에 대한 충분한 패킷 필터링을 제공해야 한다. 또한 인터넷 서비스를 제공하는 DMZ에 위치한 서버에 대해서는 최대한의 보안조치(Bastion Host로 설정, 이에 대해서는 Level 1에서 언급한 참고 자료를 참조)를 취해야 한다.

그리고 만약 웹 서버가 해킹 당할 경우까지도 고려한다면 그리고 정말 중요한 시스템에 대한 보안을 위해서는 내부 Firewall을 추가로 설치할 수 있다. 이는 만약의 경우, 웹서버(그림상에서 Public System)가 해킹을 당할 경우에 공격자가 웹서버를 통하여 또 다른 중요 서버나 내부 시스템으로 침입을 하지 못하도록 한다.

[참고 자료]

o Building Internet Firewall, O REILLY, 한글 번역서(인터넷 방화벽 구축하기)

o IpFilter Firewall 설치 및 운영:

- http://www.certcc.or.kr/tools/firewall/IPfilter/IPfilter.html

o 리눅스 Firewall 구축

- http://kldp.org/네트워킹/방화벽(firewall)/

o Improve Computer Security Through Network Design

- http://www.securitymap.net/sdm/docs/netsec/sec-domain/Security_Domains.html

2.2 원격 접근 제한

웹서버 관리의 편리성을 위해 관리자는 종종 콘솔을 이용하기보다는 원격지에서 웹서버로 접속하는 경우가 많다. 이 경우, 네트워크 도청 등의 공격을 통하여 공격자는 관리자의 ID나 패스워드를 획득하고 시스템에 접근할 수 있다. 따라서 가능한 원격 접근을 최소화하거나 하지 않아야 한다.

하지만 대부분의 경우(인터넷데이터센터에 서버를 호스팅한 경우 등) 불가피하게 원격으로 시스템 관리를 해야 하는데, 이럴 경우에는 다음과 같은 보안 대책을 마련하여야 한다.

o 시스템 관리를 위해 원격 접근을 할 경우에는 반드시 ssh과 같은 암호화를 제공하는 도구를 사용한다.

o 침입차단시스템 또는 라우터의 패킷 필터링 기능을 이용하여 관리자가 특정 시스템에서만 웹서버에 접근할 수 있도록 설정한다.

※ 주의 : 패킷 필터링 방법이 암호화 기능을 대체할 수 없음을 이해하여야 한다.

[참고 자료]

o ssh 설치 및 운영

- http://kldp.org/시스템_관리/보안(Security)/SSH/

o Universal SSL Wrapper

- http://www.stunnel.org

o Linux FreeS/WAN, implementation of IPSEC & IKE for Linux

- http://www.freeswan.org/

2.3 안전한 웹서버 프로그램

대부분의 웹사이트는 서비스의 다양한 기능을 위하여 CGI와 같은 웹 스크립트 기능을 사용하게 된다. 웹 서버를 공격하는 공격자는 대부분 이러한 스크립트의 취약점을 찾아 공격을 하게 된다. 따라서 다음과 같은 지침을 사용하여 웹서버 스크립트 프로그램을 관리하는 것이 바람직하다.

o 개발자는 웹서버에서 사용되는 스크립트 프로그램의 보안위협에 대하여 인지하고 프로그램 개발

o 보안 관리자는 웹서버상의 모든 스크립트에 대하여 보안성 검토

o 새로운 스크립트는 보안성을 검토한 뒤 실제 시스템에 적용

이러한 웹 어플리케이션을 개발할 경우에는 항상 보안을 염두에 두고 작성되어야 한다. 시스템 관리자는 웹 서버상의 모든 스크립트에 대해서 보안성을 검토한 후에 시스템에 올려야 한다.

[참고 자료]

o 안전한 웹 어플리케이션 개발 가이드라인 :

- http://www.securitymap.net/sdm/docs/secure-programming/Secure-Web-Development.pdf

o Secure Coding

- http://www.securitymap.net/sdm/docs/secure-programming/

SecureCoding-State-of-the-Practice.pdf

o 안전한 프로그래밍 가이드라인

- http://www.certcc.or.kr/paper/tr2001/tr2001-02/secure%20program%20guideline.html

2.4 웹 트랜잭션 보안

웹서버를 통하여 일반 사용자와 금융정보, 또는 특정 회원정보, 그리고 ID, 패스워드와 같은 정보를 통신할 경우에는 그 정보가 인터넷에 노출되는 위협이 발생한다. 따라서 웹서버에서 중요한 정보를 다룰 경우에는 반드시 암호화를 지원하도록 해야 한다.

SSL은 일반적으로 서버의 인증서를 사용하여 암호화 통신을 하는데 사용된다. 즉, 웹 서버와 클라이언트의 데이터를 보호하는 전반적인 기능을 제공한다. 또한 인증서를 사용하면 사용자를 확인할 수 있는 인증 문제를 해결할 수 있다.

[참고 자료]

o Building a Secure RedHat Apache Server HOWTO(한글)

- http://kldp.org/HOWTO/html/SSL-RedHat-HOWTO/ssl-redhat-howto-1.html

2.5 보안 교육

대부분의 해킹사고는 시스템 관리자의 보안 교육 부재와 충분한 시간을 갖고 시스템을 보안하지 않는데서 비롯된다. 특히, 웹사이트 관리자는 웹서버 보안과 관련된 보안교육을 반드시 받을 수 있도록 하여야 하며, 적당한 인원자원을 보안에 할당하여 충분한 시간을 가지고 사이트 보안을 할 수 있도록 하여야 한다.

3. Level III 지침 : 침입 탐지 및 대응 지침

아무리 보안 조치를 했다고 하더라도 새로운 공격방법이나 또는 부주의한 실수에 의해 웹서버가 해킹을 당할 수 있다는 사실을 염두에 두어야 한다. 본 단계의 보안 지침은 앞서 설명한 Level I, II의 예방조치에 추가하여 적용할 수 있는 내용을 다룬다. 앞서의 지침이 일차적인 보안사고 예방에 있다면, 본 지침은 서버의 안전한 운영을 위한 보안관리, 잠재적인 공격자의 탐지 및 대응에 대한 내용을 다룬다.

3.1 추가적인 접근 통제 시스템 설치

만약 웹서버가 침입을 당할 경우에 대비하여, 추가적인 접근 통제 시스템을 사용하여 보호하고자하는 자원의 침해를 예방할 수 있다. 이러한 시스템은 관리자 권한의 사용자라도, 시스템의 특정 자원에 접근하지 못하게 하는 기능을 제공한다. 그리고 이러한 기능을 제공하는 공개 소프트웨어 및 상용제품들이 다수 존재한다.

o lids(Linux Intrusion Detection System) : 리눅스 커널보안을 위한 패치로 관리자 권한으로도 특정 시스템 자원을 사용하지 못하게 하는 기능을 제공한다. root를 포함한 누구도 보안 설정된 파일 또는 디렉토리에 대하여 변경, 삭제할 수 없으며, 추가(append) 기능만을 설정할 수도 있다. 이러한 보안 기능을 원격으로 On/Off 할 수도 있다. 중요한 프로세스/네트워크 연결을 보이지 않게 감출 수도 있으며(공격자를 감시하는 프로세스를 감추는 데 유용하게 사용할 수 있음), raw device와 I/O에 접근을 제한 할 수 있다. HTTP post, mail, syslog 데몬을 이용하여 보안위반을 경고해주는 기능이 있다.

※ Homepage : http://www.lids.org

[참고 자료]

o Lids Internal (한글문서)

- http://home.postech.ac.kr/~kelee/homedata/IDS/

3.2 침입 탐지

침입탐지시스템(Intrusion Detection System)을 사용하여 잠재적인 공격에 대비하는 것이 바람직하다. 침입은 다음과 같은 방법을 이용하여 탐지 할 수 있다.

o 네트워크 기반의 침입탐지시스템

네트워크 침입탐지시스템은 네트워크를 모니터링하여 알려진 공격패턴을 탐지하는 시스템으로 현재까지 알려진 공격방법들을 대부분 탐지하여 관리자에게 보고해 준다. 따라서 관리자는 서버의 침입여부를 즉각적으로 알 수 있게 되며, 사안에 따라 적절한 조치를 시기 적절하게 할 수 있게된다. 또한 많은 네트워크 기반의 침입탐지시스템에는 공격자 차단 등의 침입 대응기능을 포함하고 있다.

o 호스트 기반의 침입탐지시스템

호스트 기반의 침입탐지시스템은 해당 웹서버에 설치되어 시스템의 침입여부를 판단하기 때문에 보다 더 정확히 서버의 이상 유무를 확인할 수 있다. 대표적인 방법으로는 주요 시스템 파일이나, 설정파일의 변조 여부를 확인하는 방법이 있으며, 또는 사용자의 활동을 모니터링하여 침입을 탐지하는 보다 정교한 상용 제품이 존재한다. 주의할 것은 호스트 기반의 침입탐지시스템이 네트워크 기반의 침입탐지 시스템을 대체하지 못한다는 것을 이해하여야 하며, 따라서 병행 사용하는 것이 바람직하다.

o 로그 파일 점검

시스템의 로그파일을 주기적으로 점검하여 공격을 탐지할 수 있다. 특히, 웹서버와 관련된 로그를 주기적으로 분석하여 공격을 탐지하고 이에 대응하여야 한다.

[참고 자료]

o Snort 설치 및 운영가이드

- http://www.certcc.or.kr/tools/Snort.html

o tripwire 설치 및 운영가이드

- http://www.certcc.or.kr/tools/tripwire.html

o 유닉스 로그분석을 통한 침입자 추적 및 로그관리

- http://www.certcc.or.kr/paper/tr2001/tr2001-05/unix_log_analysis.pdf

- http://www.certcc.or.kr/paper/tr2001/tr2001-07/Unix_log_analysis_II.pdf

3.3 사고 대응

네트워크/시스템 침입시도 또는 해킹사고를 발견하는 경우, 이에 대응하는 방법에는 다양한 방법이 동원될 수 있다. 공격 호스트에 대해서 Firewall/라우터/시스템 등에서 차단하는 방법이 있을 수 있으며, 공격 호스트를 역으로 공격하는 방법 등이 있을 수 있다. 대부분의 공격 사이트가 또 다른 해킹의 피해자라는 점에서 이러한 방법은 일시적인 대응방법밖에는 될 수 없으며, 공격 사이트 및 피해사이트 모두에게 큰 도움이 되지 않는다. 하지만 패스워드 크래킹 공격이라든가 또는 지속적인 공격을 탐지할 경우에는 라우터에서 이러한 공격 사이트를 차단하여 자신의 네트워크를 보호하여야 한다.

가장 일반적으로 인식되고 있는 대응방법은 공격사이트와 접촉하여 대응하는 방법으로, 이는 보안 사고에 관한 정보를 교환할 수 있으며, 침입 활동을 더 잘 이해하고, 잠재적인 취약성을 알아낼 수 있으며, 궁극적으로 공격 사이트 및 피해 사이트 모두의 보안을 향상시킬 수 있는 계기를 제공한다. 또한 미리 알려지지 않은 보안 사고를 예측하고, 적절하게 대응할 수 있도록 해준다. 그리고 궁극적으로는 전체 인터넷 사회의 컴퓨터 보안을 향상시켜 줄 수 있다. 다음은 RFC 1281, "Guidelines for the Secure Operation of the Internet" 에 명시된 내용이다. 보안은 혼자서 할 수 없는 것임을 알아야 한다.

인터넷은 협력적인 벤처이다. 보안문제에 있어서 다른 사이트/네트워크간에 서로 도와주는 것이 인터넷의 문화와 관행이다. 각 각의 사이트는 다른 사이트에서의 공격을 탐지했을 때 이를 해당 사이트에 알려주어야 한다. 그리고 모든 사이트는 공격자 추적, 법 집행기관의 조사 등 보안사고에 대응하기 위한 일에 대해서 서로 도와주어야 한다.

The Internet is a cooperative venture. The culture and practice in the Internet is to render assistance in security matters to other sites and networks. Each site is expected to notify other Sites if it detects a penetration in progress at the other sites, and all sites are expected to help one another respond to security violations. This assistance may include tracing Connections, tracking violatiors and assisting law enforcement efforts.

만약 해킹사고 또는 해킹시도에 대하여 적극적으로 대응을 하지 않으면, 공격자는 지속적으로 다양한 방법을 동원하여 공격을 하게되며, 결국 해킹을 당하게 된다. 국외에서 시도되는 공격에도 적극 대응하도록 하여야 한다.

[참고 자료]

o 침해사고대응방법 및 절차

- http://www.certcc.or.kr/paper/cert.html