Syn cookie

Syn cookie란 ?

기본에 충실하기 위해 TCP 기본 로직부터 알아보자.

TCP로 세션이 생성 되려면 아래와 같은 기본적인 3-way-handshake를 거친다.

 

<기본>

 

사용자          서버
Syn      --->   
         <---   Syn + Ack
Ack      --->

<Syn flooding 공격의 경우>

공격자                           서버
Syn        --->        
           <---   Syn + Ack
Syn        --->   
           <---   Syn + Ack
Syn        --->   
           <---   Syn + Ack
Syn        --->   
           <---   Syn + Ack
Syn        --->   
           <---   Syn + Ack

 Syn cookie를 사용하지 않는 경우 서버 각각의 모든 Syn packet에 대해 세션을

생성하고 공격자의 응답을 기다린다.

 

 공격이 대량으로 발생할 경우 서버는 세션 리소스는 모두 낭비 되고 결국 장애 상황에 이르게 된다.

L4는 어떨까 ?  구조상 L4가 중간에서 서버의 역할을 대신하는 것이므로 서버와 똑같이

세션 테이블 리소스를 모두 사용하고 장애 상황이 된다.

 여기서 L4의 Syn cookie 방식(Syn cookie 방식은 서버든 L4든 어디든 설정이 가능함)은

L4가 Server를 대신해서 사용자에게 Syn+Ack (Cookie)로

먼저 응답을 하고 특정 시간을 기다린다.

 

 여기서 Cookie 값이 무엇인지는 아래에 상세하게 다시 설명한다.

어찌되었건, 먼저 L4가 응답을 하고 정상적인 사용자인 경우에는 이에 대한

응답을 하지만, Syn flooding 공격자인 경우는 응답이 없기에 L4는 Server쪽으로 세션을

생성하지 아니한다. Syn Cookie는 L4에서도 세션 테이블을 생성하지 아니한다.

Cookie 값 안에 사용자가 응답 패킷으로 사용해야 하는 sequence 정보를 모두 포함하여

보내기 때문에 L4는 Cookie로 응답하고 해당 요청에 대해 잊어버린다.

이러한 일련의 동작들은 대부분 kernel 이나 Hardware ASIC단에서 이루어지기 때문에 매우 많은 양의

공격도 효율적으로 방어가 가능하다.

 

 이해를 돕기 위해 정상적인 사용자와 공격자의 패킷 흐름도를 정리해보자.

<정상 사용자의 경우, L4의 Syn cookie 기능 활성상태>

사용자                                  L4                                              Server 
Syn                        --->   
                             <---   Syn + Ack (seq = cookie)
Ack (cookie + 1)     --->        
                                          Syn                        --->  
                                                                       <---            Syn + Ack

첫번째 Syn에 대해 L4에서 Syn + Ack (seq = cookie)로 응답하고 세션테이블을 생성하지 않는다.

이에, 정상 사용자는 응답을 시도하고 이 정상적인 응답 패킷의 cookie 값을 검증하여

정상 사용자로 판단하면 L4는 실제 Server로의 세션을 생성한다.

<Syn flooding 공격자인 경우, L4의 Syn cookie 기능 활성상태>

공격자                        L4                                        Server 
Syn        --->   
           <---   Syn + Ack (seq = cookie)
Syn        --->   
           <---   Syn + Ack (seq = cookie)
Syn        --->   
           <---   Syn + Ack (seq = cookie)
Syn        --->   
           <---   Syn + Ack (seq = cookie)
Syn        --->   
           <---   Syn + Ack (seq = cookie)

공격자는 L4의 Syn + Ack (seq = cookie) 패킷을 받을 수 없거나 (Source ip 변조),

응답을 하지 않기 때문에, L4는 Syn + Ack (seq = cookie) 응답만 지속적으로 한다.

L4는 세션 불필요한 세션 테이블을 생성하지 않기 때문에 Syn flooding 공격으로 인한

세션 자원을 정상적인 사용자에게 할당 가능하게 된다.

 

<Cookie에 대한 상세 정보>

 

TCP Packet header 정보에는 아래와 같은 정보가 포함된다.

1. Port 정보, Sequence 정보, Header 길이.

2. Flag 정보

3. Checksum 정보

4. Options 40byte 정보를 가질 수 있다.  (MSS, Timestamp 등)
   MSS = maximum segment size)

 

Syn Cookie는 이중에 4번 Option 최대 40byte중에 3비트를 제외한 나머지 공간을 활용하여

sequence 값을 인코딩한 정보를 이부분에 포함하여 Client로 보낸다.

Client는 이 인코딩된 정보를 받아서 자신이 다시 응답해야할 패킷을 생성한다. 

 다소 복잡한가? 간단히 설명을 해보면, 최초 사용자가 Syn flag를 가진 패킷으로

세션을 만들기 위한 시도를 하면, L4가 Cookie 정보에 사용자가 다시 응답시에 필요한

정보를 미리 포함하여 사용자에게 던지고는 L4는 해당 내용에 대해 잊어 버린다.

정상적인 사용자라면 해당 정보를 잘 분석해서 재응답 패킷을 만들어 보낼 것이고,

이 패킷의 cookie 값을 분석하여 정상적인 세션 연결 응답이라고 L4가 판단을 하면

그때 정상적인 세션 프로세스를 거친다는 방식이다.

그래도 어려운가? 이제 어쩔 수 없다.