분산서비스거부(ddos) 공격의 원리와 대응방법 2편 : ddos 공격에 대한 대응방안

분산서비스거부(ddos) 공격의 원리와 대응방법 2편 : ddos 공격에 대한 대응방안

ddos 공격은 일종의 인해전술과 같아서 쉽게 차단하기 어려운 것이 사실이다.

그러나 공격을 궁극적으로 차단할 수 없지만 공격으로 인한 피해를 최소화하기 위한 방안에 대해 살펴보도록 하자.

현재 ddos 공격이 발생하면 대부분 백본에서 아래와 같이 공격을 당하는 victim ip에 대해 블랙홀 라우팅 처리하고 있다.

블랙홀 라우팅은 Null0 라우팅 또는 Null0 필터링이라고도 하는데, 라우터 본연의 기능인 라우팅을 이용하는 것이므로 access-list 보다는 장비의 자원을 적게 소모하면서 쉽게 설정이 가능하다. 이는 마치 리눅스의 /dev/null처럼 특정IP또는 IP대역을 가상의 쓰레기 인터페이스로 강제로 보냄으로써 접속을 차단하는 기술이다.

ROUTER# conf t

ROUTER(config)# ip route 1.1.1.1 255.255.255.255 Null0

위의 경우 공격을 받는 IP인 1.1.1.1을 목적지로 한 패킷을 차단하는 예를 보여주고 있다.

라우팅은 소스를 제어하는 것이 아니라 목적지IP를 제어하는 것이라는 것을 주의하기 바란다. 그러나 이는 공격당하는 IP를 네트워크에서 차단하고 격리함으로써 피해가 네트워크 레벨로 퍼지지 않도록 하는 방법일 뿐 공격에 대한 적극적인 대응방법이라고 할 수는 없다.

필자는 ddos공격에 대해 크게 다음과 같이 크게 두 부류로 나누고자 한다.

각각의 공격방식에 대하여 다음과 같은 대응 방법을 고려해 볼 수 있다.

➀ bandwidth 소모 공격은 백본에서 access-list 활용

UDP나 ICMP기반의 공격은 한 패킷 당 1000~1500byte짜리로 트래픽을 생성하여 가용한 대역폭(Bandwidth)을 가득 채우기 위한 형태의 공격으로서 이에 대해서는 백본에서

access-list를 이용하여 대응하는 방안을 고려할 수 있다.

대부분의 공격은 httpd 등 웹서버에 집중되고 있기 때문에 외부에는 80/tcp만 허용하고 나머지는 차단할 경우 어느 정도 대역폭을 소모하는 형태의 공격에 대응할 수 있을 것이다.

만약 1.1.1.1에서 80/tcp로 서비스한다면 다음과 같이 acl을 설정할 수 있는데 첫 번째는 장비의 uplink에서 acl을 이용하는 방법이다.

inbound 되는 패킷을 차단하여야 하므로 아래와 같이 1.1.1.1에 대해서는 80/tcp만 허용하고 이외의 트래픽은 차단하고 있다.

그리고 이외의 다른 트래픽은 모두 허용하고 있다.

- uplink 에서 acl 적용

access-list 120 permit tcp any host 1.1.1.1 eq www

access-list 120 deny ip any host 1.1.1.1

access-list 120 permit ip any any

interface TenGigabitEthernet9/1

ip access-group 120 in

만약 uplink에서 acl을 설정하는 것이 부담이 된다면 해당 가상의 인터페이스인 vlan 인터페이스에서 acl을 적용하는 것도 고려할 수 있다.

이러한 경우 아래와 같이 in이 아닌 out으로 지정하여야 한다.

interface vlan40

ip access-group 120 out

단 여기에서 주의할 점은 장비에 따라 acl 처리방식이 다르므로 HW based로 처리하는지 확인하여야 한다.

이를테면 백본장비로 많이 사용하는 6509의 경우 sup2/sup720 엔진에서는 acl 목록을 각각 16,000개, 32,000개까지 지원하며 모두 Hardware로 처리하므로 성능상의 이슈는 없는 것으로 알려져 있다.

➁ 대량의 pps유발은 서버 최적화와 보안장비(anti-ddos)로 대응

tcp syn flooding과 같은 공격은 패킷의 사이즈는 작지만 많은 패킷 즉 pps를 유발함으로써 서버나 네트워크 장비에 영향을 주게 된다.

이러한 pps 유발 공격을 받게 되면 일차적으로 리눅스 서버에는 다음과 같은 두 메시지가 출력되면서 서비스가 중지되는데 각각에 대한 의미와 대응방안에 대해 살펴보도록 하자.

- dst cache overflow

공격을 당할 때 dmesg를 실행하면 아래와 같은 메시지가 출력된다.

# dmesg

kernel: dst cache overflow

kernel: dst cache overflow

kernel: dst cache overflow

last message repeated 5 times

위 메시지의 의미는 목적지 cache가 초과했다는 의미인데, 위조된 IP로 대량의 SYN패킷이 들어오면 서버에서는 해당 IP로 SYN/ACK로 응답하고 해당 IP에 대해 라우팅캐시에 저장하게 된다.

현재 저장된 라우팅 캐시는 아래와 같이 확인할 수 있다.

# route –Cn

218.xxx.43.4 218.xxx.43.75 218.xxx.43.75 0 0 36 lo

218.xxx.43.75 218.xxx.43.250 218.xxx.43.126 0 0 0 eth0

218.xxx.43.75 211.xx.65.57 218.xxx.43.126 0 1 0 eth0

….

즉, 위의 메시지는 서버에서 처리할 수 있는 캐시테이블의 개수를 초과하여 더 이상의 접속을 처리할 수 없다는 의미이다.

이와 관련된 커널 파라미터는 아래와 같다.

net.ipv4.route.max_size = 65536  인식 가능한 라우팅의 개수

net.ipv4.route.secret_interval = 600  라우팅을 캐시 하는 시간(600초=10분)

첫 번째 파라미터를 통해 현재의 시스템에서 인식 가능한 최대 라우팅 개수는 65536개라는 것을 알 수 있으며 두 번째 파라미터는 해당 라우팅을 메모리에 캐시 하는 시간을 의미하는데, 600은 600초 즉, 10분을 의미한다.

그렇다면 65536/600을 계산해 보면 109라는 숫자가 나오는데, 이는 1초당 신규로 처리할 수 있는 라우팅 캐시 개수를 의미한다.

syn flooding 공격이 들어올 때는 초당 20만~30만pss가 유입되고 이는 결국 초당 20만개 이상의 라우팅을 처리해야 한다는 의미가 되는데, 고작 처리 가능한 개수가 109개이니 당연히 장애가 유발되는 것이다.

따라서 공격이 발생하면 다음과 같이 처리하는 것이 좋다.

* net.ipv4.route.max_size의 값을 200만이나 300만과 같이 최대한 늘리고,

net.ipv4.route.secret_interval 의 값을 3초나 5초 이내로 줄인다.

* ip route flush cache를 실행하여 캐시를 즉시 clear 시키도록 한다.

- ip_conntrack: table full, dropping packet.

이는 7장 iptables에서도 언급한 내용이지만, 리눅스 서버에서 ip_conntrack가 모듈 또는 커널에 포함되어 있으면 iptables 룰을 설정하지 않아도 자동으로 상태추적을 하게 된다.

이와 관련된 커널 파타미터는 아래와 같다.

net.netfilter.nf_conntrack_max = 32768  상태추적 할 수 있는 최대값

net.netfilter.nf_conntrack_count = 32532  현재 실시간 상태추적개수

첫 번째 파라미터를 보면 현재 처리할 수 있는 최대값이 최대 32768개로 되어 있고, 두 번째 파라미터를 보면 현재의 실시간 상태추적 개수인데, 거의 최대값에 도달한 것을 알 수 있다.

역시 수십만 pps를 유발하는 syn flooding 공격이 발생하면 당연히 상태추적 테이블이 초과하게 되고 더 이상의 서비스가 중지된다.

따라서 이러한 경우 아래와 같이 대응하도록 한다.

* 상태추적(Connection tracking) 기능을 disable한다.

굳이 iptables 방화벽을 사용하지 않을 것이라면 커널에서 이 기능을 disable한다.

* net.netfilter.nf_conntrack_max값을 수백만 이상으로 최대한 늘려준다.

* 아래 커널 파라미터값을 최소의 값으로 줄여준다.

이는, SYN 패킷이 들어와 SYN+ACK로 응답하는 것과 관련된 값인데, 첫 번째의 경우 SYN에 대해 SYN/ACK로 응답후 ACK응답을 기다리는 최대값인데 60초로 되어 있다.

syn flooding 공격은 위조된 IP를 소스로 공격이 진행되므로 60초까지 기다릴 필요도 없 고 여유도 없으므로 5초정도로 줄여주는 것이 좋다. 두 번째 이하의 경우 ACK패킷을 받지 못하였을때 재전송과 관련된 값인데, 이 값 역시 가급적 최소의 값으로 줄여주는 것

이 좋다.

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60

net.ipv4.netfilter.ip_conntrack_tcp_max_retrans = 3

net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300

net.ipv4.tcp_synack_retries = 5

그러나 서버의 최적화로도 대응할 수 없는 경우가 발생할 수 있다.

이러한 경우에는 부가적으로 고속의 처리가 가능한 전용 anti-ddos 장비를 활용하는 방법을 고려할 수 있다.

아래 장비의 경우 수백만 pps까치 처리가 가능하면서 자동학습 기능 및 공격 시 수 초내 자동대응 기능을 가지고 있으므로 syn flooding 공격 차단 시 효과적인 대응방법이 될 수 있다.

-. Cisco guard & detector (http://www.cisco.com/)

-. Intruguard (http://intruguard.com/)

-. Radware defensePro (http://www.radware.com/)

-. Riorey (http://www.riorey.com/)

다음은 트래픽 공격에는 트래픽으로 대응하는 CDN 서비스를 적극적으로 활용하는 방법을 고려할 수 있다.

국내의 CDNetworks와 같은 회사에서는 국내 각 IDC뿐만 아니라 해외에도 각각 수 백 Gbps의 네트워크를 확보하여 서비스를 제공하고 있으므로 이러한 CDN 서비스를 이용하는 것도 좋은 방안이 될 수 있다.

특히 CDN 서비스의 경우 Global 로드발랜싱을 통해 접속자와 가장 가까운 서버가 응답하게 함으로써 일상적인 속도개선 뿐만 아니라 만약 한 지점에 장애가 발생하면 DNS에서 자동으로 목록에서 삭제함으로써 정상적인 서비스가 되는 지점으로만 연결시켜주기 때문에 어느 한 쪽에서 공격을 받아도 서비스의 가용성을 더욱 높일 수 있다.

[그림] CDN 서비스 적용시 구성도

이를테면 위 그림에서와 같이 웹서버가 공격을 받을 가능성이 있을 경우 외부에 노출되는 IP는 모두 CDN을 통해 서비스되는 캐싱(Reverse proxy) 장비이며 실제 웹서버는 외부에 노출되지 않게 된다.

또한, A IDC에 있는 CDN업체의 1.1.1.1이 공격을 받아 서비스가 중지될 경우 DNS에서 자동으로 인식하여 1.1.1.1은 DNS에서 삭제하여 다른 서버로만 접속을 할 수 있도록 하게 된다.

마지막으로 고려하여야 할 사항은 바로 DNS이다.

현재 대부분의 공격은 즉각적인 효과를 보여줄 수 있는 웹서버에 집중되고 있으나 만약 장기전으로 갈 경우라면 공격자는 DNS 서버를 공격할 수도 있다.

웹서버의 경우 만약 공격을 받아 서비스가 중지되면 IP를 변경하거나 위의 CDN과 같이 여러 대로 분산하는 방법을 통해 공격을 어느 정도 피해갈 수 있지만 만약 DNS서버에 공격이 가해진다면 IP를 변경하기도 쉽지 않고 만약 수백, 수 천 개의 도메인을 서비스하는 호스팅 업체라면 그 피해가 전체 네트워크로 퍼질 수 있어 큰 문제가 될 수 있다.

따라서 관리자는 DNS을 최대한 다중화하고 각각을 다른 네트워크로 구성하는 것이 권장된다.

4장 DNS에서도 언급하였지만 대부분의 관리자는 편의상 master/slave DNS서버를 같은 네트워크에 두는 경우가 많은데 만약 해당 네트워크로 공격이 들어와 장애가 발생할 경우에는 그 피해가 매우 커질 수 있음을 주지하여야 한다.

심각한 네트워크 취약성, 그러나 대안은 있다.

지금까지 네트워크 보안의 첫 부분으로 여러 가지 네트워크의 취약성과 각각의 대응 방안에 대해 살펴보았다. TCP/IP 네트워크 자체의 취약성은 단순한 특정 응용 프로그램의 취약성과는 달리 그 피해 범위가 넓고 치명적인 경우가 있기 때문에 심각한 것이 사실이다.

그러나 그렇다고 해서 절망적인 것만은 아니다. 네트워크의 취약성은 최근에도 꾸준히 공개되고 있는데, 만약 시스템 취약성과 연계되었을 경우에는 상당 부분이 불필요한 서비스 중지나 접근제어 설정 또는 패치 등을 통해 해결될 수 있는 경우가 많이 있기 때문이다.

아울러 취약성의 정확한 원인과 작동 원리를 알아야 제대로 대응할 수 있으므로 취약성이 발견되면 단순한 툴의 사용법에만 의존하지 말고 취약성의 작동원리와 방식에 대해서도 관심을 갖기 바란다.

다음 장에서는 대표적인 네트워크 장비인 라우터를 중심으로 네트워크 보안을 강화할 수 있는 방안에 대해 살펴보도록 하자.