거절한다: 7월 2009

출처 : http://www.texcell.co.kr/support/faq/board_view.asp?article_id=6&page=1&search_key=&search_value=

<SYN Flood DoS Attack>

SYN Flood DoS는 TCP/IP의 취약성을 이용한 방식으로, 운영체제를 가리지 않고 적용된다. Windows 시스템 역시 TCP/IP를 기본적으로 사용하고 있기 때문에 SYN Flood DOS에 대해 자유로운 것은 아니다.

<TCP/IP 3-Way Handshake 동작원리>

TCP/IP 네트워크는 핸드셰이크(Handshake)라는 과정을 통해 상호간 연결을 유지한다. 핸드셰이킹은 3단계로 나누어진다. 먼저 클라이언트는 원격지 컴퓨터에게 접속하고자 하는 포트로 연결 요구를 하며, 이를 받아 원격 서버에서는 ACK(Acknowledgment)와 연결 큐로 클라이언트에 응답한다. 그리고 클라이언트가 이 ACK에 응답하면 연결이 이루어진다.

<SYN-Flooding 동작원리>

SYN(Synchronize) Flood는 이 세 가지 단계 중 마지막 클라이언트가 이 ACK에 응답하지 않는 상황에서 발생한다. SYN Flood란 명칭은 이러한 공격을 수행하는 프로그램이 최초에 SYN Flooder라는 이름으로 공개되었기 때문이다. 이런 상황에서 ACK를 발송한 서버는 클라이언트가 ACK에 응답하기 전까지 해당 접속 정보를 잠시 로그에 쌓아 둔다. 만일 동시다발적으로 이러한 요구가 증가했을 경우, 시스템은 로그를 위한 공간을 충분히 확보하지 못하게 되며 결국 네트워크 중단으로 이어지게 된다.

<SYN-Flooding 방어 및 증상>

CERT에서는 현재 이러한 공격에 대해 지금의 IP 시스템 체계에서는 사실 마땅히 막을 수 있는 방법은 존재하지 않으며, 라우터 설정이나 기타 다른 방법으로 침입을 통제하는 방편을 사용할 것을 권장한다. 또한 일반적으로 SYN Flood 공격은 시스템의 트래픽을 증가시킬 뿐, 일반적인 TCP/IP 접속 방식을 사용하고 있기 때문에 그다지 두드러진 로그상의 특징이 나타나지 않는다.

순간적인 포착은 netstat 명령어로 시도할 수 있으며, netstat 명령어로 SYN_RECEIVED가 계속 나타나면 공격에 노출된 것으로 간주할 수 있다.

<SYN Flooding 대처 방법>
SYN Flood DoS를 막는 방법은 근본적으로는 존재하지 않으나 다음과 같은 몇 가지 설정을 조작하여 SYN Flood 가능성을 낮추는 해결책은 존재한다.

첫번째 설정은 반쯤 열려진 연결 시도들을 얼마나 빨리 닫아버릴지 여부를 설정하는 것이다. 물론 이 시간 내에 지속적인 DDOS 공격을 감행한다면 큰 의미는 없지만, 상대적으로 조절하지 않은 시스템에 비해 조절한 시스템이 훨씬 안정적으로 동작할 확률이 높다. 하지만, 정상적인 접속도 제대로 이루어지지 않을 가능성이 있으니 이를 주의해야 한다.

두번째 SYN Flood를 방지하는 방법은 로그 크기를 늘리는 방법과 접속 시간을 줄이는 방법이 있다. 전자의 경우는 정상적인 접속이 저해될 가능성은 없지만, 로그를 늘려준다는 것은 공격에 대한 지연 시간만 확보하는 것이라 큰 의미는 없다.

<그 외 SYN_Flooding 에 대한 보충 설명>
(1) RFC 1918 에 의해 내부(Private) IP를 소스로 들어오는 트래픽을 차단한다.
127.0.0.0, 10.0.0.0, 172.16.0.0, 192.168.0.0 등은 Private IP 로서 내부의 가상 IP 를 사용할 때 쓰이는 주소이며 일반적으로 이러한 IP를 소스 주소로 라우팅이 될 수 없다.

(2) 임의의 IP 가 아닌 특정한 IP를 소스 주소로 계속적으로 SYN 공격이 이루어 질 경우에는 해당 IP 를 차단하는 것도 좋은 방법이다.
만약 임의의 IP로 공격지를 생성한다면 SYN_RECEIVED 로 보이는 IP 중에는 실제 네트워크에 연결되어 있는 IP 도 있을 것이고 그렇지 않은 IP 도 있을 것이다. 그러나 실제 공격을 당할 때 공격지 IP 를 검출해 보면 모두 ping 이 되지 않는 실제 네트워크에 연결되지 않은 IP 주소이다. 어째서 이런 현상이 일어날까? 이는 앞에서 설명한 TCP 의 3 Way-Handshake 원리를 잘 생각해보면 이해가 될 것이다.
즉, 무작위로 생성된 IP 를 소스로 한 SYN 패킷을 받은 서버는, 요청을 받은 모든 IP 로 SYN+ACK 패킷을 보낸다. 그런데,정작 실제로 해당 IP 를 사용중인 호스트는 SYN 패킷을 보내지도 않았는데, 공격을 받은 서버로부터 영문도 모르는 SYN+ACK 를 받았으므로 이 패킷을 비정상적인 패킷으로 간주하고 해당 패킷을 리셋(RST)하여 초기화 시킨다.
그리고 실제 존재하지 않는 IP 에 대해서 알아보자. 공격을 당한 서버가 해당 IP로부터 SYN 패킷을 받았다고 판단(실제로는 위조된 패킷이지만) 하여 SYN+ACK 패킷을 발송 후 ACK 패킷을 계속 기다리지만 해당 IP 는 인터넷에 연결되어 있지 않으므로 SYN+ACK 패킷을 받을 수도 없을 뿐더러 이에 대한 응답으로 ACK 패킷을 발송하지 않을 것임은 불을 보듯 뻔한 것이고, 결국 공격을 받는 서버는 존재하지도 않는 IP 로부터 ACK 패킷을 받을 것만을 기다리며 백로그큐는 가득 차게 되는 것이다. 이것이 백로그큐가 가득 차게 되는 이유이며 백로그큐를 가득 채우는 IP가 모두 실제로는 존재하지 않는IP 들인 것이다. 따라서 공격자의 입장에서는 인터넷상에서 라우팅이 되지 않는 IP 를 소스 IP 로 하여 공격하는 것이 가장 효과적일 것이다. 즉 인터넷에 연결되어 있는 IP 를 소스 주소로 하여 SYN Flooding 공격하는 것은 의미가 없다.
(3) 실제 공격지 IP를 추적하는 것은 거의 불가능하다.
대부분의 DoS 공격이 그러하듯이 SYN_Flooding 공격도 소스IP를 속여서 들어오기 때문에 netstat 으로 보이는 IP를 실제 공격지 IP 라고 판단해서 해당 IP로 역공격을 해서는 안 된다. 공격을 당하는 리눅스 서버에서 공격지를 아는 방법은 없으며 상위 라우터와 해당 라우터가 연결되어 있는 ISP 업체와 긴밀하게 협조가 되었을 때라야 그나마 추척이 가능하다.
그러나 사실상 협조가 이루어져도 추척하기란 매우 어려운데, 만약 라우팅 경로가 20개이상 되는 곳에서 공격한다면 20개 라우터를 관리하는 모든 관리자와 동시에 협조가 이루어져야하고 공격이 실제 이루어지고 있는 당시에 추척이 되어야 하므로 매우 어렵다고 할 수 있다. 결론적으로 공격지 IP를 추척하는 것은 불가능하다고 할 수 있다.
그리고, 참고적으로 시스템에서 위조된 패킷을 생성하는 것은 오직 root 만이 가능하므로 공격자는 공격지 시스템의 root 소유로 SYN Flooding 공격을 하는 것이라는 사실을 참고하기 바란다.
(4) 라우터나 방화벽에서 차단 가능하다.
라우터등 네트워크 장비로 유명한 CISCO 에서는 TCP SYN_Flooding 공격을 차단하기 위해 TCP Intercept 라는 솔루션을 제안했다. TCP Intercept 는 두 가지 방식으로 구현가능한데 , 첫번째 방식은 “인터셉트 모드” 라 하여 말 그대로 라우터로 들어오는 SYN 패킷 요청을 그대로 서버에 넘겨주지 않고 라우터에서 일단 가로채어(Intercept 하여) 서버를 대신하여 SYN 패킷을 요청한 클라이언트와 연결을 맺고, 연결이 정상적으로 이루어지면 이번에는 클라이언트를 대신하여 서버와 연결을 맺은 다음 두 연결을 투명하게 포워딩하여 연결시켜주는 방식이다. 따라서 존재하지 않는 IP 로부터 오는 SYN 요청은 서버에 도달하지 못하게 되는 것이다. 두번째 방식은 “와치(watch) 모드” 라 하여 “인터셉트 모드”와는 달리 라우터를 통과하는 SYN패킷을 그대로 통과시키고 일정 시간동안 연결이 이루어지지 않으면 라우터가 중간에서 SYN 패킷을 차단하는 방식이다. 몇몇 방화벽에서도 위의 두 가지 방식으로 SYN Flooding 을 차단하고 있다. 실제로 tcp intercept 를 설정하여 테스트 결과 서버 레벨에는 전혀 스푸핑된 SYN 패킷이 보내지지 않아 SYN_Flooding 공격을 차단하기 위한 가장 확실한 방법이기는 했지만 아쉽게도 라우터의 CPU, Memory 부하가 너무 높아지는 단점이 있었다. 이 설정에 대해 궁금하신 분은 http://www.cisco.com/ 접속후 "tcp intercept" 로 검색해 보기 바란다. 이 설정을 했을 경우에는 모든 패킷에 대해 인터셉트를 하므로 트래픽이 많을 경우에는 라우터가 다운되는 경우도 있으니 설정시 각별히 주의하기 바란다.

(6) Windows NT/2000 계열에서는 Registry값을 수정함으로써 튜닝이 가능하다.
이 값에 대한 튜닝은 Microsoft 의 technical page 나
http://packetstorm.securify.com/groups/rhino9/synflood.doc 를 다운로드 받아 참고하기 바란다.
AIX나 Solaris등 다른 UNIX 계열에 대한 튜닝은
http://www.cymru.com/~robt/Docs/Articles/ip-stack-tuning.html 를 참고하기 바란다.

<Radware IPS 장비의 SYN Protection 작동 원리>

<Requirement>

: Radware 장비 상에서, SYN Flood 방어를 위해 몇 가지 필수 요구사항이 설정되어야 한다.

1. 장비에서 Layer 4 Session table과 함께 운영되어야 한다.

2. 양단의 Data 전송 방식을 Static forwarding으로 설정하고, Process mode로 설정한다.

3. 장비에서 Protection을 위한 정책이 하나 이상 activate 되어야 한다.

4. 각 Protection 정책에 대한 설명

A. a TCP destination port range

i. 방어 정책을 적용하기 위하여 Destination IP 주소를 분리, 적용하기 위하여 사용된다.

B. SYN에 대한 세가지 방어 모드

i. Enabled

1. SYN 쿠키를 사용

ii. Triggered

1. 사용자에 의해 정의되어 임계치 값을 통해 SYN을 방어

2. 초기에 기본값으로 일반적인 TCP의 Random ISN을 사용

3. SYN 공격이 활성화 되었을 때, SYN Cookie를 사용

4. SYN에 대한 방어는 공격을 받는 Destination에 대해서만 활성화

iii. Disabled

1. SYN에 대해 감지 없이 모든 TCP ISN을 받아 들임

• Trigger를 설정할 때 사용되는 임계치 값에 대한 설명:

– SYN Protection Attack Protection Timeout

• TCP 3-way handshake가 완료되어야 하는 시간을 설정한다.

– SYN Protection Threshold Up Ratio

• SYN 방어를 activate 시켰을 때, 1초에 열려진 모든 session에 대해 수용할 수 있는 uncompleted SYN의 percentage 설정

– SYN Protection Threshold Down Ratio

• SYN 방어를 deactivate 시켰을 때, 1초에 열려진 모든 session에 대해 수용할 수 있는 uncompleted SYN의 percentage 설정

– SYN Protection Triggering Time

• threshold up/down 비율이 여기서 설정된 triggering time을 초과하였을 경우, SYN에 대한 방어가 activate/deactivate 된다.

– SYN Protection Minimum SYNs per Second for Trigger

• SYN protection이 발생하였을 때, 전체 open 세션에 대해 완료되지 않은 SYN에 대한 수용할 수 있는 절대적인 최소값

•

• Radware 장비를 통하여, SYN에 대한 방어를 시도할 때, Threshold(임계치)에 대한 설정은 각 network의 특성에 따라 다르다. 따라서, 이에 대해서 관리자가 manual하게 설정이 가능하며, 이 임계치를 초과할 경우, SYN flooding에 대한 발생으로 간주, Protection 기능을 enable 하게 된다.

거절한다

2009년 7월 23일 목요일

40인치 LCD TV가 70만원 대? LS전자 S400WHF

2009년 7월 20일 월요일

C++ 개발자를 위한 참고사항

나는 관대 하다?

2009년 7월 14일 화요일

공개 프록시 서버

2009년 7월 8일 수요일

2009/7/7 DDos 공격과 관련된 Syn Flooding

급등 패턴이라…

2009년 7월 3일 금요일

Yamaha TSX-130

Dream Car

Tomorrow is another day

태그

블로그 보관함

위젯 테스트