강좌
클라우드/리눅스에 관한 강좌입니다.
네트워크 분류

rate-limit를 이용한 트래픽의 제어(QoS)

작성자 정보

  • 구돌 작성
  • 작성일

컨텐츠 정보

본문

rate-limit를 이용한 트래픽의 제어(QoS)

 

access-list를 이용하여 특정 트래픽을 완전히 차단할 수 없거나, 정상적인 트래픽인데 와레즈(warez)나 웜(Worm)등으로 인한 과도한 트래픽 유발로 인하여 같은 네트워크에 있는 다른 시스템이나 네트워크에 영향을 준다면 적절히 트래픽을 제어할 필요가 있다.

 

이를 위해서는 라우터에서 제공하는 QoS(Quality Of Service)기능을 이용할 수 있다.

 

이 기능은 단위 시간 동안 일정량 이상의 패킷이 라우터로 유입될 경우 일정량 이상의 패킷은 통과시키지 않고 별도의 정책을 따르도록 하는 것인데, 이를 CAR(Committed Access Rate) 또는 다른 말로 rate limiting 또는 rate filtering이라고 하며 네트워크 관리를 위해서 뿐만 아니라 과도하게 유발되는 서비스거부 트래픽에 대해 다른 서비스에 영향을 주지 않으면서도 효율적으로 차단할 수 있는 솔루션이라 할 수 있다.

 

이는 라우터의 해당 인터페이스에 rate-limit라는 명령어형식을 이용하여 설정할 수 있는데, rate-limit의 기본형식은 다음과 같다.

 

 

rate-limit {input | output} bps burst-normal burst-max conform-action action exceed-action action

 

이때 적용되는 각 옵션의 의미는 다음과 같다.

 

 

burst-normal : 초과 허용 대역폭(bytes)

burst-max : 초과 정책을 적용할 대역폭 한계(bytes)

conform-action : 한계를 넘지 않을 때 취할 행동, 주로는 단순 패킷 전달(transmit)

exceed-action : 초과 시 취할 정책, 이를테면 패킷 드롭(drop)

 

이때 burst-normalburst-maxbyte단위로서 각각의 특성에 맞게 적절히 적용하면 될 것이다.

 

실제로 burst-normalburst-max는 큰 의미는 없으므로 임의의 값(8000)을 지정해 주면 된다.

 

 

 

이를 활용하면 다양한 대역폭 조절이 가능한데, 각 서비스별로 특성이 다르겠지만 일반적으로 프로토콜별 정상 트래픽 분포는 각각

 

> TCP : ~90 % (HTTP, FTP and P2P)

> UDP : ~10 % (DNS, SNMP, streaming)

> ICMP : <1 %

 

와 같으므로 이 제한을 적절히 설정해 두면 서비스거부 또는 분산서비스거부 공격 등을 예방하는데 유용할 것이다.

 

물론 각 프로토콜별 정확한 수치는 서비스 내용별로 차이가 있지만 다음 장에서 netflow를 활용한 flowscan을 이용하면 알 수 있다.

 

 

 

만약 스트리밍(streaming)을 제공하는 인터넷 방송의 경우라면 (스트리밍은 udp이므로) udp의 허용 대역폭을 적절히 늘려주어야 할 것이다.

 

위의 사용방법에 따라 다음과 같이 실제로 serial 0 인터페이스에 rate-limit를 설정하는 예를 살펴보도록 하자.

int serial 0

rate-limit input access-group 150 2000000 8000 8000 conform-action transmit exceed-action drop

rate-limit input access-group 160 512000 8000 8000 conform-action transmit exceed-action drop

rate-limit output access-group 150 2000000 8000 8000 conform-action transmit exceed-action drop

rate-limit output access-group 151 1000000 8000 8000 conform-action transmit exceed-action drop

rate-limit output 50000000 8000 8000 conform-action transmit exceed-action drop

 

access-list 150 permit udp any any

access-list 151 permit ip host 192.168.0.1 any

access-list 160 permit icmp any any echo-reply

 

rate-limit 설정 시 주의할 점은 rate-limit룰은 access-list처럼 위에서부터 순서대로 조건에 매칭 되는지 여부를 체크하므로 설정순서에 주의하여야 한다는 것이다.

 

, 첫 번째 매칭 되는 조건이 있으면 이하의 조건은 적용되지 않는다는 점에 주의하여야 한다.

 

 

첫 번째는 input에 대한 access-list이므로 일단 인터페이스를 통해 inbound되는 패킷 중 150access-list, udp에만 해당하는 사항이므로 들어오는 모든 트래픽 중 udp패킷은 약 2M(2000000)로 제한하는 설정이며 만약 2M가 초과할 경우에는 더 이상의 패킷을 받지 않고, 바로 drop하게 될 것이다.

 

세 번째 설정은 똑같은 설정인데 단지 outbound에 대한 제한이라는 것만 차이가 있다.

 

 

두 번째는 access-list 160번에 대한 설정인데, 160번의 의미는 access-list를 보면 icmp 패킷 중 echo-reply만 해당하므로 inbound되는 트래픽 중 echo-reply를 약 512K로 제한하였다는 것을 알 수 있다.

 

이는 외부의 브로드캐스트 주소를 증폭기(amplifier)로 악용하여 대량의 echo-reply 패킷을 유발하는 대표적인 icmp기반의 서비스거부 공격인 smurf와 같은 공격에 대한 대응 방법이다.

 

 

네 번째는 앞의 예제에서와 같이 간헐적으로 과도한 outbound트래픽을 유발하고 있는 서버의 트래픽을 제한하기 위한 설정인데, 해당 IP에서 tcpudp, icmp등의 프로토콜에 관계없이 outbound되는 패킷을 1M 정도로 제한한 것이다.

 

물론 그 이상의 트래픽이 유발되면 나머지는 모두 드롭(drop)될 것이다.

 

이는 특정한 서버에 대해 트래픽을 제한하고자 할 때 유용하게 사용될 수 있다.

 

 

마지막 설정은 access-list를 설정하지 않고 사용한 예인데, outbound되는 총 트래픽을 50M로 제한하여 더 이상의 트래픽이 유발되지 않도록 하는 것이다.

 

물론 이 값은 각자의 네트워크 환경에 따라 적절히 변경하여야 할 것이다.

 

 

 

이렇게 rate-limit로 트래픽 제한설정을 끝낸 후에는 "show interface serial 0 rate-limit" 명령어를 사용하여 rate-limiting에 대한 그간의 통계를 볼 수 있다.

 

Router>sh int serial 0 rate-limit

matches: access-group 160

params: 512000 bps, 8000 limit, 8000 extended limit

conformed 218085 packets, 20848149 bytes; action: transmit

exceeded 26 packets, 2704 bytes; action: drop

last packet: 358760ms ago, current burst: 0 bytes

last cleared 5w3d ago, conformed 0 bps, exceeded 0 bps

 

[라우터 보안설정 적용 시 주의할 점]

 

앞에서 여러 번 언급한 바와 같이 라우터 자체는 보안장비가 아니다.

 

따라서 장비의 하드웨어나 트래픽 등을 고려하지 않고 무리하게 보안기능을 적용하려고 할 경우 성능 저하뿐만 아니라 심할 경우 네트워크 장애까지 있을 수 있으므로 보안 적용 시 특히 아래의 사항은 각별히 주의하여야 한다.

 

일부는 앞에서 설명한 내용도 있지만 정리하는 의미에서 다시 한 번 확인해 보도록 하자.

 

* tcp intercept

 

tcp intercepttcp기반의 syn-flooding 방어에 매우 효과적인 솔루션으로 실제로 적용하기 보다는 그 원리만 알고 있기 바란다.

 

tcp intercept는 두 가지 방식으로 구현 가능한데, 첫 번째 방식은 '인터셉트(intercept) 모드'라 하여 라우터로 들어오는 syn 패킷 요청을 그대로 서버에 넘겨주지 않고 라우터에서 일단 가로채어(intercept하여) 서버를 대신하여 syn 패킷을 요청한 클라이언트와 연결을 맺고, 연결이 정상적으로 이루어지면 이번에는 클라이언트를 대신하여 서버와 연결을 맺은 다음 두 연결을 투명하게 포워딩하여 연결시켜주는 방식이다.

 

따라서 존재하지 않는 IP로부터 오는 syn요청은 서버에 도달하지 못하게 되는 것이다.

 

두 번째 방식은 '와치(watch) 모드'라 하여 '인터셉트 모드'와는 달리 라우터를 통과하는 syn 패킷을 그대로 통과시키고 일정 시간동안 연결이 이루어지지 않으면 라우터가 중간에서 syn 패킷을 차단하는 방식이다.

 

그러나 이 두 가지 방식은 매우 많은 메모리와 CPU를 소모하므로 실제 운영 중인 장비에서는 적용하지 않는 것이 좋다.

 

필자도 syn flooding 공격에 대응하기 위해 이 설정을 했다가 잠시 후에 라우터가 다운되는 낭패를 본 적이 있다.

 

07724729bc4793df016d97cb5ab845c0_1652840198_1812.png
 

[그림] tcp intercept의 원리

 

 

* Unicast RPF(Reverse-Path Forwarding)

 

URPF는 소스IPreturn-path가 같은 인터페이스를 사용하는지 체크하는 것으로 작동하려면 CEFenable되어 있어야 한다.

 

URPF 설정 시 ip spoofing을 효과적으로 차단할 수 있는데 URPF에는 Strict URPFLoose URPF 이렇게 두 종류가 있다.

 

그런데 두 개 이상의 ISP와 연동되어 있는 multi-homed일 경우에는 Strict URPF를 적용할 때 주의하여야 한다.

 

그렇지 않을 경우 정상적인 트래픽까지 필터링 될 가능성이 있기 때문이다.

 

 

 

* NBAR (Network-Based Application Recognition)

 

NBARtcp/udp 포트로 분류가 어려운 프로토콜이나 웹 기반의 프로토콜 등과 같이 다양한 응용 프로그램을 인식할 수 있는 분류엔진(classification engine)으로 특정한 스크립트 패턴을 가지고 IIS 웹서버를 공격하는 코드레드(Codered)나 님다(Nimda)등의 Worm을 필터링 하는데 효과적이다.

 

그러나 이 역시 트래픽이 많은 경우 성능저하에 주의하여야 한다.

 

 

 

* Debugging

 

tcpdump와 같이 패킷을 분석하거나 네트워크 문제발생시 문제해결에 매우 효과적이다.

 

그러나 적용 시 각 패킷의 상세정보까지 모니터링하므로 라우터의 성능저하에 주의하여야 한다.

 

연구실 등에서 패킷을 분석하거나 문제해결을 하고자 할 때 사용하며 실제 서비스 중인 네트워크에서는 절대 사용하면 안 된다.

 

 

 

* ip accounting

 

트래픽이 많은 곳에서는 라우터의 성능저하가 있을 수 있으므로 절대 사용하면 안 된다.

 

굳이 사용하여야 한다면 안전하면서도 더 많은 기능을 제공하는 netflow를 사용하는 것이 좋다.

 

특히 MAC주소별로 PPS를 측정하는 “ip accounting mac-address input”등은 사용해도 별로 부하를 유발하지는 않지만 IP주소별로 패킷의 개수와 바이트를 측정하는 “ip accounting output-packets”는 절대 사용하면 안 된다.

 

 

 

* SSH

 

라우터에서 사용하는 대부분의 SSHv1으로서 key recovery, CRC32, timing analysis and attacksSSH v1 자체의 취약성을 그대로 가지고 있다.

 

따라서 SSH 이용 시에는 취약성이 패치 된 최신의 버전을 이용하도록 하여야 한다.

 

 

 

관련자료

댓글 0
등록된 댓글이 없습니다.

공지사항


뉴스광장


  • 전체 회원수 59,444 명
  • 전체 게시물 30,916 개
  • 전체 댓글수 11,873 개