GNS3 - 9

※ 저장해둔 파일 불러오기 

 

컴퓨터의 CPU 점유율을 낮추기 위해서 각 장비에 auto idle pc 설정 해주기

 

각 장비별로 secureCRT 접속

 

모든 장비의 ip 설정 확인

 

라우팅 경로 설정 확인

 

※ access control list / access list / acl 개념

1. 접근 제어 --> 네트워크 통신 장비들은 고사양 게임을 한다던지, 높은 CPU를 요구할 사항들이 많이 없어서 연산 속도가 많이 느리다. 만약 여러개의 트래픽이 발생하면 장비 자체가 다운될 가능성이 높고 이를 막기 위해서 접근 제어를 사용한다.

 

- 대용량의 트래픽인 경우 : 방화벽이 알아서 막아준다. [ ex D-DOS 공격 같은 것들]

- 대용량까지는 아니지만 적당한 트래픽인 경우 : access control list [ telnet , http에서 오는 트래픽 ]

 

2. 정책 적용 대상 지정 [NAT]

 

- 네크워크의 많은 정책들의 대상을 지정한다.

 

ex)

- 어떤 트래픽은 네이버에 접속 못하게 한다.

 

- 어떤 트래픽은 빨리 처리할 수 있도록한다.

 

- telnet으로 접속할 때 어떤 트래픽 주소만 관리자로 받아들이고 나머지는 관리자로 받아들이지 않는다. 등등....

 

※ Cisco 장비에서 access list 설정

 

- standard acl [ 표준 acl ]  : 출발지 IP를 근거로 permit / deny 가능

[ 출발지만 보기 때문에 상세 설정 불가, 그렇지만 신속한 설정이 가능하다.]

• numbered acl : 번호로 설정 1 -99 / 1300 - 1999
• named acl : 이름으로 설정

 

- extend acl [ 확장 acl ] : 출발지와 목적지를 모두 볼 수 있다. 

[protocol 지정 가능 : ip, tcp, udp, icmp ...]

• numbered acl :  번호로 설정 100 - 199 / 2000 - 2699
• named acl : 이름으로 설정

번호 확인

 

==================================================================================

 

※ S1에서 S22로 핑 보내기

 

잘 나간다.

R7으로 나가는 것(out)을 막고 R1에서 R2로 들어오는 것(IN)을 제어 해보자

 

※ 본사 네트워크인 11.1.1.0 대역이 아니라 S1 대역인 11.1.1.1 대역에서 보내는 핑을 제어해보자 

 

S1 (11.1.1.1 / 32 ) R2_fa 1/0 outbound deny 명령으로 R2에서 1/0 인터페이스로 나가는 핑을 차단한다.

 

※ 설정 후에 꼭 확인해야 하는 것

 

1. 로그와 백업 확인

2. 기존설정과 추가설정 비교하기 

3. 설정하기

4. 설정 확인 - show run | in access-list

5. 적용 확인 - show ip access-list

 

 

현재 S1 -> S22 경로로 핑이 잘 가고 있다.

 

※ R2에서 access-list 설정하기

 

conf t 

access-list [숫자: 표준과 확장 acl 범위 내에 있고 사용하지 않는 번호 중 아무거나] 22 [ permit / deny]  deny [src_ip] 

11.1.1.1 [wildcard] 0.0.0.0 [옵션]

(src_ip 설정 tip)

- 만약 11.1.1.0의 본사 서버를 제어한다고 했으면 11.1.1.0 0.0.0.255 <- 이와 같은 형식으로 설정해주면 된다. 

 

-> access-list 22 deny 11.1.1.1 0.0.0.0 [Cisco에서는 뒤에 32bit로 올 0 일때 11.1.1.1만 작성해도 된다. ]

 

 

 

※ R2에서 access-list 적용하기 

 

int fa 1/0 

ip access-group 22 out

[access-group인 이유: 지금은 그냥 하나의 트레픽만 제어하기 위해서 설정하는 것이지만 평소에는 수십 개의 트래픽이 있어서 22라는 숫자 그룹에 저장이 되기 때문에 group으로 묶어준다. ]

 

 

R2에서 out 설정해주기

이전에는 잘 나가던 핑이 이제 나가지 않는다.

다시 R2에서 ↑ 눌러서 이전 명령어 불러온 뒤 Ctrl + a 눌러서 커서를 맨앞으로 옮긴다. 그 뒤에 no 입력해서 해제

 

다시 핑이 잘 나가는 것을 확인

 

설정 확인과 적용 확인까지

 

※ 만약에 11.1.1.1에서 출발하기 때문에 막히는 거라면 서버의 ip를 11.1.1.10으로 바꾼다면 핑이 나갈지에 대해서 생각해보자.

 

ip 변경 하고 핑 다시 보내보기

 

여전히 핑이 나가지 않는다.

 

※ 변경했는데  왜 안나갈까?

 

-> 11.1.1.10 대역에서는 뭘 하라는 명령어를 입력해주지 않았기 때문에 아무런 설정이 없다. 따라서 11.1.1.1은 deny되서 통신이 안되고 11.1.1.10 대역은 설정이 없기 때문에 통신 자체가 안되는 것이다. 

 

-> 11.1.1.1 대역 외의 통신은 나갈 수 있도록 허용하는 명령어를 R2에 알려줘야 통신이 가능해진다. 

 

위와 같은 명령어를 추가해준다.

 

다시 핑을 보내면 잘 통신되는 것을 확인 할 수 있다.

 

 

원래 핑으로 바꾸면 다시 deny에 걸려서 못나간다.

 

※ R3에서 S1 -> S33으로 핑이 나가지 못하도록 막아보자

 

S33으로는 핑이 현재 나갈 것이다.

 

※ S33으로 통신 안나가게 설정

 

들어오는 것 IN을 막아도 되고 OUT을 막아도 된다.

 

R3에서 IN을 막아보겠다.

 

핑이 막혔다.

 

접속이 시도되었던 것이 정상적으로 막혔다는 표시 matches

 

※ S44로 통신이 안나가게 설정 - 설정 전에 R3에서 no ip access-group 3 in 해제해야 핑 전달 가능

 

핑 전달 확인

 

out에 해당하는 인터페이스에서 11.1.1.1 대역 핑 접속을 막아준다.

 

직전에 잘 나가던 것이 다시 U로 통신 불가 상태

 

※ S2 -> S1 관리자(11.1.1.1)만 telnet 접속 할 수 있도록 설정

 

S2에 계정 만들고 local 접속 설정

 

다른 서버에서 접속 시도하면 계정 로그인 화면이 뜨는데 이것을 S1만 가능하게 만드려 한다.

 

텔넷에 대한 access는 class 설정으로 가능하다.

 

다른 서버에서 22.1.1.1 접근 시도 하면 거절 당한다.

 

S1에서 telnet 접속 시도하면 잘 되는 모습을 확인 할 수 있다.

 

※ 다른 서버의 텔넷도 위와 마찬가지로 설정해줄 수 있다. 

 

 

- 지금까지 설정한 방식은 numbered acl 방식으로 설정했다.  named acl도 살펴보자.

 

- numbered acl은 수정이 불가능하다. 

 

access-list 1 deny 1.1.1.1 0.0.0.0

access-list 1 deny 2.1.1.1 0.0.0.0

access-list 1 deny 3.1.1.1 0.0.0.0 -> 이 ip 하나만 수정하려고 하면 모두 삭제하고 다시 만들어야한다.

access-list 1 deny 4.1.1.1 0.0.0.0

access-list 1 deny 5.1.1.1 0.0.0.0

access-list 1 permit any

int fa 0/0

ip access-group 1 in 

 

- 하지만 named acl은 수정이 가능하다. -> 순서번호를 가지고 있기 때문에 수정이 가능하다. 

 

※ named acl 방식

 

- ip access-list standard CC

[10] deny 1.1.1.1 0.0.0.0 : 앞쪽에 보이지 않는 순서 번호가 적혀 있다. 

[20] deny 2.1.1.1 0.0.0.0

[30] deny 3.1.1.1 0.0.0.0

[40] deny 4.1.1.1 0.0.0.0

[50] deny 5.1.1.1 0.0.0.0

[60] deny 6.1.1.1 0.0.0.0

permit any

exit

int fa 0/0

ip access-group 1 in 

 

※ 변경 시 

ip access-list standard CC 

no 30 : 3번째 변경

30 deny 3.4.5.1 0.0.0.0

 

 

named acl 명령어 입력한 뒤 확인하기

show ip access-lists 로 확인 해보면 아까 설명 한 것과 같이 앞에 순서번호가 적혀있다.

 

특정 번호에 no 입력 후 다시 ip 설정하면 부분 변경이 가능하다.

 

※ 각각의 서비스를 차단하고 허가하기 

(R1에서 제어)

R1_fa0/1_outbound 

S1(11.1.1.1) ---> S2(22.1.1.1) telnet 허가 --> tcp eq 23 
S1(11.1.1.1) ---> S22(2.2.2.1) http 차단 --> tcp eq 80
S1(11.1.1.1) ---> S33(3.3.3.1) ping 차단 --> icmp / echo 
S1(11.1.1.1) ---> S44(4.4.4.1) ssh 허가 --> tcp eq 22
S1(11.1.1.1) ---> S55(5.5.5.1) ping 허가 --> icmp / echo

 

※ 문법 

 

access-list [숫자] 100 [permit|deny] permit [protocol] tcp [src_ip] 11.1.1.1 [wildcard] 0.0.0.0
[dst_ip] 22.1.1.1 [wildcard] 0.0.0.0 [옵션] eq 23
--> access-list 100 permit tcp 11.1.1.1 0.0.0.0 22.1.1.1 0.0.0.0 eq 23

 

 

int fa 0/1
ip access-group 100 out

access-list 100 permit tcp 11.1.1.1 0.0.0.0 22.1.1.1 0.0.0.0 eq 23
access-list 100 deny tcp 11.1.1.1 0.0.0.0 2.2.2.1 0.0.0.0 eq 80
access-list 100 deny icmp 11.1.1.1 0.0.0.0 3.3.3.1 0.0.0.0 echo
access-list 100 permit tcp 11.1.1.1 0.0.0.0 4.4.4.1 0.0.0.0 eq 22
access-list 100 permit icmp 11.1.1.1 0.0.0.0 5.5.5.1 0.0.0.0 echo
access-list 100 permit ip any any 
int fa 0/1
ip access-group 100 out

no access-list 100 -> 틀렸다면 numbered acl이라서 처음부터 다시 설정한다. 

 

 

설정 확인하기

 

- 10 telnet 허가 확인

 

 

- 20 www 거부 확인

 

라우터 장비에서 웹에 직접 접속은 안되기 때문에 80 포트가 열려있는지 여부를 확인할 수 있다. 지금은 R1에서 막아놓음

 

- 30 icmp 거부 확인(ping)

 

 

- 40 ssh 허가 확인

 

R4의 ssh 접속 허가를 했기 때문에 R4 장비에 ssh 설정 해주기

 

거절..? 일단 access-list를 확인한다.

R1에 설정한 것은 잘 제어가 된 모습 확인

 

-> 이와 같은 방법으로 access-list의 방법들을 알아보았다. ssh 접속에 대한 것은 조금 더 공부 해서 알아봐야겠다. 일단 access-list의 문제 같진 않다.. 고민 해봐야겠다.