1. 서 론

20세기 중반 이후로 통신망 기술, 교환 기술, 전송 기술의 통신 기술과 고성능 및 지능형 컴퓨터 기술, 소프트웨어 기술 그리고 단말 기술의 급격한 발달로 정보통신 발전에 지대한 영향을 주었고, 세계 각국은 자국의 미래 정보통신의 사활이 초고속통신망 구축에 달려 있음을 인식하고 통신망 구축에 박차를 가하고 있다.

국내도 마찬가지로 국가의 정보통신 사활이 이에 있음을 인식하고 정부 주도하에 초고속통신망 구축을 진행중에 있으며, 현재 일부 지역에 초고속통신망 시범 서비스를 실시하고 있다. 또한 앞으로의 각국은 정보통신의 발전이 초고속통신망 구축과 더불어 인터넷으로의 발전을 예상하고 있으며, 세계 각국은 인터넷의 접속을 통하여 각종 최신의 정보를 수집하고, 서로 정보를 교환하고 있다. 이러한 통신망으로의 발전에 힘입어 사용자들은 음성 및 비음성 등의 다양한 멀티미디어 정보 획득과 유통에 상당한 편익을 누리는 반면에 이의 역기능인 내부 네트워크의 자원 및 정보에 대한 해커들의 불법 침입 및 위협이 날로 증가하고 있다.

인터넷에 연결하여 사용하는 내부 네트워크의 자원 및 중요한 정보등을 해커로부터 보호하기 위해 방화벽 시스템에 대한 연구가 국내외에서 활발히 진행되고 있으며, 많은 상용 제품들이 시판되고 있다. 따라서 인터넷 등과 같은 외부 네트워크에 연결된 내부 네트워크를 보호하기 위해서는 네트워크를 연결해주는 장치에서 입출력되는 패킷을 분석하여 패킷 트래픽을 제어 및 차단하는 방화벽 시스템을 사용하면 네트워크를 보다 안전하게 보호할 수 있다.

지금부터 얘기 할 내용은 제 2장에서 인터넷 환경 하에서의 전반적인 보안문제를 설명하고 제 3장에서는 방화벽 시스템에 대한 일반적인 개요 및 방화벽 시스템 설계 시 고려되어야 할 사항에 대해 설명하고, 제4장은 방화벽의 종류에대해서 설명하고, 마지막으로 제 5장에서 결론을 맺는다. 그리고 APPENDIX에서는 최근 가장 큰 Hacking의 주류로 떠오르고 있는 IP Spoofing과 SYN Flooding Atack에 대한 전반적인 설명과 그 대응책에 대해 간단히 설명하고 마지막으로 Fwalls-FAQ@iwi.com 의 Marcus J. Ranum 이 관리하는 FIREWALL FAQ를 번역한 자료를 첨부 한다.

2. 인터넷 보안

1) 자원보호

• 망보안(Network Security)

■ 정보 보안(Information Security)

Security

- 데이터 무결성(integrity)

- 인증되지 않은 접근 방지

- Spoofing(속임 예:IP Spoofing)또는 도청(Audit)방지

- 서비스를 혼란 시키는 것을 방지

• 보안에 대한 절대적인 대책은 없다. 다만 범죄를 더욱 어렵게 함으로써 범죄 발생을 억제하거나 저하시키는 방향으로의 대책이 최선의 대책이다.

Requirement for Security

가) 물리적인 보안

컴퓨터, 자기테이프,디스크외에 네트웍 환경에서의 물리적 보안으로는 네트웍의 하부구조를 구성하는 케이블, 브릿지,라우터들에 적용된다. 실상 물리적 보안은 방화벽을 구성하고 보다 안전하게 유지 하는 것 보다 더 중요할 수 있다. (예: 라우터의 라우팅 테이블의변조 및 조정 또는 랜케이블의 도청)

나) 추상적 자원의 보호

물리적 자원의 보호보다 더 어렵다.

- 데이터 무결성(Data integrity) : 정보를 인증되지 않은 변경으로부터 보호 하는 것

- 데이터 가용성(Data Availability): 외부 사용자가 네트웍 트래픽을 포화시킴으로써 합법적인 데이터 접근을 방해할 수 없도록 보장

- Privacy의 보장 : 인증되지 않은 청취로 부터의 보호

(예)

① ACDC( image viewer)프로그램의 삭제 - 멋진 그림들을 더 이상 불 수 없음 -> 정보 보안의 차원에서 보면 데이터 가용성의 침해 또는 웹서버에 엄청난 양의 네트웍 트래픽을 부과하여 다른 사용자들의 접근이 불가능하게 함(Overflow) -> 정보 보안의 차원에서 보면 데이터 가용성의 침해

② 순이가 철수에게 "나 너 사랑해 !" 라는 내용의 전자메일을 보냄 --> 순돌이가 이를 중간에서 Hijacking 하여 "난 순돌이를 더 사랑해 !" 라고 순이의 메일을 변조해서 철수에게 보냄 --> 철수와 순이의 관계는 그날로 종지부를 찍게됨 : 데이터 무결성(Data integrity)이 침해 받은 사례

③ 용길이가 성민이의 나우누리 패스워드를 알아내고 나우누리에 접속해 야한 글을 공공 게시판에 올려놓음 : 성민이의 프라이버시가 침해당함

2) 정보 정책의 필요성

네트웍 보안 이전에 실시해야 할 일

가) 해당 네트웍의 위험 요소를 평가

나) 정보 접근과 방어에 관한 정책을 개발

어떤 보안 방식에 있어서도 인간은 일반적으로 가장 취약한 부분이다. 악의가 있거나 부주의하거나 조직의 정보 정책을 알지 못하는 고용자가 가장 뛰어난 보안을 손상 시킬 수 있다. 결국 보안의 완결은 보안 및 보안 정책에 대한 지속적인 교육과 의식화가 반드시 필요하다.

3) 인터넷에서의 보안문제

인터넷에서의 보안 문제는 첫째, TCP/IP 자체가 보안에 대해 취약하기 때문(즉 보안을 고려해 프로토콜이 디자인되지 못했다.) 둘째, 인터넷이 라우터들의 집합이기 때문에 데이터 전송시 송신측과 수신측 이외에 데이터를 라우팅하는 다른 조직들의 라우터에 의존해서 데이터가 전달되며 각각의 라우터에 대한 제어를 송/수신측에서 관리 할 수 없기 때문에 발생한다.

4) 인터넷 보안 기법

1. 권한(Authorization), 인증(Authentication), 무결성(Integrity) Authentication mechanism : 신원(신분) 확인에 대한 문제

-User Authentication 예) Nownuri login : peter password: *********

-IP Source Authentication : IP Spoofing을 통해 특정 네트웍에 인증된 IP로 Spoofing하여 접근 가능 - 결국 IP Source Authentication은 불완전한 인증 메카니즘 - 상호인증(Mutual Authentication) Source와 Destination을 서로 확인하기 위한 메카니즘으로 Public key encryption system을 사용한다. 서로 연결을 원하는 상대방은 메시지를 암호화(Encryption) 하고 해독하는데 사용하는 두 개의 키를 할당 받아야 한다 (비대칭 알고리즘).

상대방은 자신의 공중키(Public key)를 공중키 데이터 베이스에 등록 공고하고 데이터 암호화를 위한 비밀키는 보관한다.

비밀키에 의해 암호화된 데이터는 암호화된 비밀키에 합당한 공중키로 해독된다. 예를들어 A라는 사람과 B라는 사람은 서로 통신하기 이전에 공중 키 데이터 베이스에 각각 자신의 공중키를 등록 공고한다.

A라는 사람은 자신의 비밀 키를 이용해 데이터를 암호화해서 B에게 전자메일을 통해 전송한다. B라는 사람은 공 중키 데이터 베이스로부터 A의 공중키를 얻어은 후 이를 이용해 A로부터 전송된 암 호화된 데이터를 해독한다. 암호화된 데이터가 A의 공중키로 해독된다면 해당 데이터 는 A로부터 전송된 데이터가 확실함을 확인할 수 있다. 만약 A의 비밀키가 알려진다면 물론 상호인증에 대한 신뢰성에 피해가 예상된다. 그러나 현재로써는 최상의 암호화 메카니즘으로 PGP(Pretty Good Privacy)라는 알고리즘이 대표적인 공중키 암호 화 시스템으로 평가받고 있으며 키 인증에 대한 활발한 연구가 진행중에 있다.

나) Privacy 보호

개인의 프라이버시를 보호하기 위해 암호화 기법이 사용된다. 주로 사용되는 암호화 기법으로는 Public Key Encryption 방법이 주로 사용된다.

일반적인 암호화 기법은 암호화 된 데이터의 해독을 위해서는 암호화시 사용된 키가 해독시에도 사용되는 대칭형 암호화 시스템이 주로 사용되었다(예: Unix login password). 그러나 최근에 PGP(Pretty Good Privacy)라는 공중키 암호화 시스템이 주로 사용된다. 이 암호화 시스템은 비대칭 암호 화 시스템으로 암호화시 사용되는 키와 해독시 사용되는 키가 서로 다른 키라는 특징을 같는다. 예를 들면 A라는 사람이 B라는 사람에게 메일을 전송할 경우 A는 B의 공중키 를 이용해 메일을 암호화해 전송한다. B는 자신의 비밀키를 이용해 데이터를 해독하게된 다.

결국 데이터 전송도중 발생할 수 있는 데이터 Intercept나 변조에 대해 최고의 대안 을 제공할 수 있다. 메시지 암호화는 비밀 보장 뿐만아니라 송신자 인증을 위해서 두 번 암호화 될 수 있다. 송신자가 송신자의 비밀키를 이용해 메시지를 암호화(송신자에 대한 확인)한 후 암호화된 데이터를 수신자의 공중키를 이용하여 다시한번 암호화한다. 수신 자는 우선 송신자의 공중키로 수신된 데이터를 해독한다(송신자 인증). 그리고 해독된 데 이터를 자신의 비밀키를 이용해 마지막으로 해독한다(Privacy).

현재 공중키 암호화 방 식으로 PGP가 메일 송수신시 대중적으로 사용되고 있으나 미국에서는 PGP 보안 시스 템에 대해 무역 금지 조치를 내려 미국외의 지역 외에서는 작은 키값의 PGP version만 이 사용되고 있다. PGP freeware를 이용해 보시기 바랍니다. :>

• 공중키 암호화와 같은 기법들은 인중, 권한, 비밀 보장과 같은 문제들을 해결하는데 사용될 수 있다. 이같은 기법들을 사용하기 위해서는 클라이언트와 서버 소프트웨어를 모두 변경해야 한다.

다) Access Control(availability)

Firewalls의 사용

5) 다중 연결과 취약 링크

외부와 다중 연결을 갖는 조직이 방화벽 구축을 계획하고 있다면 그 조직의 모든 외부 연결에 방화벽을 설치하여야 하며 보안 경계가 효과적 이도록 하기 위해서는 모든 방화벽들 이 동일한 접근 제약을 사용하도록 조정해야 한다.

그렇지 않을 경우 한 방화벽들의 제약 을 회피하기 위해 우회하여 다른 방화벽을 통해 접근 할 수 있게된다. 이는 "보안 시스템 이 가장 취약한 지점만큼만 강하다"는 최약 링크의 공리(Weakest link axiom)로 해당 조직의 보안 시스템의 수준을 평가하고 분석하는 것을 난해하게 한다.

6) 방화벽 구현과 고속 하드웨어

방화벽의 구현은 기본적으로 컴퓨터들간의 권한이 없는 모든 통신을 막도록 설계되어져야 하며 외부에서 내부망으로 또 내부에서 외부로의 모든 트래픽이 보안 시스템을 반드시 경 유할 수 있도록 디자인 되어야 한다.

실제 방화벽 구현에 있어서는 망기술, 연결의 용량, 트래픽 부하, 조직정책들이 해당 조직에 적합하게 하나의 완결된 구조로 구현되어야 한다. 이를 위해서는 요구되는 처리능력을 파악하는 것이 중요하며 연결의 속도와 같은 속도로 데이터그램을 처리할 수 있어야 한다.

만약 방화벽이 데이터그램을 전송할지 여부를결 정하기 위해서 버퍼에 데이터그램을 지연시키면, 방화벽은 재전송으로 압도될 것이고 결국 버퍼는 넘쳐 방화벽의 Overflow를 초래하게 될 것이다. 결국 망속도로 동작하기 위해 서 방화벽은 그 작업에 최적인 하드웨어와 소프트웨어를 갖고 있어야 한다.

3. 방화벽 시스템의 개요

1) 방화벽 시스템 설계 시 고려 사항

인터넷 등의 외부 전산망에 연결된 내부 네트워크를 보호하기 위해서 방화벽 시스템을 구축하고자 할 경우 고려해야 할 사항은 다음과 같다.

가) 어떤 자원을 보호할 것인가 ? 보호하고자 하는 하드웨어, 소프트웨어, 각종 중요한 정보, 시스템 사용자, 시스템 관리에 대한 도큐먼트 등을 정의하고, 방화벽 시스템 구축 시 이를 고려하여야 한다.

나) 어떤 위협이 존재하는가 ? 보호하고자 하는 자원 및 정보들에 대한 위협이 어떤 것들이 있는가를 분석한다.

다) 자원이 얼마나 중요한가 ? 보호하고자 하는 자원의 중요성이 어느 정도인가를 분석한다.

라) 어떤 사용자를 인가할 것인가 ? 사용자 계정을 가진 사용자만이 네트워크를 사용하도록 할 것인지 비인가자라도 제한된 자원에만 사용하도록 할 것인지를 결정한다.

마) 요구되는 응용 및 서비스는 무엇인가 ? 보호하고자 하는 네트워크에서 사용 가능한 응용 및 서비스들이 어떤 것들이 존재하는지를 분석한다.

바) 비용 대 효과 측면에서 보호하기 위해 실현될 수 있는 기법은 무엇인가 ? 화일이나 디렉터리 등은 액세스 제어에 의해 보호하고, 네트워크 장비 및 호스트의 보호는 방화벽 시스템 사용 등의 보호 기법을 고려한다.

사) 해커 등의 불법 침입 감지 시 취해야 할 행동은 무엇인가 ? 해커 등과 같은 불법 침입자가 시스템 내부에 침입했을 때 취해야 할 대응책을 마련해야 한다.

아) 정기적으로 시스템을 점검한다. 보호하고자 하는 네트워크 및 자원들에 변화가 일어났는지 정기적으로 점검하고 기록한다. 이러한 행위는 시스템 관리자 및 네트워크 관리 시스템에 의해 자동적으로 실행한다.

방화벽 시스템을 설계할 때 상기와 같은 사항을 고려하여 보다 효과적으로 해커등과 같은 불법 침입자로부터 내부 네트워크를 보호할 수 있도록 해야 한다. 일반적으로 방화벽 시스템을 설계할 때 사용하는 패러다임은 두가지로 구분되는데

첫째로는, 내부 네트워크로의 진입을 명확하게 허용하지 않는 트래픽은 내부 네트워크로의 진입을 방지하는 것이고,

둘째로는 첫번째 패러다임의 반대 개념으로 명확하게 내부 네트워크로의 진입이 방지되지 않는 트래픽은 네트워크로의 진입을 모두 허용한다.

2) 방화벽 시스템이 방어할 수 있는 것

방화벽 시스템은 인터넷과 같은 외부 네트워크와 내부 네트워크 사이에 놓이며, 외부 네트워크로부터 내부 네트워크로의 침입을 감지하여 정보 및 자원들을 보호한다. 즉, 외부 네트워크에서 내부 네트워크로 액세스하 기 위해서는 방화벽 시스템을 통과하여야만 내부 네트워크로 진입할 수 있도록 하여 내부 네트워크에 존재하는 정보 및 자원들에 대한 트래픽을 사전에 방어하는 것이다.

3) 방화벽 시스템이 방어하지 못하는 것

방화벽 시스템은 내부 사용자가 내부 네트워크에 존재하는 중요한 정보를 디스크 혹은 테이프와 같은 매체를 통해 가지고 나가는 것은 방어하지 못한다. 또한 외부 네트워크로부터 내부 네트워크로 비 인가된 다이얼 모뎀을 통한 접근을 방어하지 못하며, 바이러스 혹은 정보 지향적인 공격에 대해서는 방어하지 못한다. 따라서 방화벽 시스템은 보호하고자 하는 네트워크의 자원이나 정보들을 완벽하게 불법 침입자로부터 보호할 수 없으며, 다만 외부 네트워크에서 내부 네트워크로의 진입을 1차로 방어해주는 기능을 수행 한다.

4) 위험 지역의 축소

인터넷 및 외부 네트워크에는 많은 해커가 존재하며, 이들은 언제 어느 통신망에 접속하여 내부 네트워크에 존재하는 자원 및 중요한 정보를 파괴, 변경, 갈취 등을 할지 예측할 수 없다. 따라서 인터넷 등 외부 네트워크에 연결된 모든 내부 네트워크는 해커들이 침입할 수 있는 위험 지역(Zone of Risk)에 놓이게 된다. 이러한 위험 지역으로부터 내부 네트워크를 분리 시키고자 하는 것이 방화벽 시스템이다.

5) 방화벽 시스템의 정보보호 서비스

방화벽 시스템의 기능을 지원하기 위해서는 다음과 같은 정보보호 서비스가 필요하다.

-사용자 인증

인터넷 상에서 Sniffer와 같은 네트웍 도구를 이용해 사용자 계정과 비밀번호를 알아 낼 수 있기 때문에 이러한 문제를 해결하고 방화벽이 설치된 내부망의 보안을 강화하기위해 보다 강력한 인증 수단이 요구된다. 이를 위해서 One-Time Password 인증 방법등이 많이 사용된다.

-접근제어

허용된 시스템에서 접근 요청을 하는지 그리고 통신 대상인 목적지 시스템이 원하는 곳인지 검사하고 허용 여부를 결정하며 네트웍 자원에 대해서 접근할 자격이 있는지를 검사한 후 접근 여부를 결정함으로써 불법 침입자에 대한 불법적인 자원 접근 및 파괴를 방지한다.

-트래픽 암호화

인터넷의 경우 TCP/IP 프로토콜을 사용하여 암호화되지 않은 Plain text형식으로 되어있기 때문에 데이터 내용에 대한 보안이 이루어 지지 않아 제 3 자에게 트래픽이 노출된 위험이 있다.이를 방지하기 위해 전송되는 트래픽을 암호화한다. 주로 사용되는 알고리즘은 DES, RSA, IDEA 등이 있다.

-트래픽 로그

외부와 내부네트웍 사이를 통과하는 모든 트래픽에 대해서 로그 파일에 기록한다.

-감사 추적 기능

내부 네트웍의 누가,언제,어떤 호스트에서 어떤 일 들을 했는가를 기록한다. 정보는 내부 네트워크의 해커 및 외부의 불법 침입자들이 시스템 내의 침입 여부를 파악할 수 있으며, 침입했을 때 적절히 대처할 수 있도록 해준다.

6) 방화벽 구축 시 장점

방화벽 구축시의 장점

• 취약한 서비스로부터 보호 방화벽은 크게 네트워크 보안을 증가시키고

원천적으로 불안전한 서비스를 필터링함으로써 서브네트 상에 있는 호스트에 위험을 감소시킨다. 선택된 프로토콜만이 방화벽을 통과 할 수 있기때문에, 서브네트 네트워크 환경은 위험에 덜 노출된다.

• 방화벽은 호스트 시스템으로의 액세스를 컨트롤할 수 있다.

예를 들면,외부 네트워크에서 한 호스트로 접속할 수 있는데, 원하지 않는 액세스는 효과적 으로 차단해 준다. 사이트는 메일 서버같은 특별한 경우를 제외한 외부로 부터의 액세스를 차단한다.

● 보안의 집중

방화벽은 대부분의 수정된 소프트웨어와 추가되는 보안 소프트웨어를 많 은 호스트에 분산시키지 않고 방화벽에 설치할 수 있다는 점에서 경제적이다. 특별히, one-time 패스워드 시스템과 다른 추가적인 인증 소프트웨를 방화벽에 설치할 수 있다.

● 확장된 프라이버시

일반적으로 해가 없다고 생각되는 것들이 실질적으로 프라이버시 침해에의 결정적인 요인이 될 수 있다. 방화벽을 사용한 사이트(호스트와의 연결 시스템)들은 핑거(finger)와 dns(domain named service)같은 서비스를 막고자 한다. 핑거는 마지막 로그인 시간과 메일 도착 여부, 다른 아이템들을 읽었는지 등 해당 계정의 사용자 정보를 디스플레이 하는 명령어다. 이런 편리한 '핑거' 서비스는 해커(시스템 침입자)들에게도 그 시스템이 얼마 나 자주 사용되는지, 시스템에 연결된 사용자가 있는지, 그리고 침해될 수 있는지에 관한 정보를 보여준다. 따라서 방화벽은 가능하면 핑거를 이용하는 것을 막음 으로써 침입자들의 접근 요인을 막고자 하는 것이다.

• 방화벽은 또한 사이트 시스템에 관한 dns 정보를 막고자 하는데 사용된다.

그래서 사이트의 이름과 ip어드레스를 인터네트 호스트에서 유출되지 않게한다. 어떤 사이트들은 이러한 정보를 막음으로써 침입자에게 유용하게 사용 될 수 있는 정보를 숨길 수 있다.

● 네트워크 사용과 비사용에서의 로그인과 통계자료 제공

인터네트 안밖으로의 모든 액세스가 방화벽을 통과 한다면, 방화벽은 액세스 정보를 기록할 수 있고 네트워크 사용에 관한 유용한 통계자료를 제공한다. 의심스러운 활동이 있을때 적당한 알람기능을 가진 방화벽은 방화벽과 네트워크가 침입 시도를 받고 있는지 또는 침입 되었는에 대한 세부사항을 제공해 준다

● 정책 시행

마지막으로 이것이 가장 중요한데, 방화벽은 네트워크 액세스 정책을 실행한다. 사실상, 방화벽은 사용자들과 서비스의 액세스를 컨트롤할 수 있다. 그래서, 네트워크 액세스 정책은 방화벽에 의해서 시행될 수 있게 된다. 그러나 방화벽이 없다면, 그러한 정책들은 전적으로 사용자들의 협조에 의존해야 한다. 사이트는 자신의 사용자들의 협조에 의존하여 보안을 유지할 수 있기 때문이다. 그러나 일반적으로 인터네트 사용자들에게는 적용되지 않는다.

4. 방화벽 시스템의 종류

방화벽 시스템은 OSI 참조 모델과 관련하여 방화벽 시스템이 동작하는 프로토콜 계층에 따라 분류 될 수 있다.

계층 3인 네트워크 계층과 계층 4인 트랜스포트 계층에서 패킷필터링 기능을 수행하는 스크리닝 라우터와 응용 계층에서 패킷필터링 기능과 인증 기능 등을 수행하는 응용 계층의 게이트웨이로 분류할 수 있다.

일반적으로 스크리닝 라우터를 설계할 경우 [명확하게 내부 네트워크로의 진입이 방지되지 않은 트래픽은 네트워크로의 진입을 허용] 하는 패러다임을 사용하고, 게이트웨이 혹은 proxy 서버의 경우 [내부 네트워크로의 진입을 명확하게 허용하지 않은 트래픽은 내부 네트워크로의 진입을 방지]하는 패러다임에 입각하여 설계한다.

1) 스크리닝 라우터(Screening Router)

스크리닝 라우터는 OSI 참조 모델의 계층 3과 계층 4에서 동작되기 때문에 계층 3과 4에서 동작하는 프로토콜인 IP(Internet Protocol), TCP (Transmission Control Protocol) 혹은 UDP(User Datagram Protocol)의 헤더에 포함된 내용을 분석해서 동작한다.

스크리닝 라우터란 네트워크에서 사용하는 통신 프로토콜의 형태, 근원지 주소와 목적지 주소, 통신 프로토콜의 제어 필드 그리고 통신 시 사용하는 포트 번호를 분석해서 내부 네트워크에서 외부 네트워크로 나가는 패킷 트래픽을 허가 및 거절하거나 혹은 외부 네트워크에서 내부 네트워크로 진입하는 패킷 트래픽의 진입 허가 및 거절을 행하는 라우터를 말한다.

이러한 진입 허가 혹은 거절 결정은 패킷필터 규칙에 따른 라우팅 테이블에 의해 결정된다. 일반 패킷과 특수한 프로토콜에 입각한 포트로 전송되는 패킷을 구별하는 능력 때문에 패킷 필터 라우터라고도 한다.

(그림 1)은 스크리닝 라우터(패킷 필터 라우터)의 위치 및 기능을 보여 준다.

가) 패킷 필터의 동작

스크리닝라우터로 연결에 대한 요청이 입력되면, IP, TCP 혹은 UDP의 패킷 헤더를 분석하여 근원지/목적지의 주소와 포트 번호, 제어 필드의 내용을 분석하고, 이들을 패킷 필터 규칙에 적용하여 계속 진입시킬 것인지 아니면 거절할 것인지를 판별한다. 연결 요청 패킷의 진입이 허가되면 이 후의 모든 패킷은 연결 단절이 발생할 때까지 모두 허용된다.

나) 패킷 필터 규칙

패킷 필터 규칙은 <표 1>과 같이 근원지 주소, 근원지의 포트 번호, 목적지 주소, 목적지의 포트 주소, 프로토콜 플래그, 행위(허가/거절) 등으로 구성된다. 이러한 패킷 필터 규칙이 정해지면 인터넷 주소에 적용하는 허가 /거절하는 조건의 순차적인 액세스 집합인 액세스 리스트를 정의한다.

스크리닝 라우터는 이러한 액세스 리스트를 가지고 프로그램 되며, 패킷을 허가 혹은 거절할 것인지를 액세스 리스트에 있는 행위에 대해서 순차적으로 결정하며, 패킷에 해당하는 액세스 리스트가 나타날 때까지 혹은 마지막 액세스 리스트에 도달할 때까지 순차적으로 점검한다.

방화벽 시스템을 실현할 경우 액세스 리스트의 점검 순서는 매우 중요하기 때문에 액세스 리스트의 점검 순서를 신중히 검토하여 사용한다.

<표 1. 패킷 필터 규칙>

* 장점

- 필터링 속도가 빠르고, 비용이 적게 든다.

. 네트워크 계층에서 동작하기 때문에 클라이언트와 서버에 변화가 없어도 된다.

- 사용자에 대해 투명성을 유지한다.

하나의 스크리닝 라우터로 보호하고자 하는 네트워크 전체를 동일하게 보호할 수 있다.

* 단점

- 네트워크 계층과 트랜스포트 계층에 입각한 트래픽만을 방어할 수 있다.

- 패킷 필터링 규칙을 구성하여 검증하기 어렵다.

- 패킷내의 데이터에 대한 공격을 차단하지 못한다.

- 스크리닝 라우터를 통과 혹은 거절당한 패킷에 대한 기록(log)을 관리 하기 힘들다.

2) Bastion 호스트

Bastion 호스트는 통신망을 보호하는데 중요한 방화벽 시스템으로 사용되며, 네트워크 관리자가 정기적으로 주의 깊게 감시 및 점검하여야 한다.

Bastion 호스트로는 상용 제품인 SPARCstation, IBM/AIX, NT Server 등이 사용될 수 있으며, 이들은 방어 기능이 철저히 구현된 호스트이다. 이러한 Bastion 호스트는 인터넷 등의 외부 네트워크와 내부 네트워크를 연결해 주는 방화벽 시스템 역할을 한다. 인터넷 사용자가 내부 네트워크로의 액세스를 원할 경우 우선 Bastion 호스트를 통과하여야만 내부 네트워크를 액세스하여 자원 및 정보를 사용할 수 있다.

해커 및 불법 침입자가 Bastion 호스트에 있는 중요한 정보를 악용하여 내부 네트워크로 접근하는 것을 방지하기 위해서는 Bastion 호스트 내에 존재하는 모든 사용자 계정을 지워야 하며, 중요하지 않은 화일이나 명령 및 유틸리티, IP forwarding 화일 그리고 라우팅 정보 등을 삭제하여야 한다. Bastion 호스트로의 입력시 강력한 인증 기법을 구현하여야 하며, Bastion 호스트는 내부 네트워크로의 접근에 대한 기록(log), 감사 추적을 위한 기록 및 모니터링 기능을 가지고 있어야 한다.

(그림 3)은 방화벽 시스템으로 동작하는 Bastion 호스트를 이용하여 외부 네트워크의 불법 사용자들로부터 내부 네트워크로의 접근을 방지하는 구성도를 나타낸 것이다.

* 장점

- 응용 서비스 종류에 보다 종속적이기 때문에 스크리닝 라우터보다 안전 하다.

- 정보 지향적인 공격을 방어할 수 있다.

- 각종 기록(logging) 정보를 생성 및 관리하기 쉽다.

* 단점

- Bastion 호스트가 손상되면 내부 네트워크를 보호할 수 없다.

- 로그인 정보가 누출되면 내부 네트워크를 보호할 수 없다.

3) Dual-Homed 게이트웨이

Dual-Homed 게이트웨이는 (그림 4)와 같이 두개의 네트워크 인터페이스 를 가진 Bastion 호스트를 말하며, 하나의 네트워크 인터페이스는 인터넷 등 외부 네트워크에 연결되며, 다른 하나의 네트워크 인터페이스는 보호하고자 하는 내부 네트워크에 연결되며, 양 네트워크간의 라우팅은 존재하지 않는다. 따라서 양 네트워크간의 직접적인 접근은 허용되지 않는다.

만약 라우팅이 가능하면 외부 네트워크로부터 내부 네트워크로의 액세스가 가능 하다. 라우팅이 없는 Dual-Homed 게이트웨이를 이용하여 인터넷 혹은 내부 네트워크의 정당한 사용자들이 응용 서비스를 제공받는 방법은 두가지로 구분되는데,

첫째 방법은 Dual-Homed 게이트웨이상에서 실행되며 서비스를 제공하는 proxy 서버를 사용하는 것이고,

두번째 방법은 응용 서비스를 제공해주는 Dual-Homed 게이트웨이에 직접 로그인한 다음 다시 내부 네트워크로 접근하는 것인데, 이 경우 강력한 인증 방법이 게이트웨이에 구현되어야 한다.

따라서 해커나 불법 침입자가 악용할 소지가 있는 명령어(suid, sgid 등), 유틸리티 및 불필요한 서비스, 프로그래밍 도구(컴파일러 등)를 이들이 사용할 수 없도록 Dual-Homed 게이트웨이에서 삭제하여야 하며, 라우팅이 되지 않도록 하여야 한다. 또한 로그인에 대한 기록 정보 및 감시 추적에 필요한 기록을 정확히 유지 관리하여야 한다. 외부 네트워크로부터 내부 네트워크로 진입하기 위해서는 Dual-Homed 게이트웨이를 통과하여야 한다.

* 장점

- 응용 서비스 종류에 좀더 종속적이기 때문에 스크리닝 라우터보다 안전 하다.

- 정보 지향적인 공격을 방어할 수 있다.

- 각종 기록 정보를 생성 및 관리하기 쉽다.

- 설치 및 유지보수가 쉽다.

* 단점

- 제공되는 서비스가 증가할수록 proxy 소프트웨어 가격이 상승한다.

- 게이트웨이가 손상되면 내부 네트워크를 보호할 수 없다.

- 로그인 정보가 누출되면 내부 네트워크를 보호할 수 없다.

4) 스크린된(Screened) 호스트 게이트웨이

스크린된 호스트 게이트웨이는 Dual-Homed 게이트웨이와 스크리닝 라우터를 혼합하여 사용한 방화벽 시스템이다.

방화벽 시스템의 구성 방법은 (그림 5)와 같이 인터넷과 Bastion 호스트 사이에 스크리닝 라우터를 접속하고, 스크리닝 라우터와 내부 네트워크 사이에서 내부 네트워크상에 Bastion 호스트를 접속한다.

인터넷과 같은 외부 네트워크로부터 내부 네트워크로 들어오는 패킷 트래픽을 스크리닝 라우터에서 패킷 필터 규칙에 의해 1차로 방어하고, 스크리닝 라우터를 통과한 트래픽은 모두 proxy 서버를 구동하는 Bastion 호스트에서 입력되는 트래픽을 점검하며, 스크리닝 라우터 혹은 Bastion 호스트를 통과하지 못한 모든 패킷 트래픽은 거절된다.

내부 네트워크로부터 인터넷 등으로 나가는 트래픽은 1차로 proxy 서버를 구동하는 Bastion 호스트에서 점검한 후 통과된 트래픽을 스크리닝 라우터로 보내고 스크리닝 라우터는 Bastion 호스트로부터 받은 트래픽을 인터넷등의 외부 네트워크로 송신할 것인지 결정한다.

Bastion 호스트와 스크리닝 라우터를 통과한 트래픽만이 외부 네트워크로 전달된다. Bastion 호스트는 외부 네트워크로 또는 외부 네트워크로부터의 서비스 요청을 허용할 것인지 아니면 거절할 것인지를 결정하기 위해서 응용 계층의 proxy 서버를 구동한다.

스크리닝 라우터의 라우팅 테이블은 외부 트래픽이 Bastion 호스트로 입력되도록 구성되어야만 하며, 이 스크리닝 라우터의 라우팅 테이블은 침입자로부터 안전하게 보호되어야 하고 비인가된 변환을 허용해서는 안된다. 만약 라우팅 테이블이 변환되어 외부 트래픽이 Bastion 호스트로 입력이 되지 않고 곧바로 내부 네트워크로 진입할 수 있다면 해커 및 불법 침입자는 내부 네트워크의 자원 및 정보를 변환, 파괴 등을 할 수 있다.

이와 같은 방화벽 시스템의 스크리닝 라우터에서는 정적 라우팅 테이블을 사용하는 것이 안전하다.

* 장점

- 2 단계로 방어하기 때문에 매우 안전하다.

- 네트워크 계층과 응용 계층에서 방어하기 때문에 공격이 어렵다.

- 가장 많이 이용되는 방화벽 시스템이며, 융통성이 좋다.

- Dual-Homed 게이트웨이의 장점을 그대로 가진다.

* 단점

- 해커에 의해 스크리닝 라우터의 라우팅 테이블이 변경되면 이들을 방어 할 수 없다.

- 방화벽 시스템 구축 비용이 많다.

5) 스크린된 서브네트 게이트웨이

인터넷과 내부 네트워크를 스크린된 게이트웨이를 통해서 연결하며, 일반적으로 스크린된 서브네트에는 방화벽 시스템이 설치되어 있으며, 인터넷과 스크린된 서브네트 사이 그리고 서브네트와 내부 네트워크 사이에는 스크리닝 라우터를 사용한다. 이와 같은 방화벽 시스템의 구성도는 (그림 6)과 같다.

스크리닝 라우터는 인터넷과 스크린된 서브네트 그리고 내부 네트워크와 스크린된 서브네트 사이에 각각 놓이며, 입출력되는 패킷 트래픽을 패킷 필터 규칙을 이용하여 필터링하게 되며, 스크린된 서브네트에 설치된 Bastion 호스트는 proxy 서버(응용 게이트웨이)를 이용하여 명확히 진입이 허용되지 않은 모든 트래픽을 거절하는 기능을 수행한다. 이러한 구성에서 스크린된 서브네트에 대한 액세스는 Bastion 호스트를 통해서만 가능하기 때문에 침입자가 스크린된 서브네트를 통과하는 것은 어렵다.

만약 인터넷을 통해 내부 네트워크로 침입하려고 한다면 침입자는 자기가 자유롭게 내부 네트워크를 액세스할 수 있도록 인터넷, 스크린된 서브네트 그리고 내부 네트워크의 라우팅 테이블을 재구성해야만 가능하다. 그러나 스크리닝 라우터가 존재하기 때문에 이는 힘들다.

비록 Bastion 호스트가 침해되었더라도 침입자는 내부 네트워크상에 존재하는 호스트로 침입해야 하고, 그리고 스크린된 서브네트를 액세스하기 위해서 스크리닝 라우터를 통과해야 한다.

* 장점

- 스크린 된 호스트 게이트웨이 방화벽 시스템의 장점을 그대로 가진다.

- 융통성이 뛰어나다.

- 해커들이 내부 네트워크를 공격하기 위해서는 방어벽을 통과할 것이 많아 침입이 어렵다.

- 매우 안전하다.

* 단점

- 다른 방화벽 시스템들 보다 설치하기 어렵고, 관리하기 어렵다.

- 방화벽 시스템 구축 비용이 많다.

- 서비스 속도가 느리다.

6) Proxy 서버/응용 게이트웨이

응용 게이트웨이 혹은 proxy 서버는 방화벽 시스템(일반적으로 Bastion 호스트)에서 구동되는 응용 소프트웨어를 말하는데 store-and-forward 트래픽뿐만 아니라 대화형의 트래픽을 처리할 수 있으며, 사용자 응용 계층 (OSI 참조 모델의 계층 7)에서 트래픽을 분석할 수 있도록 프로그램된다. 따라서 이것은 사용자 단계와 응용 프로토콜 단계에서 액세스 제어를 제공 할 수 있고, 응용 프로그램의 사용에 대한 기록(log)을 유지하고 감시 추적을 위해서도 사용될 수 있다. 응용 게이트웨이는 사용자 단계에서 들어오고 나가는 모든 트래픽에 대한 기록을 관리하고 제어할 수 있으며, 해커 및 불법 침입자를 방어하기 위해서 강력한 인증 기법이 필요하다.

응용 게이트웨이는 사용되는 응용 서비스에 따라 각각 다른 소프트웨어를 구현하여 사용하기 때문에 고수준의 보안을 제공할 수 있다.

네트워크에 첨가되고 보호가 필요한 새로운 응용 이 생기면 이를 위해 새로운 특수 목적용 코드를 생성해야 한다.

응용 레벨 게이트웨이를 사용하기 위해서 사용자는 응용 게이트웨이 장치에 로그인하거나 서비스를 이용할 수 있는 특수한 클라이언트 응용 서비스를 실현해야 한다. 각각 응용에 따라 다르게 사용하는 특수한 게이트웨이는 제각기 내부에 관리 도구와 명령 언어를 가지고 있다.

응용 게이트웨이는 실제 서버의 관점에서 볼 때 클라이언트처럼 동작하며, 클라이 언트 관점에서 볼 때는 실제 서버처럼 동작한다. 응용 게이트웨이의 실현 예는 TELNET 게이트웨이, FTP 게이트웨이, Sendmail, NNTP News Forwarder 등이 있다.

* 장점

- 응용 서비스마다 각각 다른 응용 게이트웨이를 구현하므로 보다 안전 하게 보호할 수 있다.

- 응용 사용에 따른 기록 및 감시 추적을 유지 관리 가능하다.

- 융통성이 좋다.

- 정보보호 서비스를 응용 게이트웨이에 구현 가능하다.

* 단점

- 응용 서비스마다 제각기 다른 응용 게이트웨이가 필요하다.

- 사용되는 응용 서비스가 증가할수록 구축 비용이 증가한다.

5. 결 론

인터넷에 연결하여 사용하는 내부 네트워크의 자원 및 중요한 정보 등을 해커로부터 보호하기 위해 사용되고 있는 보안의 전반을 방화벽 시스템을 중심으로 살펴보고 이들의 기능 및 성능을 분석하였으며 각 각의 장단점을 제시하였다.

주어진 환경에 가장 적합한 방화벽 시스템을 구축하는 것은 많은 고려 사항으로 인하여 쉬운 일은 아니다. 이를 선택하기 위해서는 구축 비용 대 효과, 사용하는 네트워크 기술, 보호해야 할 정보, 보안 정책, 조직의 네트 워크에 대한 정책 등을 신중히 고려하여 자신의 네트워크에 가장 타당한 방화벽 시스템을 선택하여야 한다. 그러나 방화벽 시스템이 완벽하게 해커 및 불법 침입자로부터 내부 네트워크의 모든 자원 및 정보를 보호해 준다고 믿어서는 안되며, 단지 방화벽 시스템은 내부 네트워크를 보호하기 위한 1차 방어선으로 생각하고 암호화 기법 및 강력한 인증 서비스 등과 같은 안전한 정보 보호 서비스를 구현하여야 하며, 이와 더불어 가장 중요한 보안 정책이라고 할 수 있는 사용자 및 관리자들에게 보안 교육 등을 꾸준히 실시해야 하며, 관리자는 내부 네트워크 시스템을 정기적으로 점검함으로써 발생할 수 있는 모든 면을 미리 대비하도록 하여야 한다.

1) IP spoofing

TCP/IP 프로토콜의 결함에 대해서는 이미 1985년에 로버트 모리스의 논문 "A Weakness in the 4.2 BSD UNIX TCP/IP Software"에 언급되었고 1995년 유명한 해커 케빈미트닉이 이 이론을 실제화하여 해킹을 시도하다가 체포된 사건이 있었다. 이 사건 이후로 케빈미트닉이 사용한 해킹기술은 IP spoofing라는 용어로 불리게 되며 현재까지 TCP/IP 약점을 이용한 여러 가지의 공격기법 이 지속적으로 나오고 있다.

IP spoofing이란?

spoofing이라는 것은 '속이다'라는 의미이고 IP spoofing은 IP를 속여서 공격하는 기법을 의미한다. 현재 알려진 TCP/IP 프로토콜의 약점을 이용한 IP spoofing은 다음과 같다.

- 순서제어번호 추측(Sequence number guessing)

- 반(Half)접속시도 공격(SYN flooding)

- 접속가로채기(Connection hijacking)

- RST를 이용한 접속끊기(Connection killing by RST)

- FIN을 이용한 접속끊기(Connection killing by FIN)

- SYN/RST패킷 생성공격(SYN/RST generation)

- 네트워크 데몬 정지(killing the INETD)

- TCP 윈도우 위장(TCP window spoofing)

그러나 일반적으로 IP spoofing이란 케빈미트닉이 사용한 방법을 의미하며 순서제어번호추측 공격, 반(Half)접속시도 공격 등이 함께 사용되는 고난도의 수법으로 볼 수 있다.

공격과정

가) 위 그림에서 C는 A로 자신의 IP주소를 위장하여 SYN를 보내 접속요청을한다. 요청에 대한 응답으로 A가 C에 대한 ACK와 함께 자시의 SYN을 전송하지만 C가 이에 대해 ACK를 보내지 않으면 A는 자신이 보낸 ACK에 대한 C의 응답을 기다리게 된다. 이 과정을 연속적으로 반복하면 (예를 들어 SunOs의 경우, 약 8개 정도의 SYN패킷을 80초 정도 간격으로 보낸다.) A는 외부의 접속요청에 응답할 수 없는 오버플로우 상태가 된다.

나) 이후, C는 B로 정상적인 접속을 시도하여 순서제어번호의 변화를 패킷 모니터링을 이용하여 관측한다.

다) 순서제어번호의 변화를 관찰아여 추측한 순서제어번호를 이용하여 C는 자신의 IP주소를 A로 가장한후 B에 접속요청(SYN)을 보낸다. (순서제어번호의 변화는, 예를 들어 4.4BSD에서 OS부팅시 1로 세트되고 0.5초마다 64,000씩 증가한다. 또한 새로운 TCP 접속이 만들어질 때마다 64,000씩 증가한다.)

라) B는 수신된 SYN 패킷이 A에서 온 것으로 인식, A에게 ACK와 새로운 SYN를 보내지만 이미 A는 외부와 통신 불능상태이므로 응답을 할 수 없게 된다.. (만일 A가 C보다 먼저 응답하여 RST을 보내게되면 C의 공격은 실패한다.)

마) C는 자신의 IP 주소를 A주소로 위장하여 추측된 순서제어번호를 이용해 B가 A로 보낸 SYN/ ACK에 대한 ACK를 B에 보낸다.

바) 결국 C와 B 불법적 접속이 이루어지고, B와 A는 연결되어 있는 것으로 착각한다.

사) 이후 rsh을 이용하여 echo '+ +' >/.rhosts과 같은 데이터를 보내면 된다.

방지대책

외부에서 들어오는 패킷중에서 출발지 IP주소(Source IP Address)에 내부망 IP주소를 가지고 있는 패킷을 라우터 등에서 패킷 필터링을 사용하여 막아낼 수 있다. 그러나 내부 사용자에 의한 공격은 막을 수 없으므로 각 시스템에서 TCPwrapper, ssh 등을 설치해서 운영하고 , rsh, rlogin 등과 같이 패스워드의 인증 과정이 없는 서비스를 사용하지 않는 것이 바람직하다. 그러나 여러종류의 IP spoofing은 TCP/IP의 설계와 구현상의 문제점에 기인한 것으로 새로운 프로토콜을 사용하지 않는 한 완벽한 보호대책은 존재할 수 없다. 다만 지속적인 보안관리 및 점검만이 최소한의 피해를 막을 수 있다고 할 수 있겠다.

2) TCP SYN FLOODING ATTACK

최근 두종류의 지하 잡지에 "반만 열린" TCP 연결들을 생성하므로써 서비스거부공격을 하는 코드가 발표되었다. 인터넷에 연결되어 TCP 기반의 서비스(예를 들면, 웹서버, FTP서버, 또는 메일서버 등)를 제공하는 모든 시스템들이 이 공격에 노출되어 있으며, 공격의 결과는 시스템에 따라 다르다. 그러나 이 문제에 대한 완벽한 해결책은 없으며 단지 영향을 감소시키는 방법들만이 알려져 있다.

어떤 시스템(클라이언트)이 서비스를 제공하는 시스템(서버)에 TCP 연결을 시도할 때, 클라이언트와 서버는 다음과 같이 일련의 메시지들을 교환한다. 먼저 클라이언트 시스템은 서버에 SYN 메시지를 보내며, 서버는 SYN-ACK 메시지를 클라이언트에 전송하므로써 접수된 SYN 메시지에 대해 확인한다. 클라이언트는 다시 ACK 메시지를 전송하므로써 접속 설정을 완료한다. 이렇게 하므로써 클라이언트와 서버 사이의 접속이 열리게 되고, 클라이언트와 서버사이에 서비스에 고유한 자료들을 교환할 수 있게된다. 이러한 접속방법은 모든 TCP 연결(텔넷, 전자우편, 웹 등) 에 대해 적용된다.

공격의 가능성은 바로 서버가 클라이언트에 확인 메시지(ACK-SYN)을 보낸 후 클라이언트로 부터 다시 확인 메시지(ACK)를 받기 이전의 시점에서 발생한다. 이 상태가 바로 "반만 열린" 연결이라고 불린다. 서버는 모든 진행중인 연결에 대한 정보를 저장하기 위해 시스템 메모리에 자료구조를 구축하며 이 자료구조는 그 크기가 제한되어 있다. 따라서 계속하여 "반 만 열린" 연결을 생성하므로써 이 자료구조를 넘치게 할 수 있다.

반만 열린 연결은 IP 속이기를 이용하면 손쉽게 생성할 수 있다. 공격자 시스템에서 피공격 서버에 적법하게 보이지만 실제로는 ACK-SYN에 대해 응답할 수 없는 클라이언트를 참조하는 SYN 메시지를 발송한다. 따라서 피공격 서버는 최종 SYN 메시지를 받 을 수 없게된다. 마침내 피공격 서버측의 "반만 열린" 연결을 위한 자료 구조가 가득차게 되고 이 자료 구조가 비워 질 때까지 피공격 서버는 새로운 연결 요구에 대해 응답할 수 없게 된다. 일반적으로 반만 열린 연결에 대해서는 타임아웃 값이 설정되어 있어 일정 시간이 경과하면 자동적으로 취소되게 되므로 새로운 연결에 대해 응답할 수 있게 된다. 그러나 이와같은 복구에 소요되는 시간보다 빠르게 공격자 시스템이 반복적으로 속임용 IP 패킷을 전송할 수 있다.

대부분의 경우, 이러한 공격의 피해 시스템은 새로운 네트워크 연결 요청을 받아 들이는데 곤란을 겪게 되며 서비스제공 능력의 저하를 가져온다. 그러나 기존의 외부로 부터의 연결이나, 외부로의 새로운 접속 요청 전송에는 영향을 받지 않는다. 그러나 특별한 경우, 시스템의 메모리가 고갈되거나, 파괴되거나, 또는 작동불가능하게 될 수도 있다.

SYN 패킷의 근원지 주소가 가짜이므로 공격의 근원을 알아내는 것은 어려우며 패킷이 피공격 서버에 도착한 뒤에 근원을 알아내는 것은 불가능하다. 네트워크는 패킷을 목적지 주소만을 이용하여 전달하므로 근원을 검증하는 유일한 방법은 입력 소스 필터링을 이용하는 것 뿐이다.

현재의 IP 프로토콜 기술로는 IP 속임 패킷을 제거하는 것이 불가능하므로 현재로서는 이 문제에 대한 완전한 해결책이 없는 상태이다. 그러나 관리하고 있는 네트워크로 유입되거나 이로부터 유출되는 IP 속임 패킷을 감소시킬 수 있는 방법이 있다. 즉, 라우터를 적절히 구성하므로써 공격당할 가능성을 줄이거나, 해당 사이트내의 시스템이 공격의 근원이 될 수 있는 가능성을 감 소시킬 수는 있다.

현재로서의 최상의 해결책은 외부 접속용 인터페이스로의 유입을 제한하는 필터링 라우터(입력 필터라고 부름)를 설치하여 근원이 내부 네크워크인 모든 패킷의 유입을 금지시키는 것이다. 이에 더하여 근원이 내부 네트워크가 아닌 모든 패킷의 유출을 금지시켜 관리하의 사이트로 부터 IP 속임 공격이 발생되는 것을 방지할 수 있다. 그러나 이러한 방법도 외부 공격자가 다른 임의의 외부 주소를 이용하거나, 내부의 공격자가 내부의 주소를 이용하여 공격하는 것에 대해서는 방어하지 못한다.

3) FIREWALL FAQ

Original Contributor : Marcus J. Ranum, ranum@iwi.com

1st Korean Contributor: Chaeho Lim, chlim@certcc.or.kr

-----------------------------------------------------

목차

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

-----------------------------------------------------

a) About the FAQ

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

b) 네트워크 방화벽시스템이란?

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

c) 왜 방화벽인가?

인터넷에서도 일반 사회에서 벌어지는 다른 사람의 벽에 낙서를 하거나 우체통을 훼손하거나차량을 훼손하는 등등의 일들과 유사한 행위들이 벌어지고 있는데, 여기에는 중요한 데이타나 자원들이 있을 수 있어 인터넷에 가입된 기관은 이를 막으려 하고 있다. 방화벽의 주된 목적은 이러한 불법행위에 대해 자신의 네트워크를 보호하고 내부에서는 일상적인 업무를 평시와 같이 할 수 있도록 하자는 것이다. 대부분 전통적인 기관이나 네트워크/데이타센터들은 자체적인 보안정책이나 실행강령등을 가지고 있는데, 정책이 데이타의 보호를 주목적으로 준비된 곳이라면 방화벽은 매우 중요하다. 인터네트에 접속하고자 할때 만약 규모가 큰 기관이라면,비용이나 노력에 대한 정당성을 찾기 어려울 뿐 아니라 관리적인 것도 안전한지정당화하기 어렵다. 방화벽은 보안 뿐 아니라 망관리에 대한 보증이 되기도 한다.

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

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

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

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

1. 방화벽시스템이 막을 수 있는 것은?

방화벽 서버를 통과하는 TIP/IP패킷

e) 방화벽시스템이 막지 못하는 것은?

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

f) 바이러스에 대해서는?

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

네트워크를 보호하는 것은 플로피디스크, 모뎀, 인터넷 등에서 들어오는 바이러스를 막는 것이다. 방화벽에서 바이러스를 막는 방식은 단지 인터넷에서의 바이러스침투를 막는 것 밖에 없다. 대부분은 플로피디스크에 의해 전달된다는 사실을 알아야 한다.

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

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

서 명 : 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

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

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 에서 찾아볼 수 있다.

i) 방화벽시스템 제품 업체, Consultants 는?

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

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

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

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

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

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

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

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

k) 방화벽시스템 종류는?

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

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

* 응용 레벨(Application Level)

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

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

* 네트워크 레벨 방화벽의 사례 : "스크린호스트방화벽" 이라고 할 수 있으며, 하나의 호스트에서의 접근제어가 네트워크 레벨에서 동작하는 라우터에서 이루어지며, 이때의 하나의 호스트란 "Bastion Host"이다.

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

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

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

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

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

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

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

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

을 참고하기 바란다.

m) 값싼 패킷스크린 도구는?

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

n) 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

o) WWW/HTTP 와 어떻게 동작하게 만드나?

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

* 스크린라우터를 사용한다면, "established" 접속을 라우터에서 허용한다.

* SOCKS 를 지원하는 Web 클라이언트를 사용하고 방화벽에서 SOCKS를 구현한다.

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

p) 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를 하는 싸이트와 대화할 경우에는 실패하게 된다.

q) FTP와는 어떻게 동작하게 만드나?

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

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

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

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

r) TELNET 과는 어떻게 동작하게 만드나?

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

s) Finger/Whois 와는 어떻게 동작하게 만드나?

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

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

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

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

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

u) 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 으로 나타나게 된다.

v) Source Route 는 무엇이며, 왜 위험한가?

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

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

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

w) ICMP Rediect 란 무엇이며 Redirect Bomb란?

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

가는 패스에대해 더 이상 접근할 수 없다는 식으로 이용될 수 있다.

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

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

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

y) 용어설명

권한남용(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): 사용자에게 예측하기 어려운 값을 주면 사용자가 토큰을 이용하여 계산한 값을 반환하는 사용자 인증 기술의 하나

제한암호체크썸(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): 자기 복제 능력이 있는 코드세그먼트로서 바이러스는 공격 프로그램이나 트랩도어를 가질 수도 있고, 없을 수도 있다.

z) 공헌자들

* 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.


블로그 > 20Th BOY!!
http://blog.naver.com/yayaluna/1515669

Net-SNMP

Contents

Net-SNMP Package

History of Net-SNMP

Applications of Net-SNMP

Trap Daemon

How to extend SNMP agents with Net-SNMP

Architecture of Net-SNMP Agent

Package

•         An extensible agent

•         An SNMP library

•         tools to get or set information from SNMP agents

•         tools to generate and handle SNMP traps

•         a Tk/perl mib browser

History

•         Originally based on the Carnegie Mellon University implementations

•         University of California at Davis SNMP extends CMU-SNMP, calls UCD-SNMP

•         UCD-SNMP moves to Net-SNMP in April, 2002 (Web sites also moves from www.ucd-snmp.net to www.net-snmp.net)

•         Now, Net-SNMP 5.0.8 released

Application

•         snmpcmd  [Common OPTIONS] AGENT [PARAMETERS]

–         Common command line arguments

–         Common OPTIONS

§         -c  community

§         -v 1 | 2c | 3

§         -r retries

§         -t timeout

•         snmpget [COMMON OPTIONS] [-Cf] OID [OID]...

–         SNMP application that uses the SNMP GET request to query for information on a network entity

–         Ex) snmpget -c public localhost system.sysDescr.0

–         Result) system.sysDescr.0 = Linux enterflex2.postech.ac.kr …

•         snmpset [COMMON OPTIONS] OID TYPE VALUE

–         SNMP application that uses the SNMP SET request to set information on a network entity

–         Type: i (INTEGER), u (UNSIGNED), s (STRING)…

–         ex)  snmpset -c private -v 1 localhost system.sysContact.0 s mjchoi@postech.ac.kr

•         snmpwalk [APPLICATION OPTIONS] [COMMON OPTIONS] [OID]

–         SNMP application that uses SNMP GETNEXT requests to query a network entity

–         Retrieves lots of data, a part of MIB tree (subtree) at once

–         Ex) snmpwalk -c public localhost system

–         Result)      
  system.sysDescr.0 = …

                   system.sysObjectID.0 = …

                      system.sysUpTime.0 = …

•         snmpstatus [COMMON OPTIONS]

–         SNMP application that retrieves several important statistics from a network entity.

–         The IP address of the entity. à sysDescr.0 / sysUpTime.0 /…

–         Ex)  snmpstatus -c public -v 1 localhost

–         Result) [127.0.0.1] à[Linux enterflex2 .postech . ac .kr 2.4.7-10 #1 Thu Sep 6 17 :27:27 EDT 2001 i386 ]…

•         snmptranslate [OPTIONS] OID [OID]...

–         Application that translates SNMP object identifier values from their symbolic (textual) forms into their numerical forms

–         Ex) snmptranslate system.sysUpTime.0

–         Result) .1.3.6.1.2.1.1.3.0

•         snmptrap [COMMON OPTIONS] [-Ci] enterprise-oid agent generic-trap specific-trap uptime [OID TYPE VALUE]

–         SNMP application that uses the SNMP TRAP operation to send information to a network manager 

–         Definition)

TRAP-TEST-MIB DEFINITIONS ::= BEGIN

IMPORTS ucdExperimental FROM UCD-SNMP-MIB;

demotraps OBJECT IDENTIFIER ::= { ucdExperimental 990 }

demo-trap TRAP-TYPE

                      STATUS current

              ENTERPRISE demotraps

               VARIABLES { sysLocation }

               DESCRIPTION "This is just a demo"

               ::= 17

END

–  Ex) snmptrap –v 1 -c public host TRAP-TEST-MIB::demotraps localhost 6 17 '' SNMPv2-MIB::sysLocation.0 s "Just here"

–   Etc.

–                           snmpgetnext: retrieving unknown indexed data.

–                           snmpbulkwalk :uses SNMP GETBULK requests to query a network entity

–                           snmptable: displaying table.

–                           snmpnetstat: symbolically displays the values of various network-related information  retrieved  from  a remote system using the SNMP protocol

Trap Daemon

•   snmptrapd [OPTIONS][LISTENING ADDRESSES]

–                           SNMP application that receives and logs  SNMP TRAP

–                           the default is to listen on UDP port 162

–                           snmptrapd is displayed as follows

–                           Result) 1999-11-12 23:26:07 localhost [127.0.0.1] TRAP-TEST-MIB::demotraps: Enterprise Specific Trap (demo-trap) Uptime: 1 day, 5:34:06 SNMPv2-MIB::sysLocation.0 = "Just here"

HOW To Extend

1.Define a private MIB: Example of Cluster MIB

2. Download net-snmp-5.0.8.tar.gz

3. Decompress the file in your home directory command: gtar xvfz net-snmp-5.0.8.tar.gz

4. Compile default SNMP agent

①       cd net-snmp-5.0.8

②       ./configure --prefix=“/usr/local/net-snmp”

③       make

④       make install

5. Install SNMP perl module for using mib2c

①       cd net-snmp-5.0.8

②       cd perl

③       perl Makefile.PL -NET-SNMP-CONFIG=“sh ../../net-snmp-config” -NET-SNMP-IN-SOURCE=true 

④       make

⑤       make test

⑥       make install

6. Compile the private MIB file using mib2c

–         cd net-snmp-5.0.8

–         cd local

–         mkdir cluster

–         copy the private mib in the current directory                           

ex) cp ~mjchoi/cluster.my ./cluster.my

–         export MIBS=ALL

–         MIBS=./cluster.my

–         mib2c -c mib2c.scalar.conf generalInfo

–         mib2c -c mib2c.scalar.conf currentStatus

–         mib2c -c mib2c.array-user.conf loadBalancer

–         mv generalInfo.* cluster

–         mv currentStatus.* cluster

–         mv loadBalancer.* cluster

–         cp –r cluster ../agent/mibgroup/.

8. Code the extension agent

(1) Header file: add necessary definitions C file

(1) Module definition: the code defining the contents of the MIB

     e.g. static oid      clusterName_oid[] = { 1, 3, 6, 1, 3, 1, 1, 1, 0 };

(2) Module initialization:

initialization before they can start providing the necessary information

    e.g. netsnmp_register_instance(netsnmp_create_handler_registration

                            ("clusterName",  do_clusterName, clusterName_oid,

                              OID_LENGTH(clusterName_oid), 

                              HANDLER_CAN_RWRITE));

(3) Variable handling: actually handles a request for a particular variable instance

    e.g.

char clusterName[NAME_LEN];

                     int *var_len;

  (4) Non-table-based modules:

the request handling routine is to retrieve any necessary scalar data

             e.g.

         switch (reqinfo->mode) {

           case MODE_GET:

             snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR,

                                                         (u_char *) clusterName, var_len);

             break;

    …

    }

(5) Simple tables: process a simple table with limited table index

e.g.

int serviceTable_handler(netsnmp_mib_handler *handler,

                    netsnmp_handler_registration *reginfo,

                    netsnmp_agent_request_info *reqinfo,

                    netsnmp_request_info *requests)  {

                            …

                          switch (reqinfo->mode) {

                        case MODE_GET:

                                    switch (table_info->colnum) {

                                  case COLUMN_SRINDEX:

                               snmp_set_var_typed_value(var, ASN_INTEGER, …);                                     

                                  break; 

                     …

} (7) Set-able object: the handling of SNMPSET

e.g.

switch (reqinfo->mode) {

…   

  case MODE_SET_ACTION:

       // XXX: perform the value change here

       if ( /* XXX: error? */ ) {

           netsnmp_set_request_error(reqinfo,

requests, “error_msg.”);

       }

       break;

  case MODE_SET_COMMIT:

       //  XXX: delete temporary storage

       if ( /* XXX: error? */ ) {

            netsnmp_set_request_error(reqinfo, requests,

                                     SNMP_ERR_COMMITFAILED);

       }

       break;

  }

                         …

                          }

                             …

}

(6) General tables: process a general table, which the maximum

           index is not determinable

           e.g.

              Init_{Name}_Entry();  // Perform any necessary initialization

              while (( index = Get_Next_{Name}_Entry() ) != EndMarker ) {

                  construct OID from vp->name and index

                  compare new OID and request

                  if valid {

                     save current data

                     if finished // exact match, or ordered table

                     break; // so don't look at any more entries

                  }

                 …

              }

           …

9. Compile the MIB extension and generate SNMP daemon

•         ./configure --with-mib-modules=“cluster/generalInfo, cluster/currentStatus, cluster/loadBalancer”

•         cd agent   

•         make

•         ./snmpd –c config_file (ex) ./snmpd –c /etc/snmp/snmpd.conf

–         snmpd [OPTIONS] [LISTENING ADDRESSES]

–         SNMP agent which binds to a port and awaits requests from SNMP management software.

–         collects the requested information and/or performs the requested operations and returns the information to the sender.

–         By default, snmpd listens for SNMP requests on  UDP port 161.

10.  Modify snmpd.conf for SNMP community

# First, map the community name

#               sec.name    source     community

com2sec  clusterUser  default       postech

# Second, map the security name into a group name:

#          groupName      securityModel  securityName

group clusterGroup              v1            clusterUser

# Third, create a view for us to let the group have rights to:

#          name        incl/excl          subtree               mask(optional)

view    mibview     included   .iso.org.dod.internet

# Finally, grant the group read-only access to the systemview view.

#             group context sec.model sec.level prefix read   write  notif

access  clusterGroup ""  any    noauth  exact  mibview  mibview none

1. NMS 란 무엇인가?

1.1 NMS의 정의

네트워크상의 전 장비들의 중앙 감시 체제를 구축하여 Monitoring, Planning 및 분석이 가능하여야 하며 관련 데이터를 보관하여 필요 즉시 활용 가능하게 하는 관리 시스템이다. 다시 말하면, NMS는 네트워크 관리자가 NMS제품을 사용하여 현재 운영되는 workstation으로부터 네트웍을 control and monitor할 수 있게 한다.

1.2 NMS가 하는 일

NMS(network Management System)는 전반에 걸친 정보를 수집 관리하는데 그 목적이 있다. 현재 많은 NMS상품들이 시중에 나와 있고 기본적으로 아래와 같은 공통점을 갖는다.

(1) 네트워크상의 전 장비들의 중앙 감시 체제를 구축하여 Monitoring, Planning 및 분석이 가능하여야 하며 관련 데이터를 보관하여 필요 즉시 활용 가능하여야 한다.
　
(2) SNMP Protocol을 관리Protocol로 사용하며 CMIP으로의 전환 방안이 제시되어야 한다.
　
(3) Ethernet및 FDDI네트워크에 접속되어있는 자원들을 관리할 수 있어야 한다.
　
(4) Graphic User Interface를 지향해야 한다.
　
(5) MIB-1, MIB-2및 타 Vendor Specific MIB을 지원할 수 있어야 한다.
　
(6) 보안성이 우수하고 관리가 용이해야 한다.

통상 NMS는 Workstation급에 Network관리자가 사용하기에 편한 곳에 설치하며 단위 Network에 복수 개의 NMS를 병행할 수도 있다. NMS구동은 SNPM에 의해 작동하며 SNMP(Single Network Management Protocol) System은 NMS, NMS Agent, MIB(Management Information Base) 3부분으로 이루어 진다. SNMP는 Network Device 즉, Routers, Bridges, Terminal Server, Host PC 등에 직접 Query하는 Transaction-Oriented Protocol이다.

NMS는 SNMP Agent에 정보를 의뢰함으로써 Device들을 감시 제어한다. SNMP Agent는 NMS의 요구에 응답하고 Network상의 관리 대상 장비에 존재하는 S/W이다. Agent에는 장비에 관한 정보인 MIB(Routing Table Counter, status indication 등)이 있으며 이들은 Agent에 대한 NMS의 Poll과 Query에 대한 응답으로 NMS에 보내지고 이들은 다시 DB에 저장된다.

본래 의미에서의 네트워크 관리 기능은 아직 사람에게 의지하고 있지만 최근에는 SNMP등의 규격화된 관리용 Protocol을 이용하는 제품이 출하되기 시작했다. 그러나 SNMP을 지원하고 있는 기기만 관리 대상이 되므로 이후 network에 접속되는 기기는 이와 같은 Protocol을 지원하는 추세가 가속화 되고 있다.

2. SNMP 프로토콜

2.1 기본 구성

위에서 말한 바와 같이 SNMP는 다음의 3부분으로 구성되어있다.

　1. 관리대상 (서비스 제공자, Agent)
　2. 네트워크 관리 Station(서비스 이용자, manager)
　3. 네트워크 관리 Protocol

SNMP의 기본관리구조는 그림 5.1과 같으며 서비스 제공자는 Agent로, 서비스 이용자는 Manager로 각각 불린다. 또 SNMP Protocol구성과 SNMP를 사용한 네트워크 관리방법은 그림 5.2와 같다.

SNMP는 IP (Internet Protocol)에서 작동하는 UDP(User datagram Protocol:커넥션형 트랜스포트 프로토콜)에 장치되어 있다. 따라서 SNMP통신을 하기 위해서는 Manager와 Agent모두에게 가IP Address가 필요하다.

<그림 5.1 SNMP의 기본적인 관리구조>

<그림 5.2 SNMP 프로토콜 구성과 SNMP를 사용한 네트워크 관리방법>

2.2 SNMP의 통신 방식

SNMP의 통신은 그림 5.3과 같다. SNMP를 사용한 통신은 SNMP Manager와 SNMP Agent사이에서 MIB(Management Information Base : 관리정보 베이스)를 기초로, 여러 명령어를 사용해서 네트워크를 관리한다.

● 기본 명령어와 동작

명령어

1. GET : 관리정보를 검색하는데 사용된다.
2. GET-NEXT : 관리정보를 연속해서 검색하는데 사용된다.
3. SET : 관리정보를 바꿔쓰는데 사용된다.
4. TRAP : 예외작동을 통지하는 경우에 사용된다.

동작

1. 변수 읽어들이기 : Agent가 가지고 있는 변수를 읽어들인다.
2. 변수 써 넣기 : Agent가 가지고 있는 변수를 바꿔 쓴다.
3. 트랩 : 예상치 못한 사태가 발생했음을 전한다.

이러한 명령어들은 모두 SNMP Manager측에서 발신되지만 SNMP Agent측에서는 장애 등의 예상치 못한 사태가 발생했을 때에만 SNMP Manager에게 trap명령을 통지하는 구조로 되어 있다. 또 SNMP Manager의 SNMP 애플리케이션에는 GUI와 SNMP Manager가 하나로 된 것과 따로 된 것이 있으므로 구입시 주의하여야 한다.

<그림 5.3 SNMP 통신 체제>

2.3 MIB (Management Information Base)

MIB는 SNMP에서 관리하는 정보의 데이터 베이스와 같은 것으로 (관리 항목의 정의 파일 및 표 등이 있는 것), 어떤 항목에 대하여 문의하면 어떤 대답이 되돌아올지를 각각 정해놓고 있다. MIB에는 다음의 세 종류가 있다.

1. MIB-1

MIB-1은 관리정보 베이스로 원래는 MIB라고 불렀으나 MIB의 확장판인 MIB-2가 발표됨에 따라 MIB-2와 구별하기 위해서 MIB-1이라 불리게 되었다.
MIB -1은 네트워크 관리에 필요한 최소한의 관리대상을 정의하고 있는데 그 object는 114개이다.

2. MIB-2

MIB-2는 MIB-1의 확장판으로 MIB-1의 모든 object들을 포함하여 총 171개의 object를 포함하고 있다. 현재 시장에서 제공되고 있는 대부분의 제품은 MIB-2를 지원하고 있다.

3. 확장 MIB

MIB-1, MIB-2에서는 규정되어 있지 않으나, Vendor가 가지고 있는 독자적 기능을 SNMP에서 관리할 수 있도록 정의한 관리 항목이다.

이상으로 근거리 통신망(LAN)의 전반적인 사항을 알아 보았다. 여기서는 데이터 통신의 기본 개념과 네트워킹의 기본, 네트워크 장비 및 인터네트워킹의 개요, 프로토콜, 네트워크 운영체제, 네트워크 관리 시스템 등에 대해 살펴 보았다. 이러한 근거리 통신망의 전반적인 사항은 뒤에서 배울 원거리 통신망의 기본이 된다.

RMON

Network의 효율적 이용을 위해서 현재의 Network 상태를 측정하고 과거의 기록을 토대로 앞으로의 Network 문제를 사전에 예견하고 제거하기 위해서 유용하게 이용되는 것이 RMON(Remote network-MONitoring)이다. 중앙에서 원거리 지역의 local Network의 전체 이용현황을 적은 대역폭으로 쉽게 알수 있게 해준다.

기존의 SNMP MIB들이 대리인(Agent)이 탑재된 장비 자신의 처리 결과만을 보유하고 있는 데 반해서 RMON agent는 한 세그먼트 전체에서 발생하는 트래픽을 파악하게 해준다. 즉 전체 발생 트래픽, segment에 연결된 각 호스트의 트래픽, 호스트들 간의 트래픽 발생현황을 알려준다.

이런 처리를 위해서 RMON agent는 전체 통계 데이타, 이력 데이타(history), HOST 관련 데이타, HOST MATRIX와 사전에 문제 예측 및 제거를 위해서 특정 패킷을 필터링하는 기능과 임계치를 설정해서 이에 도달하면 자동으로 알려주는 경보기능 및 사건 발생 기능을 보유하고 있어야 한다.

Network에서 발생한 트래픽 모두를 관찰하고자해서 나온 것이 Network Moniotor다. 또는 분석기(analayzer), Probe라고 부른다. 이글에서는 SNMP에서와의 혼동을 막기위해서 대리인(agent)라고 칭한다. 실제는 probe라는 말을 많이 쓴다. Network 데이타를 수집하는 Agent는 보통 단독 장비로 또는 W/S, PC/나 hub, switch등의 장비에 탑재하는 경우가 있다.단독 장비는 모든 트래픽을 분석할 수 있으나 별도로 구입해야하므로 비용이 문제고 기존장비에 탑재된 경우는 비용절감 효과는 있으나 장비고유의 업무처리 때문에 트래픽을 정확하게 분석할 수 없는 단점이 있다

RMON이 정의되어있는 RFC1757(구rfc1271)는 주로 RMON MIB에 집중되어 있다.이 문서는 기본적으로 SNMP를 기반으로 한 RMON 대리인과 RMON 관리자간의 각종 절차를 담고 있다. 즉 대리인이 관리자의 요청에 의해서 어떻게 데이타를 채집하고 그리고 그 데이타를 보관하고 어떻게 삭제하는 가에 관한 것이다.

RMON이 갖추어야할 기본적인 목표를 다음과 같이 제시하고 있다.

1) Offline 동작
관리자와 RMON 대리인간의 통신에 여향을 받지 않고 대리인은 해당 세그먼트의 성능, 구성 정보등을 축적하고 관리할 수 있어야한다.

2) Proactive Monitoring
대리인에 주어진 자원에 따라 Network를 진단하고 성능 자료의 이력 관리를 통해서 장애 및 장애에 대한 기록을 관리자에게 보고할수 있어야 한다.

3) 문제 탐지 및 보고
관리자가 특정 상태 - error , 특정 패킷 -에 대한 보고를 명령하면 이를 계속 감시하다가 탐지되면 이 사건을 기록하고 관리자에게 통보할수 있어야 한다.

4) 부가 가치 자료
수집한 자료에 의미있는 가치를 부여할 수 있어야 한다. 즉 가장 많은 트래픽과 에러를 발생시키는 호스트들을 집중 관찰함으로써 문제해결에 대한 세밀한 정보를 관리자에게 줄 수 있다.

5) 복수의 관리자
여러 관리자가 보내는 명령을 모두 수용해야 한다. 이때 대리인의 시스템 용랑에 따라서 즉 메보리 부족등으로 관리자 명령대로 수행을 못하거나 거절하는 경우가 발생할 수도 있다.

RMON 표준에는 관리자가 데이타 수집 명령을 내리지 않았을 때 , 즉 RMON Agent가 동작을 시작하면서 필요한 정보를 수집할 것인지에 대한 기준은 없다. 단지 구현하는 사람의 임의로 정해놓고 있다. 그래서 실제로 어떤 RMON Agent는 관리자가 일정한 데이타의 수집을 요청하지 않으면 전혀 데이타를 수집하지 않는 것도 있다. 대부분은 기본적으로 status , history, host, host matrix 정도의 데이타는 Agent가 스스로 데이타를 수집하기 시작한다.이때는 이 테이블 열(row)의 소유자 ,즉 만든 관리자는 "monitor"라는 이름으로 시작해서 구별할 것을 권장하고 있다.

RFC1757에는 9개의 MIB Group이 정의되어있다. 그러나 구현하는 것은 구현자 임의로 선택할 수 있다. 그러나 한 그룹을 구현하려면 그 그룹내에 있는 모든 객체를 구현해야만 한다. 즉 Host Group를 구현하면 반드시 HostControlTable, HostTable, HostTimeTable 모두를 반드시 구현해야 한다.

그리고 RMON MIB를 구현하기 위해서는 <그림1>의 system과 interface 그룹은 반드시 구현되어야 한다. 이는 RMON MIB에서 두 GROUP에 있는 객체를 이용하고 있기 때문이다. 또한 RMON MIB 각각의 그룹들은 서로 관련이 있는 경우가 많다. 그래서 하나의 그룹을 구현하면 반드시 다른 그룹도 구현해야 한다. HISTORY 그룹은 반드시 statistics 그룹의 구현이 필수다.

RMON MIB 그룹은 모두 테이블 형태다. 대부분의 그룹은 해당하는 객체들을 생성하는 데 필요한 각종 자료 - history 시간 간격, host 그룹의 HOST 수, 자료의 생성자(소유자) 등- 를 가지고 있는 관리(control) 테이블과 실제 필요한 자료를 수집하는 테이블로 구성되어있다. 관리 테이블에는 단순하게 크기를 제한하거나 수집할 자료의 interface를 지시하는 이외에 이 테이블을 포함해서 자료 테이블을 만들고 삭제하게 할 수 있는 "상태(status)" 객체가 정의되어있다.

이 상태 객체를 변경함으로써 테이블의 생성 , 자료 수집, 삭제가 이루어진다. 이 객체가 생성중(underCreation(3)) 상태이면 대부분의 자료 테이블은 완전한 자료가 아니다. 한편 대부분의 관리 테이블은 상태객체가 "valid(1)" 상태이면 관리 테이블의 자료를 수정할 수 없다. 이는 이미 설정된 관리값으로 자료 테이블이 형성된 다음이므로 수정하는 대신에 삭제하고 재설정 또는 생성중 상태로 먼저 수정하고 설정해야 한다.

복수의 관리자에게 대리인이 응답하므로 대리인은 많은 시스템 자원이 필효하게 된다. 복수관리자의 요청을 시스템 자원의 부족으로 거절하는 경우가 생길 수가 있다. 이러한 경우등을 방지하기 위해서는 주관리자가 각 그룹이에 설정될 수 있는 테이블의 열(ROW) 등을 제한하거나 관리자가 불필요하게 설정해 놓은 자원은 스스로 삭제하는 것이 필요하다. 물론 대부분의 대리인은 지나치게 많은 자원이 소모되면 일정한 규칙을 정해놓고 테이블의 열울 삭제한다. 이에 대한 명확한 표준은 없다.

1) 통계(Statistics)
한 세그먼트내에서 발생한 패키/바이트 수, Broadcat/Multicast 수, 충돌(collision) 수 및 패킷 길이별 수 그리고 각종 에러(프래그먼트, CRCAlinment , jabber, 길이미달, 길이초과)에 대한 통계를 제공한다.

2) 이력(History)
관리자가 설정한 시간 간격내에 발생한 각종 트래픽 및 에러에 대한 정보를 제공한다. 기본적으로 단기/장기적으로 간격을 설정가능하고 1~3600초를 간격으로 제한다. 이 자료를 통해 시간대별 이용현황 및 다른 세그먼트와 비교가 가능하다.

3) 경보(Alarm)
주기적으로 특정한 값을 체크하여 기준치(임계치)에 도달하면 관리자에 보고하고 대리인 자신이 기록할 보유하고 있다. 기준치는 절대값및 상대값으로 정할수 있고 계속적인 경보발생을 막기 위해서 상/하한치를 설정해서 넘나드는 경우에만 경보를 발생하게 한다.

4) Host
세그먼트에 연결된 각 장비가 발생시킨 트래픽 , 에러수를 호스크별로 관리한다.

5) 상위 N개의 Host(HostTopN)
위 호스트 테이블에 발견된 호스트 중에서 일정시간 동안 가장 많은 트래픽을 발생시킨 호스트를 찾는다. 관리자는 원하는 종류의 자료(IN/OUT 패킷, 바이트, outErrors, broad/mutiCast 패킷)와 시간 간격 및 원하는 호스트의 갯수를 설정해서 정보를 얻을 수 있다.

6) 트래픽 매트릭스(Matrix)
Datalink layer, 즉 MAC ADDRESS를 기준으로 두 호스트간에 발생한 트래픽 및 에러에 대한 정보를 수집한다. 이 정보를 이용해서 특정 호스트에 가장 많은 이용자가 누구인지를 어느 정도는 알수 있다. 다른 세그먼트에 있는 호스트가 가장 많이 이용했다면 이것은 주로 라우터를 거치므로 실제 이용자는 알 수가 없다.

7) 필터(Filter)
관리자가 특정한 패킷의 동향을 감시하기 위해서 이용한다. 이를 이용해서 트정 패킷의 발생여부를 알 수 있고 경보와 사건(event) 기능을 이용해서 한계치 이상 발생시에 알 수가 있다.

8) 패킷 수집(Packet Capture)
세그먼트에 발생한 패킷을 수집해서 관리자가 분석할 수 있도록 한다. 관리자는 패킷의 전부 또는 일정한 길이만 보관하고 읽어올수 있도록 설정이 가능하다.

9) 사건(Event)
일저한 사건이 발생하면 그 기록을 보관하고 관리자에게 경고(trap) 메세지를 보낸다. 트랩발생 및 기록 보관은 선택적이다. 경보(alarm)와 연관되어서 사건이 발생하면 사건기록 및 트랩 발생은 관리자가 사전에 설정 가능하다.

1) 트래픽 동향분석
통계, 이력, 호스트, 호스트 메트릭스 그룹들을 통해서 얻은 정보를 바탕으로 특정 세그먼트나 특정 장비에 대한 각종 정보를 알수있다. 에러가 발생하는 상황이나 특정 시간대의 트래픽 분석 , 트래픽의 증가 속도등을 측정할 수 있다.

2) 주요 장비에 대한 트래픽 분석
특히 중요한 파일/프린터/메일 서버등에 발생하는 트래픽을 분석 가능하다. 물론 이런 장비는 독자적인 관리 기능을 갖추고 있으나 이 장비의 본래 기능은 아니다. rmon을 통하여 얼마나 많은 접근이 이루어지고 , 어느 호스트가 가장 많이 이용하는가를 알 수 있다. 이것을 서버가 직접 관리하면 많은 부하가 발생한다. 또 어느 시간대에 집중적으로 접근이 발생하는 지를 알 수 있다.

3) 사전 문제 발생 제거
에러나 collision등 Network 성능에 영향을 미칠수 있는 자료를 사전에 체크하여 문제가 발생하기 전에 조치를 취할 수 있게 한다.경보 및 사건 기능을 이용하여 한계치를 위험 수위별로 설정해서 관리하면 많은 도움이 된다.

4) Network 구성 변경 자료
통계 자료를 이용해서 Network의 이용효율을 측정해서 재배치하거나 또는 메트릭스와 HostTopN을 통하여 특정한 흐스트간의 사용빈도와 가장 트래픽이 심한 서버와 같은 host를 스위치같은 장비를 통해서 분리해서 동일한 사용간을 한 그룹으로 만들어서 대여폭을 높일수 있다. WAN 대역폭 등을 계산해서 회선 교환 및 증설을 검토할 수 있다.

5) 미지원 SNMP 장비에 대한 자료 이용
기존에는 SNMP를 지원하지 않는 장비에서 발생한 트래픽을 관찰할 방법이 별로 없었다. RMON은 OSI 데이타링크 레이어를 관리하기 때문에 상위프로토콜과는 무관하다. 그래서 망관리에 대한 기능이 없던 PC등이나 ip가 아닌 ipx등의 장비에 대한 트래픽도 충분히 관찰이 가능하다.

기존에 발표된 RMON으로는 한 세그먼트에 대한 트래픽을 감시하는 데는 적합했다. 그러나 RMON은 MAC 게층까지만 분석이 가능하므로 어떤 프로토콜이 사용되는 지 그리고 어떤 애플리케이션이 Network에 영향을 주는 지는 거의 알수가 없었다. 결국 이런 점을 보완하기 위해서 등장한 것이 RMON2이다. RMON2는 최근에 표준으로 완성되어서 정식 문서로 배포되었다(RFC2021, RFC2074).

RMON2에 추가된 것은 프로토콜별 분포현황 , Network 계층 즉 IP, IPX, DECnet, AppleTalk 등의 호스트별 트래픽을 수집한다. Network 계층의 호스트간의 트래픽을 수집함으로써 애플리케이션, 웹서버와 같은 호스트에 가장 많은 트래픽을 발생시키는 호스트를 찾을 수도 있게 되었다. 그리고 애플리케이션 계층 차원에서 호스트별 트래픽을 감시 및 호스트간 트래픽을 관찰할 수 있다. 그이외에 많은 기능이 추가되었으나 자세한 설명은 RFC를 참조하면 된다.

RMON2가 발표되어서 Network 관리자는 이제 OSI 7 레이어 모두를 관찰할 수 있게 되었다. 그러나 이 모두를 구현하자면 대리인의 시스템 자원이 충분해야하고 성능이 대단해야 한다. 결국은 비용이 문제다. 이 모든 기능을 갖추려면 단독장비로 구성해야 한다. 그러나 요즘 Network 구성이 스위치를 이용해서 세그먼트를 분리하는 방향으로 나아가고 있다. 이때 스위치의 각 포트당 하나의 세그먼트가 되는 데 여기에 하나씩 RMON 대리인을 장착하기에는 비용이 문제다. 이를 해결하기 위해서 대부분의 스위치 장비가 RMON을 탑재하고 있으나 RMON과 RMON2의 모든 기능을 지원하기에는 스위치 본래의 기능에 악영향을 줄 수가 있다. 그래서 대부분 일부분만 지원할 수 밖에 없다.현재 대안으로 나온 것이 스위치의 각 PORT에 연결된 허브에 RMON을 탑재해서 해결하는 방안이다. HUB는 특별한 기능이 없어서 어느 정도는 가능하다.

출처 - http://www.hicore.com/

The Defense Advance Research Projects Agency (DARPA) originally developed Transmission Control Protocol/Internet Protocol (TCP/IP) to interconnect various defense department computer networks. The Internet, an international Wide Area Network, uses TCP/IP to connect government and educational institutions across the world. TCP/IP is also in widespread use on commercial and private networks. The TCP/IP suite includes the following protocols

1. GLBP란..

Cisco 전용 프로토콜로써, MHSRP와 MVRRP에 단점을 보안하여 효울성있게 각각 Host들에게 로드밸런싱을 하여 보내는 방식이다. 라우터들 사이에서 패킷 Load Sharing을 수행하고 동시에 백업라인구성으로 라우터 장애에 대비하게 된다.

2. GLBP Supported Platforms.

Cisco 1700 Series, Cisco 2600 Series, Cisco 3620, Cisco 3631, Cisco 3660, Cisco 3725, Cisco 3725, Cisco 3745, Cisco 7100 Series, Cisco 7200 Series, Cisco 7400 Series, Cisco 7500 Series.

3. GLBP의 개념.

- IEEE 802.3 LAN에서 단일 게이트웨이로 구성된 IP Host들을 위한 자동 라우터 백업을 제공.

- GLBP는 단일 Virtual IP 주소와 여러 개의 MAC주소를 사용하여 여러 라우터에게 Load Balancing 을 제공.

- Host들은 같은 Virtual IP 주소로 설정되고, Virtual Router 그룹 내에 모든 라우터들은 동시에 패킷 스위칭이 가능.

4. AVG(Active Virtual Gateway)

- GLBP 그룹내에 하나의 AVG는 선출되어야 되고, 선출 방법은 HSRP와 VRRP처럼 우선순위가 가장 높은 라우터가 AVG가 되며 그다음 높은 우선순위 라우터가 STandby AVG가 된다. 만약, 같은 우선순위일때는 높은 IP주소를 가지는 라우터가 선출이 된다.

< GLBP의 우선순위 설정 >

// 설정하고자하는 인터페이스 모드에서.. //

Switch(Config-if)#glbp group Priority level Group Number: 0~1023, Priority: 1~255(가장높은값: 255, Default:100)

- AVG는 같은 GLBP 그룹내에 라우터에게 Virtual Mac 주소를 각각 할당.

- 하나의 GLBP 그룹에는 최대 4대의 라우터가 존재 가능.

- PC혹은 서버와 AVF간의 중개자 역할 수행.

- HSRP처럼 현재 Active라우터가 죽을때까지 다른하나의 라우터가 Active상태로 될수 없지만, 현재 AVG의 우선순위보다 더 높은 우선순위를 갖는 라우터가 있다면 Preempt명령어로 Active상태 전환을 허용함.

< Standby AVG에서 Active AVG라우터로의 변환 설정 >

Switch(config-if)#glbp group preempt [delay minimum seconds] []안은 생략 가능함을 말함.

5. AVF(Active Virtual Forwarder)

- AVG로부터 Virtual Mac주소를 할당받은 라우터.

- GLBP는 라우터가 같은그룹내에서 하나의 Virtual Mac 주소를 가진 AVF를 결정하기 위해서 WEIGHT 기능을 사용. 각각의 라우터는 최대 WEIGHT 값(1~254)으로 시작. 특정 인터페이스가 다운이 될때, 그 WEIGHT값은 설정된 값 만큼 감소.

- GLBP는 한 라우터가 AVF가 될때와 AVF가 될수 없수을때 한계치(threshold)를 사용.  만약, 그 WEIGHT값이 낮은 한계치 아래로 떨어진다면, 그 라우터는 AVF역할은 포기. WEIGHT값이 좀 높은 한계치 위로 올라간다면, 그 라우터는 AVF역할을 다시 시작할수 있다. (Default WEIGHT는 100)

- 동적 웨이팅 조정을 원한다면 GLBP는 그 WEIGHT를 조정하기 위한 방법과 이동하기 위한 인터페이스를 알아야 함.

< 이동 되는 인터페이스에서 동적 웨이팅 설정 >

Switch(config)#track Object-number interface type mod/num {line-protocol | ip routing}
Object-number는 WEIGHT 조정을 위해 사용되어지는 임의의 값.(1~500)

조정을 일으키는 조건은 Line-Protocol(인터페이스 line-protocol이 UP인 상태) 혹은 Ip routing(IP Routing이 활성화 되어져 있어야하고, 인터페이스에는 IP가 할당되고 UP이어야한다.) 될수있다.

< GLBP 인터페이스에 한계치 설정 >

Switch(config-if)#glbp group weighting maximum [lower lower] [upper upper]
Maximum weight: 1~254(Default: 100) upper과 lower 한계치는 그 라우터가 AVF가 될수 있을때와 될수 없을때 각각 정의해준다.

< 인터페이스 모드에서 웨이팅값이 조정되어지기 위한 이동을 하기위해 어느 objects인지 알기 위해 GLBP를 설정 >

Switch(config-if)glbp group weighting track object-number [decrement value]
이동 되는 object가 실폐를 할때, 그 웨이팅은 decrement value만큼 감소 되어짐.
(1~254 Default:100)

- Host들은 통신을 하기 위해 MAC 주소를 알아야 한다. Host가 ARP로 요구를 하게 되면 한 라우터의 Virtual Mac 주소를 갖게 되고 Virtual IP를 받아 Host의 ARP 테이블에 등록을 시켜 놓는다.

(각각의 Host는 같은 가상 Ip를 같지만 가상 Mac은 서로 다를수 있다. 이것은 밑에 설명할 GLBP의 로드밸런싱에 따라 달라지게 된다.) Host는 ARP 테이블을 참고하여 하나의 AVF를 선택하여 통신하게 된다.

6. GLBP 로드밸런싱 방법

AVG는 결정론적의 구조에서 클라이언트들로 가상 라우터 MAC 주소를 분배해주는것에 의해 로드밸런싱을 설립한다.  당연히 AVG는 각각의 가상 MAC 주소를 사용하는 그룹안에 AVF들에게 먼저 알려준다. 순차적인 순서로 할당되어진 네개의 가상 MAC주소를 통하여 한그룹 안에서 사용되어진다.

1) Round Robin: Default로 설정 되어 있으며, Host가 Default Gateway MAC을 질의 할때, 다음 이용 가능한 AVF의 가상 주소를 순서대로 받는다. 트래픽 부하는 각각의 클라이언트이 똑같은양의 트래픽을 보내고 받는것으로 간주할때,  그룹내에 AVF들로 역할을하는 모든 라우터들을 통해 균등히 분배되어 진다.

2)Veighted: GLBP 그룹 인터페이스의 Weighting 값은 AVF로 보내어지는 트래픽의 비율을 결정한다. 빈번히 발생하는 ARP에서 더 높은 Weighting 결과들은 그 라우터에 가상 MAC 주소를 포함하여 응답하게 된다. 만약 인터페이스 트래킹이 설정되지 않았다면, 설정되어진 가장 최대 Weighting 값이 AVF들 사이에서 관계적인 비율로 접근하기 위해 사용되어진다. 한마디로 설명하자면 웨이트 비율에 따라 AVG의 가상 MAC주소 응답 비율을 달리하여 응답한다. (장비 성능에 차이 ...etc)

3)HOst-dependent: 가상 라우터 주소를 위해 ARP Request를 발생하는 각각의 클라이언트는 응답에 있어 늘 똑같은 가상 MAC 주소를 받는다. 이 방법은 만약 고정된 Gateway MAC 주소에 대한 요구를 가진다면 사용 되어진다. (달리 말하자면, 한 클라이언트는 Router over time동안 사용중인 로드 밸런싱 방법에 따라 다른 MAC주소들과 함께 회답들을 받는다.) 간단히 요약하자면 특정 PC나 서버에게 항상 특정 AVF의 가상 MAC주소로 ARP를 응답함.

7. GLBP 설정

Switch>enable

Switch#configure terminal

Switch(config)#interface type number

Switch(config-if)#ip address ip-address mask [secondary]

Switch(config-if)#glbp group authentication text string

// 그 그룹에서 다른 라우터들로부터 받은 GLBP패킷들을 인증화한다. (만약 당신이 authentication으로 설정한다면 GLBP 그룹내에 모든 라우터들은 같은 인증 문자열을 사용해야함.) //

Switch(config-if)#glbp group forwarder preempt [delay minimum seconds]

// 현재 AVF보다 더 높은 우선순위를 가진 라우터를 가졌다면, 한 그룹에서 AVF의 역할을 이어 받도록 그 라우터를 설정한다. (기본 delay 시간이 30초) //

Switch(config-if)#glbp group load-balancing [host-dependent | round-robin | weighted]

// GLBP AVG에 의해 사용되어지는 Load balancing의 방법을 명세화한다. //

Switch(config-if)#glbp group preempt [delay minimum seconds]

// 현재 AVG보다 더 높은 우선순위를 가진 라우더를 가졌다면,  한 GLBP그룹을 위해 AVG의 역할을 이어 받기 위해 그 라우터를 설정한다. ( 이 명령어는 기본 비활성화되어져 있다.) //

Switch(config-if)#glbp group priority level

// GLBP그룹내에서 게이트웨이의 우선순위 수준을 정한다 (Default value: 100) //

Switch(config-if)#glbp group timers [msec] hellotime [msec] holdtime

// 한 GLBP그룹에서 AVG에 의해 보내어진 성공적인 hello packet들의 사이의 간격을 설정한다. ( holdtime 인수는 hello 패킷에서 가상 게이트웨이나 가상 전송자 정보가 무효하게 설정되어지기 전에 초단위로 간격을 명세화한다. msec 키워드는 기본 초단위전송이 아닌 1/100초 단위로 표현되어 질것이다.) //

Switch(config-if)#glbp group timers redirect redirect timeout

// AVG가 하나의 AVF로 클라이언트들의 방향을 고쳐 나가도록 계속하는동안 시간 간격을 설정한다. (timeout인수는 두번째 가상 전송자가 효력이 없어지기전에 초단위로 간격을 명세화한다.) //

라우터 백업을 가능하게 하는 HSRP프로토콜.

디폴트 게이트 웨이 역할을 하는 라우터가 고장났을때 다른 라우터가 있더라도 디폴트레이트웨이가 고장난 라워로 설정되어 있으므로 멀쩡한 라우터를 사용할 수 없다.

그래서 디폴트 게이트웨이 역할을 하는 라우터가 고장 났을때 고장이 나지 않은 다른 라우터를 사용하기 위해서 시스코 라우터는 HSRP를 사용한다.

PC들은 HSPR 상에서 여러대의 라우터들을 하나의 라우터로 보는데 이것을 버추얼 라우터라고 한다. 각 라우터가 가진 실게 IP주소와 MAC주소 외에 버추얼 라우터도 하나의 IP주소와 MAC주소를 가진다. PC에서는 버추얼 라우터 주소를 디폴트게이트웨이의 주소로 구현한다. 버추얼 라우터의 IP 주소와 MAC 주소를 공유하는 라우터들은 액티브 라우터와 스탠바이 라우터로 나뉘는데, 액티브 라우터가 고장났을 때 스탠바이 라우터가 액티브 라우터 역할을 대신한다.

HSRP는 한개 이상의 그룹으로 나눌 수 있다. 왜냐하면 항상 하나의 그룹으로 묶으면 항상 한 라우터는 사용해야 하고, 다른 라우터는 쉬어야 하는데 이것은 합리적이지 않기 때문이다.  이렇게 HSRP를 여러개의 그룹으로 나누어 라우터 간에 부하를 분산하는 것을 MHSRP라고 한다.

HSRP가 시스코 프로토콜인데 반해 VRRP는 표준 프로토콜이다. 기능상으로는 둘이 같다.

GLBP의 기능도 HSRP, VRRP와 비슷. HSRP, VRRP는 한 서브넷 내에서 하나의 그룹 번호만 사용해 두대 중 한대의 라우터만 쓰레되면 트래픽 로드가 라우터 한대로 집중된다. 그래서 MHSRP, MVRRP를 사용하는데 HSRP와 VRRP에서는 MHSRP, MVRRP라고 별도로 구현해 주어야 하지만,  GLBP는 따로 구현재 주지 않아도 된다.

GLBP내의 로드 밸런싱 방법에는 3가지가 있다.

라운드로빈 :

가장 간단한 방법. pc, 서버가 디폴트 게이트웨이 mac 주소를 알고자 ARP 요청을 보내면 AVF의 버추얼 MAC 주소를 순서대로 알려준다.

WEIGHTED :

AVF 마다 다른 WEIGHT를 구현했을 때의 방법. 웨이트 비율에 따라 AVG의 버추얼 MAC 주소 응답 비율이 달라진다. 따라서 특정 AVF가 다른 AVF보다 트래픽을 많이 처리할 수도 있고, 그 반대일 수도 있다.

HOST-DEPENDENT :

특정 PC, 서버에게는 항상 특정 AVF의 버추얼 MAC주소로 ARP응답을 하는것.

AVG : Active Virtual Gateway, GLBP그룹내의 가장 높은 proirity를 가진 라우터.

AVF : Active Virtual Rorward. 일반 라우터