인터넷 방화벽에 대한 흔한 질문들

[질주(상진)]

* 네트워크 방화벽이란 무엇인가?  

 방화벽이란 한 시스템 또는 시스템의 집합으로 두 개의 네트워크 사이에서 접근 권한 정책을 강제할 수 있는 것을 말한다. 이것을 실제로 구현할 수 있는 방법은 다양하다.

 그러나, 원칙적으로 방화벽은 한 쌍의 기법으로 생각할 수 있다

- 통신을 막기 위해 존재하는 것과 통신을 허용하기 위해 존재하는 것. 어떤 방화벽은 통신의 통제에 강조를 하는 반면, 어떤 방화벽은 통신의 허용에 강조점을 둔다. 아마도 방화벽에서 인지해야 할 가장 주요한 것은 방화벽이 접근 제어 정책을 구현하는 것이라는 데 있을 것이다. 어떤 접근을 허용하고 거부해야하는지에 대한 아무런 생각도 없다면, 누군가 아니면 어떤 회사가 필요한 대로 방화벽을 구성하도록 하게 하면 기관 전체에 대한 정책을 만들어 주게 된다.  

* 왜 방화벽이 필요한가?  

 다른 사람 벽에 낙서를 한다든지 우편함을 망가뜨린다든지, 아니면 길거리에 주차해서 할 일 없이 경적이나 울려대는 멍청이들이 있는 일반 사회와 마찬가지로 인터넷에도 전자적으로 비슷한 일을 하는 사람들이 있다. 어떤 이는 인터넷을 통해서 무엇가 해 보려고 하고, 어떤 이는 민감하거나 가치있는 데이터를 보호하려고 한다. 대개 방화벽의 목적은 할 일은 하면서 멍청이들은 몰아내는 데 있다.  

 전통적인 형태의 회사와 데이터 센터에는 따라야 할 컴퓨터 보안 정책과 관행이 있다. 회사의 정책에서 데이터가 보호되어야 한다고 명시하면, 방화벽은 회사 정책의 구현체가 되므로 매우 중요해 진다. 종종 인터넷에 연결하기 어려운 이유 중의 하나는 비용이 비싸기 때문이 아니라, 경영진에게 그렇게 하는 것이 안전하다는 것을 확신하게 하는 것이다. 방화벽은 실제 보안을 제공할 뿐만 아니라, 경영진에 대한 확신을 심을 수 있는 중요한 역할을 한다.  

 마지막으로 방화벽은 인터넷에 대한 대사의 역할을 한다. 많은 회사들은 방화벽에 회사 서비스나 제품에 대한 공공 정보, 다운로드할 파일, 버그 고친 것과 같은 정보를 싣는다. 이러한 서비스 구조는 인터넷의 주요한 일부가 되었다. 그리고 후원자들을 잘 반영해 주었다.  

*방화벽이 무엇을 막는가?  

 어떤 방화벽은 전자우편만 통과하도록 허용하여, Email 서비스에 대한 공격을 제외한 모든 공격으로 보호를 한다. 또 다른 방화벽은 문제가 있다고 알려진 서비스에 대해서만 제한을 하는 다소 완화된 보호만을 한다.  

 일반적으로 방화벽은 외부 세계로부터의 허용되지 않은 인터액티브한 로그인만을 막도록 구성되어 있다. 이것은 무엇보다도 네트워크에 파괴자들이 들어오지 못하도록 막는다. 좀 더 발전한 방화벽은 외부에서 내부로의 통신은 막지만 내부에서 외부로 나가는 통신은 자유롭게 허용한다. 방화벽의 전원이 꺼질 경우 네트워크를 이용한 모든 공격으로부터 보호해 준다.  

방화벽은 단일한 "choke point"를 제공하여 보안과 감사를 할 수 있게 한다.  

모뎀을 이용하여 누군가 컴퓨터 시스템을 공격하는 상황과는 달리, 방화벽은 효과적인 전화 감청기와 추적기의 역할을 한다. 방화벽은 중요한 로깅과 감사 기능을 제공한다. 대개 방화벽은 그것을 통해 얼마만큼의 어떤 정보가 지나갔는지 관리자에게 요약보고하고 침입시도가 얼마나 있었는지 등을 보고한다.  

* 방화벽은 무엇을 못 막는가?  

방화벽은 방화벽을 통과하지 않는 것에 대해서 보호할 수 없다. 인터넷에 연결한 회사들은 인터넷을 통해서 정보가 빠져나가는 것에 대해 매우 우려를 하고 있다. 그러나 불행하게도 자기 디스크는 정보를 유출하는 데 효과적으로 이용될 수 있다. 인터넷 연결에 대해서 (경영층 수준에서) 많은 기관들은 두려워하고 있지만, 모뎀을 통한 접근에 대한 방어의 일관된 정책이 없다. 목재 집에 살면서 6피트의  강철 문을 만드는 것은 우수운 일이다. 그러나, 인터넷 방화벽을 구매하면서도  다른 많은 네트워크로 통하는 뒷문들은 무시하는 회사가 많다. 방화벽이 제대로 작동하기 위해서, 일관된 전체적 보안 구조 속의 일부가 되어야 한다. 방화벽 정책은 실제적이어야 한다. 그리고 전체 네트워크의 보안 수준을 반영해야 한다. 예를 들어, 극비나 비밀 정보를 가지는 사이트에서는 방화벽이 필요하지 않다.  이런 것들은 애초에 인터넷에 연결되면 안 된다. 다시 말해 정말 중요한 데이터가 있는 시스템인 경우에는 회사 네트워크로부터 분리되어 있어야 한다.  

 방화벽이 또 막을 수 없는 것은 내부의 침해자나 바보들이다. 산업 스파이들이 정보를 방화벽을 통해서 꺼내가지만, 이들은 전화, 팩스, 또는 플로피 디스크를 통해서 유출한다. 플로피 디스크는 방화벽에 비해서 기관에서 정보가 유출되는 가장 흔한 방법이다. 방화벽은 또한 우둔함으로부터 보호할 수 없다. 정화를 통해 민감한 정보를 말하는 사용자의 사회 공학적 공격방법의 좋은 목표다. 공격자는 그리고 인터넷으로 들어오는 바이러스를 막을 수 있다. 방화벽에서 바이러스를 막으려 하지만 굉장히 많은 바이러스는 플로피 디스크로 옮긴다.  

* 방화벽을 팔거나/서비스를 하는 회사나 자문자가는 누구인가?  

FAQ에서 이러한 것을 다루는 것은 매우 민감하다고 생각된다. 그러나, 독립적인 메일링 리스트(아무런 보증이나 권고를 하지는 않는다)를 URL  

http://www.access.digex.net/~bdboyle/firewall.vendor.html 에 나와 있다.  

* 방화벽의 기본 설계 기준은 무엇인가?  

방화벽을 설계하거나, 명세하거나, 설치를 관리하거나 하는 임무를 맡게된 행복한 사람들이 알아야 할 많은 기본적인 설계 문제가 있다.  

첫 번째 : 가장 중요한 것은 시스템을 어떻게 운영해야 하는지에 대한 회사나 기관의 정책을 반영하는 것이다. 네트워크에 연결하는 중요한 임무를 제외한 모든 서비스를 완전히 부정하도록 방화벽을 설치해야 하는가? 또는 비위협적인 방법으로 큐(queue)와 같이 감시되는 형태로서 방화벽을 설치해야 하는가?  

이러한 입장 사이에 난처한 점들이 있다. 마지막 방화벽에 대한 입장은 기술적인 결정보다는 다소 정치적인 결과가 된다.  

두 번째 : 어느 수준의 감시, 중복, 통제를 원하는가? 첫 번째 단계에서 허용할만한 위험 수준을 정하고 나서, 어느 것을 감시하고 허용하고 부정할 지에 대한 점검표를 만들 수 있다. 다시 말해서, 전체적인 목표를 이해하고 나서, 요구사항 분서과 위험평가를 결합하고 항상 충돌이 나는 요구조건을 구현하려는 명세서에서 정리한다.  

세 번째 : 경비이다. 이 문제에 대해서는 여기서는 모호한 용어로 밖에 설명할 수밖에 없다. 그러나 구매하는 것이나 구현하는 쪽의 비용이 얼마나 될지 해결방안을 정량화하려는 시도는 중요한 것이다. 예를 들어 기존 방화벽 제품이 $100,000가 든다고 하고 저성능의 경우 무료라고 하자. Cssco나 유사한 라우터에서 다소 어려운 구성(configuration)을 하는 무료 방법은 직원의 시간과 몇 잔의 ? 커피만 들어간다. 기존 방화벽을 처음부터 구현하는 것은 몇 ManMonth가 들어간다. 이것은 $30,000의 임금과 맞먹는다. 시스템 관리 부담도 고려해야 한다.  

자체적으로 구현하는 것은 좋다. 그러나, 계속적이고 값비싼 유지보수가 필요하지 않도록 구현하는 것이 중요하다. 다시 말해서 지금 구매하는 가격뿐만 아니라 지원하는 비용도 계산해야 한다는 것이다.  

기술적인 측면에서, 두 가지 생각해야 할 결정사항이 있다. 여기서 이야기하는 것이 네트워크 서비스 제공자의 라우터와 내부 네트워크의 라우터 사이의 고정적 통신 라우팅 서비스에 따른다.  

통신 라우팅 서비스는 IP 수준에서 스크린 라우터와 같은 것을 통해서 구현 되든가 프록시 게이트웨이와 서비스를 통한 응용 프로그램 수준의 구현이 될 수 있다.  

해야될 결정은 단순한 기능의 기계를 외부 네트워크에 telnet, ftp, new 등과 같은 프록시 서비스를 수행하는 노출시키는 것과 필터로서의 스크린 라우터를 설치하여 내부 기계 한 두 개와만 통신을 허용하는 것 중 어느 것을 설치해야 하는 것이다.  

두 가지 방법에는 장점과 단점이 있다. 프록시 기계에서는 감사기능과 잠재적 보안성이 증가하는 반면에 관리비용의 증가와 제공할 수 있는 서비스의 정도가 떨어진다. (왜냐하면 프록시는 필요한 서비스에 대해 각각 개발되기 때문이다.) 또 오래된 사용의 편리성과 보안과의 관계도 다시금 골치거리 로서 생각해야 한다.  

* 방화벽의 기본 유형은 무엇인가?  

개념적으로 두 가지 유형의 방화벽이 있다.  

* 네트워크 수준  

* 응용프로그램 수준  

생각하는 것만큼 크게 다르지는 않다 그리고 최근 기술은 어느 쪽이 더 나은지 나쁜지에 대한 구분을 불분명하게 하고 있다. 항상 필요에 맞는 유형을 고르는 데 신중해야 한다.  

네트워크 수준의 방화벽은 대개 IP 패킷의 송신 주소, 수신 주소와 포트 번호를 기준으로 결정한다. 단순한 라우터는 전통적인 네트워크 수준의 방화벽이다.  

왜냐하면 이것은 패킷이 어떤 것을 의미하는지에 대한 복잡한 판단과 어디서 왔는지에 대한 정확한 판단을 할 수 없기 때문이다. 현대의 네트워크 수준의 방화벽은 더욱 복잡해졌다. 그리고 그것을 통과하는 커넥션의 상태에 대한 내부 정보를 유지한다. 데이터 스트림의 내용과 같은 것들이다. 많은 네트워크 수준 방화벽을 구분하는 중요한 요소 중의 하나는 트래픽을 바로 라우터를 통과하도록 하는 것으로 사용하기 위해서는 올바르게 할당된 IP 주소 블록을 가져야 한다.  

네트워크 수준 방화벽은 매우 빠르고 사용자에게 투명하다.  

예제로서의 네트워크 수준 방화벽 : 이 예에서, 네트워크 수준의 방화벽은 "screened host firewall"이라고 나타난다. screened host 방화벽에서 네트워크 수주의 라우터에 의해 한 호스트로의 접근이 통제된다. 이 호스트는 배스쳔 호스트라 고 한다. 배스쳔 호스트는 고도로 방어된 안전한 강력한 호스트로 공격을 견딘다.  

예제로서의 네트워크 수준 방화벽 : 이 예에서, 네트워크 수준의 방화벽은 "screened subnet firewall"이라고 나타난다. screened subnet 방화벽에서 전체 네트워크에 대한 접근은 네트워크 수준에서 수행하는 라우터에 의해서 통제된다.  

screened host와 비슷한 것으로 여러 대의 호스트에 대해서 패킷 필터링을 수행한다는 점에서 다르다.  

응용 프로그램 수준의 방화벽은 프록시 서버를 돌리는 호스트를 말하는 것으로 네트워크의 직접적 통신을 허가한다. 그리고 이를 지나는 통신에 대한 로깅과 감사를 자세하게 수행한다. 프록시 응용 프로그램은 방화벽에서 수행하는 소프트웨어 요소로서 접근통제와 로깅을 하기에 알맞은 위치이다. 응용 프로그램 수준의 방화벽은 네트워크 주소 번역기로서 사용할 수 있다. 왜냐하면 통신이 한 쪽에서 다른 쪽으로 가기 전에 통신을 시작한 쪽의 출발지를 효과적으로 다른 쪽으로 바꿔줄 수 있는 응용 프로그램이 있을 수 있기 때문이다. 응용 프로그램이 중간에 끼어 있다는 것은 어떤 경우에는 성능에 영향을 미칠 수 있다. 그리고 방화벽의 투명성을 저하시킬 수 있다. TIS 방화벽 툴킷과 같은 도구를 이용하여 구성된 초기 응용 프로그램 수준 방화벽은 사용자에게 특히 투명하지 못하고 사용자에 대한 훈련을 필요로 한다. 현대의 응용 프로그램 수준의 방화벽은 완전히 투명한 것이 많다. 응용 프로그램 수준의 방화벽은 네트워크 수준 방화벽보다 더 자세한 감사를 제공하고 좀 더 보수적 보안 모델을 구현한다.  

예제로서의 응용 프로그램 수준의 방화벽: 이 예에서, 응용 프로그램 수준 방화벽은  

"dual homed gateway"라고 불린다. dual homed gateway는 보안이 매우 강화된 호스트로 프록시 소프트웨어를 수행한다. 두 개의 네트워크 인터페이스를 가지며, 각 네트워크에 연결되어 있고 그 사이를 지나는 통신을 통제한다.  

방화벽의 미래는 네트워크 수준의 방화벽과 응용 프로그램 수준의 방화벽의 사이에 있다. 네트워크 수준의 방화벽이 통과하는 통신을 인식하는 정도가 높아질 것으로 보인다. 응용 프로그램 수준의 방화벽은 낮은 수준으로 되어 투명해 질 것이다.  

결과로서 고속 패킷 필터를 하는 시스템이 통과하는 데이터를 로깅하고 감사하게 될 것이다. 더욱 더 방화벽(네트워크와 응용 프로그램 수준의)은 인터넷을 지나는 메시지를 보호하기 위해서 암호화기법을 흡수할 것이다. 단말 대 단말의 암호화를 수행하는 방화벽은 인터넷을 "전용선"으로 사용하고 이 때 데이터나 패스워드가 유출될 걱정을 할 필요가 없게 될 것이다.  

* 프록시 서버는 무엇이고 어떻게 동작하나?  

프록시 서버(때로는 응용프로그램 게이트웨이나 전달기(forwarder)는 보호해야 할 네트워크와 인터넷 사이를 중계해 주는 응용 프로그램이다. 프록시는 네트워크 사이를 통과하는 통신을 제한하기 위해서 라우터 기반의 통신 통제 방식 대신에 사용된다. 사용자 인증을 위한 지원과 추가적인 로깅을 수행하기도 한다. 프록시가 응용 프로그램 수준의 프로토콜을 이해해야 하기 때문에 프로토콜에 따른 보안(예를 들어 FTP 프록시는 내부로 들어오는 FTP는 허가하고 외부로 유출되는 FTP는 불허할 수 있다.)을 할 수 있다.  

프록시 서버는 응용 프로그램에 따라 다르다. 프록시를 통해 새로운 프로토콜을 지원 하기 위해서는 그에 따른 프록시를 새로 개발해야 한다. 인기를 끌고 있는 프록시 서버로 TIS Internet Firewall Toolkit("FWTK")이 있다. 이것에는 Telent, rlogin, FTP, X-Window, http/Web과 NNTP/Usenet news에 대한 프록시가 있다. SOCKS는 공통 프록시 시스템으로 클라이언트 쪽 응용 프로그램에서 컴파일하여 방화벽을 통과하도록 되어 있다. 사용하기 쉽다는 장점이 있으나, 인증이나 프로토콜 에 따른 로깅을 지원하지 않는다. SOCKS에 대한 자세한 것은  

ftp://ftp.nec.com/pub/security/socks.cstc를 찾아보기 바란다.  

"FILES"라는 파일에서 디렉토리 내용에 대한 것을 먼저 점검하는 것이 좋을 것이다.  

* 저렴한 패킷 스크린 도구는 무엇인가?  

Texas AMU 보안 툴에는 스크린 라우터를 구현할 수 있는 소프트웨어가 있다.  

(ftp://net.tamu.edu/pub/security/TAMU ).

Karlbridge는 PC기반의 스크린라우터 키트이다.  

(ftp://ftp.net.ohio-state.edu/pub/kbridge )

DEC의 "screend" 커널 스크린 소프트웨어가 BSD/386, NetBSD, BSDI용으로 이용 가능하다. 많은 상용 라우터가 다양한 형태의 스크린을 지원하고 있다.  

* Cisco 라우터에서 알맞은 패킷 필터링 규칙은 무엇인가?  

다음 예는 Cisco를 필터링 라우터로 사용할 때 가능한 한가지 구성 방법이다.  

특정 정책을 반영하는 한 예이다. 사람마다 정책은 다를 수 있다.  

이 클래스 B 네트워크 주소인 128.88.0.0을 가지고 서브넷(subnet)로 8비트를 이용한다. 인터넷 연결은 "red" 서브넷인 128.88.254.0이다. 다른 서브넷은 믿을만한 "blue" 서브넷이다.  

다음과 같은 점을 생각하고 있으면 구성방법을 이해하기 쉽다.  

1. 이 규칙에서 Cisco 라우터는 외부로 나가는 패킷에 대한 필터링만을 한다.  

2. 규칙은 순서대로 적용되고 적용될 수 있는 첫 번째 것이 나타나면 멈춘다.  

3. 모든 것을 고부하는 접근 목록 뒤에는 암시적인 거부 규칙(implicit deny rule)이 있다.  

아래 예는 구성(configuration) 중의 필터링 부분에 초점을 맞춘다. 읽기 쉽게 줄 번호를 붙이고 편집했다.  

* 명시적으로 허가되지 않는 것은 거부된다.  

* 외부 게이트웨이와 청색 네트 호스트 사이의 통신은 허가한다.  

* 청색 네트로부터의 통신은 허가한다.  

* 청색 네트로의 FTP 데이터 커넥션(data connection)용 포트를 허가한다.  

  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(경로지정) 패킷을 버리도록 한다.  

* : 이더넷 0이 적색 네트(위험한 네트)에 있다. 이 인터페이스로 나가는 통신은 확장 접근 목록 10번을 적용한다. 적색 네트로 부터의 출력은 청색 네트의 입력으로  생각할 수 있다.  

* : 이더넷 1이 청색 네트에 있다. 이 인터페이스로 나가는 통신은 확장 접근 목록 11번을 적용한다.  

* : 청색 네트로 나가는 게이트 웨이로부터의 통신은 모두 허가한다.  

* : 포트 1024와 5000 번 사이에 들어 있는 커넥션이 적색 네트로부터 들어올 경우 허가한다. 이는 ftp 데이터 커넥션이 청색 네트로 이루어질 수 있게 하기 위해서다.  

5000은 OpenView가 시작하는 곳으로 상한선으로 정했다. 주의: 다시 언급하는데, 이것이 주어진 정책에 따른 수용 가능한 규칙으로 보는 것이다. Cisco 라우터에서 소스 포트에 관한 필터링을 할 수 없다. 새로운 버전의 Cisco 펌웨어에서는 분명히 소스 포트 필터링을 제공하고 있다. 첫 번째 맞는 규칙을 찾을 때까지 규칙의 비교가 계속되므로 다소 간단한 규칙을 사용하겠다.  

* : 청색 네트의 모든 패킷이 게이트웨이로 가는 것을 허가한다.  

* : SMTP(tcp 포트 25번) 가 적색 네트로 가는 것을 거부한다.  

* : 적색 네트로의 모든 통신을 허가한다.  

Cisco.com은 Cisco 라우터를 이용한 방화벽 구축을 할 수 있는 자료들이 있다. FTP를 통해 ftp.cisco.com://pub/acl-examples.tar.Z에서 얻을 수 있다.  

새로운 Cisco 펌웨어(9.21에서 시작)는 내부로 들어오거나, 외부로 나가는 패킷에 대한 통제를 명시할 수 있다.  

* 방화벽에서 Web/HTTP를 작동하게 하려면?  

3 가지 방법이 있다. - 한가지를 선택하라  

* 스크린 라우터를 사용하고 있다면 라우터를 통해 연결이 되도록 허가한다.  

* SOCKS를 이용하는 웹 클라이언트를 이용하고 SOCKS를 방화벽에서 수행한다.  

* 방화벽에서 프록시가 가능한 웹 서버를 수행한다. TIS 방화벽 툴키트에는 http-gw 라고 불리는 프록시가 있으며, 이것은 Web, gopher/gopher+ FTP를 프록시한다.  CERN도 프록시 기능이 있다.  

자주 접근하는 웹 페이지에 대한 캐쉬기능도 있기 때문에 많은 사이트에서 사용하고 있다. 많은 웹 클라이언트는 프록시 서버 지원(Netscape, Mosaic, Spry, Chameleon 등)을 하고 있다.  

* 방화벽에서 DNS를 작동하게 하려면?  

어떤 기관은 DNS의 정보를 외부로부터 숨기려고 한다. 많은 전문가들은 DNS 이름을  숨기는 것이 별로 도움이 된다고 생각하지 않는다. 그러나 만일 사이트/기업 정책이 도메인 이름을 숨기도록 요구한다면, 이것은 그러한 정책을 수행하는 한 접근법이 된다. 그리고 인부 네트워크에서 표준이 아닌 주소를 사용하고 있기 때문에 도메인 이름을 숨겨야 할 이유가 있을 수 있다. 어떤 경우이든 이름을 숨겨야만 한다. DNS 이름을 숨겼기 때문에 침입자가 방화벽에 들어 왔을 때  공격을 지연할 것이라고 착각하지 마라. 네트워크 상에 있는 정보는 네트워크 레이어(network layer)자체만으로 쉽게 얻을 수 있다. 이것에 대한 데모를 원한다면 LAN의 서브넷에 ping으로 브로드 캐스트를 하고 나서 "arp -a"를 해보라. DNS에서 이름을 숨기더라도 메일 헤더나 뉴스를 통해서 호스트 이름이 빠져나가는 것을 알아야 한다.  

이러한 접근법은 다양한 것 중에서 하나이다 그리고 인터넷에서 호스트의 이름을 숨기고자 하는 기관에 유용하다. 이 접근법의 성공은 DNS 클라이언트가 같은 기계에 있는 DNS 서버에 묻지 않아도 된다는 것이다. 다른 말로 바꾸면, 호스트에 DNS 서버가 있다고 해도, 그 기능을 사용하지 않고 다른 DNS 서버에 클라이언트로서 요청을 해도 문제가 되지 않는다는 것이다.(이것은 때때로 장점이 되기도 한다.)  

먼저 DNS 서버를 배스쳔 호스트에 만든다. 이 서버는 외부에서 접근할 수 있다.  

기관의 도메인을 관장하는 서버가 되도록 한다. 서버가 알 수 있는 것이 외부에서 알아낼 수 있는 전부가 된다. 게이트웨이의 이름과 주소, MX 레코드와 같은 것. 공공 서버가 되는 것이다.  

그리고 나서, 내부 기계에 DNS 서버를 설치한다. 이 서버도 도메인에 대한 관장을 주장한다. 그렇지만 공공 서버와는 달리 이 서버에는 모든 자료가 있다. 이 서버는 정상적인 네임서버가 된다.  

여기서 정상적인 DNS 정보를 제공한다. 이 서버에는 전진 쿼리(forward query)를 설정하여 공공 서버에서 자신이 해결할 수 없는 쿼리를 해결하도록 한다.  

(UNIX에서 /etc/named.boot에 "forwarders"라는 줄을 이용한다.)  

마지막으로 DNS 클라이언트를 설치한다(UNIX 기계에서 etc/resolf.conf) 정상적인 서버 및 공공 서버도 포함한다. 이것이 열쇠다.  

내부 클라이언트는 내부호스트에 대해서 내부 서버에 요청하여 답을 얻는다. 내부 클라이언트가 외부 호스트에 대해서 내부 서버에 묻게 되면 이 내부 서버는 공공 서버에 요청한다. 공공 서버는 인터넷에서 답을 가져온다. 공공 서버에 있는 클라이언트도 동일한 과정을 거친다. 외부의 클라이언트는 내부 호스트에 대해서 묻게되면 공공 서버로부터 제한된 답만을 얻게 된다.  

이러한 접근법은 두 서버 사이에 패킷 필터링 방화벽이 있다는 것을 가정한다.  

방화벽에서는 DNS 요청을 두 서버 사이에서 할 수 있도록 허가한다. 그렇지만 다른 호스트들과의 DNS는 제한한다.  

이러한 방식에서 다른 방법은 PTR 레코드를 IN-ADDR. ARPA 도메인에 넣는 것이다.  

공공이 아닌 호스트에서 address-to-name을 에러가 아닌 unknown. YOUR. DOMAIN과

같은 형태로 돌려준다. 이와 같은 방법은 ftp.uu.net같은 FTP 사이트에서 ftp를 사용하는 기계에 대한 이름을 요구할 때 유용하다. 이러한 방법은 DNS 중복 검사를 하여 주소와 호스트 이름을 검사하는 곳에서는 사용할 수 없다.  

일반적으로 FTP를 방화벽을 통해서 수행하는 것은 ftp-gw와 같은 프록시 서버를 이용하던가 제한된 포트 영역으로 들어오는 연결을 허가하거나, 설정된 스크린 규칙에 따라 내부로 들어오는 연결을 제한하는 것이다. FTP 클라이언트는 제한된 영역의 포트 번호에서 데이터 포트를 형성하도록 고쳐야 한다. 이는 내부 호스트에서 FTP 클라이언트 프로그램을 고칠 수 있어야 한다는 것을 의미하는 것이다.  

어떤 경우에는 FTP 다운로드만 하기 원한 경우, FTP를 죽은 프로토콜로 만들고 서버에 요청한다. 공공 서버는 인터넷에서 답을 가져온다. 공공 서버에 있는 클라이언트도 동일한 과정을 거친다. 외부의 클라이언트는 내부 호스트에 대해서 묻게되면 공공 서버로부터 제한된 답만을 얻게 된다.  

이러한 접근법은 두 서버 사이에 패킷 필터링 방화벽이 있다는 것을 가정한다.  

방화벽에서는 DNS 요청을 두 서버 사이에서 할 수 있도록 허가한다. 그렇지만 다른 호스트들과의 DNS는 제한한다.  

* 방화벽을 통해 FTP를 사용하려면?  

일반적으로 FTP를 방화벽을 통해서 수행하는 것은 ftp-gw와 같은 프록시 서버를 이용하던가 제한된 포트 영역으로 들어오는 연결을 허가하거나, 설정된 스크린 규칙에 따라 내부로 들어오는 연결을 제한하는 것이다. FTP 클라이언트는 제한된 영역의 포트 번호에서 데이터 포트를 형성하도록 고쳐야 한다. 이는 내부 호스트에서 FTP 클라이언트 프로그램을 고칠 수 있어야 한다는 것을 의미하는 것이다.  

어떤 경우에는 FTP 다운로드만 하기 원한 경우, FTP를 죽은 프로토콜로 만들고 파일은 web을 이용하여 다운로드 받게 할 수 있다. 사용자 인터페이스는 확실히 더 낫다.

 그리고 (포트의 제한을 요구하는) 콜백call-back) 포트 문제를 해결할 수 있다. 웹을 통한 FTP 방법을 취할 경우 사용자는 FTP로 파일을 외부로 보낼 수 없게 된다. 이는 문제가 될 수 있다.  

다른 접근법으로 FTP "PASV" 옵션을 이용할 수 있다. 이것은 외부 FTp 서버가 클라이언트에서 연결을 시작하도록 허가한다는 것을 의미한다. PASV 접근법은 원거리 의 FTP 서버가 이러한 기능을 지원한다는 것을 말한다.(RFC 1579를 통해 더 자세한 정보를 보기 바란다.)  

SOCKS 라이브러리로 연결된 FTP 클라이언트를 구성하는 것이 더 좋은 사이트도 있다.  

* 방화벽을 통해 Telnet를 사용하려면?  

Telnet은 일반적으로 FWTK의 tn-gw와 같은 프록시를 이용하거나 정해진 스크린 규칙에 따라 연결을 하가 할 수 있게 라우터를 구성해서 사용할 수 있다. 프록시는 베스쳔 호스트에서 수행되는 독립된 형태의 것 일수도 있고 SOCKS 서버와 변형된 클라이언트의 형태일 수 있다.  

* 방화벽을 통해 finger와 whois를 사용하려면?  

많은 방화벽 관리자들은 믿을 수 있는 호스트로부터만 finger 포트로 연결을 허가한다. 이 때 finger 요청은 다음과 같은 형태이다. :: 이러한 접근법은 표준 UNIX finger에서만 가능하다. tcp_wrapper나 FWTK의 netacl을  

이용하여 특정 기계에 대한 접근 제한을 할 수 있다. 이러한 접근법이 모든 시스템에 대해 적용되는 것은 아니다. 왜냐하면 어떤 finger 서버는 user@host@host finger를 허용하지 않기 때문이다.  

많은 사이트는 외부로부터의 finger 요청을 여러 가지 이유로 해서 받아들이지 않는다. 가장 큰 이유는 과거의 finger 서버에서의 보안 문제 때문이고(인터넷 웜에서) 사용자의 finger 정보에 들어있는 민감한 정보가 유출될 수 있기 때문이다. 일반적으로 사용자가 민감한 정보를 .plan 파일에다 둘 경우, 방화벽에서 해결할 수 없는 심각한 보안 문제를 안게 되는 것이다.  

* 방화벽을 통해 gopher, archie,와 다른 서비스를 사용하려면?  

많은 방화벽 관라자들은 gopher와 archie 서비스를 직접적으로 허가하지 않고 web프록시를 통하도록 허가하고 있다. FWTK의 http-gw와 같은 프록시는 gopher/gopher+  

를 HTML로 바꿔주고 그 반대의 기능도 수행한다. archie와 다른 쿼리에 대해서 많은 사이트에서는 ArchiePlex 와 같은 인터넷기반의 Web-to-archie 서버를 이용한다.  

많은 새로운 서비스가 계속해서 나타나고 있다. 이들 중 상당수가 보안에 대해서 잘못 설계되어 있거나 전혀 보안을 고려하지 않고 설계되었다. 그리고 이들을 설계한 사람들은 이 서비스를 이용하고 싶으면 xxx 포트를 허가하면 된다고 즐겁게 이야기한다. 불행하게도 모든 사람이 그렇게 할 수 있지 못하다. 그래서 방화벽 뒤에 있는 사람들은 많은 새롭고 재미있는 장난감을 이용하는데 어려움을 느끼게 된다. RealAudio와 같은 것은 직접적인 UDP 접근을 해야 하는 좋은 예이다.  이러한 문제에 부딪힐 때 명심해야 할 것은 새로운 서비스를 허용하기 전에 어떤 보안상의 위험이 있는지를 최대한 찾아내는 것이다. 보안상의 문제가 전혀 없을 수도 있지만 그와 마찬가지로 트럭이 지나갈 수 있을 정도의 발견되지 않은 커다란 구멍이 있을 수도 있는 것이다.  

* 방화벽을 통해 X 윈도우를 사용하려는 데 문제는?  

X 윈도우는 매우 유용한 시스템이다. 그러나 불행하게도 콘 보안 문제가 몇 가지 있다. 원격 시스템에서 로그인을 하거나 위장을 할 수 있는 경우 X 디스플레이에서 사용자가 입력하는 키스트로크나 윈도우를 감시할 수 있다.  

이러한 문제를 극복하기 위한 시도가 있었으나 공격자가 사용자의 X 디스플레이를 방해하는 것은 너무 쉽다. 대부분의 방화벽은 모든 X 통신을 막는다. 어떤 것은 응용 프로그램 프록시를 통해서 허용하기도 한다. Firewall Toolkit에는 X에 대한 프록시가 있는데 x-gw라고 불리며 사용자가 telnet 프록시를 통해 수행하여 방화벽에 가상 X 서버를 생성하게 한다. 가상 X 서버에 연결요청이 오게 된다.  

사용자는 그것을 허용하지에 대한 팝업 윈도우를 보게된다. 별로 아름다운 것은 아니지만 X를 안전하게 지킨다.  

* 소스 라우트 통신은 무엇이고 그것이 위협이 되는 것은?  

정상적으로 패킷이 출발지에서 목적지까지 이용하는 라우트는 출발지와 목적지 사이의 라우터에서 결정한다. 패킷은 어디로 가고 싶은지(목적지 주소)만 알려준다. 그리고 어떻게 목적지에 도달할 지에 대해서는 알지 못한다.  

패킷을 보내는 송신자(출발지)쪽에 목적지까지 도착할 라우트를 패킷에 포함하도록 하는 옵션이 있다. 그래서 "source routing"이라는 이름이 생겨난 것이다.  

방화벽에서 소스 라우팅은 중요하다.  

왜냐하면 공격자가 방화벽의 내부의 시스템으로부터 왔다고 주장하는 패킷을 생성할 수 있기 때문이다. 일반적으로 그러한 통신은 방화벽으로 라우트가 되지 않을 것이다. 그러나, 소스 라우트 옵션을 이용하면, 공격자의 기계와 목적지에 있는 모든 라우트가 거꾸로 패킷을 공격자에게 (소스 라우트의 역방향으로) 돌려준다.  

이러한 공격을 구현하는 것은 아주 쉽다 따라서 방화벽 제작자들은 이런 일이 일어나지 않을 거라고 과소평가해서는 안 된다.  

실제로 소스 라우팅은 거의 사용되지 않았다. 사실 일반적으로 사용되는 경우가 네트워크 문제를 고치거나 특정한 경우 막힘 제어 (congestion control)을 하기 위해 통신을 특정 경로로 바꾸는 경우에만 사용된다. 방화벽을 구현할 때, 소스 라우팅은 어느 지점에서 막혀야 한다. 대부분의 상용 라우터는 소스 라우팅을 막을 수 있는 기능을 가지고 있다. 그리고 UNIX의 많은 버전들도 배스쳔 호스트를 만들 때, 소스 라우트된 통신을 막거나 무시하도록 이용될 수 있다.  

* ICMP 리디렉트(redirect)는 무엇이고 redirect 폭탄은 무엇인가?  

ICMP 리디렉트는 이것을 받는 쪽에서 라우팅 테이블의 내용을 대체하도록 한다. 이것은 라우터가 호스트에게 호스트가 최적이 아닌 라우트를 사용하고 있든지 목적지에 대해 잘못된 라우트 - 즉 잘못된 라우터를 통신을 보내고 있다는 -를 사용하고 있음을 알려주기 위해서 사용된다. 잘못된 라우터는 호스트에게 ICMP 리다이렉트 패킷을 보내서 호스트가 올바른 라우트가 무엇인지 알게 해 준다.  

ICMP 리디렉트 패킷을 강제로 보낼 수 있고 목표 호스트가 그것에 반응을 한다면 라우팅 테이블을 바꾸거나 호스트의 관리자가 의도하지 않은 곳으로 패킷을 보내어 보안을 침해할 수 있다. ICMP 리디렉트는 서비스거부 공격을 위해서 사용할 수 있다. 이 경우, 호스트가 잘못된 라우트를 받아서 연결이 끊어지게 하던가 ICMP 네트워크 도달 불능 패킷을 받게 하여 특정 네트워크에 접근할 수 없게 한다.  

많은 방화벽 제작자들은 ICMP 통신을 막는다. 이렇게 하면 외부자가 ping을 하거나 라우팅 테이블을 고치는 것을 막을 수 있다.  

* 서비스거부(denial of service)란 무엇인가?  

서비스거부란 누군가 네트워크를 혼란하게 하거나, 멈추게 하거나, 통신량을 넘치게 하거나 하여 쓸 수 없게 하는 것이다. 서비스거부의 문제는 막을 수 없다는 것에 있다. 이유는 네트워크의 방산된 특성에 있다. 모든 네트워크 노드는 다른 네트워크에 연결된 네트워크에 연결되어 있다. 방화벽 관리자나 ISP는 관리할 수 있는 영역에 있는 지역적인 몇 개만을 다룰 수 있다. 공격자는

* 방화벽 관련 용어 해설집  *

Abuse of Privilege: 기관의 정책이나 법에 따라 사용자가 하지 말아야 할 행위를 할 때.  

Application-Level Firewall: 완전한 TCP 연결 상태와 순서에 따르는 프로세스에  의해 서비스가 제공되는 방화벽 시스템. 응용 프로그램 수준의 방화벽은 통신을 실제 내부 호스트가 아니라 방화벽에서 나가는 것처럼 주소를 바꿀 수 있다.  

Authentication: 시스템에 접근하려는 사용자의 신분을 결정하는 처리 절차.  

Authentication Token: 사용자를 인증하기 위해서 사용되는 장치. 도전/ 응전, 시간 기반 코드순서와 그 밖의 다른 기법들에 의해서 인증 토큰이 수행된다. 여기에는 종이에  기반한 일회용 패스워드 목록도 있을 수 있다.  

Authorization: 어떤 형태의 행위를 허용할 지 결정하는 처리절차. 대개 인증의 문맥 속에 포함되어 있다. 사용자를 인증하면, 다양한 형태의 접근 행위가 허가된다.  

Bastion Host: 공격에 대항할 수 있도록 강화된 시스템으로 공격을 받을 수 있는 가능성이 있는 위치에 설치한다. 배스쳔 호스트는 방화벽의 일부가 되는 것이 일반적이고 그렇지 않다면 "외부" 웹 서버나 공공의 접근이 가능한 시스템이 된다.  

대개, 배스쳔 호스트는 다용도 운영체제(UNIX, VMS, WNT, 등)에서 수행하고 ROM에 기반한 펌웨어의 운영체제는 이용하지 않는 것이 보통이다.  

Challenge/Response: 인증 기법의 하나로 서버가 예측 불가능한 도전을 사용자에게 보내고 사용자는 인증 토큰을 이용하여 응전(응답)을 계산한다.  

Chroot: UNIX에서 격리된 파일 시스템의 부분집합에서만 수행하도록 프로세스를 제한하는 기법.  

Cryptographic Checksum: 단방향 함수를 이용하여 파일에서 나중에 참고할 수 있는 "지문"을 생성하는 것. 체크섬 시스템은 UNIX 에서 파일 시스템의 변조를 확인하는 주요한 방법이다.  

Data Driven Attack: 무해한 것으로 보이는 데이터에 공격코드를 넣어서 하는 공격의 형태로 사용자나 다른 소프트웨어에 의해서 공격을 수행하도록 한다.  

방화벽의 경우, 자료 기반 공격은 데이터의 형태로 방화벽을 통과하여 방화벽 뒤에서 공격을 하므로 주의를 요한다.  

Defense in Depth: 네트워크의 각 시스템이 최대한 안전하게 하는 보안 접근법.  

방화벽과 병용하여 사용할 수 있다.  

DNS spoofing: 공격대상 시스템의 이름 서비스 캐쉬를 변조하거나, 도메인 이름 서버를 공격하여, DNS 이름을 바꾸는 것.  

Dual Homed Gateway: 이중 인터페이스 게이트웨이는 두 개 이상의 인터페이스를 가지는 시스템으로 각 인터페이스는 다른 네트워크에 연결되어 있다. 방화벽 구성에서 이중 인터페이스 게이트웨이는 대개 통신의 일부 또는 전체를 통제한다.  

Encrypting Router: Tunneling Router 와 Virtual Network Perimeter를 보라  

Firewall: 둘 이상의 네트워크 사이에서 경계를 한정지으려는 시스템 또는 시스템의 결합체.  

Host-based Security: 공격으로부터 단일 시스템을 안전하게 하려는 기법. 호스트에 따른 보안은 운영체제와 버전에 따라 달라진다.  

Insider Attack: 보호되고 있는 네트워크의 내부에서의 공격

Intrusion Detection: 침입이나 침입시도에 대한 발견. 침입은 소프트웨어 전문가 시스템이나 손으로 로그나 네트워크 상에서 이용 가능한 정보를 통해서 발견한다.  

IP Spoofing: IP 네트워크 주소를 이용하여 부정하게 다른 시스템으로 가장하려는 시도  

IP Splicing / Hijacking: 능동적으로 설정된 세션이 공격자에 의해서 납치되고 동시에 조작되는 공격. IP 납치 공격은 인증이 끝난 뒤에 이루어지고 공격자는 인가된 사용자의 권한을 가진다. IP 납치에 대한 방어책으로는 네트워크나 세션 수준의 암호화에 의존하는 것이다.  

Least Privilege: 수행할 수 있는 시스템 권한의 최소만을 가지고 수행하게 하려는 설계. 이것은 다양한 행위를 하는 허가 정도를 낮추고 높은 권한을 가진 사용자나 프로세스가 허가되지 않은 행위를 하여 보안 문제를 일으킬 수 있는 가능성을 낮춘다.  

Logging: 방화벽이나 네트워크에서 발생한 사건에 대한 정보를 저장하는 과정 Log Retention: 로그가 유지되는 것  

Log Processing: 감사 로그(이력자료)가 처리되고 중요 사전을 찾고 요약이 되는 과정  

Network-Level Firewall: 네트워크 프로토콜 패킷 수준에서 통신을 검사하는 방화벽  

Perimeter-based Security: 네트워크의 진입 및 출로에 대한 접근통제를 안전하게 하는 기법. 

Policy: 기관-수준의 규칙으로 전산 자원과 보안 관행 그리고 수행 절차의 납득할만한 규칙들  

Proxy: 사용자의 편에서 수행하는 소프트웨어. 일상적인 프록시는 사용자로부터 연결을 받아들이고, 사용자 또는 클라이언트 IP의 주소가 프록시를 사용할 수 있는지 없는지에 대한 결정을 한다. 아마도 그 외에 추가적인 인증을 실시하고 사용자를 대신하여 원격지에 대한 연결을 완료한다.  

Screened Host: 스크린 라우터 뒤에 있는 호스트. 호스트에 접근할 수 있는 정도는 스크린 라우터의 스크린 규칙에 따라 달라진다.  

Screened Subnet: 스크린 라우터 뒤에 있는 서브네트. 서브네트에 접근할 수 있는 정도는 스크린 라우터의 스크린 규칙에 따라 달라진다.  

Screening Router: 관리자에 의해서 설정된 규칙의 집합에 따라 통신을 허가하거나  

Session Stealing: IP Splicing을 보라  

Trojan Horse: 소프트웨어 개체의 하나로서 정상적인 일은 하는 것처럼 보이지만 사실은 트랩도어나 공격 프로그램을 포함하고 있다.  

Tunneling Router: 신뢰할 수 없는 네트워크를 통해 통신을 암호화하고 포장하여 (encapsulating) 하여 라우팅할 수 잇는 시스템이나 라우터이다.  

Social Engineering: 공격 목표가 되는 사이트에 대한 사용자나 관리자에 대한 공격. 사회 공학적 공격은 대개 사용자나 교환원에게 전화를 해서 정당한 사용자인 것처럼 속여 시스템에 대한 불법적인 접근을 허가받으려는 것이다.  

Virtual Network Perimeter: 방화벽 뒤에서 보호되고 있는, 단일의 네트워크로 보이는 네트워크로서 실제로는 신뢰할 수 없는 네트워크에서 암호화된 가상 링크로 연결되어 있다.  

Virus: 자체 복사하는 코드의 일부. 바이러스에는 공격용 프로그램이나 트랩도어가  있을 수도 있고 없을 수도 있다.

내용출처 : [기타] 인터넷 : IT네트워크정보보안교육센터 www.unixbank.co

    -네이버-