인터넷 방화벽 시스템 - 질의응답

서문

이문서는 Fwalls-FAQ@iwi.com 의 Marcus J. Ranum 이 관리하는 FAQ를 번역한 것 이며, 주기적인 Update 및 국내용으로 추가한 버젼을 지속적으로 관리할 것이다.
원문: http://www.certcc.or.kr/paper/x1.txt

Original Contributor : Marcus J. Ranum, ranum@iwi.com
1st Korean Contributor: Chaeho Lim, chlim@certcc.or.kr

-----------------------------------------------------
목차

0.  About FAQ
1.  네트워크 방화벽시스템이란?
2.  왜 방화벽인가?
3.  방화벽시스템이 막을 수 있는 것은?
4.  방화벽시스템이 막지 못하는 것은?
5.  바이러스에 대해서는?
6.  방화벽시스템에 대한 좋은 참고자료는?
7.  네트워크에서 받을 수 있는 좋은 참고자료는?
8.  방화벽시스템 제품, Consultants 는?
9.  방화벽시스템 설치를 위한 네트워크 설계는?
10. 방화벽시스템 종류는?
11. 프락시서버는 무엇이며, 어떻게 동작하나?
12. 값싼 패킷스크린 도구는?
13. CISCO 에서의 적당한 필터링 규칙은 무엇인가?
14. WWW/HTTP 와 어떻게 동작하게 만드나?
15. DNS와 어떻게 동작하게 만드나?
16. FTP와는 어떻게 동작하게 만드나?
17. TELNET 과는 어떻게 동작하게 만드나?
18. Finger/Whois 와는 어떻게 동작하게 만드나?
19. Gopher/Archie, 기타 서비스와 어떻게 동작하게 만드나?
20. X-Window 와 동작하게 만들 경우의 관련 이슈는?
21. Source Route 는 무엇이며, 왜 위험한가?
22. ICMP Rediect 란 무엇이며 Redirect Bomb란?
23. 서비스거부(Denial of Service)란 무엇인가?
24. 용어 설명
25. 공헌자들
-----------------------------------------------------

0. About the FAQ

이 FAQ는 어떤 특정 제품이나 업체, 컨설턴트응 위한 것이 아니며, 이 FAQ에 대한 어떤 코멘트라도 환영한다. 이것에 대한 코멘트는 Fwalls-FAQ@iwi.com 으 보내면 이 FAQ는 http://www.iwi.com 에서도 볼 수 있다.


1.  네트워크 방화벽시스템이란?

방화벽이란 2개의 네트워크 사이에서 접근제어 정책을 구현할 수 있도록 하는 시스 템이나 시스템들의 집합이다. 궁극적으로 이 시스템이 수행하는 기능의 입장에서는 2개의 메카니즘으로 이루어지는데, 즉 네트워크에서의 트래픽을 막는 것과 허용하는 것이다. 방화벽에 따라 2가지중 어떤 하나가 더욱 강조될 수 있으나 아마 가장 중요한 것은 방화벽이 접근제어 정책을 구현다는 사실이다. 만약 어떤 접근제어에 의해 막거나 허용할 것인지 알 수 없을 때나 단순히 어떤 것을 허용한다는 생각을 가지거나 제품이 제공하는 혹은 그들이 생각하는 식으로 구현하려한다면 그들은 당신이 속한 기관 전체의 정책을 만드는 것이다. 


2.  왜 방화벽인가?

인터넷에서도 일반 사회에서 벌어지는 다른 사람의 벽에 낙서를 하거나 우체통을 훼손하거나차량을 훼손하는 등등의 일들과 유사한 행위들이 벌어지고 있는데, 여기에는 중요한 데이타나 자원들이 있을 수 있어 인터넷에 가입된 기관은 이를 막으려 하고 있다. 방화벽의 주된 목적은 이러한 불법행위에 대해 자신의 네트워크를 보호하고 내부에서는 일상적인 업무를 평시와 같이 할 수 있도록 하자는 것이다.

대부분 전통적인 기관이나 네트워크/데이타센터들은 자체적인 보안정책이나 실행강령등을 가지고 있는데, 정책이 데이타의 보호를 주목적으로 준비된 곳이라면 방화벽은 매우 중요하다. 인터네트에 접속하고자 할때 만약 규모가 큰 기관이라면, 비용이나 노력에 대한 정당성을 찾기 어려울 뿐 아니라 관리적인 것도 안전한지 정당화하기 어렵다. 방화벽은 보안 뿐 아니라 망관리에 대한 보증이 되기도 한다.

마지막으로 방화벽은 인터넷에 대한 기관의 대사관 역할을 하게 된다. 많은 기관들이 방화벽에 자신의 제품이나 서비스에 대한 공개 정보 서버로서 활용하여 파일을 제공한다. 이러한 시스템의 많은 경우에서 인터넷서비스의 중요한 역할(사례: UUnet.uu.net, whitehouse.gov, gatekeeper.dec.com 등)과 자신의 기관이 인터넷에서의 어떤 역할을 하는지 잘 반영할 수 있게 한다.

어떤 방화벽은 단지 전자우편 트래픽만을 허용하기도 하는데, Email 서비스 공격이 아닌 모든 네트워크공격에 대해 보호한다. 어떤 방화벽은 보다 느슨한 제한을 두어 단지 문제가 알려져있는 서비스만 막는다.

일반적으로 방화벽은 외부에서의 불법적인 대화형 접근을 막을 수 있도록 구성할 수 있으며 불법행위자들이 내부의 네트워크내 기계로 접근하는 것을 봉쇄한다. 그러면서 내부 사용자는 외부에 자유롭게 접근할 수 있도록 허용한다. 하지만 방화벽은 어디에서 출발한 트래픽일지라도 제어할 수 있다.

방화벽은 보안과 기록(Audit)가 필요한 곳이라면 단 하나의 점검할 수 있는 기능이 제공되어 매우 중요하다. 어떤 컴퓨터가 다이얼모뎀에 의한 공격을 받을 수있는 것과는 달리 방화벽은 효과적인 전화태핑과 역추적 도구 기능이 제공된다. 방화벽이 제공하는 로그를 이용하여 어떠한 트래픽일지라도 관리자에게 보고할 수있도록 만들고 얼마나 많은 침입시도가 있었는지를 알 수 있다.


4.  방화벽시스템이 막지 못하는 것은?

방화벽은 방화벽을 통과하지 않는 트래픽에 대해서는 막을 수 없다.
인터넷에 연결된 많은 기관들이 인터넷에 연결된 통로를 따라 누출될 수 있는 데이타의 보호를 위해서는 관심이 많다. 하지만 오히려 마그네틱 티으프에 의한 데이타의 유출에 대해서는 관심이 그다지 많지 않으며 또한 모뎀을 통해 인터넷 접근에 대한 보호가 필요하며 꾸준한 정책이 요구된다는 것을 잘 모르고 있다.
이것은 나무집에 살면서 두꺼운 철제 대문을 만드는 것과 마찬가지로, 많은 기관들이 값비싼 방화벽제품을 구매하면서 자신의 네트워크로 들어가는 수많은 뒷문에 대해서는 신경도 쓰지 않은 것과 같다. 방화벽이 잘 동작하기를 바란다면 기관 전체의 보안구조의 일부로서 동작하게금 일관성을 가지는 것이 좋다.
방화벽에 대한 정책은 현실적이어야 하며, 전체 네트워크의 보안 수준을 잘 반영하도록 해야한다. 예를 들어 최고등급이나 분류된 데이타를 가진 곳에서는 방화벽이 전혀 필요없다. 즉 이 기관은 인터넷에 연결해서는 안되며, 이러한 정보를 처리하는 시스템은 전체 네트워크로 부터 차단해야 하는 것이다.
또 하나 문제는 방화벽이 기관의 배반자나 스파이들에 대해서는 보호할 수 없다는 것이다. 산업스파이가 방화벽을 경유하여 정보를 빼낼 수 있지만 대부분 전화나 팩스, 프로피디스크 등을 선호하게 된다. 또한 방화벽은 어떤 바보같은 행위에 대해서도 막을 수 없다. 사용자가 중요한 정보를 무심코 흘릴수도 있으며, 침입자의 사회과학적수법에 속게 되면 방화벽을 개방 시킬 수도 있다.


5.  바이러스에 대해서는?

방화벽은 바이러스에 대해 효과적으로 막지는 못한다. 네트워크를 통해 전달될 수 있는 실행파일을 작성할 수 있는 방법들이 많이 있으며, 그러한 방법들을 제공하는 바이러스나 구조들이 많이 존재한다. 방화벽은 사용자들을 대신하여 모든 것을 막을 수 없으며, 네트워크의 전자우편이나 복사를 통해 전달된 바이러스에 대해 효과적으로 막을 수 없으며, 이러한 사례들은 여러가지 버젼의 Sendmail 에서, 혹은 Ghoscript, Postscript Viewer 등에서 발견되었다. 바이러스에 대해 대책을 세우려는 기관들은 기관 전체의 차원에서 바이러스 제어 수단을 세워야 하며, 방화벽에서 바이러스를 검출하겠다는 발상보다 중요한 시스템이 부팅될 때 마다 바이러스 스캐닝할 수 있도록 하는 편이 좋다. 바이러스 스캐닝 도구를 이용하여 네트워크를 보호하는 것은 플로피디스크, 모뎀, 인터넷 등에서 들어오는 바이러스를 막는 것이다. 방화벽에서 바이러스를 막는 방식은 단지 인터넷에서의 바이러스침투를 막는 것 밖에 없다. 대부분은 플로피디스크에 의해 전달된다는 사실을 알아야 한다.


6.  방화벽시스템에 대한 좋은 참고자료는?

방화벽에 대한 책자를 소개 한다.

서 명 : Firewalls and Internet Security: Repelling the Wily Hacker
저 자 : Bill Cheswick and Steve Bellovin
출판사: Addison Wesley Edition
년 도 : 1994
ISBN  : 0-201-63357-4

서 명 : Building Internet Firewalls
저 자 : D. Brent Chapman and Elizabeth Zwicky
출판사: O'Reilly Edition
년 도 : 1995
ISBN  : 1-56592-124-0

서 명 : Practical Unix Security
저 자 : Simson Garfinkel and Gene Spafford
출판사: O'Reilly Edition
년 도 : 1991
ISBN  : 0-937175-72-2 (discusses primarily host security)

서 명 : Internetworking with TCP/IP Vols I, II and III
저 자 : Douglas Comer and David Stevens
출판사: Prentice-Hall
년 도 : 1991
ISBN  : 0-13-468505-9 (I), 0-13-472242-6 (II), 0-13-474222-2 (III)

서 명 : Unix System Security - A Guide for Users and System Administrators
저 자 : David Curry
출판사: Addision Wesley
년 도 : 1992
ISBN  : 0-201-56327-4


7.  네트워크에서 받을 수 있는 좋은 참고자료는?

Ftp.greatcircle.com - Firewalls mailing list archives. Directory: pub/firewalls
Ftp.tis.com - Internet firewall toolkit and papers. Directory: pub/firewalls
Research.att.com - Papers on firewalls and breakins. Directory: dist/internet_security
Net.Tamu.edu - Texas AMU security tools. Directory: pub/security/TAMU
iwi.com - Internet attacks presentation, firewall standards

인터넷방화벽시스템 메일링리스트는 "방화벽 관라자 및 개발자들의 포럼"이며, 이의 가입은 전자우편의 내용에 "subscribe firewalls" 를 넣어 Majordomo@GreatCircle.Com 으로 보내면 된다. 메일링리스트의 아카이브는, ftp.greatcircle.com 으로 악명 FTP를 이용하여 pub/firewalls/archive 에서 찾아볼 수 있다.


8.  방화벽시스템 제품 업체, Consultants 는?

이러한 내용이 FAQ에 들어가야 할지는 민감한 내용이 되겠지만 업체와는 무관하게 다음 URL에서 관리되고 있으며, 이것은 어떤 보장을 하거나 권고는 아니다.

http://www.access.digex.net/~bdboyle/firewall.vendor.html


9.  방화벽시스템 설치를 위한 네트워크 설계는?

방화벽을 설계, 사양을 작성하거나, 구현 혹은 설치를 위한 사전 검토를 위한 사람들을 위해 이미 알려진 설계 이슈들이 많이 나와 있다.

처음이자 가장 중요한 이슈로서 당신의 조직이 어떻게 시스템을 운영할 것인지에 대한 정책을 반영하는 것으로서, 매우 중요한 네트워크에서의 작업을 제외하고는 모든 접속을 거부하는 식의 시스템을 운영할 것인가 아니면 덜 위협적인 방법으로 접속해 오는 모든 트래픽에 대해 조사하고 점검하는 방식으로 시스템을 운영할 것인가라는 선택을 할 수 있다. 이러한 선택은 결정권에 대한 당신의 태도에 달려있으며, 특히 엔지니어링 측면의 결정 보다 정책적인 결정에 따르게 된다.

두번째 이슈로는 어느 정도 수준의 모니터링, 백업 및 제어를 원하는가 라는 문제이다. 첫번째 이슈로서 기관이 받아들일 수 있는 위험 수준이 세워졌다면, 이제 어떤 것을 모니터하고, 허용하고, 거부할 것인가라는 체크리스트를 작성해야 한다. 즉, 기관의 전체적인 목적을 결정하고 위험평가에 근거한 필요성 분석을 하며, 구현하고자 계획하여 사양을 마련했던 목록과 구별될 수 있는 문제점들을 가려낸다.

세번째 이슈는 경제적인 문제이다. 우리가 여기에서 정확하게 지적할 수 있지는 못하지만 이것을 구매하는데 드는 비용과 구현에 드는 비용을 정확하게 정량적으로 산출하고자 하는 것이 중요하다.  예를 들어 완전한 방화벽제품의 구매에 드는 비용은 무료에서 100,000 달러에 이를 수 있으며, 무료에는 Cisco라우터의 비용과 구성 및 스태프의 인건비 등은 포함되지 않은 것이다. 제품 구매에 드는 비용에는 월 30,000달러 의 인건비 등이 포함된다. 그리고 시스템 관리에 드는 오버헤드 등이 포함된다. 방화벽 시스템의 우선 설치 및 구현에 드는 비용 뿐 아니라 지속적으로 드는 비용과 지원비 등이 계상되어야 한다.

기술적인 측면에서 몇가지 결정해야 할 것이 있는데, 기관 내부의 네트워크와 네트워크 서비스 제공자 사이에서의 고정적 트래픽 라우팅 서비스 등에 대해서도 결정하야 한다. 트래픽라우팅은 라우터에서의 IP 수준의 스크린 규칙이나 혹은 프락시게이트웨이 나 서비스에서의 응용 수준 등에서 구현되어야 한다.

telnet, ftp, news 등의 프락시를 설치되는 외부에 노출된 기계가 외부네트워크에 둘 것인가 혹은 하나 이상의 내부 기계와 통신을 허용하는 필터링으로서의 스크린라우터를 만들 것인가를 결정해야 한다. 각각의 접근 방식은 장단점이 있는데, 프락시기계가 고급 수준의 기록성과 잠재적인 보안 기능을 많이 구현해야 하는만큼 또한 비용이 많이 요구되기 때문이다. 프락시는 요구되는 서비스 마다 따로 따로 설계되어야 하며, 편리성과 보안에 드는 비용은 상대적이다.


10. 방화벽시스템 종류는?

개념적으로 2개의 타입이 있다.

  * 네트워크 레벨(Network Level),
  * 응용 레벨(Application Level)

이러한 2가지 타입에 대해 어떤 것이 좋고 어떤 것이 나쁘다는 식의 판단을 내리기는 어려운 점이 있지만 기관의 요구사항에 어떤 것이 부합되는지를 잘 판단하는 것이 좋다.

네트워크 레벨의 시스템은 IP 패킷의 Source/Destination 어드레스와 포트에 의해 결정하게 된다. 단순한 라우터는 낡은 방식의 네트워크 레벨 방화벽을 제공하는데, 이것은 어떤 패킷이 동작하는지 어떠한 네트워크에서 왔는지를 판단해야 하는 복잡한 규칙에 대해 판단하기 어렵고, 현재의 네트워크 레벨 방화벽은 매우 복잡해져서 허용된 접속들의 상태와 어떤 종류의 데이타 내용 등을 관리할 수 있다.
한가지 중요한 구별점은 네트워크 레벨 방화벽이 라우트를 직접 제어할 수 있으며,할당된 IP 블럭을 정당하게 사용할 수 있도록 해준다는 점이다. 네트워크 레벨 방화벽은 매우 빠르며, 사용자에게 투명한 서비스를 보장한다.

* 네트워크 레벨 방화벽의 사례 : "스크린호스트방화벽" 이라고 할 수 있으며, 하나의 호스트에서의 접근제어가 네트워크 레벨에서 동작하는 라우터에서 이루어지며, 이때의 하나의 호스트란 "Bastion Host"이다.
* 네트워크 레벨 방화벽의 사례 : "스크린서브네트방화벽" 이라는 것으로 구현될 수 있으며 이것은 네트워크 레벨에서 동작하는 라우터가 하나의 전체 네트워크에 대한 접근제어를 할 수 있음을 말한다. 스크린호스트의 네트워크란 점만 빼면 스크린 호스트와 유사한다.

응용 레벨 방화벽은 2개으 네트워크 간에 항상 직접적인 트래픽을 막고, 트래픽에 대해 로그, Audit 기능 등이 지원되는 프락시를 실행하는 기계를 말한다. 프락시 응용은 방화벽의 소프트웨어 부분이므로 많은 로그와 접근 제어 기능을 주는 것이 좋은 것이다. 응용레벨 방화벽은 어드레스 번역기로서 사용될 수 있다. 어떤 쪽에서 들어와 다른 쪽으로 나가기 때문에 처음 시도한 접속에 대해 효과적인 마스킹을 할 수 있는 것이다. 이렇게 중도에 응용을 가지는 것은 어떤 경우에는 성능에 문제를 가질 수 있으며, 투명성이 보장되지 않는다. TIS 툴킷 등에 구현된 것과 같은 초기응용레벨 방화벽은 일반사용자에게 투명하지도 않으며, 어떤 연숩이 필요하였다. 최근의 응용레벨 방화벽은 투명성이 보장되며, 보다 상세한 Audit 보고와 네트워크레벨 방화벽보다 보다 온전한 보안 모델을 제공하고 있다.

* 응용레벨 방화벽 사례 : "이중네트워크게이트웨이(Dual-Homed Gateway)"이 있을 수 있으며, 프락시를 실행하는 고도의 보안이 제공되는 시스템이다. 이것은 2개의 네트워크 인터페이스를 가지고 하나의 네트워크 인터페이스에 대해서는 모든 트래픽이 그냥 통과되는 것을 막는다.

미래의 방화벽시스템은 네트워크레벨 과 응용레벨 방화벽의 어떤 정도에 해당된다. 이것의 의미는 네트워크레벨에서는 보다 상위의 기능을 가지려 하고 응용레벨에서는 보다 하위 기능을 가지려 하기 때문이다. 최종 결과는 아마 매우 빠른 패킷 스크린 기능과 모든 트래픽에 대한 로그와 Audit 등이 예측되며, 특히 네트워크를 통해 전달되는 트래픽의 보호를 위해 암호 기법이 사용되리라고 보여진다. 종단간 암호 방식은 데이타나 패그워드 등이 도청되는 것을 막는 방식을 원하는 사설백본(Private Backbone)에서 여러 인터넷 접속점을 가진 기관에서 유용할 것이다.


11. 프락시서버는 무엇이며, 어떻게 동작하나?

흔히 응용게이트웨이 혹은 응용 전달자라고 하는 프락시 서버는 보호된 네트워크와 인터넷 사이의 트래픽을 중재하는 응용이라고 볼 수 있으며, 네트워크간에 직접 트래픽이 통과되는 것을 막는 라우터 기반의 트래픽제어을 대신하여 이용된다. 많은 프락시들은 그밖에도 추가적인 로그 기능과 사용자 인증 기법들이 지원되며, 사용되는 응용프로토콜을 이해해야 하므로 각각의 프로토콜에 특정적인 보안 기능을 구현할 수 있다. 예를 들어 FTP 프락시는 들어오는 FTP접속은 허용하고 나가는 FTP접속을 막을 수 있다.

프락시 서버는 응용에 특정적이다. 만약 프락시를 경유한 새로운 프로토콜을 지원하려면 그를 위한 프락시를 개발해야 하며, 일반적으로 사용되는 프락시 서버들은 Telnet, rlogin, FTP, X-Window, http/web, NNTP/Usenet 서비스 등을 가진 TIS 툴키트이다.  SOCKS는 일반적인 공통의 프락시이며, 클라이언트 응용쪽에서 함께 컴파일 되어 방화벽과 함께 사용할 수 있다. 이것의 장점은 사용하기 편리하다는 점이 있지만 사용자 인증의 부가 기능이나, 프로토콜에 특정적인 로그 기능이 제공되지 않는다는 것이다. SOCKS에 대해서는

ftp://ftp.nec.com/pub/security/socks.cstc

을 참고하기 바란다.


12. 값싼 패킷스크린 도구는?

TAMU(The Texas AMU) : 스크린 라우터 기능 구현 소프트웨어
ftp://net.tamu.edu, pub/security/TAMU

Karlbridge : PC-based screening router kit
ftp://ftp.net.ohio-state.edu/pub/kbridge
DEC "screend" kernel screening software for BSD/386, NetBSD, and BSDI


13. CISCO 에서의 적당한 필터링 규칙은 무엇인가?

다음 사례는 CISCO 라우터를 필터링 규칙에 의해 구성하는 것을 보이고 있으며, 이것은 특정 정책에 의한 것이며, 각 기관은 자신의 정책에 따라 구현해야 한다.

* 이 사례에서는 128.88 B Class 어드레스를 가지고 있으며, 8 비트를 서브네트로 활용하고 있다. 인터넷 접속 부분은 128.88.254 이며, 모든 다른 서브네트는 내부의 신뢰하는 네트워크이다. 다음 사항을 기억하면 구성을 잘 이해할 수 있다.

- CISCO 에서의 규칙은 외부로 나가는 패킷에 대해서만 적용한다.
- 규칙들은 순서대로 시험되며, 처믐 매치에 정지한다.
- access list 규칙의 마지막 부분에 묵시적인 접근거부로서 모든 것을 거부한다.

  이 사례는 구성의 필터링 부분만 보인 것이며, 라인번호는 작의적으로 붙인것이다.
  여기에 적용된 정책은,

- 선언된 접근 허가가 아니면 모든 거부한다.
- 외부의 게이트웨이와 내부망과의 트래픽은 허용한다.
- 내부망에서 출발한 서비스는 허용한다.
- 내부망으로 가는 FTP 데이타 접속 포트들은 허용한다.

  1. no ip source-route
  2. !
  3. interface Ethernet 0
  4. ip address 128.88.254.3 255.255.255.0
  5. ip access-group 10
  6. !
  7. interface Ethernet 1
  8. ip address 128.88.1.1 255.255.255.0
  9. ip access-group 11
 10. !
 11. access-list 10 permit ip 128.88.254.2 0.0.0.0 128.88.0.0 0.0.255.255
 12. access-list 10 deny tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 lt 1025
 13. access-list 10 deny tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 gt 4999
 14. access-list 10 permit tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255
 15. !
 16. access-list 11 permit ip 128.88.0.0 0.0.255.255 0.0.0.0 255.255.255.255
 17. access-list 11 deny tcp 128.88.0.0 0.0.255.255 0.0.0.0 255.255.255.255 eq 25
 18. access-list 11 permit tcp 128.88.0.0 0.0.255.255 0.0.0.0 255.255.255.255

* NO IP Source-route : 이것은 필터링 규칙은 아니지만 여기에 넣는 것이 좋는데, 라우터가 모든 source-route 패킷을 거부하도록 한다.
* IP Access-Grpup 10 : 이더넷 0 는 안전하지 않은 네트워크이며, 확장된 접근 리스트 10 은 이 인터네페이스에서 나가는 쪽으로 적용된다. 안전하지 않은 네트워크에서의 출력은 이 닌터페이스에서의 입력으로 간주된다.
* IP Access-Group 11 : 이더넷 1은 안전한 네트워크이며, 확장된 접근리스트 11은 이 인터페이스에서의 출력으로 적용된다.
* Permit 128.88.254.2 : 게이트웨이 기계로 부터 안전한 네트워크로 가는 트래픽을 허용한다.
* 접근리스트 10 Permit tcp : 안전하지 않은 네트워크로 부터 오는 모든 1024 에서 5000 번까지의 접속을 허용한다. 이것은 안전한 망으로 돌아오는 FTP 데이타 접속을 허용한다는 것이며, 5000 은 OpenView 시작인 것과 같이 상위 제한번호 이다. 우리는 이것을 주어진 정책에 의해 허용한 것이며, Cisco 에서는 소스포트에 대해 필터를 할 수 있는 방법이 없다. 이 규칙은 처음 매치때 까지 시험되므로 이것을 사용할 수 밖에 없다.
* 접근리스트 11 Permit ip : 모든 안전한 네트워크에서 게이트웨이로 가는 패킷을 허용한다.
* 접근리스트 11 Deny tcp : 안전하지 못한 네트워크로 가는 모든 SMTP(25) 메일을 거부한다.
* 접근리스트 11 Permit tcp : 안전하지 못한 네트워크로 가는 모든 TCP 트래픽을 허용한다.

Cisco.Com 에서는 방화벽을 구축하는 사례들을 가지고 있으며, 새로운 버젼의 Cisco펌웨어들은 관리자가 inbound/outbound 패킷들에 대한 필터링을 할 수 있도록해주고있다. 사례들의 모음은 다음에 있다.

ftp://ftp.cisco.com/pub/acl-examples.tar.Z


14. WWW/HTTP 와 어떻게 동작하게 만드나?

다음 3가지 방식 중에 하나를 선택하면 된다.

* 스크린라우터를 사용한다면, "established" 접속을 라우터에서 허용한다.
* SOCKS 를 지원하는 Web 클라이언트를 사용하고 방화벽에서 SOCKS를 구현한다.
* 방화벽에서 웹서버 프락시를 구현한다. TIS 툴키트는 http-gw라는 프락시를 지원하고 있으며, Web, Gopher/gopher+, FTP 프락시까지 지원된다. CERN httpd 도 프락시를 지원하며, 많은 기관들은 자주 접근되는 페이지에 대해 캐쉬 성능과 함께 도작하도록 사용한다. 많은 웹클라이언트들(Netscape, Mosaic, Spry, Chameleon 등)은 프락시 서버를 지원하며, 함께 구현되어 있다.


15. DNS와 어떻게 동작하게 만드나?

많은 기관들이 DNS 이름을 바깥에 드러나지 않게 하고 싶어 한다. 전문가들은 이것이 가치있다고 생각하지는 않지만 기관의 정책이 그렇다면 이러한 접근방법들이 알려져 있다. 또 하나의 이유는 기관 내부에서 표준 어드레스를 사용하지 않는 경우가 있을 수 있는데, 이경우에는 어쩔 수 없이 이 방법을 사용하지 않을 수 없다. 이것 때문에 느려진다든가 방화벽이 침입자에 의해 침해를 받지는 않는다.  기관의 네트워크에 관한 정보들은 네트워크 계층 자체에서는 너무나 쉽게 알려질 수 있는데, 이의 시험을 위해서는 LAN 에 ping 서브네트 방송 어드레스를 이용하여, "arp -a"을 해보면 알 수 있다. DNS에서의 이름을 감추는 것은 메일 헤더나 뉴스헤더 등에 호스트 이름을 드러내지 않도록 해주기도 한다.

이 접근방식은 각 기관이 자신의 호스트 이름을 외부에 드러내지 않도록 하는데 유용하며, 이 접근 방식의 성공여부는 DNS 클라이언트들이 같은 기계에 있는 서버와 대화하지 않도록 하는데 있다. 즉 이것은 만약 어떤 한 기계에 서버가 있다면 기계의 DNS 클라이언트 행위가 다른 기계에 있는 서버에게 재전달되는 잘못이 없기때문이다.

먼저, Bastion 호스트에 DNS 서버를 구축하여 외부에서 대화할 수 있도록 한는데, 기관의 도메인에 대해 공식적인 궈한을 가질 수 있도록 한다. 사실 모든 이 서버가알고 있는 것은 외부에서 알도록 공개하고 싶은 것들 뿐이다. 이것은 공개적인 서버로서 게이트웨이의 이름과 어드레스, 와일드 MX 레코드 등등이다.

그리고 나서 내부기계에 DNS 서버를 구축한다. 이 서버도 역시 공개서버와는 다르지만 공식적인 권한을 가질 수 있도록 하는데 진짜로 데이타를 가진 일반 서버인것이다. 그리고 이 서버를 공개서버를 resolve 할 수 없도록 /etc/named.boot 에 "forwarders" 라인을 이용하여 질의를 포워드하게금 세업한다.

마지막으로 /etc/resolv.conf 파일에서 공개서버를 가진 기계를 포함한 모든 클라이언트들이 내부서버를 사용하도록 조정하는데 이것이 주 포인트이다.

내부 클라이언트들은 내부호스트에 대해서는 내부서버에게 물어보고 응답을 받으며, 외부호스트에 대해서는 공개 서버에게 물어보도록 되어있는 내부서버에게 요청한다. 공개서버에 있는 클라이언트도 마찬가지로 동작하며, 하지만 외부의 클라이언트들은 내부의 정보에 대해 공개서버로 부터 제한된 정보만을 받게 된다.

이러한 접근방법은 이 2개의 서버간에 패킷 필터링 방화벽이 있다는 것을 가정하고 있으며 이것은 상호 DNS 대화를 허용하지만 다른 호스트 사이에는 DNS를 제한하는 것이다.

이러한 접근 방식의 또 다른 유용한 트릭은 기관의 IN-ADDR.ARPA 도메인에 와일드카드 PTR 레코드를 채택하는 방버이다. 이것은 어드레스-네임 어떠한 내부의 호스트에 대한 lookup도 에러가 아닌 "unknown.Your.Domain" 식으로 반환하게금 하며, 대화하려는 호스트에 대한 이름을 가지도록 해주는 ftp.uu.net 와 같은 익명FTP에 적당한 것이다. 이것은 호스트 이름이 그것의 어드레스와 마찬가지로 매치되는지 DNS ceross-check를 하는 싸이트와 대화할 경우에는 실패하게 된다.


16. FTP와는 어떻게 동작하게 만드나?

일반적으로 FTP를 방화벽과 동작하게 만드는 것은 TIS 툴킷의 ftp-gw 식의 프락시나 혹은 내부네트워크로 들어오는 접속에 제한된 영역을 주어 허용하든지, 아니면, "establicshed" 스크린 규칙과 같은 방법을 이용하여 내부로 들어오는 접속을 제한할 수 있다. FTP 클라이언트들이 그 정해진 영역으로 데이타 포트를 바인드할 수 있도록 고쳐지면 내부의 호스트에 있는 클라이언트들이 수정될 수 있게금 한다.

어떤 경우에는 만약 FTP 다운로드가 기관이 원하는 모든 것이라면 FTP를 죽이고, 대신에 Web 을 다운로드 기능에 사용될 수 있다. 만약 Web FTP를 사용한다면 사용자는 FTP 파일을 가져갈 수 없게 되고 문제가 생길 수 있다.

또다른 접근 방법으로서 원격지 서버가 클라이어트로 하여금 접속을 시도하도록 지정하는 FTP 의 "PASV" 옵션을 사용할 수 있다. 이것은 FTP 서버가 이러한 동작을 지원하도록 운영되어야 한다.(RFC 1579)

어떤 싸이트들은 SOCKS 라이브러리를 지원하는 FTP 프로그램 버젼을 선호한다.


17. TELNET 과는 어떻게 동작하게 만드나?

TELNET 는 TIS 툴킷의 tn-gw 처럼 응용프락시를 사용하는 것이 일반적이다. 혹은 "established" 스크린규칙을 이용하여 외부로 나가는 접속을 허용하도록 라우터를 구성할 수 있다. 응용프락시는 Bastion 호스트에서 단독 프락시로 실행되도록 할 수 있으며, 혹은 SOCKS서버와 수정된 클라이언트를 사용할 수 있다.


18. Finger/Whois 와는 어떻게 동작하게 만드나?

많은 방화벽시스템은 단지 신뢰하는 시스템에서만 finger 포트를 이용할 수 있도록 열어주는데, "finger user@host.domain@firewall" 형태를 지원하도록 한다. 이 접근방식은 표준 유닉스의 finger 버젼에서 동작하며, tcpwrappper나 TIS 툴킷의 netscl을 이용하면 서비스 접근을 제어할 수 있다. 어떤 finger 서버 버젼에서는 이러한 접근 방법을 지원하지 못할 수도 있다.

많은 기관들이 외부에서의 finger 접석을 허용하지 않는데, 이유는 finger 가 웜 프로그램등에서 취약점이 되었었다는 이유와 내부의 정보를 외부로 유출하고 싶지않은 이유들에 기인한다. 하지만 기관의 사용자들이 자신의 .plan 등에 주요한 정보나 민감한 정보를 넣어두고 있다면 방화벽이 풀 수 있는 것보다 더욱 심각한 보안 문제들을 야기할 수 있는 것이다.


19. Gopher/Archie, 기타 서비스와 어떻게 동작하게 만드나?

많는 방화벽관리자들은 gopher나 archie를 직접 동작하게 하는 것이 아니라 웹프락시를 통해 사용하도록 하고 있다. TIS 튤킷에서의 http-gw 프락시등에서는 gopher/gopher+ 질의를 html로 바꾸어주고 있으며, archie나 다른 서비스들을 위해서는 ArchiePlex와 같은 인터넷 기반의 웹-Archie 서버 등을 지원하도록 한다. 웹이 인터넷의 모든 것을 지원하고자 하는 경향이 있다.

많은 새로운 서비스들이 만덜어지고 있지만 어떤 것들은 보안 문제를 신경쓰지 않고 설계되기도 하고 어떤 것은 라우터에서 특정 포트를 경유하도록 설계해 줄 수 있지만 많은 새로운 응용들이 이렇게 지원하지 않으며 방화벽을 염두에 두고 설계하지 못하고 있다. 특히 UDP 접근을 직접 원하는 경우에는 문제가 있다. 만약 이러한 문제들을 직접 느낄 수 없다면 우선 이것들에 대해 허용하여 보라. 이것들이 보안을 전혀 내재하고 있지 않다는 것을 알게 될 것이며, 알수 없고 막을 수도 없는 보안 취약점들을 그대로 안고 있다는 것과 같다.


20. X-Window 와 동작하게 만들 경우의 관련 이슈는?

X 윈도우는 매우 유용한 시스템이지만 매우 보안에 위험한 요소들을 가지고 있는데, 원격지시스템은 워크스테이션의 X 디스플레이를 조작하여 사용자가 입력하는 키를 모니터하거나 윈도우 내용 전체를 복사할 수 있다.

가령 MIT 의 Magic Cookie 등을 이용하여 이러한 시도를 막을 수 있지만, 공격자의 사용자 X 디스플레이를 방해할 수 있는 요소는 여전히 남아있다. 대부분의 방화벽은 모든 X 트래픽을 막아버린다. 어떤 경우에는 DEC의 CRL X 프락시(ftp://crl.dec.com)와 같은 응용 프락시를 이용할 수 있다. TIS 툴킷은 x-gw라는 프락시를 이용하고 있는데, 사용자는 telnet 프락시를 이용하여 방화벽의 가상 X 서버를 생성하게 된다. 가상 X 서버에 X 접속 요청이 들어오면 접속 요청이 허용된 것이라면 이것에 대해 Pop-Up 으로 나타나게 된다.


21. Source Route 는 무엇이며, 왜 위험한가?

보통 패킷이 목적지까지 가기위한 경로는 그 경로상에 있는 라우터에 의해 결정되고 패킷 자체는 목적지 주소만 가지고 있을 뿐 경로에 대한 어떤 정보도 가지지 않는다.

하지만 옵션으로서 패킷을 보내는 쪽에서 목적지까지 가는 경로를 정의할 수 있다. 그래서 이름 그대로 'Source Routing"이다. 방화벽에서는 공격자가 내부망으로 곧장 들어가도록 요구할 수 있기때문에 문제가 된다. 일반적으로 그러한 트래픽이 방화벽자원에 라우팅되지 않도록하며, Source Routing 에 대해서는 목적지 시스템과 공격자의 호스트사이에 모든 라우터의 역경로를 반환하게 한다. 이러한 공격에 대한 구현은 매우 간단하며, 방화벽 구축자는 이러한 일들을 염두에 두어야 한다.

실질적으로 Source Routing 은 거의 사용되지는 않는다. 사실 이것의 적법한 사용은 네트워크 문제 디버그를 위한 것이며, 어떤 특수한 상황하에서 네트워크 혼잡성제어를 위한 특정 링크에 대해 사용하게 된다. 방화벽을 구축할 때 Source Routing은 어떤 점에서 막아야 하며, 대부분의 상용라우터는 이것을 막는 방법이 제공된다. 그리고 방화벽을 지원하는 유닉스 플래트홈 버젼에서도 이것을 금지하거나 무시하는 방법들이 제공된다.


22. ICMP Rediect 란 무엇이며 Redirect Bomb란?

ICMP Redirect는 라우팅테이블에 존재하는 문제를 수신자에게 반환한다. 이것은 특정한 목적지에 대한 라우트에 생긴 문제점과 적합하지 않은 라우팅을 사용하는 호스트에 얘기하는 라우터에 의해 사용된다. 잘못된 라우터는 호스트에게 ICMP Redirect 패킷을 되돌려주며, 정확한 라우팅을 알려주게 된다.  만약 ICMP Re-direct 패킷을 위장하고 상대편 시스템이 이것을 인지한다면 상대편 시스템의 라우팅테이블을 바꾸어 네트워크 관지자가 의도하지 않은 패스를 주어 보안문제를 일을킬 수 있다. 이것은 또한 서비스 거부(Denial of Service) 공격에 이용될 수 있는데, 주로 네트워크 접속을 잃어버리게금 하는 식이고, 특정한 네트워크로 가는 패스에 대해 더 이상 접근할 수 없다는 식으로 이용될 수 있다.

많은 방화벽 구축자들은 네트워크에 ICMP Redirect 패킷을 스크린할 수 있도록 하고 있으며, 외부자들이 호스트를 ping 할 수 있는 능력을 제한하든가 라우팅테이블을 고칠 수 없도록 한다.


23. 서비스거부(Denial of Service)란 무엇인가?

서비스거부란 어떤이가 네트워크나 방화벽이 정상동작 못하게 파괴하거나 정지시키거나 고장내거나 넘치게 만드는 것이다. 이것의 문제점은 인터넷에 대해 보호기능을 마비시킨다는 점이다. 이유는 네트워크의 분산된 성능과 능력에 있는데, 각각의 네트워크 노드들은 각 또다른 네트워크에 상호 연결되어 있는 것이다. 방화벽관리자나 ISP들은 미치는 단순한 근거리의 일부만 제어할 수 있다. 공격자는 언제나 상대가 제어하는 곳을 Upstream 시켜 접속을 파괴할 수 있다. 만약 어떤 네트워크의 동작을 방해하고 싶다면 언제든지 네트워크를 잘라버릴 수 있는 것이며, 이런 유사한 서비스거부 방법들은 매우 많다. 만약 어떤 기관이 접석 및 서비스 시간이 중요하고 어떤 매우 중요한 업무를 인터넷에서 하고 있다면 네트워크의 정지나 문제점에 대비한 복구 능력을 가지고 있어야 할 것이다.


24. 용어설명

권한남용(Abuse of Privilege): 어떤 사용자가 허용되지 않은 행위를 할 경우
응용레벨방화벽(Application-Level Firewall): 전반적인 TCP 접속 상태와 순서등을 관리하는 프로세스가 제공되는 방화벽시스템, 외부로 나가는 트래픽이 내부호스트가 아닌 방화벽에서 다시 re-addressing 되어 나타나게 된다.
인증(Authentication): 시스템에 접근하는 사용자의 신원을 확인, 결정하는 프로세스
인증토큰(Authentication Token): 사용자를 인증하는 이동형 장치로서, challenge/response 및 time-based code sequences 등의 기법을 이용하며, 이것은 종이에 적어둔 일회용 패스워드도 포함될 수 있다.
인증허가(Authorization): 어떤 행위가 허용될 수 있는지 결정하는 과정으로서, 보통 이것은 인증의 개념이다. 한번 인증이 되면 그 사용자는 어떤 형태의 접근과 행위를 인증 허가된 것이다.
베스쳔호스트(Bastion Host): 어떠한 공격에도 견딜 수 있도록 만든 시스템으로서 어떤 네트워크에서의 공격을 예측하고 만든다. 이것은 방화벽의 한 구성 요소로서 외부의 웹서버일 수 있는 공개 접근할 수 있는 시스템이다. 일반적으로 이것은 ROM 위주의 Firm 운영체제가 아닌 일반 목적의 운영체제를 가진 시스템이다.
질문/응답(Challenge/Response): 사용자에게 예측하기 어려운 값을 주면 사용자가 토큰을 이용하여 계산한 값을 반환하는 상요자 인증 기술의 하나
Chroot: 어떤 프로세스가 파일 시스템의 어떤 부분에서만 영원히 동작하도록 제한
암호체크썸(Cryptographic Checksum): 나중에 참조하기 위해 만든 유일한 지문으로 만드는 단방향 함수로서 UNIX의 파일시스템의 내용 변경을 막기위한 주요한 수단이 된다.
데이타주도공격(Data Driven Attack): 공격하기 위해 어떤 사용자나 다른 프로그램에 의해 실행되는 불법의 데이타에 의한 공격으로서 방화벽에서는 내부의 네트워크로 침투하기 위한 데이타가 방화벽을 공격할 수 있다.
깊은방어(Defense in Depth): 네트워크의 모든 시스템이 완전히 보호해야한다는 보안접근 방식의 하나로서 방화벽에 도입되어 사용될 수 있다.
DNS위장(DNS spoofing): 다른 시스템의 DNS 이름을 가장하여 상대시스템의 네임 서비스 캐쉬를 훼손하거나 정당한 도메인의 서버를 공격하는 것
이중네트워크게이트웨이(Dual Homed Gateway): 2개 이상의 네트워크 인터페이스를 가져 2개의 네트워크를 상호 연동하는 게이트웨이로서, 방화벽 구성시 네트워크를 패스하는 트래픽에 대해 막거나 필터링하는 역할을 한다.
암호라우터(Encrypting Router): 라우터 터널과 가상네트워크 경계를 보라
방화벽(Firewall): 2개 이상의 네트워크 경계를 해주는 시스템이나 어떤 집합
호스트기반의보안(Host-based Security): 각각의 호스트에 대한 공격에 대비하는 보안기술로서 운영체제나 관련 버젼에 따라 달라지게 된다.
내부공격(Insider Attack): 보호된 네트워크 내부에서의 공격
침입탐지(Intrusion Detection): 네트워크에서 알 수 있는 정보나 로그에 기반을 둔 전문가시스템 혹은 사람이 침입이나 침입시도를 탐지하는 것
IP 위장(IP Spoofing): 다른 시스템의 정당란 어드레스를 위장한 공격
IP 끊기, 납치(IP Splicing / Hijacking): 현재 접속되어 있는 세션을 뺏는 공격 으로서 이미 사용자가 인증된 세션을 가로챈다. 이것에 대한 주된 대응은 세션이나 네트워크 계층에서의 암화를 지원하는 것이다.
최소권한(Least Privilege): 시스템이 최소한의 권한으로 동작하도록 만드는 것으로 이것은 어떤 행위가 실행될 때 이의 인증허가가 최소화할 수 있으며, 사용자나 어떤 프로세스가 보안에 위배되는 행위를 할지도 모르는 비인가된 행위를 일으킬 여지를 줄인다.
기록(Logging): 방화벽이나 네트워크에서 일어나는 사건들의 기록
기록유지(Log Retention): 어떻게 오랫동안 기록을 유지하고 추적감사할 수 있는가
기록프로세스(Log Processing): 어떻게 기록이 처리되고, 주요 사건을 찾아 요약 할 수 있는가라는 감사추적성
네트워크레벨방화벽(Network-Level Firewall): 네트워크 프로토콜 레벨에서의 트래픽을 검사되는 방화벽
경계기반의 보안(Perimeter-based Security):네트워크의 모든 입구/출구에서의 접근을 제어하여 네트워크를 보호하는 기술
정책(Policy): 전산자원의 허용된 사용 수준, 보안기술, 운영절차 등에 대한 기관차원의 규칙
프락시(Proxy): 사용자를 대신하는 소프트웨어 에이젼트로서 대표적인 프락시는 어떤 사용자의 접속을 받아 이것이 허용된 호스트나 사용자인지 점검하고 어떤 추가적인 인증 기능을 할 수도 있는데, 원격지 목적지로 사용자의 대신한 접속을 만든다.
스크린호스트(Screened Host): 스크린라우터 다음의 호스트로서 스크린호스트에 접근될 수 있는 정도는 라우터에 정의된 스크린규칙에 따라 달라진다.
스크린서브네트(Screened Subnet): 스크린라우터 다음의 하나의 서브네트로서 서브네트에 접근될 수 있는 정도는 라우터의 스크린규칙에 따라 다르다.
스크린라우터(Screening Router):관리자가 설치시 정의한 일련의 규칙에 근거한 트래픽을 허용하거나 거부할 수 있는 라우터
세션훔치기(Session Stealing): IP Spoofing 을 보라
트로이목마(Trojan Horse): 트랩도어나 공격 기능을 가지고 동작하는 일반적인  프로그램 엔티티
터널라우터(Tunneling Router): 트래픽을 신뢰할수 없는 네트워크를 통해 보낼 때 암호화 후 인캡슐레이션하여 보내고 수신쪽에서는 다시 복호화를 하도록 기능이 지원되는 라우터
사회공학(Social Engineering): 상대편 시스템의 관리자나 사용자를 속이는 공격으로 대부분 전화 등을 통해 정당한 사용자처럼 위장하여 권한을 얻는 경우를 말한다.
가상네트워크경계(Virtual Network Perimeter): 신뢰할 수 없는 네트워크 사이에 암호화된 가상 링크로 연결된 방화벽들 너머 하나의 보호된 네트워크처럼 보이게 하는 네트워크
바이러스(Virus): 자기 복제 능력이 있는 코드세그먼트로서 바이러스는 공격 프로그램이나 트랩도어를 가질 수도 있고, 없을 수도 있다.


25. 공헌자들

  * Primary Author: mjr@iwi.com - Marcus Ranum, Information Warehouse!
  * Cisco Config: allen@msen.com - Allen Leibowitz
  * DNS Hints: brent@greatcircle.com - Brent Chapman, Great Circle Associates
  * Policy Brief: bdboyle@erenj.com - Brian Boyle, Exxon Research

Copyright(C) 1995 Marcus J. Ranum. All rights reserved. This document may be used, reprinted, and redistributed as is providing this copyright notice and all attributions remain intact.

----------------- END OF FIREWALL FAQ(HANGUL) --------------------------------