SYN Segment를 전송한 후 SYNSENT 상태로 서버의 ACK Segment를 기다린다.
서버는 클라이언트로부터 SYN Segment를 수신한다.
[step 2] : 클라이언트 <———(ACK + SYN)——— 서버
서버가 클라이언트의 SYN Segment에 대한 ACK Segment를 전송한다.
Acknowledge Number는 client_isn + 1 로 설정한다.
Sequence Number는 서버의 최초 순서 번호(server_isn)로 설정한다.
동시에 서버가 클라이언트에게 연결을 요청하는 SYN Segment를 전송한다.
SYN bit를 1로 설정한다.
SYN/ACK Segment를 전송하고 SYN RCVD의 상태로 클라이언트의 ACK를 기다린다.
클라이언트는 ACK Segment을 받고 연결이 완료된 ESTAB 상태가 된다.
💡 [step 2]는 엄밀히 말하면 2개의 Handshake에 해당한다. 1. 응답하는 ACK Segment 전송 2. 연결을 요청하는 SYN Segment 전송 두 과정은 서로에게 영향을 끼치지 않고 독립적이다. 따라서, 1번과 2번 Segment 정보를 동시에 전송함으로써 1개의 Handshake로 처리할 수 있고, 네트워크 트래픽을 절약할 수 있다.
[step 3] : 클라이언트 ———(ACK)———> 서버
클라이언트는 서버의 SYN Segment에 대한 ACK Segment를 전송한다.
연결 요청이 아니기 때문에 SYN bit를 0으로 설정한다.
서버는 ACK Segment를 받고 연결이 완료된 ESTAB 상태가 된다.
[after] : 클라이언트 <———(Data)———> 서버
클라이언트와 서버가 서로 데이터를 주고받는다.
2-Way-Handshake
2-Way Handshake에서는 하나의 SYN 요청, 하나의 ACK 응답만 존재한다.
정상적인 2-Way Handshake 과정
클라이언트 ———(SYN)———> 서버
클라이언트가 서버에게 연결을 요청한다.
SYN 패킷을 전송한다.
서버는 SYN 패킷을 받고 ESTAB 상태가 된다.
클라이언트 <———(ACK)——— 서버
서버는 연결 수락 및 응답 패킷을 보낸다.
ACK 패킷을 전송한다.
클라이언트는 ACK 패킷을 받고 ESTAB 상태가 된다.
문제점
ISN 동기화가 이루어지지 않는다 (클라이언트가 서버의 ISN을 알 수 없다).
서버가 전송한 Segment의 순서를 구분할 수 없다.
Pkt Loss나 Delay를 탐지할 수 없다.
작업 순서가 달라져 오류가 발생한다.
작업의 중복 수행이 발생할 수 있다.
“half open connection” 상황이 발생할 수 있다.
한 쪽 Host만 연결된 상태를 의미한다.
연결된 Host는 계속 자원을 낭비하게 된다.
SYN Flooding(DoS의 일부)에 취약하다.
문제 상황 1
클라이언트 ———(SYN)———> 서버
클라이언트가 서버에게 연결을 요청한다.
SYN 패킷을 전송한다.
서버는 SYN 패킷을 받고 ESTAB 상태가 된다.
클라이언트 <———(ACK)——— 서버
서버는 연결 수락 및 응답 패킷을 보낸다.
ACK 패킷을 전송한다.
클라이언트 ———(SYN)———> 서버
2번 ACK 응답이 지연되고 클라이언트는 Timeout에 걸린다.
클라이언트는 Packet Loss가 발생했다고 판단해 요청을 재전송한다.
클라이언트는 2번 ACK 패킷을 받고 ESTAB 상태가 된다.
3번 요청에 대한 ACK 패킷이 왔으나, 1번 요청에 대한 ACK 패킷이 도착했다고 착각한다.
클라이언트 와 서버의 연결이 종료된다.
서버에게 3번 SYN 패킷이 도착한다.
서버는 새로운 연결 요청이라고 착각한다.
서버는 ACK 패킷을 보내고, ESTAB 상태가 된다.
클라이언트는 이미 종료된 연결에 대한 ACK 패킷이 도착했기 때문에 무시한다.
서버는 ESTAB 상태로 대기하며, 자원을 낭비하게 된다.
문제 상황2
문제상황 1과 3번까지는 동일하다.
클라이언트 ———(Data)———> 서버
클라이언트가 서버로 데이터를 전송한다.
서버는 4번 데이터를 수신하고 ACK 패킷을 전송한다.
첫 번째 data(x+1)을 진행한다.
위 그림에서는 ACK 패킷이 손실되거나 지연되었다.
클라이언트 ———(Data)———> 서버
ACK 패킷이 도착하지 않아 Time-Out이 발생한다.
클라이언트가 4번 데이터를 재전송한다.
클라이언트와 서버의 연결이 종료된다.
서버에게 3번 SYN 패킷이 도착한다.
서버는 새로운 연결 요청이라고 착각한다.
서버는 ACK 패킷을 보내고, ESTAB 상태가 된다.
서버에게 6번 재전송 패킷이 도착한다.
두 번째 data(x+1)을 진행한다.
data(x+1) 작업이 중복 처리된다.
SYN Flooding
SYN flooding은 네트워크 보안 공격 중 하나로, 공격자가 대상 서버에 대량의 TCP SYN 요청 패킷을 보내서 서버의 리소스를 고갈시키는 공격이다.
공격자 ———(SYN)———> 서버
이 과정을 반복해 대량의 SYN 패킷을 전송한다.
대량 연결 요청 자체에서 서버에게 부담을 준다.
서버의 리소스가 모두 소진된다면 응답하지 못하는 상태가 된다. = 서비스 거부(Denial Of Service,DoS) 상태
서버는 SYN 패킷을 받으면 SYN 패킷 관련 정보를 백 로그 큐에 저장해 관리한다.
공격자 <———(SYN+ACK)——— 서버
SYN+ACK 패킷을 전송하고 ACK를 받을 때까지 대기한다.
서버는 half-open 상태가 된다.
하지만, 공격자는 ACK를 전송하지 않고 서버를 계속 기다리게 한다.
half-open 연결이 계속 쌓이고, 서버의 연결 테이블이 고갈되어 서비스 거부 상태가 된다.
방어 방법
1. 대기 큐(백로그 큐) 크기 늘리기
저장공간을 늘려 수용할 수 있는 양을 늘리는 방법이다.
시간을 잠깐 늦추는 것 뿐, 결국 가득차게 되어 근본적인 해결방법이 될 수 없다.
2. SYN Cookie
3-Way Handshake와 유사하다.
SYN Cookie 를 사용한다는 점에서 다르다.
작동 방식
클라이언트 ———(SYN)———> 서버
클라이언트가 서버에게 연결을 요청한다.
서버는 클라이언트의 IP 주소, 포트 번호, 시간 정보 등을 이용하여 쿠키를 생성한다.
쿠키는 일시적으로 서버 메모리에 저장되고, 연결이 수립된 후에는 즉시 제거 된다.
클라이언트 <———(SYN + ACK (SYN Cookie))——— 서버
서버는 SYN+ACK 패킷의 ISN에 Cookie 값을 넣어 전송한다.
서버는 클라이언트로 부터 받은 SYN 패킷과 연결 정보를 저장할 필요가 없다.
Cookie 정보를 저장하지만 메모리 사용량이 적다.
클라이언트 ———(ACK)———> 서버
클라이언트는 ACK 응답 패킷을 보낸다.
서버는 Sequence Number(Cookie 값 + SYN 패킷의 크기)가 올바른지 확인한다.
일치하면 연결되고, 일치하지 않으면 패킷을 무시한다.
특징
정상적인 상황에서는 작동하지 않는다.
처리할 수 있는 한계를 초과했거나 SYN Flooding 공격이 가해질 때만 반응한다.
백로그 큐가 차기 시작하면 경고 메시지를 뿌리고, 이후 새로운 연결 요청에 대해서는 SYN Cookie가 작동하게 된다.
DOS 공격(1대에서 공격)은 막을 수 있지만 DDOS공격(여러 대에서 공격)은 막을 수 없다.
완벽한 해결방법은 아니므로, 다른 방식과 결합하여 사용한다.
연결 요청의 수를 제어하거나, 캐싱을 사용하거나, 로드밸런싱을 사용하여 버퍼가 가득차는 현상을 막을 수 있다.
질문
Q. 두 호스트가 동시에 연결을 시도하면, 연결이 가능한가요? 가능하다면 어떻게 통신 연결을 수행하나요?
