본문 바로가기
조회 수 5134 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

+ - Up Down Comment Print
?

단축키

Prev이전 문서

Next다음 문서

+ - Up Down Comment Print

http://cafe.naver.com/neteg/80968


VII. Security

 

 

보안은 원래 상당히 광범위한 개념으로 논리적 보안, 물리적 보안의 섹터를 모두 다루고 있으며, 인류 기원과 함께 다양한 분야에서의 보안에 대한 니즈(needs)와 그에 대한 솔루션들이 제공되어지고 있다. 그러나 CCIE 시험에서 다루는 Security , 보안의 범위는 IP 네트워크에서의 보안을 다루고 있다.

<?xml:namespace prefix = o /> 

보안의 목적은 일반적으로 CIA라고도 불리는 기밀성(confidentiality), 무결성(Integrity) 그리고 가용성(Avaiability)로 나뉘어 진다. 기밀성은 중요한 정보에 대해 허가된 사람에게만 노출됨을 의미하고, 무결성은 정보의 전달과정에서 최초의 데이터가 왜곡되지 않음을 의미하며 가용성은 해당 정보가 정당한 사용자에게 언제라도 제공되어질 수 있어야 함을 의미한다.

 

IP 네트워크에서 기밀성을 보장하기 위해서는 VPN(Virtual Private Network), SSH등의 패킷 암호화 기술을 지원한다. 무결성을 위해서는 MD5 SHA등의 해쉬 함수를 사용하는 방법이 적용된다. 가용성을 위해서는 서비스 거부 공격(DoS)에 대한 방어 기술이나 HSRP와 같은 다양한 이중화 기법들이 사용되어 진다.

 

아래는 CCIE 시험에서 다루어지는 Security 기술에 대한 출제 범위이다. 사실 보안을 위해서는 네트워크 전체 기술에 대한 광범위하고도 심층도 깊은 이해가 필요하다. 이 모든 것을 다루기는 어려우므로 여기서는 중요한 내용 위주로 기술하고 단순한 부분은 개념만 이해하고 넘어가기로 한다. 또한 앞서 라우팅이나 IOS Feature등에서 이미 거론했었던 기술들은 과감히 생략하기로 하겠다.

 

[표 – Security 출제 범위]

Security

Access-list

Zone Based Firewall (설명 생략)

Unicast Reverse Path Forwarding (uRPF)

IP Source Guard (설명 생략)

AAA

CoPP

Cisco IOS Firewall

IPS (설명 생략)

SSH

802.1x

NAT (설명 생략)

Routing Protocol Authentication (설명 생략)

Device Access Control (설명 생략)

Security Features (설명 생략)

 


 

1. access-list

 

여기서는 시스코 라우터상에서 엑세스 리스트(ACL)와 엑세스 그룹을 사용하여 네트워크상의 위협(threat)과 공격(attack)을 방어하는 방법을 알아보자. ACL은 일반적으로 외부 네트워크에서 유입되는 패킷을 라우터상에서 차단하여 내부의 네트워크를 보호하는 일종의 파이어월(firewall) 기능을 제공한다.

 

 

 

1) 엑세스 리스트 생성

 

엑세스 리스트는 다음과 같이 네가지 종류가 있다.

 

[엑세스 리스트 종류]

구분

종류

ACL 번호

사용 속성

넘버드

(numbered)

스텐다드

(standard)

1~99

1300~1999

소스 IP

익스텐디드

(extended)

100~199

2000~2699

소스/데스티네이션 IP

소스/데스티네이션 TCP/UDP 포트

프로토콜 타입(IP, ICMP, UDP, TCP )

네임드

(named)

스텐다드

(standard)

문자

소스 IP

익스텐디드

(extended)

문자

소스/데스티네이션 IP

소스/데스티네이션 TCP/UDP 포트

프로토콜 타입(IP, ICMP, UDP, TCP )

 

ACL은 한 라인 이상으로 구성되며, 각 라인별로 IP 패킷의 패턴에 대한 서술과 이에 대한 허용(permit) 또는 거부(deny) 정책이 반드시 기재되어 있다. ACL이 여러 라인으로 구성되어 있다면, 관심 트래픽이 되는 패킷을 top down 방식으로 윗줄부터 차례로 대응해 보고 매치되는 라인이 있으면 그 라인의 허용 또는 거부 정책에 따라 포워딩 여부가 결정된다. 패킷이 ACL의 마지막 라인까지 매칭되지 않으면 묵시적으로 거부로 처리된다.

 

, ACL의 마지막 라인에는 눈에 보이지 않더라도 관리자의 정의와 관계없이 언제나 ‘deny all’ 라인이 존재한다. 만약 모든 라인에 패킷이 해당되지 않을 경우, 그 패킷을 포워딩 해야 한다면 마지막줄에는 항상 ‘permit any’ 또는 ‘permit ip any any’ 구문이 와야 한다. 사실 기술할 필요는 없지만 마지막줄에 ‘deny any’ 또는 ‘deny ip any any’를 추가하는 경우가 있는데, 이는 최종적으로 deny 된 패킷을 카운트하기 위해서이다.

 

네임드 익스텐디드 엑세스 리스트는 소스/데스티네이션 IP, 포트 번호, 프로토콜 등을 모두 취급할 수 있고, 또한 넘버드 엑세스 리스트처럼 번호도 사용이 가능하기 때문에 가장 광범위하게 사용할 수 있기 때문이다. 또한 넘버드 엑세스 리스트와는 달리 라인별로 시퀀스 넘버가 자동적으로 생성되므로 향후 라인별 관리 즉, 추가/삭제가 상당히 용이하다. 라인별 생성된 시퀀스 넘버는 10, 20, 30, 40 등의 순으로 생성되는데, 라인 시퀀스 넘버 35로 설정하면 30 40 사이에서 프로세싱이 진행된다. 특이한 점은 라우터를 재부팅하면 시퀀스 넘버는 자동으로 35 40으로, 40 50으로 밀려서 변경된다. 네임드 엑세스 리스트를 사용하면 알파벳 문구로 이름을 줄 수 있지만 ‘in’ ‘out’ 라는 이름은 IOS에서 거부된다. 참고로 IOS XR을 사용하는 시스코사의 CRS-1 같은 라우터들은 시스템 퍼포먼스가 상당히 뛰어난 관계로 네가지 엑세스 리스트 중에 가장 시스템 리소스를 많이 점유하는 네임드 익스텐디드 엑세스 리스트한가지만 지원한다. IOS XR은 현재 CCIE 시험과 무관하다.

 

[ - 엑세스 리스트 명령어]

구분

종류

명령어

넘버드

스텐다드

access-list 1 permit 1.1.1.0 0.0.0.255

익스텐디드

access-list 100 permit ip any 1.1.1.0 0.0.0.255 eq 80

access-list 100 permit ip 1.1.1.0 0.0.0.255 eq 80 any

네임드

스텐다드

ip access-list standard NUMBERED-STANDARD

 permit 1.1.1.0 0.0.0.255

익스텐디드

ip access-list standard NUMBERED-EXTENDED

permit ip any 1.1.1.0 0.0.0.255 eq 80

permit ip 1.1.1.0 0.0.0.255 any eq 80

 

참고로 만약 특정 호스트에 대해서만 ACL을 적용하려 한다면 와일드 마스크를 ‘1.1.1.1 0.0.0.0’ 처럼 설정하면 되지만, ‘host’ 라는 명령어를 사용하여 ‘host 1.1.1.1’ 처럼 설정해도 된다. , ‘access-list 1 permit 1.1.1.0 0.0.0.255’ 라는 구문은 ‘access-list 1 permit host 1.1.1.1’로도 표현이 가능하다. ‘host’ 명령어는 모든 ACL에서 사용이 가능하다.

 

 

 

2) 엑세스 리스트 적용

 

앞서도 언급했듯이, ACL은 그 자체로는 아무런 효력을 발휘하지 못하고 단순히 관심 트래픽이 매칭 되느냐, 그렇지 않느냐 하는것만 측정할 수 있다. 실제 패킷을 라우터상에 유입시킬 것이냐, 또는 유출시킬 것이냐 하는 것은 인터페이스에서 ‘access-group’ 명령어를 사용하여야 하기 때문이다. 인터페이스에서 ‘access-group’을 적용할 경우에는 ‘in’ 또는 ‘out’ 방향으로 설정할 수 있다.

 

일반적으로 ‘in’ ACL에서 취급하는 패킷의 목적지에 가까운 라우터에서 설정하고 ‘out’은 패킷의 최초 유입지에 가까운 곳에서 설정하는 것이 유리하다. 일반적으로 익스텐데드 엑세스 리스트는 스텐다드 엑세스 리스트의 기능을 포함한다. 그러나 관심 트래픽에 대해 소스 IP만 취급해도 될 경우에는 패킷의 앞부분만 확인해도 되는 스텐다드 엑세스 리스트를 사용하는 것이 시스템 리소스를 아끼는데 유리하다. 인과 아웃 어떤 방향에 적용해도 무방하다면 가급적 인으로 설정하는 것이 유리하다. 이유는 인에서 설정하면 패킷의 유입 자체를 막아 버리므로 향후에 발생할 불필요한 프로세싱이나 대역폭 점유를 사전에 방지할 수 있기 때문이다.

 

[엑세스 리스트 방향]

구분

명령어

설명

인바운드

In

라우터의 인터페이스로 들어오는 데이터 흐름

아웃바운드

out

라우터의 인터페이스에서 외부로 나가려는 데이터 흐름

 

위에서 작성한 ACL을 인터페이스에 적용해 보자. 넘버드 ACL의 경우에는 스텐다드, 익스텐디드 여부에 관계없이 ‘access-group’ 명령어 뒤에 적용할 ACL 번호를 기재한 후에 적용 방향을 지정하면 된다. 네임드 ACL의 경우도 마찬가지로 ‘access-group’ 명령어 뒤에 적용할 ACL 이름을 기재한 후에 적용 방향을 지정하면 된다.

 

[엑세스 그룹 설정]

구분

방향

명령어

넘버드 ACL 적용

인바운드

interface FastEthernet0/0

 ip access-group 1 in

아웃바운드

interface FastEthernet0/1

 ip access-group 100 out

네임드 ACL 적용

인바운드

interface FastEthernet0/0

 ip access-group NUMBERED-STANDARD in

아웃바운드

interface FastEthernet0/1

 ip access-group NUMBERED-EXTENDED out


 

 

2. Unicast Reverse Path Forwarding (uRPF)

 

네트웍 보안에는 시스템 가용성에 대한 직접적인 공격이 있는데, 이를 DoS(Denial of Service) 공격라고 한다. DoS 공격은 일반적으로 트리거(Trigger) 공격과 플루드(Flood)의 두가지 유형이 있다. 트리거는 운영 체제나 어플리케이션의 취약점을 이용하여 공격하는 방법이고, 플루드는 일반적인 서비스 기능을 이용하되, 비정상적으로 과다한 트래픽을 발생시켜 시스템의 가용성을 헤치는 방법이다.

 

트리거 공격에는 유명한 ‘Land’ 공격이 있는데, 이는 공격자(크래커)가 패킷의 source IP destination IP를 동일하게 설정한 SYN 패킷을 만들어서 보내는 방식이다. 플루드 공격은 일반적으로 인터넷 익스르포러 창에서 화면 새로고침을 위해 F5번 키를 자주 누르는 것과 같다.

 

스푸핑(spoofing)이라는 단어가 속이다는 의미를 가진 것처럼, IP 스푸핑은 TCP/IP 프로토콜의 약점을 이용하여 자신의 IP를 속임으로써 보안 위협을 가하는 기법이다. IP 스푸핑을 막기 위해서는 외부에서 라우터로 들어오는 패킷중에서 출발지 IP주소(Source IP Address)에 내부망 IP주소를 가지고 있는 패킷을 필터링을 사용하여 막아낼 수 있다. uRPF는 이를 위한 대표적인 기법이다.

 

[– uRPF 설정]

구분

명령어

문제

R1에서 S0/0 인터페이스로 유입되는 패킷중에 Source IP가 자신의 라우팅 테이블에 존재하는 것만을 전송하고 나머지 패킷은 폐기한 후에 로그를 남기도록 설정하라.

R1

access-list 100 deny ip any any log-input (or log)

 

interface S0/0

 ip verify unicast reverse-path 100

 


 

3. AAA

 

AAA는 기존의 라우터상에서 구현되는 CLI 기반의 인증보다 더 높은 수준의 확장성을 제공하는 인증과 관련된 서비스이다. AAA는 인증(authentication), 인가(authorization), 어카운팅(accounting)의 약자로 사용자에 대한 식별, 허용 가능한 권한 수여, 접근에 대한 기록과 감사가 그 주된 목적이다. 이는 일반적으로 네트워크상의 장비 또는 서비스에 대해 허가받지 않은 접근 시도를 방지하기 위해 제안된 아키텍처이다. 물론 AAA를 사용하지 않더라도 네트워크 장비등에서 어느 정도 보안의 구현이 가능하다. 그러나 앞서도 설명했듯이 라우터 단위의 보안 설정 기능에 대한 한계가 있고 수많은 네트워크 자원과 수많은 사용자들에 대한 관리가 필요할 경우에 대한 한계도 분명 존재한다. 결국 AAA는 이러한 라우터와 같은 네트워크 장비들의 기능이나 관리에 대한 한계를 극복하고 확장성을 제공하기 위해 제안되어 진다.

 

 

 

1) AAA 모델

 

그럼 AAA 모델의 요소 3가지에 대해 알아보자. 인증(authentication)이란 사용자나 관리자가 정말로 맞는지 증명하는 과정이다. 인증에서는 다양한 방법을 사용하는데 일반적으로 유저네임(username)과 패스워드가 맞는지를 확인한다. 인가(authorization)란 인증 이후에 진행되는 과정으로, 접근한 사용자 또는 관리자에게 허가되어 질 수 있는 자원 또는 권한을 제공하는 과정이다. 예를들어 관리자에게는 라우터의 글로벌 설정 모드에 대한 접근 및 설정 권한을 주고, 일반 사용자에게는 단순히 모니터링 기능만을 주는 행위를 의미한다. 어카운팅(accounting)은 일반적으로 감사(auditing) 기능과 병행이 되는데, 사용자나 관리자의 접속 여부, 접속후 행위, 접속 시간등에 대해 기록을 남기고 후에 감사하기 위한 용도로 사용되어 진다. 쉽게 말해서 사용자나 관리자가 시스템에 로그인한 순간부터 로그아웃 할 때까지의 모든 행위에 대한 로그를 남기는 것이다.

 

 

 

2) AAA 구현 방법

 

이번에는 시스코 장비상에서 AAA를 구현는 방법을 알아 보자. AAA를 구현하는 방법은 3가지가 있다. 물론 가장 기초적인 작업으로 시스코 라우터상에 AAA를 사용하겠다는 관련 명령어를 입력하면 된다. 중요한 것은 이때 AAA 정책을 어떤 장비의 DB에 저장시킬 것인가 하는 것이다. 일반적으로 두가지 방법이 있는데, 라우터 자신의 로컬 DB에 저장하는 방법과 외부 서버의 DB에 저장하는 방법이 있다. 일반적으로 시스코사의 ACS 서버와 같은 외부 인증 서버의 DB에 저장하는 경우가 있다.

 

로컬 서버의 DB AAA 관련 정보를 저장하는 경우는 어떤 경우일까? 아무래도 소규모 네트워크이고 유저네임과 패스워드는 시스코 라우터에 저장된다. 그러므로 사용자에 대한 인증은 라우터의 DB에 의존하게 되므로 외부 서버나 DB는 필요가 없다.

 

[그림 로컬 인증]

 

 

사용자가 라우터에 인증 요청시, 라우터가 로컬 DB를 이용하여 직접 인증한다.

 

이에 반하여 수많은 라우터와 수많은 사용자가 존재하는 대규모 네트워크에서는 인증을 별도로 담당하는 외부의 서버를 두는 것이 유리하다 이 경우 외부의 TACACS+ RADIUS 같은 프로토콜을 사용하는 인증 서버는 단순히 사용자에 대한 인증뿐만 아니라 권한 관리 및 어카운팅도 보다 명확히 관리할 수 있다.

 

[그림 외부 서버 인증]

 

사용자가 라우터에 인증 요청시, 이는 라우터에 정의된 외부 서버에 의해 대행된다.

 

 

 

3) AAA 설정

 

CCIE R&S 시험에서는 ACS 같은 외부의 서버에 대한 설정은 요구하지 않는다. , 라우터에 대한 명령어 설정만 명확히 알고 있으면 되는데, 일반적으로 AAA 중에서도 인증(authentication) 위주로 출제된다. 시험장에서 사용되는 IOS에서 AAA 기능을 사용하기 위해서는 글로벌 모드에서 ‘aaa new-model’ 명령어를 실행시켜야만 관련 명령어가 사용 가능한 상태가 된다. 라우터의 경우 콘솔 접속과 텔넷접속 등 모두에 AAA를 설정할 수 있는데, 아래는 텔넷 접속에 대한 AAA 설정 사례이다.

 

[– AAA 설정 방법]

구분

명령어

로컬 DB

username username password password

!

aaa new-model

aaa authentication login default local

!

line vty 0 4

 login local

외부 서버

(RADIUS)

username username password password

!

aaa new-model

aaa authentication login default group radius

radius-server host a.b.c.d

radius-server key key

!

line vty 0 4

login authentication default

외부 서버(TATACS+)

실패시 로컬DB 사용

username username password password

!

aaa new-model

aaa authentication login default group tacacs+ local

tacacs-server host a.b.c.d

tacacs-server key key

!

line vty 0 4

login authentication default

 

 

 

4) RADIUS & TACACS+

 

외부 인증서버를 사용하기 위한 대표적인 보안 프로토콜로는 RADIUS TACACS+, 그리고 Kerberos가 있다. 이중에서 Kerberos의 경우 CCIE R&S에서 다루지 않으므로 논외로 두고 ACS 서버가 지원하는 RADIUS TACACS+ 프로토콜 정도만 이해하면 된다. 그러나 앞서 설명했듯이 여기서는 직접적인 서버 설정은 불필요하므로 단순한 개념과 라우터에서 명령어 설정만 이해하고 넘어가도록 하자.

 

RADIUS(Remote Access Dial-In User Service)RFC에서 정의한 표준 프로토콜로 접근 서버 인증과 어카운팅 프로토콜로 개발되었다. RADIUS UDP를 사용하는 클라이언트/서버 프로토콜로서 TACACS+에 비해 CPU 부하가 적고 메모리 점유율도 낮다. TACACS+(Terminal Access Controller Access System Plus)는 시스코에서 개발하였으며 인증, 인가 어카운팅 기능을 분리할 수 있는 프로토콜이다. 이는 RADIUS와는 다르게 TCP를 사용하지만 클라이언트/서버 모델인 점은 유사하다. TACACS는 원래 세가지 타입이 존재한다. TACACS TACACS의 최초 버전으로 인증만 처리할 수 있다. XTACACS(eXtended TACACS)는 인증뿐만 아니라 어카운팅 기능도 수행할 수 있다. TACACS+는 앞서 설명했듯이 AAA의 모든 구성요소를 지원하고 TCP를 사용하여 안정성도 높으므로 가장 보편적으로 사용되어지고 있다.

 

[– RADIUS vs TACACS+ 비교]

구분

RADIUS

TACACS+

기능

인증, 인가

인증, 인가, 어카운팅

전송 프로토콜

UDP

TCP

CHAP

단방향

양방향

지원 프로토콜

no ARA, no NetBEUI

멀티 프로토콜 지원

보안

패스워드 암호화

전체 패킷 암호화

어카운팅

확장 가능

제한적


 

 

4. CoPP

 

CoPP‘Control Plane Policing’의 약자로 시스코 라우터나 스위치를 제어하는 컨트롤 플레인 즉, CPU 모듈에 대한 보안을 위한 기능이다. 최신 제품들은 일반적으로 ASIC에 의한 분산 아키텍처를 수행하지만, 일반적으로 시스코의 카탈리스트 스위치 제품군은 Supervisor 모듈에서, 라우터 제품군은 RP(Routing Processor) 모듈에서 중앙집중적으로 제품을 관리한다. 이런 사유로 시스코 제품군의 SUP이나 RP같은 컨트롤 플레인이 다운되면 다운되면 시스템 전체의 장애가 유발되므로 이에 대한 심도깊은 보안이 별도로 필요하다.

 

CoPP에 대한 설정은 일반적으로 MQC(Modular QoS CLI)로 설정한다. 이런 사유로 ACL, class-map, policy-map을 작성하면 된다. 적용은 특정 인터페이스가 아니라 컨트롤 플레인 즉, CoPP 그 자체에서 하며 유입되는 방향으로 설정하면 된다.

 

일반적으로 시스코 제품은 CoPP 기능을 통하여 컨트롤 플레인으로 향하는 관리자가 정한임계치 이상의 이상 패킷이 유입될 경우, 이를 드롭시키는 방식 즉, 폴리싱(policing)으로 보안을 허가한다. CoPP를 설정하는 방법은 MQC와 유사하며, 적용시에는 인터페이스 대신에 ‘control-plane’ 항목 하단에서 설정하면 된다. 가끔 시험에서 policy-map 이름을 ‘CONTROL-PLANE’ 처럼 반드시 case-sensitive(대소문자 구분)하게 하라고 출시되기도 한다. 물론 CoPP는 컨트롤 플레인으로 유입되는 트래픽에 대한 패킷 방어만이 목적이므로 항상 ‘input’ 방향으로 적용하면 된다.

 

[– CoPP 설정 방법]

구분

명령어

문제

Source IP 1.1.1.1 telnet만 트래픽은 제한없이 컨트롤 플레인 쪽으로 유입될 수 있고, 나머지 telnet traffic들은 200Kpolicing 시켜라. 그리고 policy-map 이름은 ‘CONTROL-PLANE’로 대소문자를 구분(case-sensitive)하여 정확히 입력해라.

설명

Source IP 1.1.1.1인 패킷에 대해서는 폴리싱을 적용할 필요가 없으므로 deny로 설정하고, 나머지 패킷에 대해서는 폴리싱을 적용하면 된다.

ACL

access-list 111 deny tcp host 1.1.1.1 any eq telnet

access-list 111 permit tcp any any eq telnet

class-map

class-map CLASS-COPP

 match access-group 111

policy-map

policy-map CONTROL-PLANE

class CLASS-COPP

 police 200000 conform-action transmit exceed-action drop

적용

control-plane

service-policy input CONTROL-PLANE

  

 


5. Cisco IOS Firewall

 

시스코 라우터에서는 일반적으로 네트웍들을 연동시켜 주는 게이트웨이 역할 뿐만 아니라 기본적인 보안을 위한 방화벽(firewall) 기능도 제공해 준다. 시스코 라우터를 구동하는 IOS에서는 일반적으로 access-list를 사용하여 방화벽 기능을 제공하는데, 여기에는 다음과 같은 다양한 기술이 존재한다.

 

[– Cisco IOS Firewall 종류]

구분

설명

ACL

Source IP, Destination IP, 포트 넘버등을 이용하여 인터페이스 등에서 유입 또는 유출되는 패킷의 permit deny 여부를 수행한다.

Lock-and-Key

Telnet 세션을 통해 접근 목록에 대해 인증을 할 수 있다.

Reflexive ACL

내부 네트웍에서 외부로 보낸 패킷에 대한 응답 패킷만을 어용함으로써 보안을 강화할 수 있다.

Context-based

ACL (CBAC)

라우터를 통과하는 모든 세션에 대한 세부 상태 테이블을 관리하여 강력한 보안을 제공한다.

Port to Application Mapping (PAM)

호스트 단위로 설정이 가능하며 비표준 포트에서 동작하는 서비스를 CBAC로 제어할 수 있다.

 

여기서는 Lock-and-Key, Reflexive ACL, CBAC에 대해서만 간단히 기술하기로 한다.

 

 

 

1) Lock and Key

 

앞서 언급하였듯이 Lock-and-Key telnet 세션을 통해 접근 목록에 인증을 하는 기능으로dynamic access-list라고도 불리운다. 클라이언트(라우터C)에서 서버(라우터A)로의 직접적인 Telnet 세션은 불가 하더라도, 신뢰된 Lock-and-Key 라우터(라우터B)에 접속하여 인증을 받으면 클라이언트에서 서버로 접속이 가능한 구조이다. 이는 일반적으로 autocommand 기능과 함께 사용되며 access-enable 명령어를 사용하여 특정 호스트만에 기능 적용이 가능하다. 설정방법은 다음과 같다.

 

[– Lock-and-Key 설정 방법]

구분

명령어

R1

! Lock-and-Key를 위한 dynamic access-list 설정

username cisco password ccie

ip access-list extended LOCKANDKEY

 permit tcp any host 1.1.1.1 eq telnet

 dynamic LAK permit ip any any

 deny ip any any

 

Interface F0/0

 Ip access-group LOCKANDKEY in

 

! 외부에서 Telnet 접속시 Lock-and-Key를 동작시키는 설정

line vty 0 4

 login local

 autocommand access-enable host timeout 10 (히든 명령어; 10)

 

참고로 ‘autocommand’ 명령어 부분은 히든 명령어로 라우터에서 ‘?’ 입력시에도 보이지 않는다.

 

 

 

2) Reflexive ACL

 

Reflexive(재귀) ACL 내부 네트워크에서 외부로 보낸 패킷에 대한 응답 패킷만을 허용함으로써 보안을 강화하는 기법이다. 이는 방화벽 개념과 유사한데, 설정사항에 따라서 외부 네트워크에서 발생된 트래픽은 내부로의 유입이 허용하지 않게 할 수 있다. , 내부에서 외부 네트워크로 TCP 패킷이 나갈때 reflexive ACL로 인해 임시적인 ACL이 항목에 생성되기 때문에, 외부로 나가는 트래픽에 대응하는 트래픽만이 내부로 들어오는 것을 허용한다.

 

다만 이는 네트웍으로 유입되는 트래픽중에 Layer 4 계층 정보만을 검사하므로 FTP와 같은 어플리케이션을 제대로 검사하지 못하는 단점이 있다. Reflexive ACL Inbound ACL, Outbound ACL 그리고 Reflexive ACL의 세가지 영역으로 나뉘어 진다.

 

[– Reflexive ACL]

구분

명령어

R1

! to Outbound 트래픽 설정

ip access-list extended TO_OUTBOUND

permit ospf any any (허용되는 트래픽)

permit icmp any any (허용되는 트래픽)

permit tcp any any reflect ACL (리턴 허용 트래픽)

 

! to Inbound 트래픽 설정

ip access-list extended TO_INBOUND

permit ospf any any (허용되는 트래픽)

permit icmp any any (허용되는 트래픽)

permit tcp any eq telnet any (허용되는 트래픽)

evaluate ACL (리턴 허용되는 트래픽)

 

! 인터페이스에 Reflexive ACL 적용

interface S0/0

ip access-group TO_OUTBOUND out

ip access-group TO_INBOUND in (Reflexive ACL 적용)

 

 

 

3) Context-based ACL (CBAC)

 

CBAC IOS에서 상태감시(Stateful) 방화벽 기능을 제공하며 OSI 3/4/7 계층에 대한 TCP/UDP 세션정보를 바탕으로 필터링이 가능하다. CBAC은 라우터를 통과하는 모든 세션에 대한 상태 테이블을 만들어 관리기 때문에 FTP와 리얼오디오 같은 어플리케이션 계층의 데이터까지도 읽을 수 있어 4계층까지만 검사하는 Reflexive ACL과 달리 어플리케이션까지 검사가 가능하고 이로 인한 트래픽 필터링 기능을 제공하므로 자바(java) 애플릿에 대한 필터링 까지도 가능하다. 또한 특정 트래픽을 검사하여 침입탐지 기능도 수행하여 필요시 경고 및 감사 메시지를 생성할 수도 있다.

 

CBAC은 라우터에서 패킷이 유입되거나 나갈 때 이에 대한 세션 정보를 기록하기 때문에 리턴 트래픽에 대해 임시적인 dynamic ACL을 작성하고 이를 extended ACL의 최상단 즉, 첫머리에서 적용하게 한다. 참고로 CBAC만 설정하면 모든 트래픽이 허용된다. 그러므로 CBAC 관련 트래픽은 CBAC에서 제어하고, 나머지 트래픽은 ACL을 사용하여 트래픽을 제어하도록 해야 한다.

 

[– CBAC 설정]

구분

명령어

R1

! CBAC 설정

ip inspect name CBAC icmp (리턴 icmp 허용)

ip inspect name CBAC telnet (리턴 telnet 허용)

ip inspect audit-trail (감사 설정)

 

! ACL 설정

ip access-list extend ACL

 permit ospf host 1.1.1.1 any

 deny ip any any

 

! 인터페이스에 ACL CBAC 적용

interface F0/0

 ip access-group ACL in

 ip inspect CBAC out

 

위의 경우 F0/0을 통해서는 일부의 OSPF 패킷만 유입될 수 있지만, CBAC을 통해 내부에서 발생되어 외부로 전달된 icmp telnet 패킷에 대한 리턴 패킷은 유입을 허용한다.

 

 

6. SSH

 

SSH Secure Shell의 약자로 일반적으로 Telnet와 유사하지만 보안이 더욱 강화된 프로토콜이다. Telnet는 서버와 클라이언트간에 암호화 되지 않은 클리어 텍스트(clear text) 형태로 통신을 하는 프로토콜이다. 네트웍에서는 일반적으로 라우터나 스위치가 서버의 형태를 띄고, 제어하는 콘솔 PC나 또 다른 억세스 라우터/스위치 등이 클라이언트의 형태를 띄며 일반적으로 TCP 포트 23번을 사용한다.

 

SSH Telnet과 유사한 방식이지만, 서버와 클라이언트간의 통신 내용이 암호화 되어 있어 보안에 더욱 강하며 일반적으로 TCP 포트 22번을 사용한다. SSH는 버전 1 2가 있으며 일반적으로 시스코 라우터는 관리자에 의한 접속 보안을 위해 대부분 SSH 서버와 클라이언트 기능을 모두 지원한다.

 

[– SSH 설정 방법]

구분

명령어

문제

R2 loopback0 2.2.2.2에서만 R1으로 SSH 접속이 허용되게 설정하여라. 이때 username rack1, password ccie이며 domain-name rack1.cisco.com으로 설정하라. 또한 SSH 관련 log를 발생시켜라.

설명

R1 SSH 서버로 동작해야 하며, 클라이언트 접속을 위한 계정을 먼저 만들어야 한다. R1에서 SSH 서버 동작시에 crypto key를 만들어야 하며 rsa 타입으로 만들면 된다.

R1 SSH 서버 설정

! SSH 계정, 도메인, 로그, ACL 설정

username rack1 password ccie

ip domain-name rack1.cisco.com

ip ssh logging event

access-list 2 permit 2.2.2.2

 

! SSH 서버 설정

line vty 0 4

 transport input ssh

 login local

 access-class 2 in

 

! 여기까지 설정하고 라우터를 재부팅한 후에, show run 하면 위에서 생성된 crypto key값이 몇줄 생성됨을 확인할 수 있다.

R1 SSH 서버 설정 설명

먼저 SSH 클라이언트를 위한 username과 패스워드를 만든다.

DNS를 위한 domain-name을 설정한다.

SSH 로그 이벤트를 남기도록 설정한다.

R2 loopback0 2.2.2.2에서만 접속이 가능하도록 설정한다.

 

Telnet이 아닌 ssh 서버기능을 활성화 시킨다.

클라이언트가 로그인시에 라우터 로컬 DB username을 사용하도록 한다.

접속은 R2 loopback0만 가능하도록 access-class를 설정한다.

R2 SSH 클라이언트 설정

ip domain-name rack1.cisco.com

ip ssh source-interface lo0

crypto key generate rsa

R2 SSH 클라이언트 설정

먼저 domain-name을 설정한다.

R1 SSH 접속시 2.2.2.2만 허용하므로, R2SSH 클라이언트로 사용 될경우 source interface loopback0를 사용하게 설정한다.

 

모든 설정이 끝났으면 R2에서 아래처럼 R1(IP : 1.1.1.1)에 접속을 해보면 된다.

 

[– SSH 접속 방법]

R2

ssh – v 2 –l rack1 1.1.1.1 ;- Version 2

 

 


7. 802.1x

 

IEEEInstitute of Electrical and Electronics Engineers의 국제전기전자기술자협회 약자로 일반적으로 아이 트리플 이(I triple E)’라고 읽는다. 이 기관은 말 그대로 국제전기전자기술에 대한 기술을 정의하고 표준을 제정하는 단체로, 1980 2월에 제정된 컴퓨터 통신망 표준을 위한 기술이 IEEE 802 표준들이다. 현재는 IEEE 802.1 부터 802.12까지 표준화가 제정되어 있다. 참고로 IEEE에서는 일반적으로 OSI Layer 2에 관련된 표준을, IETF에서는 OSI Layer 3에 대한 표준을 제정하고 있다고 이해하면 된다.

 

IEEE 802.1xOSI 7 계층중에 데이터링크 계층에서의 보안을 위한 기술로, 일반적으로 줄여서 Dot1x(닷 원 엑스)라고 불리운다. CCIE 시험에서는 L2 기술인 VLAN과 관련된 인증 문제들이 출제되고 있다. 시험에서는 일반적 특정 스위치 포트에 접속된 호스트(PC) dot1x 인증을 지원하면 특정 VLAN에 연동되도록 유도하고 있다.

 

[– SSH 설정 방법]

구분

명령어

문제

Multihost를 가진 SW2 F0/8에 설정하라.

F0/8에 연동된 호스트가 dot1x를 지원하면 VLAN 100에 배정하라.

F0/8에 연동된 호스트가 dot1x를 지원하지만 인증에 실패하면 VLAN 100에 배정하라.

F0/8에 연동된 호스트가 dot1x를 지원하고 인증에 성공하면 VLAN 1에 배정하라.

설명

참고로 dot1x를 지원하지 않는 PC OS Windows 98이다. 시험에서는 스위치 설정만 할 뿐 실제 PC를 연동하지는 않으므로 시험에서의 결과 확인은 불가하다. SW2에서는 당연히 aaa new-model을 선언해야 한다.

SW2

aaa new-model

aaa authentication dot1x default group radius

dot1x guest-vlan supplicant (히든 명령어이므로 암기 필요)

dot1x system-auth-control

 

interface F0/8

 switchport mode access

dot1x port-control auto

 dot1x host-mode multi-host

dot1x guest-vlan 100

dot1x auth-fail vlan 100 (위의 dot1x guest-vlan supplicant 미 입력시)

 

 

 

- VII. Security 편 완료 -

 

 

 

[Copy Right by CrazyWoo(우명하) ; woomha@naver.com]


Title
List of Articles
번호 제목 글쓴이 날짜 조회 수
공지 How To Install GNS3 on Ubuntu 10.04 LTS Hojung 2011.04.25 6228
50 Cisco SPAN Hojung 2013.04.17 2217
49 f/r setting on main interface Hojung 2011.05.03 2296
48 Reset configuration in router/switch Hojung 2011.05.03 2618
47 Basic Configuration (password, domain-lookup, hostname, timeout) Hojung 2011.05.03 3077
» [Crazy4CCIE-R&S편]VII.Security Hojung 2011.04.27 5134
45 [Crazy4CCIE-R&S편]VI. IP QoS (완료) Hojung 2011.04.27 9218
44 [Crazy4CCIE-R&S편]V.IP Multicast (완료) Hojung 2011.04.27 8865
43 [Crazy4CCIE R&S편]번외편 - 다이나밉스 운영 환경 최적화 Hojung 2011.04.27 5087
42 [Crazy4CCIE-R&S편]IV.IP and IOS Feature (완료) Hojung 2011.04.27 6348
41 [Crazy4CCIE-R&S편]II.IGP(9-IPv6-(3)-OSPFv3) Hojung 2011.04.27 4860
40 [Crazy4CCIE-R&S편]II.IGP(9-IPv6-(2)-RIPng) Hojung 2011.04.27 3530
39 [Crazy4CCIE-R&S편]II.IGP(9-IPv6-(1)-Concept) Hojung 2011.04.27 3343
38 [Crazy4CCIE-R&S편]II.IGP(8-Redistribute(재분배)-(3)-Red&Filter) Hojung 2011.04.27 2910
37 [Crazy4CCIE-R&S편]II.IGP(8-Redistribute(재분배)-(2)-Red&Metric) Hojung 2011.04.27 5059
36 [Crazy4CCIE-R&S편]II.IGP(8-Redistribute(재분배)-(1)-Concept) Hojung 2011.04.27 7074
35 [Crazy4CCIE-R&S편]II.IGP(7-Distribute-(3)-distribute-list-설정) Hojung 2011.04.27 3793
34 [Crazy4CCIE-R&S편]II.IGP(7-Distribute-(2)-labconfig) Hojung 2011.04.27 2621
33 [Crazy4CCIE-R&S편]II.IGP(7-Distribute-(1)-concept Hojung 2011.04.27 2486
32 [Crazy4CCIE-R&S편]II.IGP(6-Filtering-(1~5)access-list&prefix-list Hojung 2011.04.27 4046
31 [Crazy4CCIE-R&S편]II.IGP(5-EIGRP-(5)-Authentication) Hojung 2011.04.27 2885
Board Pagination ‹ Prev 1 2 3 Next ›
/ 3

Designed by sketchbooks.co.kr / sketchbook5 board skin

나눔글꼴 설치 안내


이 PC에는 나눔글꼴이 설치되어 있지 않습니다.

이 사이트를 나눔글꼴로 보기 위해서는
나눔글꼴을 설치해야 합니다.

설치 취소

Sketchbook5, 스케치북5

Sketchbook5, 스케치북5

Sketchbook5, 스케치북5

Sketchbook5, 스케치북5