TCP SYN Flooding 공격의 원인과 해결책1편 : SYN Flooding 공격의 원리

SYN Flooding 공격의 원리

흔히 웹 서비스가 다운되면 아파치의 경우 MaxClients에서 지정한 숫자를 초과하여 프로세스가 떠 있을 때 발생하는데, 웹 프로세스의 개수도 정상적이었고 또한 서버에 부하(load average)도 전혀 없었다.

그래서 급한 마음에 웹 서비스를 재가동하여 서비스가 재 시작하였는데, 잠시 후에는 다시 동일한 현상이 발생하는 것이었다.

심지어는 웹 서비스만 중지되는 것이 아니라 네트워크 자체가 다운되어 네트워크를 재시작하거나 아예 시스템을 재부팅해야만 다시 접속이 정상적으로 이루어지는 현상도 발생하였다.

이 현상과 관련하여 별다른 로그도 없었는데, 평소와 다른 단 한 가지 단서는 netstat으로 확인하였을 때 SYN_RECV가 매우 많다는 것이었다.

얼마 후에 알게 되었지만 결론적으로 이는 SYN Flooding이라는 서비스 거부공격이었는데, 이 사실을 알고 대처하기까지는 꼬박 이틀이 소모되었다.

비슷한 시기에 필자와 마찬가지로 다른 서버 관리자들도 이 공격 때문에 원인과 대처 방법을 알지 못해 고생을 많이 했다고 들었다.

개인적으로 이 사건을 계기로 필자는 SYN Flooding에 대한 자료를 모으기 시작했고 아울러 본격적으로 보안에 대해 공부하는 계기도 되었다.

사실상 SYN Flooding 공격의 개념이 소개된 지는 꽤 되었지만 원격에서도 간단하게 실행할 수 있는 공격 소스가 광범위하게 배포되어 있기 때문에 쉽게 실행이 가능하고, 실제로 원래의 공격 근원지를 찾기란 거의 불가능하다는 특성 때문에 최근에도 이 공격이 자주 확인되고 있으며 심지어는 앞에서 설명한 스머프 공격처럼 다른 공격에 포함되어 있거나 분산서비스거부(ddos)공격 소스에 포함되어 있기도 했다. ddos 의 경우 같은 공격이라도 규모와 대처방법이 상이한데 이에 대해서는 뒤에서 별도로 살펴보도록 하겠다.

또한 서버용 플랫폼으로 가장 많이 사용되고 있는 리눅스나 윈도우 2000 서버의 경우 아무리 최신의 모든 패치를 하였다 하더라도 별도의 커널 파라미터나 레지스트리를 변경하지 않았다면 이 공격을 실행할 경우 단 몇 초 만에 서비스가 정지해 버리게 된다.

따라서 제대로 알지 못할 경우 피해가 확산될 수 있기 때문에 지금부터 설명할 SYN Flooding 공격의 원리와 대처방법에 대해 정확하게 알고 이해하는 것은 보안 관리에 매우 중요하다 할 것이다.

SYN Flooding이라는 용어에서 SYN이란 TCP 패킷에 존재하는 SYN 비트를 의미하는데, SYN 비트는 TCP 패킷에만 존재하므로 이 공격은 TCP에만 해당하는 공격이다.

이처럼 SYN Flooding 공격은 TCP 자체의 근본적인 취약점을 악용한 공격의 형태이므로 먼저 TCP에 대해 간단히 살펴보는 것이 순서일 것이다.

TCP는 "Transmition Control Protocol"의 약자로 UDP와는 달리 신뢰성 있는 연결을 담당한다.

따라서 서버와 클라이언트 간에 본격적인 통신이 이루어지기 전에는 다음 그림과 같이 소위 "3 Way handshake(일부 번역서에는 이를 “3번 악수기법”으로 번역하였다)"라는 정해진 규칙이 사전에 선행되어야 한다.

[그림] 3 way handshake의 개념

1단계. A 클라이언트는 B 서버에 접속을 요청하는 SYN 패킷(TCP)을 보낸다. 이때 A 클라이언트는 SYN을 보내고 B서버로부터 SYN/ACK로 응답을 기다리는 SYN_SENT 상태가 된다.

2단계. B 서버는 SYN 요청을 받고 A 클라이언트에게 요청을 수락한다는 ACK와 B에서도 접속을 한다는 SYN flag가 설정된 패킷을 발송하고, A가 ACK로 다시 응답할 것을 기대한다.

이때 B 서버는 SYN_RECEIVED 상태가 된다.

3단계. A 클라이언트는 B 서버에게 ACK를 보내고 이후로부터 연결이 이루어지고 본격적으로 데이터가 교환된다.

이때 A,B 서버는 모두 ESTABLISHED 상태가 된다.

이것이 TCP가 연결을 맺기 위해 필요한 3 way handshake의 기본적인 flow이다.

그런데, 이 그림에서 약점을 찾아보자. 그렇다. 만약 악의적인 공격자가 1단계만 요청(SYN)하고 B서버로부터 응답(SYN +ACK)을 받은 후 3단계, 즉 클라이언트에게 ACK를 보내지 않는다면 어떻게 될까? B 호스트는 SYN+ACK 패킷을 받은 A로부터 응답이 올 것을 기대하고 반쯤 열린 이른바 "Half Open" 상태가 되어 대기 상태에 머무른 후 일정 시간(최대 75초) 후까지 다음 요청이 오지 않으면 해당 연결을 초기화 하게 되는데, 초기화하기 전까지 이 연결은 메모리 공간인 백로그 큐(Backlog Queue)라는 공간에 계속 쌓이게 된다.

그런데, 이러한 악의적인 연결 시도를 백로그 큐에서 초기화하여 지워버리기 전에 악의적인 새로운 요구가 계속 들어오게 된다면, 또한 위조된 새로운 요구가 연결을 초기화하는 속도보다 더 빨리 이루어진다면 어떻게 될까?

이러한 경우 SYN 패킷이 백로그 큐에 어느 정도 저장이 되겠지만 결국 가득 차게(flooding) 되어 더 이상의 연결을 받아들일 수 없는 상태, 즉 서비스 거부 상태로 들어가게 되는 것이다.

이처럼 백로그 큐가 가득 찼을 경우에 공격을 당한 해당 포트로만 접속이 이루어지지 않을 뿐 다른 포트에는 영향을 주지 않고, 또한 서버나 네트워크에 별다른 부하도 유발하지 않기 때문에 관리자가 잘 모르게 되는 경우가 많다.

또한 다른 서비스 거부공격과는 달리 많은 트래픽(bps)을 유발하는 공격이 아니므로 쉽게 파악이 되지 않는 공격 형태이다.