6일차

* 본 게시물의 내용은 수업에서 배운 것을 정리한 것이므로 악용해서는 안됩니다.

  잘 알려져있는 기술들이므로 악용하더라도 쉽게 적발됩니다.

  절대 악용해서는 안됩니다.

가상 회사 발표 후

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

ACL

: 접근 제어를 하기 위한 리스트

standard/extended

standard는 3계층 정보만 봄 / 1~99번

extended는 포트 번호를 가지고도 필터하기 때문에 4계층 까지 본다. / 100~199번

DMZ 

: 비보안 영역과 보안 영역 사이의 중립 지역.

 외부 트래픽을 차단하기 위해서

  문제 확산 방지

  외부에서 접근해서 공개적으로 사용하는 서버

서버팜

: 

외부에서 접근 못하고, 내부자들만 사용하는 서버들을 모아놓은 것.

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

ospf로 전체 통신 가능하게 하라

network 1.1.12.1 0.0.0.0 area 1 이런식으로 해줘도 무방함.

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

R1의 라우팅 테이블 확인

R4와의 핑 통신

R4 뿐만 아니라 인접장비와의 통신들도 모두 확인 해준다.

 

방화벽은 보통 화이트 리스트로 설정한다.

아래는 1.1.34.4를 거부하고 나머지를 허용하는 ACL이다

정책을 설정 한다.

정책 설정 후 인터페이스에 적용 시켜준다

show access-list로 정책을 확인한다.

ping 통신이 UUUUU로 뜬다

UUUUU 라고 뜨는 경우는 두가지 경우가 있다

1. 라우팅 테이블에 없을 경우

2. 중간 장비가 알려줄 때

위 경우엔 2번 상황인데 이런 경우엔 쓸데 없는 패킷으로 인해 과부하가 생길 수 있으므로 unreachables 메시지를 안보내는 설정을 해준다.

설정후 ping 통신을 다시 해보니 ..... 으로 뜨는 것이 보인다.

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

만든 ACL을 한번 지워보겠다.

잘    되는 것이 보인다.

이렇게 된다고 깔끔하게 지워진 것일까?

show run으로 확인 해보니 인터페이스에 설정이 남아있다.

남아 있는 인터페이스 설정도 지워주었다.

ACL을 지웠을 때 나머지 설정이 지워지는 장비도 있고 , 안지워지는 장비도 있으므로 확인을 해준다.

이번엔 번호가 아니라 이름으로 만들어 보겠다.

                 

inbound-acl이라는 이름으로 만들었고

확인을 해보니 이름으로 뜬다.

후에 인터페이스에 적용 시켜주었다.

R4에서의 확인

안된다.

R3에서의 확인

잘 된다.

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

지우지 않은 채로 화이트리스트를 추가 해준다.

deny any를 입력해주면 거부한 패킷이 몇개인지 체크가 가능하다.

show run으로 확인 해보니 덮어 씌우기가 되어 있다.

 

in은 설정 하나만 가능하다.

패킷은 둘다 확인이 가능하다.

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

ACL 수정을 해보겠다.

저 두 deny와 permit 사이에 넣어주고 싶다

    

넣어줘보았다.

이렇게 꼬여 있다.

               

이 명령어로 리시퀀스 해주니까

위와 같이 바뀌었다.

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

다 지우고 extended ACL을 만들어 보겠다

지우고

출발지가 1.1.34.4고 , 목적지가 1.1.12.1인 것은 차단하고

나머지는 허용하겠다

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

 

위에선 R3에서 됐는데 R2에서 해야한다.

    이번엔 tcp 프로토콜을 사용하는 것을 필터링 하는 것이다.

    별 다를바는 없고 ip 대신 tcp 만 들어갔다.

R3에서의 핑                                                         

R3에서의 telnet (R1에서 telnet 설정이 되어 있어야함)

R4에서의 핑 통신은 되고

telnet은 안되는 것이 보인다

다음은 포트번호로 하는 것이다

show access-list 102로 봤을때 eq 80 했던 것이 www로 바뀐게 보인다

R4에서 telnet 80번포트는 안되지만 기존 23번 포트는 열린다

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

이렇게 라우팅 되는 정보를 알 수 있다.

공격 대상이 될수 있는 장비가 노출되기 때문에 막는 것이 좋다.

option-control 이라는 이름으로 ACL을 구성했다.

그리고 fa0/0 에 적용시켰다.

그랬더니 이번엔 경로가 안나오는 것을 볼 수 있다.

패킷을 잡아보니 icmp가 있다

옵션에 record route가 있습니다.

traceroute은 여전히 보인다

traceroute는 TTL 값을 이용하는데, TTL은 네트워크를 나누어주는 장비가 받을 때 마다 1을 줄인다. 0이되면 출발지에게 만료됐다고 알려준다.

각 장비에 TTL 값 1, 2, 3 차차 늘려서 보냄으로써 거쳐가는 장비를 알 수 있다.

패킷을 잡아보면은 각 장비마다 3번씩 보낸다.

처음엔 

           TTL 값이 하나씩 증가 하는 것이 보인다.

TTL 값이 지나치게 낮은 것을 거르면 되겠다.

check-ttl 이라는 이름의 extended ACL

ttl이 10보다 낮은 출발지 any 목적지 any인 것을 deny 하겠다.

나머지는 허용

인터페이스에 적용

잘 되던 R4에서 traceroute가 이제 안되는 것을 확인 할 수 있다.

근데 R2에서 neighbor가 끊어지는 현상이 발생한다.

어떻게 하면 traceroute를 방어 하는 상태에서도 ospf가 정상적으로 동작하게 할 수 있을까?

ospf hello 패킷을 잡아보니 TTL값이 1이였다.

그래서 ospf 패킷은 허용 해주는 ACL을 추가했다.

다시 neighbor가 맺어진게 보인다.