요약: 방화벽 속성 가이드

• 웹을 보고 몇몇 사용자들과 이메일을 교환하기 위해서만 인터넷에 연결하고자 한다면, 방화벽은 잊어버려라. 그냥 네트웍 연결 없는 PC 몇 대에서 서비스 공급자에게 간단한 전화 접속을 구성한다. BlackICE 같은 간단한 개인용 방화벽을 설치한다. PC를 사용하지 않을 때는 모뎀을 끈다.
• Solaris/SunOS: sp/Solaris_hardening.html 이나 sp/Solaris_hardening3.html 의 지시에 따라 시스템에서 불필요한 서비스를 제거한다.
• Linux/BSD/IPchains/IPfilter 를 사용하려면, [fire3]을 구입하여 읽는다.
• 프락시를 지능적 패킷 필터링 및 로깅과 함께 사용한다.
• 필터:
  • 살만한 여유가 있으면, SunScreen (또는 다른 투명 지능적 필터) 에다 좋은 프락시 (예를들어 Gauntlet 또는 FWTK) 를 사든가, 아니면 Firewall-1 을 하나 산다. 더 좋은 것은 둘 다 사서, 두 가지 다른 필터를 가지는 것이다 - 방어의 다양성. (다른 제품은 안 좋다는 뜻이 아니라, 저자가 이 제품들을 운영해 봤는데 잘 동작했다는 것이다).
  • 적어도 다음 패킷들은 차단한다 : 모든 69(tftp), 87(link), 111 및 2049(RPC & NFS), 512-514("r" commands), 5151 (lpd), 540 (uucpd), 2000 (OpenWindows) 및 6000 (X windows), snmp, exec, bootp, tftp, syslog 그리고 프락시 서비스에 필요한 것을 제외한 모든 UDP 포트 (e.g. DNS 및 NTP) 차단. 모든 소스 라우팅과 IP 전달(forwarding) 패킷 (즉 spoof 된 IP 패킷을 걸러낸다).
• 저렴한 솔루션으로는, 두 대의 라우터 + FWTK를 운영하는 배스천 호스트를 사용한다 (그러나 제대로 구성하려면 숙련된 인력에 대한 비용이 든다). 단순한 장치라도 정기적으로 로그를 감시해야 한다. 또 다른 방법으로 조그만 유닉스 서버에 (무료) ip_filter 를 올려 사용하면 라우터보다 지능적인 필터를 제공할 수 있다.
• 소스를 가지고 있는 것이 중요하다면, FWTK/Gauntlet 이 유일한 선택일 것이다.
• 방화벽을 통해서는 절대적으로 최소한의 서비스만을 허용한다 (e.g. WWW, Email, NNTP).
• 들어오는 유닉스 로그인 연결이 허용되어야 한다면, challenge response (e.g. Watchword) 나 유니크 토큰(e.g. SecurID.) 등과 같은 안전한 인증 서비스와 SSH를 함께 사용한다.
• 좋은 스캐너 도구를 사용하여 (e.g. ISS, Satan) 외부에서 정기적으로 내부 네트웍을 스캐닝 해서, 어떤 구멍들이 보이는지 확인 ( 및 수정!) 해 보는 것이 좋다. 또한 DMZ 호스트들 상에 있는 모든 파일들에 대해 정기적으로 무결성을 검사한다 ( e.g. tripwire 같은 도구를 이용하여).
• 방화벽 감시, 감사 및 변경 관리에 대해 조직의 프로세스를 수립한다.
• 항상 최신의 정보를 유지 : 방화벽 관리자는 FIRST 나 CERT 배포 리스트에 꼭 포함되어 있도록 하고, BUGTRAQ 과 방화벽 리스트에도 포함되게 한다.
• 재난에 대비하라! 조만간 공격을 당하게 될테니, 야기될 공황상태를 줄일 수 있도록 계획을 준비한다 (서면으로). 가능하다면 FIRST 선상에 독자적인 대응 팀을 구성하도록 한다.  

도입

방화벽은 광범위하고 복잡한 주제이며, 여기에서는 한정된 개요만 설명한다. 더 상세한 내용에 대해서는 [fire2] 와 [fire1] 을 참조한다. 모든 네트웍은 보안 도메인으로 분류되어야 하며, 이 도메인들은 서로 방화벽, 허브/라우터 또는 소프트웨어 (VPNs)에 의해 분리된다. 고전적인 방화벽들은 결국 가상 LAN에 의해 무색해 질지도 모르는데, 이 경우 방화벽들은 두 개의 VPN을 연결하는 시스템이 된다. 어떤 것이든 서로 다른 보안 정책을 가지는 두 도메인들 간의 접근을 통제하는 객체가 필요하다.

방화벽은 보안수준/도메인이 다른 어떤 두 네트웍 간에도 사용될 수 있지만, 이 절은 인터넷 방화벽에 많이 집중한다. 

방화벽이란?
정의:

두 네트웍 간을 흐르는 패킷들을 미리 정해놓은 규칙에 따라 차단하거나 보내주는 패킷 필터. 간단한 패킷 필터는 라우터이다. OSI 모델의 네트웍 계층에서 동작한다.
프락시 는 네트웍들 사이에서 특정 프로그램에 대한 접속을 허용/거부하는 작고 단순한 프로그램이다. OSI 모델의 응용 계층에서 동작한다.
방화벽 은 두 네트웍 사이의 트래픽을 제어하기 위해 특별히 구성된 시스템 (또는 시스템들의 네트웍) 이다. 방화벽은 패킷 필터에서부터, 다중 필터, 전용 프락시 서버, 로깅 컴퓨터, 스위치, 허브, 라우터 및 전용 서버에까지 이를 수 있다.
게이트웨이 즉 배스천 호스트는 어떤 어플리케이션에 대한 접근을 제공하는 안전한 컴퓨터 시스템이다. 나가는 트래픽을 깨끗하게 하고, 들어오는 트래픽을 제한하며 외부로부터 내부 구성을 숨길 수도 있다. 

왜 방화벽을 사용하는가?

• 내부 사내 네트웍에 대한 각 외부 연결은 이로 인해 내부 네트웍의 보안이 저하되지 않도록 보호되어야 한다. 네트웍 보안수준은 가장 약한 링크의 보안수준이라는 것을 기억하라.
• 모든 기업은 보안 정책을 가지고 있어야 하고 외부 네트웍에 대한 연결을 그 정책에 따라야만 한다. 보통 이것은 어떤 종류든 방화벽을 통해서만 가능하다.
• 방화벽은 기밀정보가 나가는 것과, 공격자가 들어오는 것을 차단하는 데 도움을 준다.
• 네트웍들간의 통신에 대한 자세한 통계를 제공할 수 있다 (누가 어떤 서비스를, 얼마나 자주 쓰는지와, 성능상의 병목지점을 보여주는 등)
• 통신에 대한 로깅과 감사 증적을 제공할 수 있어, 로그를 분석하면 공격자를 탐지하고 알람을 울리는 데 사용할 수 있다.
• 그러나, 강력한 방화벽이 곧 더이상 내부 호스트 보안이 필요없음을 의미하는 것은 아니다 - 그와는 반대로, 대부분의 성공적인 공격은 내부자로부터 온다!
• 널리 쓰이는 방화벽 솔루션을 가져다가 모든 외부 연결에 사용할 것을 권고한다.
• 방화벽에서 다루는 기술적 위협의 예로는 IP spoofing, ICMP 폭탄, 위장(masquerading) 및 취약하게 구성된 내부 시스템 접근 등이 있다.
• 방화벽으로 감소되는 위험의 예로는 호기심 많은 또는 악의적인 해커들로부터의 공격, 산업 스파이, 회사 데이타(즉 고객, 근로자 및 회사 데이타)의 우발적 노출 그리고 서비스 거부 공격 등이 있다.

방화벽은 어떻게 보호를 하나?
방화벽은 보통 다음 레벨에서의 보호를 위한 메카니즘을 가지고 있다:

• 네트웍 계층: IP 패킷이 깨끗해지고 (소스 라우팅 불능, 유효한 외부 주소를 가지는 패킷만 허용 등) 미리 정의된 규칙에 따라 라우팅된다. 어떤 방화벽들은 내부 IP 주소를 유효한 인터넷 IP 주소로 변환할 수 있게 해주고(NAT 즉 Network Address Translation, 네트웍 주소변환) 또 어떤 것들은 모든 내부 주소를 방화벽 주소로 대체한다 (내부 호스트로는 주소를 찾아갈 수 없음을 의미).
• 전송 계층: 송신자와 수신자 양쪽 모두의IP 주소에 따라 TCP 및 UDP 포트에 대한 접근을 허용/차단할 수 있다. 이것은 많은 TCP 서비스들에 대한 접근 통제를 제공하지만, 어떤 경우는 전혀 동작하지 않기도 한다. (e.g. X11, ftp, portmapper 서비스).
• 응용 계층:
  • 프락시 서버 (응용 게이트웨이라고도 불림)는 어떤 특정한 어플리케이션에 대한 요청을 받아들여, 최종 목적지까지 진행시키거나 요청을 차단 하거나 한다. 이상적으로는 프락시가 최종 사용자에게 투명해야 한다. 프락시는 접근통제와 이송(forwarding) 기능을 내장하고 있는 표준 어플리케이션들에서 불필요한 기능을 벗겨낸 신뢰할 수 있는 버전이다.
  • 일반적인 프락시들은 HTTP(WWW 용), telnet, ftp 등등을 포함하고 있다. 인터넷 이메일(smtp)를 비롯한 어떤 어플리케이션들은 relay나 forwarder로 사용되도록 설계되기도 한다.
  • DNS 어플리케이션은 IP 주소를 가지고 호스트이름을 찾도록 (또는 그 반대로) 해준다. DNS는 정보가 어디로부터 오는지 실제로 검사하지는 않으므로, 공격자가 DNS 서비스를 spoof 하여 잘못된 정보를 주도록 할 수 있다 (가령 공격자 시스템의 호스트 이름이 신뢰되는 호스트의 것인 양).
  • rlogin 과 NFS 같은 어플리케이션들은 접근 통제에 호스트이름을 사용하므로 DNS spoofing 에 취약하다.
  • 프락시 접근 통제 목록에는 DNS 이름 대신 IP 주소를 사용해야 한다 (DNS spoofing의 위험을 최소화 하기 위해). 그러나 라우터가 올바르게 구성되어 있지 않고 스위치를 사용하지 않는 경우 IP 주소도 spoof 될 수 있다.
• 암호화: 방화벽은 기밀성을 제공하고, 무결성을 인증 또는 개선하기 위해 암호화를 사용할 수도 있다. 기밀성을 위해 암호화를 사용하는 경우 (종종 VPN, Virtual Private networks, 가상사설망 이라고 불림), 두 가지 일반적인 경우가 있다:
  1. 암호화가 방화벽에서 수행된다, 즉 방화벽이 VPN의 종점이다. 방화벽은 VPN 안에서 사용된 프로토콜들을 이해하고 필터할 수 있으며, 지능적인 로깅을 제공할 수 있다.
  2. 암호화가 방화벽 안쪽의 호스트에서 수행된다 (End-to-End 암호화). 방화벽은 암호화된 스트림을 보기는 하지만 이해하지는 못한다. 이것은 여러분이 방화벽 관리자를 신뢰하지 않을 때는 유용하지만, VPN 안의 프로토콜들을 필터하고자 할 때는 별로 유용하지 않다. VPN은 공격자에게, 방화벽 관리자가 알아채지 못하는 진입 지점이 된다. 그러므로, 방화벽 안쪽의 VPN 종점은 매우 신중하게 구성/감시되어야 하고 강력한 인증과 같은 방화벽 메카니즘을 사용하도록 한다.
• 방어의 깊이 (Dept of defence): 방화벽은 또 여분의 보안 장벽을 가지고 있어서, 단일 지점 장애로 인해 네트웍이 함락되는 경우가 없어야 한다. 방화벽은 가능한 한 사용자(보안을 약화시킬 수 있는) 와 네트웍에게는 보이지 않아야 한다 (공격하기가 어렵도록).
• 신뢰성: 중복 라우팅, 클러스터, RAID, cold standby 등등이 모두 다양항 가용성 수준을 제공하기 위해 사용될 수 있다. 방화벽을 설계하기 전에 요구되는 서비스의 신뢰도를 먼저 명시해야 한다.

문제점: 많은 인터넷 어플리케이션들이 "프락시 인식" 을 못하고 (e.g. Microsoft NetMeeting), 각각의 연결마다 달라질 수 있는 복합적인 포트를 사용한다. 이러한 프로토콜들이 (안전하게) 방화벽을 건너가도록 허용하는 것은 매우 어렵다. 몇 가지 실용적인 해법이 있는 것 같다 :

• 프로토콜의 복잡성을 "이해하고" 필요한 경우 동적으로 포트를 열어주는 지능적인 패킷 필터를 사용한다. 단점: 지능적인 (비싼?) 필터가 필요하다.
• 인트라넷 클라이언트에서 TCP/IP 스택 대신, 인트라넷 바깥에 있는 호스트에 대한 호출을 특정한 "프락시 서버" 로 전환시켜, 프락시가 인터넷으로 연결하도록 해주는 "프락시" 인식 스택으로 바꾼다. 프락시 서버는 (지능적 필터에 의해 잘 보호되지 않는 한) 침투당할 수 있다고 가정하는 "희생양" 이 되지만, 내부 시스템에 특별한 접속이 없어 내부 시스템을 공격하는 데 사용되지 못한다. Microsoft Proxy 는 위의 원리를 사용하여 PC를 프락시 한다 (유닉스는 못함).
  단점: 모든 클라이언트에 SW가 설치되어야 한다.
• SOCKS 인식하는 어플리케이션을 구입 (e.g. Navigator, Applet viewer, etc.), 또는
  • 어플리케이션을 재컴파일하여 SOCKS 프락시 시스템을 사용하게 한다. 단점: 소스를 건드려야 한다. 또는,
  • 시스템 라이브러리를 SOCKSifies 버전으로 대체한다 (쉽지 않고 에러나기 쉽다).

참고 문서

어디서 부터 시작하나?

1. 목표를 정의한다: 어떤 서비스들을 원하는가? 비용은 얼마까지 괜찮은가? 서비스들에 대한 업무적 정당성을 부여한다.
2. 누구/무엇을 보호하려 하며, 누구/어떤 것 (위협)으로부터 보호하려고 하는가?
3. 알려진 취약점들 중 어떤 것들을 다루어야 하는가?
4. 위의 위협들은 어떤 위험 (발생 가능성 및 결과 또는 영향)을 초래하는가?
5. 수용할 수 없는 위협들에 대해 대응할 전략을 개발한다 : 정책, 조직, 프로세스 및 특정한 기술적 메카니즘들
6. 적절한 기술적 솔루션을 선정한다: 정해진 예산으로 수용 가능한 위험 수준에서 필요한 서비스에 접근하게 해주는 도구들로 어떤 것이 있는가? 안정적이고 잘 알려진 기술적 구조를 선택하고, 솔루션을 테스트한 후, 안전하게 설치한다.
7. 지원 조직과 역할, 프로세스를 규정한다. 방화벽을 관리하려면 잘 정비된 팀이 필요하다. 보안 침해를 신속히 처리하기 위한 프로세스가 반드시 존재하도록 한다. 공격에 대비한 계획을 세워라!
8. 방화벽에 대해 정기적인 모니터와 독립된 감사를 실시한다.
9. 인터넷 방화벽을 운영한다는 것은 끊임없는 작업이므로, 인터넷의 기술적 사회적 발전을 지켜보는 것이 현명하다.

정책

방화벽을 통해 어떤 서비스들이 어떤 방향으로 허용되는지를 명시하는 서면 문서가 있어야 한다. 디폴트는 열린 것인지 닫힌 것인지도 규정한다, 즉 어떤 서비스가 정책에 명시되어 있지 않다면, 이것이 허용된다는 것을 의미하는가 혹은 그렇지 않다는 것을 의미하는가? 이것은 관리자의 서명을 받아야 하며, 그러지 않으면 "모든 사람들이 다루어졌다고 생각했던" 구멍을 통해 보안이 침해될 경우 방화벽 관리자는 매우 곤란한 입장에 처할 것이다. 다음은 인터넷 방화벽을 위한 정책의 예시이다:

인터넷 방화벽 정책 (예)

보안 요구사항:

1. 접근 통제

• 사내 네트웍으로부터의 모든 인터넷 접속은 방화벽에 있는 프락시를 통해서 발생해야만 한다.
• 디폴트 구성: 명시되지 않은 모든 서비스들은 금지된다.
• 모든 사용자들은 인터넷 사용자들과 이메일을 교환할 수 있다.
• R&D 부서 사용자들은 WWW, ftp 및 real audio를 사용할 수 있다. 다른 사람들은 인가가 필요하다.

2. 보증

• 방화벽과 프락시 시스템들은 민감한 호스트로서 설치되어야 한다. 불필요한 모든 서비스들은 운영체제에서 중지한다. 사용자들은 이 시스템들에 직접 로그온 할 수 없어야 한다.
• 방화벽 정책과 구성은 정확하게 문서화 되어야 한다.
• 방화벽 시스템들에 대해 정기적인 모니터링과 연례 감사를 실시해야 한다.
• 사용잗르과 방화벽 관리자들은 각자의 책임을 인지하고 있어야 하고 이러한 책임들을 질 수 있도록 교육을 받아야 한다.

3. 로깅

• 상세 로그를 보존해야 한다 (가능하다면 별개의 서버에).
• 자동적으로 분석되어야 하고, 치명적인 에러는 알람을 발생시켜야 한다.
• 로그는 적어도 1년간 보관해야 한다.
• 의미 있는 로그 엔트리들은 매일 검사해야 한다.
• 방화벽 사용량에 대한 통계를 얻을 수 있어야 한다.

4. 가용성

• 방화벽은 높은 가용성을 제공해야 하고 그에 관해 필요한 일들을 수행해야 한다 (백업/복원 등)
• 변경 관리와 사고 대응을 위한 프로세스가 있어야 한다.

5. 필요한 기능:
나가는 (outgoing) 서비스:

다음 서비스들은 특정한 내부 호스트로부터 (e.g. 프락시를 통해) 인터넷으로 나가는 것이 필요하다:
1. Email, WWW (HTTP), ftp, telnet, SSH
2. DNS (resolve Internet names)
3. News (NNTP)
4. Real Audio

들어오는 (incoming) 서비스:

다음의 인터넷 서비스들은 특별히 보호되는 서브넷 상에 구성된 프락시 호스트들을 통해 안으로 들어오는 것이 허용되어야 한다:
1. Email: 모든 사용자들은 안전한 게이트웨이를 통해 인터넷 이메일을 받을 수 있어야 한다.
2. News (NNTP)
3. Secure Logins (소수의 규정된 사람들에 대해): SecurID + SSH 를 통해

다른 인터넷 서비스들을 필요로 하는 시스템들은 모두 특별한 외부 (안전하지 않은) 서브넷에 두어야 한다. 이들은 인터넷에 직접 연결되도록 한다. 이 호스트들로부터 내부 네트웍으로의 접근에 대해서는 인터넷 호스트의 접근에서와 같은 규칙이 적용된다.
인터넷에 제공되는 서비스들:

다음 서비스들은 인터넷에 제공되어야 한다 (보호되는 영역내의 안전한 서버들에 의해):

1. 방화벽/ 프락시 시스템의 DNS resolution.
2. WWW 서버.
3. Anonymous ftp 서버.
4. 특별한 프로젝트/ 다른 회사들과의 협력을 위한 사용자 FTP 서버 .  

방화벽의 유형 선택

1. 구입할 것인가 직접 만들 것인가? : 직접 만드는 것은 충분한 기술과 자원이 있을 때만 가능한 선택이다.
Do-it-yourself:

• 테스트와 확인이 더욱 중요하다. 그렇지 않은가?
• 시간과 전문적 기술을 필요로 한다. 사용자 인터페이스는 일반적으로 상용 방화벽이 더 낫다.
• 공개 제품을 사용하면 소스 코드를 만질 수 있다. (TIS 같이 어떤 벤더들은 소스도 팔지만).
• 공개 제품에 대한 지원 은 더 좋을 수도 나쁠 수도 있다 (어떤 제품이냐에 따라). 자주 사용되는 공개제품 (Linux, FWTK, etc.) 은 뉴스그룹에서 빈번하게 논의되고 사람들이 서로 서로 많이 도움릉 준다. 다른 공개 제품은 지원이 전혀 없다. 어떤 상용 제품들은 지원을 받기가 너무나도 어렵고 시시해서 지원을 받는 것이 비싸거나 (시간적으로) 복잡한 문제들은 해결을 못한다. (e.g. 몇 가지 제품이 연관됐을 때).
• 지식을 유지하기 위한 투자가 필요하다. 방화벽이 계속해서 (안전하게) 돌아갈 것인가?
• 서로 다른 부서/사업 단위에 따라 다른 종류의 방화벽들이 많이 필요한 큰 회사들에서 유용할 수 있다.
• 더 유연하다.

벤더:

• 어떤 테스트들을 수행하는지, 제품의 보안성과 견고성에 대해 어떻게 보장하는지 물어본다.
• 현재의 버그를 수정하기 위한 다음 업그레이드를 기다리는 것이 불만스러울 수 있다...
• 더 비쌀 수도 있지만, 더 쌀 수도 있다 (일반적으로 설치/구성이 더 쉬움)

2. 비용 : 위험을 고려한다, 보호되는 자산은 얼마나 가치가 있는가? 외부 연결은 위험을 감수할 만한 가치가 있는가? 예산을 세운다. 외부 연결에 드는 실제 비용을 산정한다 (하드웨어, 소프트웨어, 컨설턴트, 지원 인력, 통신비, etc.). 누가 비용을 지불할 것인지 고려한다: 회사, 부서 또는 개별 사용자들. 5명의 사용자가 인터넷으로 이메일을 보낼 수 있도록 하기 위해 $100'000 짜리 방화벽을 사지 않도록 하라! 500명의 사용자들에 대해 $5000 의 예산만을 책정하지 않도록 하라! 

3. 보증 : 테스트가 잘 된, 이상적으로는 신뢰되는 OS (가능하다면 ITSEC 평가를 받은) 를 사용한다. 불필요한 모든 서비스를 제거하고 모든 보안 패치를 설치한다.
=> 미리 만들어진 방화벽을 구매한다면, 반드시 안전하고 불필요한 것들을 제거한 버전의 운영체제를 사용하도록 확인한다. 필요하다면 벤더가 패치를 빨리 만들어 쓸 수 있게 하는지 확인한다.

• 보증은 방어의 깊이 (일련의 다양한 보호 장벽) 와 방어의 다양성 (중복적으로 보호하는 다양한 메소드/제품들) 을 통해 최대화될 수 있다. 
• 이상적으로는 모든 진정한 방화벽 벤더들은 인정받는 표준 (ITSEC 또는 TCSEC) 에 대해 자기들의 시스템을 인증 받아야 할 것이다.  TCSEC C2 레벨은 잊어버려라.. 거의 도움이 안된다.
• 이해도 잘 되고 인증받은 버전들 (B1,B2) 도 구할 수 있는 유닉스 변형을 권고한다.
• NSCA 는 "상업적 현실"에 토대를 둔 (TCSEC/ITSEC 만큼 비싸지 않다는 의미) 방화벽에 대한 인증 메카니즘을 가지고 있다. 자기 방화벽이 ?으을 받았는지 확인해 보도록 하라.
• 마찬가지로 SC magazine ( www.westcoast.com) 도 인증제도를 도입했다.
• 잘 알려진 군수 및 우주 산업체인 Harris 의 Cyberguard 가 ITSEC 인증을 받은 유일한 방화벽인데(May 1998), 저자는 이 제품은 사용해본 경험이 없다.
• NT 는 흥미롭지만, 많은 서비스들이 운영되어야 하기 때문에 복잡해지는 경향이 있다. 또 설치나 구성변경 시 재부팅해야 하고 자동화 하기가 어렵다.
  NT 는 유닉스 경험이 없는 작은 사이트에서 많이 쓰이는 경향이 있다.
  Cyberguard 는, 이제 NT에서도 사용할 수 있는데, NT 를 강화하는 모듈을 포함하고 있다. 이것은 흥미로운 일인데, 저자는 아직 테스트 해보지 못했다.

4. 위험:  방화벽은 어떤 문제들을 염두에 두어야 하는가?

기술적:

• 장애의 단일 지점.
• IP & DNS spoofing, 소스 라우팅.
• Sendmail, RPC 서비스(e.g. NFS, NIS), 오래된 inetd 서비스
• 명문(Clear text) 패스워드 (telnet, r* commands), 나쁜 패스워드, 디폴트 계정
• 외부 및 내부로부터의 비인가 접근
• Win95/NT 파일 공유
• WWW 서버 취약점
• Anonymous FTP 취약점
• UDP 기반 서비스
• 호스트간 신뢰
• 서비스 거부 공격 (UDP, 이메일 폭탄, SYN flooding, ping of death, ping flooding etc..)
• 가용성 보장을 위해 백업이 필요하다면,
• 백업 전략:
  • 내부 네트웍 상에는 백업 서버를 피한다. 백업 서비스들은 종종 클라이언트에 root 접근을 필요로 하는데, 이로 인해 방화벽에 잠재적인 취약점을 열어주게 된다.
  • 또는 더 좋은 방법은: 가능한 한 적은 백업을 필요로 하는 방화벽 솔루션을 선택한다 (e. g. 읽기전용 호스트, 전용 시스템에 로깅 - 이 시스템만 백업하면 됨).

비 기술적:

• 잘못된 구현/관리: 명확한 방화벽 정책, 올바른 구성, 잘 정의된 조직과 프로세스, 역할, 책임.
• 민감한 정보의 누출 : 명확한 정보 정책과 분류

5: 관리의 용이성

• 접근통제 규칙은 구현과 통제가 쉬워야 한다. 규칙들은 이해하기 쉬워야 한다, 가령 "port xxx는 IP 주소 yyy를 가지는 호스트로의 ACK=z인 들어오는 연결에 대해 Disable 되나, 주소 xxx로 나가는 port xxx는 enable" 보다는 "호스트 yyy로부터의 모든 telnet 접속을 Disable" . 친근한 GUI 도 많은 도움이 된다.
• 사용자, 호스트 또는 네트웍을 추가하는 데에는 최소한의 수고만 들어야 한다. 사용자와 호스트 그룹화가 가능해야 한다.
• 유지보수: 상용 방화벽을 산다면 소프트웨어 갱신과 fix를 얻을 뿐만 아니라 시스템 가용성을 보장하는 유지보수 계약을 고려하도록 한다. 유료 유지보수가 너무 비싸다면, 바쁜 방화벽들에 대해 최소한 디스크 미러링이나 cold 또는 warm standby 를 권고한다.
• 내부로부터 내용 서버들 (WWW, ftp)을 어떻게 하면 안전하게 갱신할 수 있을 것인가? 어떻게 하면 이 서버들은 최소한의 위험을 가지고 내부로 질의를 던질 수 있을 것인다? 하나의 해법은 SSH의 일부인 "scp" 프로그램을 사용하는 것이다.
• 시간에 따른 접근 통제: 어떤 방화벽들은 (e.g. Firewall-1 V3.0 이상) 특정 서비스를 언제 사용할 수 있는지 규정할 수 있게 해준다.이것은 아주 유용한 기능이다. 가령, 아마 들어오는, 인가된 로그인은 업무 시간에만 허용되어야 한다? 아주 유용할 것임에도 불구하고, 저자는 규칙에 만료일 을 설정할 수 있는 방화벽을 알지 못한다. 

6. 로깅

• 로깅을 동작시키고 (가능하다면 write-once 매체에) 매일 로그를 모니터한다. 로그를 너무 많이 하기는 쉽지만, 디스크 공간은 상대적으로 싸고 너무 적은 것 보다는 너무 자세한 것이 낫다.
• Syslog: 방화벽 안쪽에 있는 시스템에 로그하고, 이 시스템의 syslog는 외부에서 접근이 불가능 하도록 한다. 인터넷 서버들 (외부에 있는)은 이 경우 로컬에 로그해야 할 것이다.
• 자동 로그 분석과 알람 메카니즘을 설치한다 (e.g., 네트웍 관리 소프트웨어인 swatch 또는 맞춤 스크립트). 
• 각각의 ruleset 에 대해 다양한 수준의 로깅을 할 수 있어야 하고 사용자 정의 가능한 이벤트 통지 (이메일, 호출기, 알람등을 통한) 가 가능해야 한다. 버려지거나 거부된 패킷과 수용된 패킷 모두 로그할 수 있어야 한다.
• 중요하고 치명적인 이벤트들은 요약되어 빨리 검사할 수 있도록 해야 한다.
• 방화벽 사용량과 공격 시도에 대한 상세 통계는 상당히 바람직하다. 이러한 통계들은 누가 방화벽을 사용하고 있으며 얼마나 많은 잠재적 침입이 방화벽에 의해 차단되는 지를 보여준다. 이 두번째 항목은 IP, TCP 및 응용 레벨에서의 분석을 필요로 하기 때문에 어려울 수 있지만, 경영진에게 정당성을 입증하는 데 도움이 된다.물론 성공적인 공격 은 또 다른 일이다.
• 로깅과 알람 능력은 서로 다른 제품들 간에 상당히 다르다. 상세한 로깅, 요약 통계, 자동 로그 삭감 및 이송은 맞춤 가능한 알람 메카니즘과 함께 대부분의 사이트에서 필요로 한다. 가능하다면, 보고서는 HTML 같은 표준 양식으로 제공되어야 한다. (어떤 플랫폼에서도 읽기 쉬움).
• 정확한 알람 발생은 매우 중요하다. 주요 침해에 대해 몇 분 안에 아는 것도 중요하지만, 주요 보안 위험이 아닌 사사로운 작은 문제로 한밤중에 담당자를 깨우는 일도 없어야 할 것이다..
• 가능하다면 로그 브라우저는 GUI와 명령줄 형태 모두로 볼 수 있어야 한다.

7. 조직: 방화벽 보안은 움직이는 목표물이다. 방화벽 관리자가 최근의 보안 이슈들에 대해 최신의 정보를 유지하고 있도록 하기 위한 프로세스가 존재해야 한다.

8. 가용성: 방화벽에 대해 서비스 신뢰성 요구사항이 규정되어야 한다. 방화벽에 의해 보호되는 연결이 중대한 임무를 수행하고 있는가? 중단시간은 얼마나, 언제 가능한가? 어떤 형태의 시스템 백업 및/또는 여분(redundancy) 이 아마도 필요할 것이다.

Building blocks

패킷 필터링: 라우터들은 일차 패킷 필터로 구성될 수 있다. 그러나, 로깅 능력이 제한되어 있으며, 상태 기반 필터링을 제공하지 않는 경우가 잦고, 종종 고위 포트들 (e.g. 데이타베이스) 은 완전히 열어 놓으며 매우 복잡한 ruleset 을 가진다.
이러한 이유로, 지능적인, 상태 기반 필터나 패킷 필터 소프트웨어를 탑재한 전용 호스트를 사용하는 것이 바람직하다. 그렇지만 모든 방화벽들이 상태기반 필터링을 제공하지는 않는다는 것에 주의한다. 라우터가 필터링에 사용되는 경우, 구성하기 쉬운 rule-set을 가지고 있는 것을 고른다. 필요한 필터링의 전형적인 예는 다음과 같다 (더 상세한 내용은 아래 서비스 부분에서 찾을 수 있다).

• 프락시 서비스에 필요한 것을 빼고는 모든 UDP 포트를 차단한다. (e.g. DNS 및 NTP).
• 모든 소스 라우팅과 IP 전달 패킷을 차단한다 (spoofed IP 패킷을 걸러낸다).
• 들어오는 모든 패킷들에 대해 주소 spoofing 에 대한 검사를 한다 (즉 내부 호스트의 주소를 가지는 패킷이 외부 인터페이스에 있어서는 안됨)
• 적어도 다음 포트들은 차단한다: 69(tftp), 87(link), 111 와 2049(RPC & NFS), 512-514("r" commands), 5151 (lpd), 540 (uucpd), 2000 (OpenWindows) and 6000 (X windows).
• Cisco: Cisco firmware 9.21 이후 버전을 사용한다. Cisco 라우터 필터에 대한 예가 ftp.cisco.com:/pub/acl-examples.tar.Z 에 있었는데 없어진 것 같다. 웹이나 ftp.cisco.com 을 찾아보기 바란다.  
• 아래 견본제품 절에 견본제품 목록이 있다.

내용 필터링 많은 새로운 방화벽들은 정보 정책에 따라 정보의 흐름을 제한하기 위한 목적으로 지나가는 정보의 내용을 분석한다. 이메일, 뉴스 메시지, ftp 및 http 파일 업로드 및 다운로드가 분석이 가능하다. 인식이 가능하고 (정책에 따라) 거부될 수 있는 내용의 예로:

• 이메일
• 바이러스
• 자바 애플릿
• 트로이 목마
• ActiveX 프로그램
• 자바스크립트
• 특정 파일 이름
• 파일의 유형 (e.g. 실행파일)
• 제품들은 견본제품 절 에 나열되어 있다.

실제 내용 필터가 얼마나 유용한지에 대한 논의는 securityportal.com/direct.cgi?/closet/closet20000412.html 를 참조한다.

프락시: 응용 프락시(또는 응용 게이트웨이) 는 보통 응용계층에서 로깅과 접근통제를 제공하지만, 대신 성능 저하 (모든 트래픽이 프락시를 지나가야 함) 및 복잡성 (프락시는 특별한 호스트 상에서 운영되어야 함) 을 감수해야 한다. 클라이언트 프로그램을 수정해야 할 필요가 있을 수도 있다. 이상적으로는 보안을 최대화 하기 위해 프락시와 필터링을 함께 사용해야 한다. 아래 서비스 절도 참조한다.

• 네트웍의 내부와 외부 사이를 지나야 하는 모든 서비스에 대해 프락시를 사용한다.
• 강력한 인증 메카니즘이 있거나 이메일 및 뉴스용을 제외하고는 외부로부터의 프락시 접근이 금지되도록 모든 프락시를 구성한다.
• 접근 통제 목록에 서브넷/호스트 이름 보다는 IP 주소를 사용한다.
• 특별한 호스트에 대한 프락시가 존재하지 않는다면, 아마 FWTK 에 있는 plug-gw, SOCKS, 또는 Microsoft Proxy 라도 사용할 수 있을 것이다 . 
• 아래 견본제품 절에 견본제품 목록이 있다.

견본 구조

방화벽을 설치하는 방법은 여러가지가 있다. 여기 주된 방법들을 소개한다. 방화벽은 선택은 비용, 성능, 가용성 요구와 방화벽에 의해 보호되는 정보의 민감성에 달려있다. 고도로 안전하고, 고성능의 고가용성을 가지는 시스템들은 저렴하지가 않다. 높은 가용성이 중요하다면, 비용은 두배가 될 수 있다.

보안은 방어의 깊이 (일련의 다양한 보호 장벽) 와 방어의 다양성 (중복적으로 보호하는 다양한 메소드/제품들) 을 통해 최대화될 수 있다. 

기본 필터 구조 (screening router)

가장 저렴한 (그리고 가장 덜 안전한) 설치는 라우터 (각 인터페이스에서 들어오고 나가는 패킷을 필터할 수 있는) 를 사용하여 하나 (또는 그이상)의 내부 서버로의 접근을 가려내는 것이다. 인터넷에 연결하려면 라우터는 보통 어쨌든 필요하므로, 필터는 공짜인 셈이다. 이 서버가 모든 외부 연결을 위한 시작점이다. 외부에 접속하려는 내부 클라이언트 이 스크린 서버를 통해서 접속한다.

• 단점:
  • 라우터에 복잡한 (따라서 실수하기 쉬운) 필터링 규칙이 필요하다. 세밀한 접근통제는 거의 불가능하다.
  • 대부분의 라우터들이 로깅을 할 수 없기 때문에, 있을 수 있는 공격들에 대해 거의 알 수가 없다.
  • 스크린 라우터는 다른 내부 호스트들의 외부 접속을 허용하도록 쉽게 수정될 수 있다. 이것은 금방 감당하지 못할 정도로 되어 좋지 않다 (과다한 호스트, 과다한 복잡한 규칙, 확인이 어려움).
  • 어떤 (오래된) 라우터들은 소스 라우트된 패킷들을 제대로 가려내지 못한다.
  • 라우터들은 인증을 첨가할 수 없다.
  • 내부 구조를 숨기기 어렵다.
  • 하나의 장애물 밖에 없다.
• 장점:
  • 투명하고 간단하다.
  • 가장 싼 솔루션이고, 보안은 가장 낮다.
  • 라우터를 지능적 필터로 교체하여, 세밀한 접근통제, IP spoofing 으로부터의 보호, 그리고 로깅도 (그러한 로깅은 낮은 수준으로, 해석하기가 힘들긴 하지만) 제공할 수 있다.

분석: 이 구조는, 자금이 심각한 문제인 경우가 아니라면 (그렇다고 하더라도, 과연 위험을 감수할 만 한가?) 권장할 만 하지 않다. 개선방안으로, 라우터 필터 대체용으로 "지능적 필터" (아래 참조) 를 사용할 수 있다. 

듀얼 홈 방화벽 구조 (Dual Homed Firewall Architecture)

이 고전적인 방화벽 구조에서는, 두 개의 네트웍 인터페이스를 가지는 호스트를 설치 하는데, 인터페이스 중 하나는 내부에, 다른 하나는 외부에 각각 연결된다. 게이트웨이 상에서는 패킷 전달을 비활성화 시키고, 정보는 응용 계층에서 지나간다. 게이트웨이는 양쪽에서 모두 접근할 수 있지만, 트래픽이 직접 가로질러 갈 수는 없다. 통상적으로, 인터넷 연결을 위해 라우터도 한 대 필요하다.

• 라우터를 사용할 수 있다면, 이를 이용하여 패킷 클리닝과 필터링을 설정한다. 아니면 게이트웨이 자체에 패킷 필터가 통합될 수도 있다.
• 단점:
  • 듀얼 홈 호스트가 패킷을 전달할 수 없으므로, 게이트웨이를 지나다니는 모든 서비스들에 대해 프락시가 존재해야 한다 (게이트웨이가 패킷필터도 또한 가지고 있는 경우가 아니라면). 모든 서비스가 프락시 될 수 있는 것은 아니며 또 사용자 입력이나 구성도 필요하다.
  • 방화벽의 성능은 시스템 하나의 성능으로 제한된다.

분석:

• 간단한 구조로 확인하기도 쉬우나, 게이트웨이의 신중한 구성을 필요로 한다. 내부 네트웍을 숨길 수 있다.
• 저렴하지만, 방어의 깊이 (2 개의 장애물) 와 방어의 다양성은 약하다. 기본적인 나가는 서비스 (HTTP.telnet.ftp) 를 사용하는 작은 사이트에는 충분할 수도 있다.
• 이전의 예와 마찬가지로, 라우터 필터링 대신 지능적 필터를 사용하여 보안을 개선할 수 있다.
• 인터넷 서버들 (WWW, ftp) 은 보통 세번째 네트웍에 위치하게 된다.

스크린 호스트 구조 (Screened Host Architecture)

기본필터의 변형으로 두 개의 필터를 사용하며, 추가된 필터는 스크린 호스트와 클라이언트들 사이에 위치한다. "보호되는" 호스트는 배스쳔 호스트 (Bastion Host)라고 한다.

• 기본 필터 구조보다 필터링 규칙이 단순한데, 외부 라우터는 배스쳔 호스트와 외부 사이의 트래픽만을, 내부 라우터는 배스천 호스트와 내부 사이의 트래픽 만을 허용한다.
• 비용은 더 들지만 보안도 개선된다 (더 많은 장애물, 더 큰 방어의 깊이).
• 두 가지 다른 라우터가 사용되는 경우, 방어의 다양성이 개선되는 대신, 더 복잡해질 것을 감수해야 한다.
• 라우터는 로깅을 할 수 없으므로, 패킷 레벨에서 있을 수 있는 공격들에 대해 거의 알 수가 없다.
• 라우터들은 FTP 같은 이중 포트 프로토콜에 대한 "지능적 " 필터링을 할 수가 없다.
• 인터넷 서버들(WWW, ftp)은 보통 내부 네트웍에 대한 접속 없이 외부에 위치한다.
• 상대적으로 저렴한 솔루션.

=> 이 구조는 자금이 빡빡하거나 단순한 나가는 서비스만 사용하는 작은 사이트를 위한 솔루션이 될 수 있을 것이다.
=> 이 구조에 대한 간단한 개선방법은 "지능적 필터"의 사용일 것이다: 컴퓨터 한 대를 외부 필터로 사용하되, 특별한 방화벽 소프트웨어를 이용하여 패킷과 서비스를 걸러낸다. 이 솔루션은 그리 비싸지 않은데도 ( 아마 단순한 시스템에 $5000 정도 더), 더 나은 보호와 로깅 가능성을 보여준다. 이 컴퓨터의 OS는 매우 신중하게 구성되어야 한다.

스크린 서브넷 (또는 DMZ) 구조

이 구조는 스크린 호스트 구조의 연장이다. 고전적인 방화벽 설정은, 외부와 프락시가 있는 "반(semi) 보호" 또는 비무장지대 (DMZ) 서브넷 사이에 패킷 필터가 있는 것이다 (이것은 외부에서 DMZ 구역의 서비스로의 제한된 접근만을 허용한다). 프락시로/부터의 접근만을 허용하는 또 다른 패킷 필터에 의해 DMZ 는 내부 네트웍으로부터 더욱 분리된다.

• 위에서 말한 필터들은 로깅이 가능한 "지능적" 필터라는 것에 유의한다.
• 내부와 외부 네트웍들 사이에 들어오고 나가는 모든 서비스들은 DMZ에 있는 프락시 서버들을 통해 지나간다.
• 인터넷에 제공되는 서비스 (WWW 나 anon ftp 같은) 는 내부로의 접속이 전혀 없는 전용 시스템 상에서 운영된다 (이 시스템은 잠재적으로 함락된- "희생양"으로 간주해야 하기 때문에). WWW 나 (쓰기 가능한) ftp 를 인터넷에 제공하는 서버는 완전하게 안전하기가 어렵다. 어떤 사이트에서 웹 상거래 같은 안전한 서비스를 제공한다면, 강력한 SSL을 가지고, B1 (TCSEC) 인증을 받은 OS를 사용하며, 매우 제한적인 사용량/모니터링/감사/변경 관리 등등을 가지는 전문화된 2차 웹서버를 설치할 것을 권고한다.
• DMZ 는 switched LAN 이나, 사이에 듀얼 홈 배스천 호스트가 있는 두 개의 switched LAN 일 수 있다. 프락시된 연결만이 들어올 수 있고 필터 내의 소프트웨어 에러에 대한 보호를 하기 때문에 후자가 더 안전하다. 배스천 대신에 여분의 필터가 디폴트 라우트에 추가되지 않는 한 직접적인 내부 <-> 외부 연결은 더이상 불가능하다..
• 모듈러하고 유연함.
• 앞의 솔루션보다 방어의 깊이와 다양성(그러나 비용과 복잡성 또한)이 높아진다.
• 방어의 다양성을 최대화하기 위해서는, 위에서 보여진 "패킷 필터"들 대신 두 가지 다른 방화벽을 사용한다.
• 아주 높은 가용성을 위해서는 앞뒤 필터와 함께 DMZ를 이중화하여, 중복 라우팅(redundant routing)을 지원하는 라우터로 서로 묶을 수 있다 (두 대는 내부에 두 대는 외부에).

=> 큰 사이트나, 귀중한 자산을 보호하는 사이트에 권고된다... 

보이지 않는 필터(Invisible Filter) 구조

어떤 제품들은 브리지처럼 동작해서 TCP/IP 트래픽에는 보이질 않는다. 한 예로써 Sun Microsystems 의 SunScreen 이 있다. 이것은 아주 큰 이익을 주는데, 특히 필터가 지능적이라면 더욱 그렇다 - 패킷 필터를 공격하기가 매우 어렵다.

• 필터가 IP 주소를 가지고 있지 않으므로, 공격하기가 훨씬 어렵다. 보이지 않는다는 것은 중요한 보안적 이익이다.
• 브리지는 할 수 있지만 라우트는 할 수 없기 때문에 현재의 주소나 서브넷 마스크를 바꾸지 않고도 현재 네트웍에 삽입될 수 있다. 그러나 이것은 또한 라우터가 여전히 필요하다는 것도 의미한다!
• 고도의 가용성을 위해 이중 필터를 사용할 수 있어야 한다.

==> 위의 필터는 장애의 단일지점이 된다. 이것이 죽거나, 실수로 잘못된 규칙이 추가되면 어떻게 되나?
==> 하지만 방어의 다양성은 앞의 솔루션만큼 좋지 않다. 최대의 보호를 위해, 위의 필터를 "DMZ 구조" 에서 보여진 패킷 필터/로거로써 사용할 수 있다.

방화벽 암호화/터널

(인터넷과 같은) 공중망을 건너는 안전한 데이타 통신이 필요할 때, 가장 투명한 솔루션은 IP 계층에서의 TCP/IP 트래픽 암호화이다.

• 위의 시나리오에서, 사이트 B와 C는 안전하게 정보를 교환할 수 있지만 사이트 A와는 그렇지 않다.
• 서로 호환되지 않는 프로토콜들을 사용하는 암호화 방화벽이 다양하게 많이 있다. 몇몇 회사들이 자기들의 솔루션을 제안 표준으로 밀고 있긴 하지만 (e.g. Cisco의 PIX, Netscape의 SSL, Sun의 SKIP, Microsoft의 PPTP, SSH), 명확한 표준이 없다. 어떤 제품들은 방화벽-방화벽 간 암호화를 제공하고, 또 다른 것들은 종단간 (end-to-end), 또는 두 가지 모두를 제공한다. IPsec 표준(완성이 되긴 되었다면)은 좀더 나은 VPN들의 상호운용성을 허용해야 한다.
• 모든 미국 제품들은 약한 암호화를 가지고 있다.
• 저자는 다음의 "강력한" VPN 들을 성공적으로 사용하고 있다. (미국 수출규제에 걸리지 않는): 단순한 TCP 포트의 터널링을 위해 SSH ( www.datafellows.com), 그리고 모든 TCP/IP 트래픽을 위해서는 FORT E+ (www.elvis-plus.com 또는 www.elvis.ru ) , 이것은 Sun의 SKIP 과도 상호 운용된다.
• 인터넷을 거치는 가상 네트웍들은 인터넷 그 자체와 마찬가지의 가용성 및 성능 문제를 안고 있다. 가상 네트웍을 이용하여 원격 사무실과 연결하기 전에 이를 고려하라. 

구성 이슈

OS (운영 체제)

• 단순하게 한다.
• 보증 절도 참조한다.
• 절대적으로 필요한 서비스가 아니라면 (e.g.inetd services, NFS, NIS, X11, portmapper/RPC, sendmail, lpr, Netbios...) 모든 서비스를 비활성화한다. 네트웍 로그인이 가능해서는 안된다. 관리자 로그인은 콘솔이나 SSH 같이 안전한 서비스를 통해서만 일어나야 한다.
• ROM이나 CD-ROM 에 포함된 OS는 바이러스, 트로이 목마 등등의 문제를 없애준다. CD-ROM 은 디스켓으로부터 패치할 수 있고 ROM 보다 업그레이드 쉽기 때문에 더욱 흥미롭다.
• 가능하면 tcp_wrappers (또는 이와 동등한 것) 를 사용하여, 더 나은 로깅과 IP 계층의 접근 통제를 할 수 있도록 해준다 (아주 간단하진 않지만).
• TCP_SYN flooding: 일종의 서비스 거부 공격으로 (1996년 여름에 출현), 잘못된 소스 IP 주소를 사용하여 한 서버에 수천개의 TCP 연결을 반만 설정해 놓는 것이다. SYN 이 하나 올 때마다, 연결을 제어할 수 있도록 하기 위해 메모리 조직이 할당된다. 이 공격은 두 가지 방법으로 사용될 수 있다. 반만 열린 연결의 수가 제한되지 않았다면, OS (메모리 및 자원 관리 지능) 와 사용할 수 있는 메모리에 따라, 서버는 과부하가 걸려 느려지거나 다운되기까지 할 것이다. 요즘의 유닉스 시스템들은 다운되지는 않고 느려질 것이다. 이에 대한 장기적인 솔루션은, 벤더들이 자신들의 TCP 알고리듬을 수정하여, 공격을 인지하고 가능하면 네트웍 속도 등에 따라 타임아웃을 줄이도록 하는 등등을 할 수 있도록 하는 것이다.
  새로운 많은 방화벽들은 SYN flooding 에 대한 보호를 제공한다.
  SYN_RCVD 상채의 TCP 연결 수를 확인하는 데 쓰일 수 있는 간단한 스크립트를 소개하면 (Solaris용):

  #!/bin/sh
  count=`netstat -an -f inet | egrep SYN_RCVD |wc -l `
  if [ $count -gt 50 ] ; then
      echo "This server may be under a SYN attack. Please check current connections!"
  fi

  cron에서 위 스크립트를 30분 마다 돌리도록 할 수 있다. 받아들일 수 있는 연결 수는 (위에서는 50) 서버 사용량에 달려있다는 것에 주의한다. 바쁜 시간대에 서버를 관찰하여 이 값을 추정한다. 

서비스

서비스를 구성하는 것에 대한 훨씬 더 자세한 사항들은 [fire2] 를 참조한다. [unix1] 도 훌륭한 참고 자료이다.

• NNTP: 가능하면 뉴스 전용 서버를 사용한다. 높은 가용성이 중요하다면, 자동적인 그룹 생성을 허용하지 않는다. 자기가 뉴스를 교환하는 사이트로부터만 외부 NNTP 연결을 허용한다 (뉴스 구성 파일과 패킷 필터를 사용하여). 신뢰하는 외부 NNTP 서버를 내부 뉴스 서버에 연결하고 또 그 반대의 경우를 위해 패킷 필터링과 프락시를 사용한다. 반드시 최신 패치가 설치되어 있도록 한다 (e.g. INN 은 몇 가지 취약점을 가지고 있다).
• HTTP (WWW):
  • WWW 서버를 제공하기 : 가능하다면 전용 배스천 호스트를 사용한다. 신중하게 접근 통제를 구성한다: 어떤 사람이 프로그램을 서버에 올려서 실행시킬 수 있는가? HTTP 서버가 접속할 수 있는 외부 프로그램을 통제한다. cgi-bin 디렉토리에 어떠한 interperter 도 없도록 주의한다. .
  • 외부 서버에 접근하기 : 외부 접근을 위해서는 프락시 HTTP 서버를 사용한다 - 내부 네트웍으로부터의 직접 접속을 허용하지 않는다. 외부로부터의 프락시 접근이 금지되도록 프락시를 구성한다. 성능을 위해 (DNS가 아닌) IP 접근통제를 사용한다. 로깅을 활성화한다 (상세한 로깅은 성능에 불리한 영향을 줄 수 있다) . 프락시에서는 패스워드 보호를 사용하지 않도록 하고 (사용자 불만, 스니핑 쉬움) proxy_xxx 환경 변수들이 설정되어 있지 않도록 한다.
    패킷 필터링: 불행히도, 모든 HTTP 서버들이 80번 디폴트 포트를 사용하지는 않는다. 포트 80, 81, 800, 8000, 8080, 8888, 7070 (SHTTP) 및 어쩌면 다른 포트로의 나가는 프락시 접속을 허용한다.
  • HTTP 클라이언트를 신중하게 구성하고 (e.g. ActiveX, JavaScript 및 아마도 Java 를 사용하지 않음으로) 사용자들에게 외부의 조언에 따라 클라이언트를 재구성하지 말도록 경고한다. NCs, X-Terminals, Net-TerminalsConsider 등과 같은 중앙화되도록 만들어진 컴퓨터의 사용을 고려해 본다
• Gopher & WAIS: WWW 클라이언트를 gopher 클라이언트로 사용한다.
• Archie: Archie 서버를 운영하지 말도록 하고, 사용자들에게 WWw 게이트웨이를 통해 Archie에 접근하도록 가르친다.
• Finger: 들어오는 finger 요청을 배스천 호스트로 제한한다. 이 호스트 상에 finger 대체 데몬을 운영한다. 나가는 finger는 허용할 수도 있지만, 클라이언트 바이너리를 대체할 것을 고려한다.
• Whois: 외부에서 보이는 Whois 서버를 운영할 필요가 없다.
• Talk & IRC (Internet Relay Chat): 내부 시스템들과 인터넷 간의 talk 을 허용하지 않는다. 절대적으로 필요한 경우라면, DMZ에 전용 배스천 호스트를 만들고 내부 사용자들은 이 시스템으로 telnet 하여 인터넷과 talk 하도록 한다.
• DNS:
  • 외부 세계에서 접속할 수 있도록 외부 DNS 서버를 배스천 호스트에 구성한다. HINFO 레코드가 외부 세계에서 보이지 않도록 한다.
  • 최신 BIND 버전을 사용하고 (ftp://ftp.isc.org/isc/bind/src/) spoofing을 피하기 위해 lookup을 이중으로 역전 (double-reverse) 시킨다 (그러나 성능 저하는 감수하고).
  • 특히 NAT가 사용되는 경우, 모든 내부 DNS 데이타를 숨기고 전달(forwarding)과 거짓 레코드를 사용하는 것을 고려해 본다. 이것은 모든 사이트에 맞는 것은 아니며 다른 소스로부터 호스트 정보를 얻기도 쉽다 (네트웍으로 ping, 메일 헤더 등등). DNS 분리는 또한 비용도 더 들지만, NAT를 사용하는 큰 사이트에서는 표준적인 관행이다.
• Syslog: 외부로부터 syslog를 허용하지 않는다. 모든 방화벽 시스템들로부터의 syslog를 전용 호스트로 중앙화 (loghost 를 사용하거나 scp로 로그를 수동으로 모아서) 하여 여기에서 로그를 정기적으로 가지치고, 보관하고 분석하도록 할 것을 고려해 본다.
• 네트웍 관리: 네트웍 관리자들이 아마도 방화벽 양쪽의 모든 시스템에 대한 전적인 접근을 원할 것이다.
  • 외부로부터 SNMP가 방화벽을 건너가지 못하도록 한다 (이것은 특별한 라우터 구성이 필요할 지 모른다).
  • ICMP 요청이 밖으로 나가는 것은 허용하지만, 들어오는 ICMP 요청은 "필요한" 시스템들로만 제한한다 (e.g. 네트웍 공급자의 시스템). ICMP echo 응답은 양쪽 모두 허용한다. 밖으로 나가는 traceroute 은 허용하되, 들어오는 요청은 위의 ICMP 에서와 마찬가지로 제한한다. 안전한 ICMP 메시지 유형만 허용한다.
• 라우팅:
  • 명시된, 신뢰하는 주소들 간에는 어쩌면 있을 수도 있지만, 이를 제외하고는 라우팅 프로토콜(RIP 같은)이 방화벽을 건너가도록 허용하지 않는다.
  • 가능한 경우 static routes 를 사용한다.
  • Gated 는 누가 나에게 RIP 할 수 있는지를 통제하는 데 관심이 있다.
• NTP (Network Time Protocol): NTP 는 전적으로 내부에서만 사용할 것을 고려해 본다 (예를 들어 라디오 시계가 있는 서버를 참고로 사용하여). NTP를 외부에서 반드시 운영해야 한다면, NTP 배스천 호스트를 프락시 서버로 사용하고 패킷 필터를 써서 누가 연결할 수 있는 지를 제한한다.
• rexec, rex, FSP, TFTP, NFS, NIS/YP, lpr, lp: 어떤 방향으로든 허용하지 않는다 .
• X11: 외부에서의 연결은 권고하지 않는다. 필요한 경우, 프락시 서버를 사용하고 (FWTK x-gw 같은) 더 좋은 것은, SSH 의 암호화된 X11 전달을 사용한다.
• 이메일.
  • SMTP: Sendmail 은 방화벽 구축에서 가장 큰 악몽이다!
  • 일반적인 보관 후 전달(store-and-forward) 기능을 사용하여 모든 메시지가 이메일 게이트웨이 를 통해 지나가게 한다. 내부와 외부 사이 직접적인 연결은 허용하지 않는다.
  • 가능하면 sendmail 전용 호스트를 사용하고 모든 서비스/사용자들을 제거하여 연결할 수 있는 대상을 제한한다. 이 호스트는 내부 DNS 서버들을 resolve 해야 할 것이다.
  • 외부 연결은 배스천으로만 허용한다. 내부 서버들은 이메일 게이트웨이 로만 접근할 수 있도록 하고 그 반대도 마찬가지다. sendmail 앞에, 배스천 상에서 smap/smapd (FWTK의 일부) 또는 그와 대등한 것을 사용한다. Sendmail 은 버그도 너무 많고, 크고 복잡래서 25번 포트로 직접 접속을 허용할 수가 없다.
  • 나가는 메일의 "from" 주소로부터 호스트이름을 벗겨내기 위해 ruleset 을 해킹해야 할 지도 모른다.??
  • 보다 높은 가용성과 성능을 위해 두 대의 메일 게이트웨이를 구성하고, 모두 MX 레코드 목록에 넣는다.
  • 이메일을 통해 패스워드가 인터넷 상으로 전송되는 것을 허용하지 않는다.
  • POP: 인터넷을 거쳐 POP을 사용하지 않는다 (패스워드를 스니핑하기가 너무 쉽다).
• FTP:
  • Outgoing: 프락시를 사용하거나, 상태 기반 필터링을 하는 방화벽에 의해 보호되는 몇몇 내부 호스트들로부터만 허용되어야 한다.
  • Incoming: 만약 들어오느 연결이 허용되어야 한다면, 배스천 호스트로만 허용한다. Anonymous 인 경우, ftp 쓰기가 허용되어야 한다면, 쓰기 가능한 영역이 제삼자를 위한 전송 영역으로 이용될 수 없도록 보호한다.
  • Anonymous 서버: anon ftp에 대해 파일을 put 할 수 있는 사람의 수를 내부적으로 제한한다. 관련된 문제들에 대해 이들을 교육한다.
• Telnet:
  • Incoming: 들어오는 telnet 세션은 모두 금지하거나 엄격하게 제한한다. 특별한 인증 프락시 서버를 사용한다 (일회용 패스워드를 쓰는). 더욱 좋은 방법으로는, SSH 를 사용한다.
  • Outgoing: 패킷 필터링이나 프락시를 사용하여 연결을 허용할 수 있다. Telnet 세션의 데이타 기밀성을 보호하기 위해, 암호화된 버전의 사용을 고려하라 (e.g. SSH 또는 DES Telnet).
• UUCP: 필요한 경우 (UUCP 는 요즘엔 거의 쓰이지 않는다), 필터링을 하는 배스천 호스트를 거치도록 UUCP를 route하고, 아니면 닫아놓는다.
• BSD "r" commands: 들어오는 연결은 허용하지 말고 나가는 것은 프락시를 거쳐 나가는 rlogin 만을 허용한다.
• Real audio: www.realaudio.com 에서 FWTK 와 함께 동작하는 프락시를 구할 수 있지만, 저자의 경험으로는 문제가 있었으나 지원을 받지 못했다. 문제는 TCP와 UDP가 모두 사용된다는 것이다. 몇몇 벤더들은 프락시를 제공한다. Mediator-1 real audio proxy 는 잘 동작하고, shareware 이며 가격이 싸다 www.comnet.com.au/htmls/mediator1.html.
• MBONE: 은 멀티캐스팅 어플리케이션이다. 알려진 프락시가 없다. 

CORBA & 방화벽 (July 1998)

CORBA/IIOP 는 클라이언트와 서버 사이의 접근을 통제하고 연결을 관리하는 "man in the middle" (즉 방화벽) 을 예상하고 설계되지 않았다. "IIOP 가능한 방화벽" 이 IIOP 클라이언트로부터 서버로 나가는 접근을 통제할 수 있어야 하고 또 IIOP 클라이언트로부터 방화벽 뒤의 서버로 들어오는 연결도 통제할 수 있어야 한다. 서버쪽에서, 가장 큰 어려움은 방화벽이 모든 포트에서, 그리고 모든 내부 호스트로 향하는, IIOP를 가지는 연결을 listen하도록 구성하는 것이다 (IIOP의 특징 중 하나가 포트가 동적으로 할당 되는 것으로, 특정한 포트 번호에 단순한 IIOP 필터를 할당할 수가 없다).

CORBA 2.2 는 CORBA 프락시의 도입을 고려하여 확장되고 있지만, 이 사양에 맞는 제품(아래에 논의)은 아마 아무리 빨라도 1999년 초까지는 나오지 않을 것이다. 오늘날, IIOP가 방화벽을 지나다니도록 하는 방법이 두 가지 있다 (IIOP 서버로 들어오는 연결 또는 ORBs). 나가는 방법은 CORBA 2.2 절에서 다룬다.

1. IONA의 Wonderwall (www.iona.ie/products/internet/wonderwall/ 과 Sysadmin doc) 이 유일하게 알려진 사용할 수 있는 프락시이다. Wonderwall 은 객체의 Interoperable Object Reference (IOR) 를 "프락시화" 하고 프락시 IOR 상에서 원격 invocation을 할 수 있게 한다. 또 HTTP 터널링 모드에서도 동작할 수 있다.
   장점: 객체 레벨에서 로깅과 접근 통제를 제공한다. 어플리케이션을 변경할 필요가 없다. Orbix & Orbixweb 으로의 메시지가 암호화될 수 있다. Iona는 시장 선도자이다.
   단점: callback 의 문제가 아직 해결되지 않았다. 독자적인 제품이다 (공개 표준이 아님). 확인되지 않은 걱정으로는 Wonderwall 이 클라이언트 ORB 와 서버 ORB 가 IONA 것일 때만 동작한다는 설이 있다 (실세계에서의 테스팅이 필요하다)..
2. Visigenic 에는 Gatekeeper 라는 것이 있는데, 이것은 그냥 터널된 HTTP 를 풀어서 올바른 서버로 그 요청을 보내줄 수 있는 게이트웨이일 뿐이다. 이들은 또 IOR 대신에 URL을 사용하는 독자적 방법도 가지고 있다 . ( www.sys-con.com/java/reviews/visibroker/index.html)
3. HTTP 터널링: 클라이언트가 HTTP 에 IIOP 메시지를 덧붙이고, IIOP를 풀어서 처리하는 방법을 알고있는 반대쪽의 유사 HTTP 서버가 이를 가로챈다.
   Wonderwall 도 HTTP 터널 모드에서 동작할 수 있다.
   장점: 방화벽 필터를 변경할 필요가 없다. UBS 홈뱅킹 (  /www.ubs.com/e/telebanking.html) 은 AdNovum의 소프트웨어 ISIWEB ( www.adnovum.ch/ISI/isi.html ) 을 통해 이러한 구조로 동작한다. ISIWEB 은 수정된 Apache HTTP 프락시를 사용한다.
   단점: 메시지들이 IIOP/HTTP 의 혼합이고 더이상 CORBA wire-level 호환이 아니다. HTTP 프락시는 원래 하도록 설계되지 않은 일을 하게 "수정"되어, "백도어" 가 생성되었다. 추가적인 HTTP 처리/번역이 성능에 영향을 미친다.
   
   IIOP 정책/규칙의 정의과 트랜잭션 로깅이 방화벽에서 일어나지 않아, 방화벽은 터널을 통해 무엇이 지나가는지에 대한 "통제를 할 수 없다" - 따라서 수정된 HTTP 프락시가 CORBA 객체 접근 로깅과 접근 통제 또한 담당해야 한다 ( ISIWEB 은 아직 이것을 하지 않는다. Wonderwall 은?)

CORBA 2.2 방화벽 사양:
새로운 문서에서는 [corba1] 방화벽이 CORBA 모델에 통합되게 할 수 있도록 CORBA 의 변경을 계획하고 있다. 방화벽을 건너는 CORBA 통신을 가능하게 하고, call-back 과 SSL 도 지원하는 새로운 구성요소 GIOP 프락시가 제시된다. 방화벽을 건너는 방법으로 세가지가 제시되는데, 처음 두개는 선택사항이고, 세번째는 필수사항이다.

1. 패킷 필터를 가지고 잘 알려진 TCP 포트를 이용하기. 방화벽은 보통 포트 번호와 IP 주소를 가지고 TCP/IP 패킷을 걸러낸다. 나가는 접속에 대해서 방화벽은 단순히 선택된 내부 호스트로부터 (선택된) 외부 호스트로의 IIOP 포트를 허용할 수 있다. 그런 "잘 알려진"포트는 아직 없지만, SSL 가능한 포트에 더하여 하나를 정의한다. 방화벽은 IIOP 에 대해 아무것도 모르기 때문에 CORBA 객체에 대해서는 접근 통제를 제공할 수가 없다. 그래서 이 솔루션은 어떤 특정한 상황에서 (e.g. 방화벽이 실제로 프락시 없는 연결을 허용할 때), 나가는 IIOP 연결에 대해서만 적합하다.
2. 나가는 연결에 대해 SOCKS 프락시를 사용. CORBA 제품들의 라이브러리들을 SOCKS화 된 TCP 라이브러리와 재링크함으로써, 연결은 네트웍 계층에서 (방화벽에 있는) SOCKS 프락시를 통해 route 된다. SOCKS는 IETF 승인 표준이다.
3. (새로운) GIOP 프락시를 사용하기. 다음은 계획서로부터 추출한 것이다 (이탤릭체) [corba1]. 기본적으로 이것은 IIOP 응용계층을 이해하고 내부 또는 외부의 CORBA 객체로의 접근을 허용 또는 거부할 수 있는 고전적인 방화벽 프락시를 정의하고 있다.
   GIOP 프락시는 GIOP 메시지를 이해하고 특정한 전송계층의 ORB 간 프로토콜이 지원되는 응용레벨 방화벽이다. 즉 TCP GIOP 프락시는 IIOP 메시지를 이해한다. 서버에 연결을 맺으려면, 클라이언트는 먼저 GIOP 프락시에 연결을 설정한다. GIOP 프락시가 outbound 프락시라면, ORB는 프락시 객체의 IOR를 가지고 구성되어야 한다. GIOP 프락시가 inbound 프락시이면, 서버의 IOR 은 방화벽상에 있는 프락시 객체의 IOR 을 포함하고 있어야 한다. GIOP 프락시를 통하는 연결에는 두 가지 형식이 있다: normal 과 passthrough.
   • normal 연결은, 클라이언트의 관점에서 볼 때 방화벽이 서버처럼 동작하고, 서버의 관점에서는 방화벽이 클라이언트처럼 동작하는 것이다. 프락시는 GIOP 트래픽을 모니터할 수 있다. 이것은 두 가지 보안 문제를 일으킨다. 첫번째는 클라이언트가 GIOP 프락시를 신뢰하지 않을 수 있어, 프락시가 트래픽을 검사하는 것을 원치 않을 수 있다는 것이다. 두번째로, 클라이언트와 서버가 프락시는 알지 못하는 특별한 인증 및/또는 암호화 메카니즘을 사용하고 있을 수 있다.
   • Passthrough: 프락시는 자기가 받는 모든 GIOP 메시지를 적절한 쪽에 단순히 전달만 한다. 이것은 프락시가 트래픽을 검사할 수 있는 능력이 없거나 검사가 허용되지 않는 것을 인정한다. Pass-through 연결에서는, 방화벽이 그 연결상의 GIOP 대화를 유지할 책임이 없으며, 자신의 GIOP 메시지는 하나도 발행하지 않을 수도 있다. (응답이라든지 연결 종료 같은). Pass-through 연결은 전송 레벨 방화벽과 비슷한 동작을 보이지만, 객체 레벨상에서 동작한다. 즉 일단 프락시가 특정한 객체로의 접근을 허용한 후에는 , 어떤 트래픽이든지 (GIOP 상호작용의 규칙에 따라) 방해받지 않고 프락시를 통해 지나갈 수 있다.

계획서에는 SSL 상으로 IIOP를 사용하기 위한 솔루션도 포함되어 있는데, 두 가지 각본이 있다 : trusted 및 untrusted 프락시.

1. Untrusted 프락시들은 클라이언트로부터의 정보를 pass-through 연결의 형태로 전달할 수 있다. 즉 프락시는 암호화된 바이트 스트림을 볼 수 없다. 이것은 클라이언트와 서버 통신의 무결성을 보장하긴 하지만 접근통제를 위한 조건을 거의 남겨놓지 않는다. 이러한 유형의 연결은 프락시가 접근 통제 목록을 완전히 적용하는 능력을 제한하지만, 서버나 클라이언트 중 한쪽이라도 프락시를 완전히 신뢰하지 않는 경우에는 필요하다.
2. Trusted 프락시는 pass-through 연결을 이용하여 연결을 전달할 수도 있지만, 서버로 별도의 연결을 확립하여 완전한 접근 통제를 제공할 수도 있다. 이것은 접근통제의 구현을 untrusted 의 경우처럼 서버쪽에서든지 또는 프락시에서 operation을 기준으로든지 할 수 있게 해준다. 모든 trusted 프락시들은 대상 서버에 따라 결정되는 trust group 에 속한다.
   
   모든 프락시들이 대상 객체의 IOR 과 클라이언트의 인증서에 접근 가능하므로, 이들은 클라이언트가 pass-through 연결을 사용해도 되는지 아닌지를 판단할 수 있다. 어떤 주어진 환경에서든 프락시가 클라이언트의 pass-through 사용을 허용할 지 거부할 지는 프락시를 구현하는 사람에게 달려있다.

계획서의 마지막 부분은 쌍방향 GIOP을 이용하거나 프락시를 확장함으로써 call-back 을 지원하는 메카니즘을 제시한다 :

위에 덧붙여 보다 포괄적인 솔루션을 제공하기 위해, GIOP 프락시 객체는 클라이언트가 호출할 수 있는 기능을 제공한다. 프락시는 알맞은 방화벽 정보를 가지고 있는 IOR을 생성할 것이고, 그 다음에 이것은 서버로 전해질 수 있다.T서버는 GIOP 프락시에 연결을 설정할 수 있고, 그위에 트래픽을 보낼 수 있다. 프락시는 클라이언트와 이미 쌍방향으로 맺어져 있는 연결을 재사용하여 GIOP 메시지를 클라이언트에게 보낸다.

견본 제품

이 절에서는 몇가지 제품과 함께 저자가 느끼는 장단점을 소개한다. 광범위하게 테스트된 제품들에 대한 보고서들이 가장 자세히 되어 있다.

아래에 논의되지는 않았지만, 아직 시간이 없어 확인하지 못한, 흥미로운 새 방화벽으로 프랑스 제품인 Netasq 100 이 있다. 이것이 흥미로운 것은 시간에 따른 규칙 때문이다:

시간 관리: 필터링, 네트웍 주소 변환 (NAT) 및 URL 필터링 절차들은 프로그램 가능한 시간에 trigger 되는 구성 파일로 체계화된다. 따라서 업무시간과 비업무시간에 따라 다른 절차를 정의할 수 있다. 이것은 조직의 보안을 강화한다. 그럴 필요가 없는데도 문을 열어두는 사람은 없다!

www.netasq.com 을 참조한다.

ITSEC 인증 제품

ITSEC ([itsec] 과 [itsem] 참조) 은 부록 C 에 상세하게 기술되어 있다. 이것은 유럽판 TCSEC (Orange Book) 으로 보다 완벽하다. ITSEC은 기능성과 보증을 분리한다. 보증 레벨은 E1 에서 E6 까지 있다. 예시 기능 등급으로 F-C1, C2, B1, B2, B3 을 정의하는데 이는 TCSEC 등급에 상응하고, 새로운 등급인 IN, AV, DI, DC 및 DX 은 네트웍(TCSEC에는 결여된)을 포함하고 있어서 흥미롭다.

다음은 ITSEC의 인증을 받았거나 평가가 진행중인 방화벽 목록이다. www.itsec.gov.uk/ 도 참조한다.

지능적 필터(스크린)

지능적 필터들은 방화벽 시장에서 상대적으로 새로운 것이지만, F1 같은 (아래 참조) 선도적인 방화벽 안에 병합되어 있다. 이번 절에서는, 특정한, 잘 알려진 필터들을 소개한다.

IP Filter

IP Filter 는 TCP/IP 패킷 필터로, 방화벽 환경에서 사용하기에 적합하다. Loadable 커널 모듈로 사용하거나 유닉스 커널에 병합하여 사용할 수 있다 ; 가능한 한 loadable 커널 모듈로 사용할 것을 강력하게 권고한다. 필요한 대로 시스템 파일을 설치하고 패치할 수 있도록 스크립트가 제공된다.

이것의 저자는 Darren Reed (darrenr@cyber.com.au) 이고, 방화벽에 하위 레벨 패킷 접근 통제 계층을 추가하는 것이 가능할 것으로 보인다.
특징: IP filter 는 프로토콜(udp 또는 tcp), IP fragment, 포트 (및 범위), IP 옵션, TCP flags, ICMP 유형/코드의 필터링을 제공하고, NAT, 로깅, 투명한 라우팅, VLSM (Variable Length Subnet Masks : 가변길이 서브넷 마스크 ) 을 제공한다. 뿐만 아니라, 서비스의 redirection "투명 프락시" 그리고 패킷 상태를 분석하여 TCP ack/일련번호가 맞는지 확인할 수도 있다.
장점: 무료, 유연성, 소스코드, 많은 유닉스 기종에서 동작
단점: GUI 가 없음, 신중한 구성 필요. 주소 그룹을 정의할 수 없어 많은 수의 네트웍을 보호하는 방화벽의 경우 규칙이 매우 복잡해질 수 있음. 마찬가지로 프로토콜 그룹 정의도 불가능.
http://cheops.anu.edu.au/~avalon/ip-filter.html, ftp://coombs.anu.edu.au/pub/net/ip-filter/ 도 참조한다. 그리고 majordomo@coombs.anu.edu.au 로 제목을 "subscribe ipfilter" 로 하여 메일을 보내면 메일링리스트에 가입할 수 있다.

저자는 이 인상적인 패키지를 대충 보기만 했는데 꼼꼼한 테스트를 할 시간은 없었다 (또 그럴 필요도 없었다, 이미 Sunscreens를 쓸 수 있었으니까). Solaris에서 컴파일되면, 깔끔한 SVR4 패키지가 생성되어 깨끗하게 설치/제거할 수 있다. 여기 3.1.5에 대한 README 파일로부터의 추가 정보가 있다 :

IP Filter - 어떤 것인가 ?
============================
이 패키지 이면에 있는 사상은 유닉스 워크스테이션을 라우터로 사용하는 사람들에게 (대학에서는 흔한 일로 보임), 이를 나가고 들어오는 패킷들에 대해 패킷 필터링을 적용할 수 있게 하자는 것이다. 이 패키지는 Sparcs 에서 운영되는 SunOS 4.1의 모든 버전과 Solaris 2.4/2.5 에서 테스트되었다. 그냥 보안 증대를 위해, IP를 route하지 않는 Sun 워크스테이션에 이 작은 커널 확장분을 설치하여 효과적으로 사용하는 것도 물론 가능하다. 이것은 또 멀티캐스트 패치와 통합될 수도 있다. 또한 BSDI 뿐만 아니라 최신의 모든 free BSD에서도 성공적으로 테스트되었다.

이 필터는 IP 패킷 큐의 inbound 와 outbound 측 모두에 대해 규칙 목록을 보유하고 있으며, 패킷이 소스 라우트 옵션에 대한 검사를 채 받으러 가기도 전에 패킷을 차단하기 위해, 가능한 한 빨리 검사가 이루어진다. .........저자도 이것을 TIS의 Firewall Toolkit 과 함께 사용하여 자체 방화벽을 성공적으로 설치하고 운영해 보았고, mbone 라우터상에서도 사용해 보았다.

Linux/BSD/IPchains/IPfilter 를 사용하고 싶으면, [fire3] 를 사서 읽어보고 부속 웹사이트도 확인해본다.

ipchains

주소 그룹 정의가 없어, 많은 수의 네트웍을 보호하는 방화벽의 경우 규칙이 매우 복잡해질 수 있음. 마찬가지로 프로토콜 그룹 정의도 불가능.

Linux//ipchains를 사용하고 싶으면, [fire3] 를 사서 읽어보고 부속 웹사이트도 확인해본다.

Firedog/Firemasq

Firemasq 는 무료 방화벽으로, 리눅스상에서 IPchains 와 함께 운영되도록 설계되었다.

Sinus

Sinus 홈페이지로부터의 추출 www.ifi.unizh.ch/ikm/SINUS/firewall/

SINUS 방화벽은 인터넷의 일상적인 위협으로부터 당신의 네트웍을 보호하기 위한
돈 안들고 쉬운 방법이다. .....

IP, TCP, UDP, ICMP, IGMP 패킷들의 모든 헤더 필드를 필터링.
지능적인 RIP 및 FTP 지원.
이해하기 쉬운, 텍스트 기반의 구성.
여러 대의 방화벽 구성을 위한 그래픽 관리 인터페이스.
카운터와 타임 아웃을 포함하는 동적 규칙.
상세한 로깅, 경고 및 카운터 정보.
패킷 및 주소 spoofing 방지 - GNU GPL 라이센스.

소프트웨어를 설치하려면, 리눅스 2.0.x 기반의 시스템이 있어야 함....

소프트웨어에 대한 철저한 테스트를 수행하였고, 12개월 이상 다운없이
계속해서 운영되었지만, 누군가 결군 소프트웨어의 버그를 발견하리라고 확신한다......

흥미롭게도, 이것은 SKIP v2 VPN 암호화의 무료 구현과도 함께 온다.ftp.tik.ee.ethz.ch/pub/packages/skip/

SunScreen 100, 200, EFS 그리고 EFS3

Note: 저자는 더 새로나온 Sunscreen EFS 3 에 대한 기사를 썼다. sp/SunscreenEFS.html 또는 www.boran.com/security/sp/SunscreenEFS.html 를 참조한다. 아래에는 오래된 버전들만 다루고 있다.

SunScreen 은 Sun (www.sun.com 참조) 에서 최근 출시된 제품으로 패킷 필터링 (상태기반), 최대 4개의 이더넷들간의 투명 스위칭 그리고 SKIP 프로토콜을 이해하는 호스트들에게는 IP 레벨 암호화가 제공된다.
이것은 패킷을 route 하지 않는다 (왜냐하면 이것은 RIP를 이해하지 못하고 라우팅 테이블이 없으며 IP 호스트들에게 보이지 않으므로). 이것은 이더넷 스위치처럼 동작하고, 어떤 인터페이스에서 어떤 IP 주소들이 예상되는지 알아야 한다.
(원래의) Sunscreen 100 은 구성을 위한 윈도우 기반의 GUI를 가지는 "블랙 박스"로 판매되었다. 이것이 Sunscreen EFS 로 발전되었고 지금은 대부분의 Sun/SPARCs에 설치될 수 있는 소프트웨어로서 200 이 판매되며 Motif & 웹 기반 관리 GUI 를 가지고 있다.
관리용 PC나 웹 GUI는 암호화된 TCP (SKIP) 연결을 통해 "블랙 박스"에 연결된다 (이후로는 Sunscreen 이라고 부른다). 가격은 $20k 정도이다.

VPN: Sunscreen 은 SKIP 프로토콜을 이용하여 VPN (virtual private networks : 가상 사설망) 들을 설정하는 데 사용될 수 있다. 종단점에서 종단점 (터널링) 또는 종단점에서 Sunscreen (게이트웨이=일반) 암호화가 있을 수 있다. 일반 모드에서 sunscreen은 각각의 종단점에 대해 인증서를 필요로 하고, 특정한 서비스들만을 (암호화된) 특정한 대상 IP 주소로만 허용하기 위한 규칙을 추가할 수 있다. 터널링 모드에서, Sunscreen은 단순히 SKIP (SKIP V1을 위한 IP 소켓 79 와 SKIP V2를 위한 IP 소켓 57) 이 통과되거나 통과되지 못하게 하고, 패킷이 Sunscreen에 의해 복호화 되는 것이 아니기 때문에 개별 서비스들이 통과되거나 차단될 수 없다. Sunscreen 100 & EFS 는 SKIP V1 만 지원한다.

개요:
100 에서는: OS (단일 사용자 모드에서 돌아가는 암호화된 TCP/IP 스택을 가지고 있는 stripped Solaris 2.4)가 CD-ROM 안에 포함되어 있다.i 하드웨어는 그냥 SPARCstation 5 에 1GB 디스크, 32MB RAM, 플로피 드라이브, CD-ROM 및 quad Ethernet 인터페이스를 가진다. Sunscreen은 CD-ROM 으로 부팅하고 내장 하드 디스크는 스와핑, 로깅 및 구성 정보에만 사용한다.

200 에서는: Sunscreen 소프트웨어는 관리 스테이션과 Screen의 두 부분으로 되어 있다. 둘 다 Solaris 2.5 이상을 쓰는 대부분의 SPARC 에 설치된다. 관리 스테이션은 부트 플로피를 생성하는데 이것은 200 CD-ROM 과 함께 screen 과 Solaris 2.5.1 을 설치하고, 구성하는데 사용된다. 설치 로그는 디스켓에 쓰여진다 (디버깅에 매우 유용). 몇 개의 Screen 들을 하나의 관리 스테이션이 관리할 수 있고 몇 개의 관리 스테이션이 같은 Screen 에 접근할 수도 있다.

장점:

• 구성 디스켓을 넣고 껐다 켠 후, admin GUI 로 연결하여 올바른 config만 받으면 15분 안에 간단하게 재설치가 된다.
• 투명성: 브리지처럼 동작하고 IP 주소가 없어, 공격하기 힘들다,
• 견고하고 신뢰성 있다 (한번 안좋은 경험을 빼고..).
• 필터는 상태기반으로 대부분의 TCP/IP 프로토콜 및 서비스들을 걸러낸다. IP 프로토콜이 아닌 것도 (IPX 같은) 이더넷 패킷 유형에 의해 걸러낼 수 있다. Real audio 필터는 100 에서는 패치로 가능하고 200에는 디폴트로 포함된다.
• 새로운 사용자 정의 서비스도 걸러질 수 있다 (그러나 독자적으로 상태 엔진을 정의할 수는 없다).

단점:

1. 비싸다 (IMHO).
2. 100: 구성과 모니터링을 GUI로 하므로 (즉 명령줄 인터페이스가 없음), 자동화 할 수 없다. 200 은 훨씬 개선되어, 원격 관리와 스크립트 자동화에 적합한 좋은 명령줄 인터페이스를 가지고 있다.
3. "net meeting" 필터가 없다.
4. 맞춤 필터 엔진을 생성할 수 없다.
5. 100: 포트의 범위 를 구성할 수 없다 (필요에 따라서는 큰 문제점). [200 에서는 수정됨].
6. 소스 코드가 제공되지 않는다.
7. 규칙에 "만료일"이 없고, 하루의 특정 시간대나 일주일의 특정한 날에 적용될 수 없으며, 코멘트 필드도 없다.
8. 100: NAT (Network Address Translation) 기능이 없다. [200 에서는 수정].
9. "일반l" 수출 버전은 작은 (40bits = 별로 쓸모가 없음) 암호화 키 길이를 가진다.
10. 프락시가 포함되어 있지 않은 순수한 필터이다. 따라서 방화벽을 위한 프락시를 또 사야 한다.
11. 규칙의 충돌이 허용되지 않아, 어떤 구성들은 짜증나게 한다.
12. 100: GUI 가 별로 직관적이지 않고 때로는 조잡하다. 에러 메시지는 모호하고, 문제의 실제 근원을 찾기가 매우 어려울 수 있다.. 버그 투성이다 (아래 참조), 그러나 '96년 4월 이후 Sun 에 의해 수정된 것은 하나도 없다. 200 은 더 낫긴 하지만 (더 안정적), 아직도 원시적인 GUI를 가지고 있다.
13. 100: 소프트웨어가 없으므로 관리 PC를 재설치할 수가 없다 (새로운 html front end로 이를 해결할 수 있을 지 모른다). 그러나, 새로 설치된 PC가 production Sunscreen의 현재 구성을 "가져와" 사용할 수 있으므로, PC가 죽더라고 구성 파일이 분실되지는 않는다.
14. 로깅이 패킷 레벨에서 일어나, 상위 레벨 로그 분석을 할 수 없다. 로그 브라우저는 원시적이다.
15. RJ45 만 지원되므로 배선이 문제가 될 수 있다. (즉 AUI 가 아님).
16. 버그 (100):
    • 100: "통과" 및 "실패"한 패킷들은 로그되지만 인터페이스에서 버려진(dropped) 패킷들은 로그가 안된다.
    • Sunscreen과 PC 사이에 꼬인 RJ45 를 사용할 수는 있지만, 전송 문제가 발생할 수 있으므로 권고되지는 않는다.
    • SNMP udp 상태 기반 필터에는 문제가 있었다.
    • "서브넷 주소"를 정의할 때, XX.XX.XX. 의 형태가 입력되면 XX.XX.XX.0. 으로 해석되는 것이 아니라, 관리 PC에서 끝에 숫자를 덧붙여 XX.XX.XX.4 (예를 들자면) 로 만든다. Workarounds: 서브넷 주소의 끝에 .0 을 꼭 붙이도록 한다.
    • 수정된 PC-NFS 에 대한 문서가 없다. 문제 해결이 어려워질 수 있다.
    • GUI 에는 Sunscreen 구성의 다운로드를 방해하는 심각한 버그가 있다. 이것은 몇몇 상황에서 발생한다, e.g. 관리 아이콘과 로그 브라우저가 함께 사용됐을 때. Sun은 이 문제를 몇개월동안 알고 있었지만 고치지 않았다. Workarounds: a) PC를 재시작한다. b) admin 유틸리티를 중단하고, config 디렉토리에서 *.pfm 파일을 삭제, 또는 c) 다운로드 하기 전에 configuration 을 하나 업로드한다. 업로드할 configuration이 없는 초기 설치에서는, 아무 규칙도 없는 cofig 를 다운로드 받은 후 그다음에 실제 config를 다운로드 해본다.
    • Sunscreen을 재부팅하지 않는 한 트래픽 통계가 0 으로 reset될 수 없다.
    • 32MB 보다 큰 로그파일들은 매번 PC로 전송될 수가 없고, 종종 잘린다.
    • 로그는 Sunscreen으로 자동적으로 다운로드 하거나 다른 시스템으로 전송될 수 없다.
    • 로그 브라우저가 로그파일 안에 있는 패킷 수를 정확하게 세지 않는다.
    • "요약" 로그 엔트리에는 관련된 tcp/udp 포트 번호가 나타나지 않는다.
    • 커다란 구성파일을 Sunscreen으로 다운로드할 때 불가사의한 조건하에서 종종 깨진다. (direct crossed RJ45 와 hub connections 에서).
    • 규칙은 변경되지 않았더라도 매번 다운로드 전에 재컴파일된다. 이것은 인생을 매우 느리게 만든다.
    • 규칙 컴파일러는 암호문같은 에러 메시지를 내보내어, 단순한 에러인데도 많은 시간을 허비할 수 있다!
    • Sunscreen 설치 디스켓을 생성할 때, "게이트웨이" 즉 디폴트 라우터를 정의해야만 하는데, 예를 들어 Sunscreen 을 로컬 네트웍에서만 관리하고 싶은 경우 처럼 이것이 바람직하지 않을 수 있다. 이 버그는 보안 노출을 증가시킨다.
17. 버그 (200):
    • 200 을 위한 점보 패치가 있는데, 반드시 설치하도록 한다. 관리 스테이션과 Screen 사이에 꼬인 RJ45 를 쓸 수 있지만, hme (100MB 인터페이스) 인 경우, 동작을 거부하거나 무지하게 느려진다. 이 문제는 200용 점보패치에서 수정될 것이다.
    • 설치 플로피에 있는 파일들의 "name mangling" 에 대한 문제들이 발견되었다. 설치가 실패하면, Sunscreen 콘솔에 로그온하여, 플로피를 넣고 파일이름을 확인한다. ~ (tilde)가 들어간 파일이 하나라도 있으면, 이름을 변경해야 한다. 이 문제는 Solaris 2.6 관리 스테이션에서 일어난다 (2.6 은 2.5와 다른 DOS name mangling 을 가지고 있으므로)..
18. 권고사항:
    • 콘솔 패스워드를 디폴트 값에서 다른 것으로 바꾼다.
    • 고가용성을 위해 "warm standby"의 설치를 고려해 본다. "warm standby" 는 configuration이 다운로드된 후 마스터와 동일한 설치 디스켓을 써서 설치된다. 마스터가 다운되면, 그냥 케이블만 백업으로 연결하면 된다. FTP 및 다른 연결기반의 세션들은 차단되지만, HTTP 세션들은 실제로 알아채지 못할 것이다. 이러한 유형의 standby 시스템은 중요한 구성상의 변경이 있을때도 유용하다 (구성이 잘못되면 언제든 standby 로 돌아가면 된다). 

프락시와 필터

오늘날 시장에는 많은 제품들이 있다. 다음은 (저자에게) 가장 잘 알려져 있거나 혁신적인 견본제품들이다. 상세한 최신 목록은 인터넷에서 찾을 수 있을 것이다. [list] 를 참조한다. 위의 지능적필터 부분도 참조한다.
TBD: screend ftp://ftp.vix.com/pub/vixie/ .

TAMU drawbridge (free)

Drawbridge 는 텍사스 대학에서 만든 (ftp://ftp.tamu.edu) 원래 PC (DOS) 기반의 공개 패킷 필터 (상태기반은 아님) 였다.

Drawbridge 는 아직도 업데이트되고 있으며, 지금은 FreeBSD 기반이다. http://drawbridge.tamu.edu. Drawbridge 의 주요 강점은 규칙(rule)을 1개 처리하든 1000개 처리하든 성능이 일정하게 유지된다는 것으로, 이는 처리되는 규칙의 개수와 직접적으로 성능이 연관되는 대부분의 방화벽과는 매우 다른 점이다.

TIS Gauntlet & FWTK (상용/무료)

FWTK (Firewall Toolkit) 은 프락시를 직접 구축하기 위한 무료 유틸리티들의 집합이고, Gauntlet 은 같은 것인데 상용의 완성된 제품이다. FWTK 는 종종 어떤 특정 기능이나 서비스가 결여된 벤더 방화벽을 보완하는데 사용되기도 한다.

전체

• 전체 소스코드가 제공된다. 유틸리티들이 꽤 작아, 소스코드 확인 및 변조가 그렇게 어렵지 않다.
• FWTK 는 통일된 프로그램이 아니고, 함께 동작하는 독립된 작은 유틸리티들의 집합이다. GUI는 없다. 이로 인해 개별 도구들은 매우 유연하고 "혼자" 쓰기 편하지만, 서투른 사람들에게는 감시 및 구성하기가 더 어렵다.
• Ftp, telnet, rlogin, http, 그리고 (sort of) SMTP 및 NNTP 프락시가 제공되고, 잘 알려진 인증 시스템들(S/Key, SecurID, Kerberos...)과 인터페이스하는 인증 서버도 제공된다.
• Inetd 서비스는 netacl wrapper를 이용하여 IP 주소를 기반으로 하는 접근통제를 추가할 수 있다.
• 모든 프락시는 chroot 하고 추가적인 보호를 위해 주어진 UID 하에서 돌아갈 수 있다.
• HTTP 프락시는 캐싱을 하지 않고 (캐싱은 성능을 현저하게 개선할 수 있다), SSL 도 지원하지 않는다.

무료버전: FWTK (Firewall Toolkit)

• 축소된 버전 (패킷필터링이나 통계분석이 없는) 을 무료로 얻을 수 있는데 ( www.fwtk.org 또는 ftp://ftp.tis.com/pub/firewalls/toolkit/fwtk.tar.Z 참조, 현재 버전은 V2.1), 이로 인해 오늘날 가장 많이 쓰이는 방화벽이 되었다. 무료 버전을 다운받기 전에, TIS에 등록을 해야 한다.
• 공개 버전은 X11-over-telnet proxy (SSH는 이를 더 잘 수행함) 와 같이 몇몇 상용제품에서 볼 수 없는 기능들을 제공한다.
• Sendmail 로의 접근을 보호하는 smap 유틸리티는 잘 동작하며 이를 추천한다.
• 운영체제를 깨끗하게 해주는 스크립트는 없다. 수작업으로 OS를 최소로 strip 해야 한다.
• FWTK 도 리포팅 도구(ftp-summ.ch, http-summ.sh, tn-gw-summ.sh, weekly-report.sh), portscan 및 netscan 같은 유용한 유틸리티들을 포함하고 있다.

상용 버전 (June 99)

- 패킷 필터는 상태기반이 아니며 확실히 udp 에 문제가 좀 있다.
- GUI 는 F-1 같은 시장 선도자들의 기준에 못미친다. 익숙해져야만 하고 실수가 일어나게 할 수도 있다.
+ GUI 외에 명령줄 도구가 제공된다.
+ TIS 는 trusted UNIX 도 판매하지만, Gauntlet 과 함께 제공되지는 않는다.
+ 상세한 통계 분석을 위한 도구가 제공된다. 

SOCKS 5 (21 Oct.1996)

SOCKS는 클라이언트쪽 어플리케이션에 컴파일되어 방화벽을 통해 동작할 수 있게 하는 범용 프락시 시스템이다. 사용하기 쉽지만, 인증이나 별도 로그 같은 추가적인 지원은 없다.ftp.nec.com/pub/security/socks.csts/socks5/ 를 참조한다. . 넷스케이프의 HTTP 프락시와 자바 애플릿뷰어는 SOCKS를 지원한다. 이것은 이제 IETF 승인을 받은 인터넷 표준이 되었다.

SOCKS의 가장 큰 문제는, 클라이언트가 "SOCKS 화" 되어야 한다는 것이지만, SOCKS화된 클라이언트들이 상당수 있고 몇몇 플랫폼들에는 적합한 라이브러리들도 있다.

다음은 Socks 버전 5 홈페이지 www.socks.nec.com 로부터 추출한 것이다 :

Authenticated firewall traversal (AFT) 이라고도 알려진 SOCKS5 프로토콜은 전송계층에서의 네트웍 프락시 수행에 대한 공개 인터넷 표준(rfc1928)이다. SOCKS5는 SOCKS4에서 충분히 접근하지 않았거나 아예 빼먹은 몇가지 이슈들을 해결하고자 했다 :

강력한 인증
인증 방법 협상
메시지 무결성 및 비밀성
UDP 어플리케이션 지원

두 가지 인증 방법을 지원하기 위한 두 가지의 추가적인 SOCKS5 관련 표준이 있다. 하나는 "SOCKS V5를 위한 Username/Password 인증" (rfc1929) 이고 다른 하나는 "SOCKS V5를 위한 GSS-API 인증" (rfc1961) 이다. 인증을 제공하는 것 이외에도, GSS-API (Generic Security Service Application Programming Interface)는 메시지 무결성과 기밀성도 지원한다.

NEC에서 구할 수 있는 공개 버전은 대부분의 플랫폼에서 쉽게 컴파일되고, ping, ftp, traceroute, telnet 용 프락시를 기본적으로 제공한다. 또한 안전한 터널(VPNs)을 설정하는 데 사용될 수도 있는데, 이 기능은 아직 저자가 테스트 해보지 못했다. SOCKS의 주된 문제는 클라이언트가 SOCKS화 되어야 한다는 것이다. 즉 SOCKS 프락시 서버와 대화하는 법을 알아야 한다. 이 변경은 대부분의 경우 작은 것이지만 컴파일이 필요하다. 그러나 많은 경우 (Winsock, Solaris), 시스템 공유 라이브러리들을 SOCKS aware 라이브러리로 대체하여, 클라이언트가 재컴파일되거나 변경되지 않고도 SOCKS를 사용하도록 할 수 있다!

저자의 경험:

• Solaris에서는 잘 동작하고 이를 추천하지만, Win95/NT에 대해서는 어려움이 발견되었다 (즉 TCP dlls 를 SOCKSified DLLs 로 대체하는데)..
• SSH (on Solaris) 는 SOCKS와 완벽하게 동작한다 (올바른 옵션으로 컴파일되면).
• 권고: SOCKS 서버가 반드시 네트웍 외부에서 클라이언트로의 접근을 거부하도록 구성한다. 잘못 구성된 SOCKS 프락시가 내부로의 프락시 연결을 제공했던 일이 있었다! 

Firewall-1 V3.0 (Jan.1998)

Checkpoint Technologies 개발하고 Sun에서도 재판매하는 이 제품은 상태기반의 패킷필터링 과 프락시 서버를 모두 제공한다. 이것은 가장 인기있는 방화벽 중의 하나다. 성능은 아주 좋고 [dcom] 어떤 이들[nworld]이 가장 좋아하기도 한다. 필터 구성을 위한 좋은 GUI가 있다. 소스코드는 제공되지 않는다. Sun에서 판매하는 버전은 대개 Checkpoint 에서 직접 판매하는 것보다 6개월정도 느리지만, Sun 환경에는 더 잘 통합된다. 추천. www.checkpoint.com 참고.

• 패킷 필터는 OS TCP/IP 드라이버를 직접 걸어 동작한다.
• 가장 기능이 많은 방화벽중의 하나로 NAT, VPNs, stateful inspection, 맞춤 가능한 필터 엔진, 매우 유연한 rule 구성, 시간에 따른 접근통제, 별도의 "시스템 정책/특성", VDOlive, NetMeeting 등 새로운 프로토콜을 위한 필터 엔진, 내용 필터링(바이러스, 애플릿) 등등의 기능을 가진다. 사실 어떤이들에게는 너무 복잡할 수도 있다!
• 가격은 그리 나쁘지 않아, 25 호스트에 대해 $3000 정도로 시작한다.
• 유닉스와 NT에서 운영된다.
• 구성과 모니터링을 고도로 자동화할 수 있다.
• 운영체제를 깨끗하게 해 주는 스크립트는 없다. 수작업으로 OS를 최소한도로 strip 해야 한다.
• 나쁜점:
  • 명령줄이나 GUI를 사용할 수 있으나, 둘다 사용할 수는 없다!
  • GUI는 아주 예쁘지만 매우 불안정해질 수 있다 (core dumps). 
  • Buggy....

Cyberguard Firewall

이 방화벽은 패킷필터 (stateful?) 와 프락시 서버를 모두 가지고 있다. 뛰어난 성능. [dcom]. Harris's Trusted UNIX를 기반으로 한다. Cyberguard는 군수 및 항공산업에서 잘 알려져 있다. NT와 유닉스(SCO)에서 운영된다. 이 방화벽은 아주 좋은 것처럼 보이고 ITSEC의 인증을 받은 유일한 제품인데 (July 1998) 저자는 이 제품에 대한 경험이 없다. 

Norman Firewall (June 1996)

Norman Data Systems 는 또하나의 군수 공급업체로, HP-UX 10.09.01 CMW 또는 Secureware SMP+ 2.4 (an SCO derivative)의 B1 운영체제(TCSEC approved) 를 기반으로 하는 방화벽을 제공한다. 이 방화벽은 몇몇 독특한 기능을 가지고 있다:

• 파일 전송에 대해 자동적으로 바이러스 signature 나 "hot words"를 검색할 수 있다. 전송이 중단되고 파일은 방화벽에 저장되어 관리자가 검사한다.
• B1 레벨 라벨링지원.
• dual-homed, 프락시만 되는 (http, ftp, telnet..) 게이트웨이. 내부와 외부간 직접적인 패킷 필터링은 지원되지 않는다.
  www.norman.com   을 참고..

"black box" firewalls

• Sonic Systems Inc www.sonicsys.com 에서 만든 SonicWALL 은 재미있는 조그만 하드웨어 장치이다. 작고 검은 라우터처럼 생겼는데, 사실은 NAT 와 상태기반 필터링을 하는 작은 방화벽으로 SYN flooding, Ping of death, IP spoofing 도 막을 수 있고 ActiveX, Java 및 cookies 도 걸러낼 수 있다. 웹브라우저를 통해 구성한다. 가격은 ~$3000.
• GNAT Box www.gnatbox.com 는 PC 기반의 하드웨어 솔루션으로 유닉스나 Win95/NT 에서 원격으로 제어할 수 있고 신형 방화벽에서 필요로하는 기능들 중 많은 것을 제공하는 것 같다. 필터링은 상태기반인 것 같지는 않다.
  축소된 무료 버전인 GNAT Box light 도 있는데, 소수 사용자용으로만 쓸 수 있다.

윈도우 NT/2000 프락시

여기 짧은 목록이 있는데, 아직 완성을 해야 한다...

• AnalogX proxy (무료). AnalogX Proxy 는 로컬 네트웍에 있는 어떤 다른 시스템이라도 중앙의 시스템을 통해 요청을 발송할 수 있게 해주는 작고 간단한 서버이다. 이게 무슨 얘기인가? 간단하다, 인터넷에 연결된 시스템에 Proxy를 운영한다; 다른 시스템들은 프락시를 사용하도록 구성한다 (아주 쉽다, readme 에 자세한 설명이 있다), 그러면 됐다! 이제 당신의 네트웍 상에 있는 어떤 다른 시스템에서라도 웹을 서핑할 수 있다! HTTP (web), HTTPS (secure web), POP3 (메일수신), SMTP (메일발신), NNTP (newsgroups), FTP (파일전송), 그리고 Socks4/4a 및 일부l Socks5 (no UDP) 프로토콜을 지원한다! It works great with Internet Explorer, Netscape, AOL, AOL Instant Messenger, Microsoft Messenger, 그리고 또 많은 것들과 훌륭하게 동작한다!
• Microsoft Proxy
• Mail Essentials
•  

HTTP 프락시

HTTP 에서는, 캐싱기능이 있는 프락시가 성능을 현저히 올려준다.

• 가장 인기있는 웹서버인 Apache ( www.apache.org) 는 언제나 볼만한 가치가 있다.
• W3C HTTP 캐싱 프락시는 성능이 좋은 것으로 알려져 있지만, ftp 프락시에는 좀 문제가 있는 것처럼 보인다.www.w3c.org 참고. 명령줄 인터페이스로 인해 어떤 이들은 구성하기 어려워한다.
• (상용) Netscape proxy 는 잘 알려져있고, 조금 비싸지만, 잘 동작하는 것 같고 구성을 위한 HTML GUI 인터페이스를 가지고 있으며, SSL과 HTTPS 도 지원한다. GUI 구성 인터페이스는 URL과 관리자 패스워드로 접근한다 - 따라서 좋은 패스워드를 선택하도록 주의해야 한다! Admin URL에는 접근을 제한할 것을 권고한다 ( obj.conf 참조). 관리자 이름 & (암호화된) 패스워드가 파일로 저장되므로(admpw), 이 파일은 Netscape가 돌아가는 사용자(e.g. http)나 root 만 읽기/쓰기 가능하도록 주의해야 한다. Netscape가 돌아가는 사용자는 안전한 계정을 가지도록 (read 가 안전하게 구성되고 될 수 있으면 차단되도록) 유의한다. 암호화된 패스워드가 파일에서 삭제되면, 더이상 패스워드는 없는 것이다.
• FWTK http 프락시는 캐싱이 없고 안정성에 좀 문제가 있다. 안정성 문제는 (분명히) 상용버전에서 다루어졌다.
• Microsoft 프락시 (NT에서만 운영됨) 는 흥미롭지만 Netscape 처럼 기능이 풍부하지 않고 대규모 사이트에서는 사용하기 힘들다. 그러나 NetMeeting 같은 어려운 프로토콜을 프락시할 수 있게 해준다. 

내용 필터

방화벽을 통해 흐르는 정보의 분석과 내용에 따른 제한은 정보 보호 정책을 구현하는데 도움이 될 수 있다. 내용필터 제품에 대해 논의한 기사가 SC magazine (www.westcoast.com) 1998년 8월호 50페이지에 있다.

대부분의 상용 방화벽들은 내용필터링을 제공하거나, 내용 필터링을 이들의 프락시에 붙일 수 있는 연결고리를 제공한다. 뿐만아니라 침입탐지를 위한 몇몇 트래픽 모니터링 도구들도 일종의 내용 필터링을 한다.

• Content Technologies (www.mimesweeper.com 또는 www.contentsecurity.com) 의 MIMEsweeper 와 WEBsweeper는 아마 가장 잘알려진 필터들 중의 하나일 것이다. 이들은 전용 NT 박스위에서 운영되고, 각각 메일 게이트웨이와 http 프락시로 방화벽 안 또는 앞에 설치된다. 가격은 100 사용자에 ~$3000 정도. 1998년 말, Secretsweeper 가 발표되었는데 이것은 Secrets for Windows 로 암호화된 첨부파일의 검사를 가능하게 해준다. S/MIME 으로 암호화된 첨부파일을 검사하는 비슷한 제품도 확실히 있다.
• AbirNet Inc.  www.abirnet.com 의 SessionWall-3 은, 가격이 ~$1600 정도로, 어떤 시간대에 다운로드할 수 있는 파일크기까지 포함하는 - 피크시간대의 네트웍 부하 감소에 도움이 됨 - 상세 정보 정책을 설정하는 데 사용될 수 있다.
• Tenfour www.tenfour.com의 TFS Gateway 는 NT 용 메일 게이트웨이를 제공하는데 스팸 필터링, 바이러스 스캐닝 (3rd party), 암호화 (with PGP) 및 메시지 추적 등 다양한 기능을 가진다. 중소규모의 조직을 위해 설계되었다. 가격은 ~$600 정도.
• Finjan www.finjan.com  필터는 자바 프로그램/애플릿에 대한 미세 필터링에 있어서 독자적이다.
• Checkpoint 는 보안 제품들이 서로 통합될 수 있도록 하는 공개 OPSEC 표준(www.opsec.com 참고) 을 정의했다. 현재는 내용 분석, 인증, 침입탐지, 이벤트 분석 및 가용성 분야에서 Firewall-1에 깔끔하게 통합되는 몇 가지 third party 제품들이 있다.
  F-1을 사용하고 있다면 확실히 흥미로운 일이다....
• PGP Policy Management Agent for SMTP 는 이메일 게이트웨이와 함께 동작하여, 게이트웨이를 통과하는 PGP 포함 이메일 메시지가 정책을 준수하도록 확인한다. See also
  기능: 암호화된 메시지들 중, 회사의 메시지 복구 키중 한 가지 이상으로 또한 암호화되지 않은 것은 모두 거부한다. 메시지에 대한 전자서명의 사용을 허용, 거부, 또는 요구한다. 모든 이메일과 첨부파일들이 정책 요구사항을 통과하기 전에 암호화되어야 할 것인지 아닌지를 결정한다. 재래식 암호화로만 암호화된 모든 메시지를 거부할 수 있게 해준다. 재래식 (대칭형으로도 알려진) 암호화는 수신자가 발신자와 동일한 passphrase를 사용해야 한다. 특정 키로의 암호화 사용을 허용하지 않는다, 특정 IP 주소나 도메인에 적용되는 정책의 검사를 제한한다. www.pgpinternational.com/product/pol-man.html
  정책은 전체 도메인, 네트웍, 네트웍, 서브넷, 또는 IP 주소를 대상으로 할 수 있다.
• 일반적인 내용 검사 API (www.news.com/News/Item/0,4,26737,00.html?owv 참조):
  • API는 일차적으로 안티바이러스, 또는 악성 자바 애플릿/ActiveX control 을 차단하기 위한 "내용 검열" 소프트웨어들이 방화벽, 라우터, 프락시 서버, 캐싱 장비 --회사 네트웍의 가장자리에 위치하는 소위 "perimeter" 제품--들과 동작할 수 있게 하기 위해 설계되었다.
  • 이러한 노력은 Stardust 와 Finjan에서 출발했는데, 이들의 소프트웨어는 악성 애플릿을 차단하는 것이다. 이의 범위와 목표에 대한 초안은, 1998년 10월 15일에 나오기로 되어 있는데, Finjan, 방화벽 선두주자 Check Point, 안티바이러스 벤더인 Symantec, 그리고 VPN 회사인 Aventail의 대표들에 의해 쓰여지고 있다.
  • Check Point의 영업개발 이사인 Bradley Brown은, 이 새로운 노력이 이미 내용검열 소프트웨어 벤더들 사이에서는 널리 채택된 CVP "content vector protocol" 의 후계자가 될 수 있을 것이라고 말했다.

로그 분석

방화벽과 syslog 로그를 분석하여 공격, 예외적인 행위 또는 통계를 알아내는 방법을 찾기란 쉽지 않다. 대부분의 상용 방화벽은 어떤 종류의 로그 브라우저를 제공하고 있지만, 대개 매우 원시적이다.

• 가능하다면 GUI와 명령중 로그 브라우저를 모두 가지고 있는 방화벽을 도입한다. 전자는 시스템을 빨리 배우는데 도움이 될 것이고, 후자는 자동화된 로그 분석을 위한 (펄) 스크립트를 만들 수 있게 해준다.
• 로그는 정기적으로 예외적인 엔트리들이 있는지 검사해야 한다. 가능하다면 로그를 중앙화하여 write-once 매체에 기록한다. 방화벽 필터: fail rules 사용, 잘못된/spoofed IP 패킷, 트래픽/서비스/사용자/아이템 기반의 사용.

일반적인 로그 분석 도구 : 다음과 같은 방법으로 자동화된 로그 분석과 알람을 수행할 수 있다:

• DIY (Do It Yourself):
  • 예외적인 것들에 대해서만 간결한 보고서를 원한다면, 독자적인 스크립트를 작성하여, 이상이 없다고 알고 있는 것은 버리고, 정상적인 사용에 대한 통계를 계산하여 나머지 (예외라고 가정되는) 엔트리를 보고하도록 해야 한다. 이 방법은 또한 시스템 문제가 빨리 탐지되도록 해준다.
  • 여러 대의 시스템에 대해 수행해야 한다면, SSH를 사용하거나 로그 분석을 돌려 결과를 중앙 콘솔로 전달하는 클라이언트/서버 소켓 프로그램을 작성한다.
  • 펄은 매우 강력하고, 대부분의 시스템에서 동작하므로 가장 선호되는 도구이며, NT 이벤트로그, WWW 로그, 유닉스 (syslog) 로그를 분석하기 위한, 그리고 클라이언트.서버 소켓을 쉽게 작성하기 위한 펄 모듈이 있다....
  • 펄이 어렵다고 생각되면 grep, sort & cut 등을 써본다.
  • 방화벽 필터에 대해 체크해야 할 것들: fail rules 사용, 잘못된/spoofed IP 패킷, 트래픽/서비스/사용자/아이템 기반의 사용.
• 많은 시스템들에서 "디폴트" 도구들이 제공된다. 신규 시스템을 구입할 때, GUI 와 명령줄 로그 브라우저가 포함되어 있는지 확인한다.
  예: F-1 (fw log 와 fw logexport 및 GUI broswer), Sunscreen log browser/command line, NT event viewer & resource kit tools, etc.
• IP 필터의 저자인 Darren Reed는 1999년 6월에 Nsyslog를 발표했는데, TCP 연결을 지원하고 SSL과 함께 사용하면 syslog 메시지의 전달을 암호화할 수 있는 syslog 제공 도구이다. 흥미로워 보이지만, 아직 테스트하지는 못했다. coombs.anu.edu.au/~avalon/nsyslog.html
  
• Webtrends for Firewalls V1.1 www.webtrends.com 
  판정: 동작시킬수가 없었음!
  • F-1 (OPSEC 또는 exported logs를 통해), Raptor, Gauntlet UNIX/NT, Cisco PIX, Lucent, Secure Computing, AltaVista 로그를 분석할 수 있다. 그러나 이들 파일에 직접적인 접속이 필요하다.
  • 들어오고 나가는 웹 요청을 분석할 수 있다.
  • 불어,독어 또는 영어로 보고할 수 있고 이메일,ftp 또는 실시간 HTML 파일로 보고서를 낼 수 있다.
  • 보고서 양식은 워드, 엑셀 CSV, ASCII 또는 HTML 이다. 보고서 레이아웃과 내용을 customise 할 수 있다.
  • NT 에서 운영되고 (선택적으로 서비스로) 친근한 GUI를 가지고 있다.
  • *지나치게* 비싸지는 않다. $999 .

  단점:

  • 동작시킬수가 없었다 (F-1 exported logs로).
  • 유닉스에는 GUI가 없다?

• Axent Omniguard ITA (Intruder Alert) 는 일련의 민감한 호스트들에 대해 로그를 수집하고 변경사항을 감시하여, 이벤트에 대응하고 대응을 중앙화하는 시스템이다.
  가격: 1-25 유닛: Manager CHF 7500.-, Server Agent: 3700.-, Workstation Agent:1500.-.
  판정: ITA 는 민감한 환경에서는 잠재력이 있으나. 설정하기가 어렵고 비싸다. Solaris 를 위한 디폴트 구성은 그리 좋지 못하다.
  ITA 가 중요한 문제들만 보고하고 이 문제들을 상세히 보고하도록 하는 게 쉽지 않다.
  
  테스트 시스템: NT4 & Solaris 2.6 에이전트, 콘솔 NT4. Oct'98 에 V3.0 테스트. CD 에 따르면 V3.0 SR2 / 16.6.98 이었지만, about 박스에는 V3.0,/12.12.97 라고 나와있었음.
  
  개요:
  • ITA 는 두가지 주요 기능을 가지고 있다:
    1. 여러 대의 시스템들에 있는 로그를 네트웍을 통해 수집하여 중앙에서 분석하고, 필요하면 경고를 발생하고 행동을 취할 수 있다.
       유닉스에서는, syslog, utmp 그리고 선택적으로 C2 및 btmp 로그들이 검사된다. 추가적인 ASCII 로그도 구성할 수 있다.
       NT에서는, 시스템, 어플리케이션 및 보안 이벤트 로그가 검사된다.
    2. Byte Rotary, Word Rotary 체크섬 및 MD5 해쉬를 사용하여 특정 파일 목록에 대한 무결성을 정기적인 간격으로 체크할 수 있다. Solaris 에서의 디폴트 설치에는 간단한 일반적인 목록이 포함되어 있다 (왜 목록에 /etc/shadow 나 /etc/default 가 없을까? /etc/passwd 는 두개가 있고 /etc/inetd.conf 는 철자가 틀렸다).
       /omniguard/ita/system/THIS_HOSTNAME/ita.ini 도 참고한다.
       Note: 체크섬은 절대 사용하지 않도록 한다, 속이기가 너무 쉽다. 해쉬 (MD5, SHA-1) 같은 강력한 단방향 함수만 사용해야 한다.
  • ITA "에이전트" 는 감시되는 각 호스트에 설치된다. 에이전트는 이벤트를 점검하는 "매니저" 와 통신한다. 메인 GUI 는 "Admin" 호스트 상에서 돌아가고, 하나 이상의 "매니저" 에 연결하여 매니저와 그 에이전트들을 디스플레이/구성할 수 있다.
  • 로그에서 어떤 expression 들을 감시/무시하고 (Rule Select/Ignore Clauses 라고 함) 해당되는 조치를 취할 것인지 (Rule Action Clause 라고 함)를 약정하는 정책들이 정의된다. ITA 에서 디폴트 정책을 제공하는데, 이것을 복사해서 적합하게 고치든지 새로운 정책을 추가할 수 있다.
    • Rules 는 경고 레벨을 가지고 있다: Green, Yellow 또는 Red (rule value 라고 함).
    • Select/Ignore clauses는 로그 엔트리와 매치시키기 위한 expression 에서 * (임의 갯수의 문자) 와 ? (한 문자) 의 사용을 허용한다.
    • 다른 select 옵션들: 특정 사용자나 시스템에서 발생된 이벤트, ITA 클라이언트 명령어/메시지/에러, 다른 이벤트가 일으킨 플래그, 특정 날짜/시간 간격 & 주기 [이건 인터페이스가 약간 조잡함] 와 타이머 (이건 이해가 안됨).
    • Actions 는 다양할 수 있다: 로컬이나 원격 로그에 메시지 쓰기, SMTP 이메일 보내기, 사용자에게 "윈도우 알림" 보내기, 호출하기 (모뎀을 통해), 프로세스 종료하기 (유닉스에서 PID 를 알 수 있거나 NT에서 사용자이름을 알 수 있을 때 - 그 사용자의 모든 프로세스들이 종료됨), 세션을 끊기 ( 유닉스 로그에서 세션 ID나 NT에서 사용자이름을 알 수 있다면), 특정 시간동안 플래그 올리기/취소하기, 타이머 시작/취소하기, (사용자 정의) 스크립트/명령어 실행, ITA 데이타베이스에 이벤트 기록하기, (admin 이 아닌) 사용자 계정(로그에서 사용자이름을 알 수 있을 때)을 사용금지 시키기.
    • 여러 개의 규칙들 간에 action을 공유할 수 있도록 Shared Actions 를 정의할 수 있다.
  • Solaris 에서는 특정한 syslog 엔트리들만이 디폴트로 감시된다. 다음 엔트리들이 설치시 /etc/syslog.conf 에 추가된다:
        *.info;mail.err;mark.none /omniguard/ita/system/THIS_HOSTNAME/syslog
         mail.debug /omniguard/ita/system/THIS_HOSTNAME/syslog.mdbg
    
    /omniguard/ita/bin/itarc 스크립트를 수정하여 ITA_EXTRA_FILES 에 감시할 로그 목록이 포함되도록 해야 한다. e.g.
              solaris-sparc)
                  ITA_EXTRA_FILES='/var/adm/sulog,/var/adm/loginlog'
              ;;
  • ESM 로그는 자동적으로 감시된다.
  • ITA에는 책임의 분담을 허용하기 위해 서로 다른 권한을 가지는 다양한 사용자들이 구성될 수 있다. 권한: ITA 구성 보기, 정책 & 도메인 변경, 이벤트 보기, 매니저 구성 변경, 에이전트 구성 변경, 새로운 에이전트 등록, 사용자 계정 정보.
  • ITA View 는 과거 및 실시간 이벤트에 대한 질의를 할 수 있게 해주는 도구이다. 데이타는 그래픽 또는 표 형식으로 나타날 수 있다.
    • 미리 정의된 일반 views : FYI/Text, Moderate Concern/graph, Moderate Concern/text, Emergency/graph, Emergency/text.
    • 이벤트는 변수(사용자, 시스템, 규칙, 정책, 값, 텍스트 및 사용자 정의 변수)에 대한 수작업 질의 뿐 아니라 정책 및 에이전트에 의해 선택될 수도 있다. 사용자 변수들은 새로운 로그들과 이들의 형식을 규정할 때 정의되는 변수들이다 (에이전트에서 오른쪽 클릭하고 properties 를 선택해서 이 로그들이 어떻게 추가되는 지 본다).
  • ITA 사용자들이 최근의 공격들과 이들의 탐지 방법에 대해 최신의 정보를 유지 하도록 도와줄 수 있는, Axent 보안 전문가들이 운영하는 웹사이트가 있다 (www.axent.com/swat/swat.htm). 이것은 어쩌면 대단한 서비스이다.
    • po 부분: SR2 release (1998년 6월) 이후로 NT나 유닉스 정책 모두 바뀌지 않았다.
    • 공격 시그너쳐 부분: 최근의 공격들과 이들을 인지하는 방법을 설명한다. 각 공격에 대해 signature ID 가 제공되지만, 패스워드로 보호되어있다. 아마 Axent 유지보수 계약이 되어 있으면 이들 공격을 탐지할 수 있는 정책들을 다운로드 할 수 있을 것이다.
    • 보안 작업 부분: 사용자 로그온 같은 정보를 수집하기 위한 FYI 정책을 제공한다.
    • 위협 부분: 관리자 로그온 같은 위협에 대응하는 정책들을 제공한다. 정책이 별로 없고 유닉스 상의 FTP root 로그인에 한정된다.
    • 통합 부분: 다른 어플리케이션/제품들에서 발생한 이벤트들을 감시하는 정책을 제공. 목록이 매우 짧다.
    • 데모 부분은 ITA와 함께 동작하는 몇몇 공격 데모들을 포함하고 있다.
    • "hack stories"에는 하나만 있다.
    • 해커 및 보안 사이트들로의 링크는 유용하다.

  장점:

  • 다양한 시스템들의 로그를 하나의 중앙 view로 통합하기 위한 프레임웍으로서 괜찮아 보인다.
  • 클라이언트/서버 구조, 많은 운영체제 지원. 유용한 GUI.
  • 정책이 ASCII 파일로/부터 export/import 될 수 있다.

  단점:

  • 복잡한 시스템. 설정이 장난 아님. 온라인 도움말이 별로 자세하지 않고 문맥이 잘 안통한다.
  • NT: 중요한 레지스트리 키들에 대한 변경을 감시하기 위한 정책이 없다.
  • UNIX: SSH 연결을 감시하기 위한 정책이 포함되지 않음.
  • 유닉스에서 이진(binary) 로그를 감시할 수 없다.
  • Select/Ignore clauses 에서 사용되는 expression들은 매우 한정되어 있고 Perl, Awk 또는 egrep 같은 전형적인 정규 expression 엔진의 힘에 미치지 못한다. 이로 인해 clause 작성이 더 조잡해지고 시간이 걸린다.
  • 명령중 인터페이스가 없다.
  • NT 상에서 표준 위치에 설치되지 않는다 (Program Files 대신 /omniguard 에 설치).
  • Post-install 스크립트는 매니저의 중지 & 시작을 허용한다. 또 NT 상의 매니저에 에이전트 등록/취소를 허용하지만 Solaris 에서는 아니다 (왜?).
  • ITA Admin은 모든 에이전트 연결을 테스트하고 상태를 보고하는 옵션이 없다.
  • 정책 라이브러리에 있는 항목들에 대한 변경은 "적용된" 정책에 반영되지 않는다. 라이브러리에서 삭제 후 다시 추가해야 한다.
  • 심각: Rule을 시작하는 로그 엔트리가 action에 복사되지 않는다. 즉 action 이 만약 사용자에게 알리고, 로그에 쓰거나 ITA view에 쓰는 것이라면, 이벤트 이름/시간/심각도는 보고되지만 실제 로그 엔트리는 보고되지 않는다. 이상한 일이다. 뭔가 조치가 이루어져야 할 것 같다 ?
  • 문제점:
    • NT 시스템 dll 시간이 변경된 것으로 보고되었는데, 정확하게 한시간 틀렸다. 아마 ITA 가 시간 문제를 가지고 있는 게 아닐까? 테스트는 GMT 에서 수행되었다.
    • 로그가 계속 이름이 변하는 경우 어떻게 감시할 수 있는가? 어떤 로그 이름들은 현재 날짜를 포함하고 매일 아침 새롭게 생성된다 (e.g. MS HTTP proxy).
    • 새로운 정책이 생성되고 아무 변경 없이 삭제되었을 때 ITA Admin 이 다운됐다.
    • ITA view 는 로컬호스트레서 FYIT generic view 를 로드할 때 다운됐다.
    • SYN flooding 정책은 얼마만큼의 시간범위동안 얼마나 많은 TCP 연결을 허용할 지 설정할 수 없게 되어 있다. 따라서 많이 사용되는 서버에서는 중단될 수도 있다.

  권고사항:

  • ITA 로부터 최상의 효과를 얻으려면: 테스트하고 이해한다. ITA가 무엇을 어떻게 하길 바라는지 신중히 결정한다. 어떤 시스템 관리자들이 어떤 책임을 가질 것인가? 파일럿 테스트를 한다. Axent ITA 과정을 듣는다. 최종 설치를 계획한다.
  • Admin 용으로는 빠른 시스템이 필요하다.
  • /omniguard/ita/system/THIS_HOSTNAME/agent.log 그리고 manager.log 를 검사하여 에이전트가 여러가지 로그에 연결할 수 있었는지 확인하고 매니저가 제대로 시작되었는지 확인한다.
  • 방화벽에 사용될 때는, 에이전트 & 매니저 사이에 특정 소켓이 열려야 할 것이다 (디폴트로 에이전트->매니저는 5051 그리고 매니저->에이전트는 5052). ITA view 를 위한 포트 번호는 변경될 수 있다. 클라이언트 통신을 위한 동적 포트가 매니저에 할당도리 수도 있다. 사용되는 동적 포트의 범위는 ITA.INI 의 [Manager] 부분에서 구성할 수 있다. 따라서 매니저가 방화벽의 한쪽에 있고 에이전트가 다른 쪽에 있다고 가정할 때:
    • 에이전트에서 매니저로 5051 포트 허용.
    • 클라이언트 연결을 위한 범위를 선택하여 ITA.INI 에 넣고 방화벽이 이 포트들을 매니저에서 클라이언트로 통과시키게 한다.
  • 매니저는 매우 안전한 시스템이어야 한다, 적어도 가장 강력한 에이전트만큼은 보호되어야 한다 (공격당했을 경우 trust 오용을 방지하기 위해).
  • 에이전트의 CPU 와 네트웍에 과도하게 부하를 주지 않도록 조심한다. ITA의 (유용한) "throtteling" 기능을 사용하여 네트웍 대역폭을 제한한다.
• CyberCop Server 는 Network Associates( www.nai.com )의 제품으로 Axent ITA 에 상당하는 제품이다 (위).
  www.nai.com/products/security/cybercopsvr/index.asp 를 참고.
  Solaris 버전을 다운로드할 수 없다 (하지만 분명히 Solari 에서 사용 가능하다).
  Tivoli 나 Cisco PIX 로 통지할 수 있다.
  테스트 환경: NT SP3, 1.01 demo 설치(dated 16.3.98). Uninstall 이 없음! 30분 후 NT가 다운. 시스템으로부터 제거.
  판정: 테스트 중단? (너무 베타웨어적인 것 같다).

개인 방화벽 / 침입탐지 시스템

이 절은 새로운, 다른 기사로 다시 썼다. 개인 방화벽 기사를 한 번 보기 바란다.

방화벽 침투 테스팅

방화벽 침투 테스팅은 실제 보안 수준을 기대 수준에 비교할 수 있게 해준다. 여기 침투방법/이슈에 대한 간단한 개요를 설명한다. 이 자료가 실제 다른 방화벽을 공격하는 데 실제로 사용될 수 있으므로, 비교적 잘 알려진 취약점들만 설명하여, 해커들에게 동기를 부여하지 않도록 했다 (그러길 바란다!). 아래에서 언급되는 준비 단계는 신중하게 실행하고, 결과를 어느정도 왜곡할 가능성이 있더라도, 방화벽 관리자들이 곧 있을 침투 테스팅에 대해 알고 있도록 할 것을 강력히 권고한다.

준비
경영진의 승인을 받아, 다음을 포함하는 테스트 계획을 준비한다:

• 목표, e.g.:
  • 정책의 이행을 테스트한다 (취약점, 에러 보고)
  • 방화벽 정책의 효과를 테스트한다 (정책이 타당한가?)
  • 조직적 유효성/반응을 테스트
• 범위: 무엇을 테스트하고 특히 무엇을 테스트하지 않을 것인가: e.g.,
  • 다른 네트웍 진입 지점/원격 접속(모뎀) 시스템(wardialers)과 같은 우회 가능성
  • 방화벽 서비스/운영체제/구성의 취약점
  • 로깅 레벨 & 분석.
  • 관리자는 침입을 알아채는가, 그리고 어떻게 대응하는가? 침입 탐지 정책이 있으며 지켜지고 있는가?
• 테스팅은 어느정도까지 갈 수 있는가?
  • 방화벽 작용이 붕괴되어도 되는지 안되는지(즉 공격의 강도) 그리고 공격이 내부와 외부 모두로부터 허용되는지.
  • 서비스 거부 공격이 허용되는지 (있을법하지 않은).
  • 사회 공학적 공격이 허용되는지.
  • 방화벽 관리자가 사전에 통보받아야 하는지 (권고 IMHO, 단 몇시간 전에라도). 이것은 경영진의 승인이 필요한 중요한 결정이다.
  • 소스코드를 검사할 것인지.
  • 라우터, 브리지, 배선을 검사할 것인지.
• 마감 기한, 비용, 산출물(보고서)과 책임에 대한 기술.
• 계획에 서명을 받고, 특정한 날에 테스트를 시작할 것을 허락받는다.

테스트 단계 1: 간접적인 정보수집
이 단계에서는, 방화벽은 접근하지 않으며, 따라서 공격 시도는 탐지되지 않는다.

• DNS 를 이용하여 (e.g. nslookup/dig, whois, ARIN) 그 네트웍에 대해 어떤 정보들이 알려지는지 알아보고, 그려본다.
• 공개 아카이브 (인터넷)을 검색하여 이 도메인의 종업원들로부터 게시된 것들을 찾아본다. (security, UNIX 및 NT 뉴스그룹, 이메일-리스트 아카이브 등등).
• 대상의 인터넷 WWW, ftp 서버에 대한 정보를 조사한다. 회사에 대한 정보를 제공할 수 있는 사이트들을 조사한다 (e.g. SEC).
• 방화벽에서 어떤 종류의 제품을 쓰는지 이미 명백하다면, 벤더 정보를 알아내어 인터넷 (또는 다른 소스)에서 이 제품들의 취약점과 관련된 정보들을 찾는다.

테스트 단계 2: 직접적인 정보수집
이제는 방화벽 관리자가 우리를 탐지할 수 있지만, 방화벽의 파괴는 일어나지 않는다.

• 이메일 게이트웨이의 제품 이름과 버전을 확인한다.
• 되돌아오는 이메일 헤더를 확인하여 (존재하지 않는 사용자에게 이메일을 보내본다), 내부 시스템의 이름/구조가 나타나는지 본다.
• 주소 공간을 스캔하여 (부드럽게, 즉 ping으로) 사용가능한 호스트를 찾거나, 또는 stealth scan 을 한다, 즉 TCP FIN 패킷을 보내 RST가 돌아오는지 기다림으로써 (그러면 서비스가 없는 것임) 사용되는 포트를 확인만 하는 도구를 사용한다. 가령 nmap 을 사용한다.
• 전화회선을 스캔하여 모뎀을 찾는다 (e.g. ToneLoc, PhoneSweep 또는 THC 으로)