C# - 코드로 재현하는 소켓 상태(SYN_SENT, SYN_RECV)
예전 글에서,
코드로 재현하는 소켓 상태(FIN_WAIT1, FIN_WAIT2, TIME_WAIT, CLOSE_WAIT, LAST_WAIT)
; https://www.sysnet.pe.kr/2/0/1334
소켓을 닫는 과정에 해당하는 4-way handshake 단계를 설명하면서 각각의 소켓 상태를 VM을 이용해 재현하는 방법을 설명했습니다. 그렇다면, 소켓을 연결하는 3-way handshake 과정에 발생하는 SYN_SENT와 SYN_RECV는 어떻게 재현할 수 있을까요? ^^
우선, TCP 연결 시 3-way handshake는 다음의 과정으로 진행이 됩니다.
보는 바와 같이, connect를 하는 측의 소켓은 서버로 SYN 패킷을 전송하면서 스스로는 SYN_SENT 상태로 바뀝니다. 그리고 이 SYN 패킷을 받은 서버는 SYN-ACK를 클라이언트에 응답하게 되고 SYN_RECV 상태로 바뀝니다.
마지막으로 SYN-ACK를 받은 클라이언트는 서버로 ACK를 전송하면서 SYN_SENT에서 ESTABLISHED 상태로 바뀝니다. 이와 함께 서버 역시 ACK를 수신하면서 SYN_RECV 상태에서 ESTABLISHED 상태로 바뀝니다.
자, 그럼 여기서 SYN_SENT 상태를 재현해 볼까요? ^^
이를 위해서는 서버 코드는 필요 없고, 단지 클라이언트 코드만 다음과 같이 작성한 후,
using System;
using System.Net.Sockets;
namespace ConsoleApp1
{
internal class Program
{
static void Main(string[] args)
{
string host = args[0];
int port = int.Parse(args[1]);
Connect(host, port);
}
static void Connect(string host, int port)
{
using (Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp))
{
Console.WriteLine("Trying to connect " + host + ":" + port);
try
{
socket.Connect(host, port);
Console.WriteLine("Connected!");
}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
}
}
}
}
존재하지 않는 서버를 지정해 실행하면 됩니다. 윈도우의 경우
Connect의 timed-out이 기본 설정으로는 21초 정도 걸리므로,
...[생략]...
Console.WriteLine(DateTime.Now);
Connect(host, port);
Console.WriteLine(DateTime.Now);
...[생략]...
/* 실행 결과
c:\temp> ConsoleApp1.exe 192.168.100.50 5000
2022-10-28 오후 4:50:12
Trying to connect 192.168.100.50:5000
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. 192.168.100.50:5000
2022-10-28 오후 4:50:33
*/
그 21초 사이에 netstat로 SYN_SENT 상태의 소켓을 하나 확인할 수 있습니다.
c:\temp> netstat -ano | findstr 5000
TCP 220.150.155.21:59832 192.168.100.50:5000 SYN_SENT 50380
쉽죠? ^^
반면, SYN_RECV 상태는 netstat로 확인하기에는 너무 빨리 지나가므로 재현이 어렵습니다. 이전에 설명한 대로, SYN_RECV는 Socket Server 측에서 SYN 패킷을 받았을 때, TCP Driver 단에서 SYN-ACK를 클라이언트로 보내게 된 후 전이되는 서버 측의 소켓 상태입니다. 당연히 바로 이 순간에는 SYN_RECV 상태를 확인할 수 있는데요, 문제는 서버가 보낸 SYN-ACK를 수신한 클라이언트는 곧바로 ACK를 보내주므로 이를 수신한 서버는 최종적으로 SYN_RECV에서 ESTABLISHED 상태로 바뀝니다. 결국 SYN-ACK를 보낸 서버가 클라이언트의 ACK를 수신하는 그 짧은 시간에만 SYN_RECV 상태에 머물기 때문에 확인이 쉽지 않습니다.
실력 있는 커널 개발자라면, 아마도 TCP Device driver를 조작해 보내오는 ACK를 일부러 처리하지 않고 지연 또는 누락할 수 있는 기능을 만들 수 있을 것입니다. 아니면, 아주 절묘하게 클라이언트에서 서버로 SYN를 보내자마자 클라이언트 프로그램이 실행되고 있는 Network를 끊어 서버로부터 전송된 SYN-ACK를 수신하지 못하도록 하면 됩니다.
그 외에 가능한 방법이 하나 더 있는데요, 클라이언트 측에서 TCP socket을 사용하지 않고 raw socket을 이용해 IP+TCP 패킷을 직접 구성한 다음 서버로 보내, 이후 서버가 보낸 SYN-ACK에 반응하지 않으면 됩니다.
바로 그런 목적의 소스코드가 지난 글에 설명한,
Windows 11 환경에서 raw socket 테스트하는 방법
; https://www.sysnet.pe.kr/2/0/13151
"
tcp_syn_flood.c"입니다. 해당 소스코드의 서버 정보만 변경해 빌드하고,
#define DEST_IP "192.168.100.50"
#define DEST_PORT 15501 // Attack the web server
// ...또한 안전을 위해 SYN 패킷을 한 번만 보내도록 소스 코드의 while 루프를 제거...
지정한 IP/PORT에 해당하는 서버에 다음의 소켓 서버를 만들어 실행해 두면,
using System.Net.Sockets;
using System.Net;
internal class Program
{
static void Main(string[] args)
{
TcpListener serverSock = new TcpListener(IPAddress.Any, 15501);
serverSock.Start(2);
Console.ReadLine();
}
}
이제 tcp_syn_flood 예제 코드를 실행해 테스트할 수 있습니다. 그럼, 클라이언트는 raw socket을 이용해 TCP SYN 패킷을 서버로 보내게 되고, 서버는 SYN-ACK를 클라이언트로 전송하게 되지만 그것을 받아주는 클라이언트가 없으므로, 이때 서버에서 netstat를 실행하면 SYN_RECV 상태를 확인할 수 있습니다.
c:\temp> netstat -ano | findstr 15501
TCP 0.0.0.0:15501 0.0.0.0:0 LISTENING 2300
TCP 192.168.100.50:15501 192.168.100.20:35117 SYN_RECEIVED 2300
이 글에서 재현한 tcp_syn_flood는, 재미있게도 이름에서 의미하는 것처럼
TCP SYN Flood 공격과 연관이 있습니다.
핵심 코드를 잠시 볼까요? ^^
{
// Step 1: Fill in the TCP header.
tcp->tcp_sport = rand(); // Use random source port
tcp->tcp_dport = htons(DEST_PORT);
tcp->tcp_seq = rand(); // Use random sequence #
tcp->tcp_offx2 = 0x50;
tcp->tcp_flags = TH_SYN; // Enable the SYN bit
tcp->tcp_win = htons(20000);
tcp->tcp_sum = 0;
// Step 2: Fill in the IP header.
ip->iph_ver = 4; // Version (IPV4)
ip->iph_ihl = 5; // Header length
ip->iph_ttl = 50; // Time to live
ip->iph_sourceip.s_addr = rand(); // Use a random IP address
ip->iph_destip.s_addr = inet_addr(DEST_IP);
ip->iph_protocol = IPPROTO_TCP; // The value is 6.
ip->iph_len = htons(sizeof(struct ipheader) + sizeof(struct tcpheader));
// Calculate tcp checksum
tcp->tcp_sum = calculate_tcp_checksum(ip);
// Step 3: Finally, send the spoofed packet
send_raw_ip_packet(ip);
}
보는 바와 같이, TCP 연결 시 사용하는 SYN 비트를 설정한 후 공격 대상이 되는 서버에 SYN 패킷을 전송만 합니다. 이와 함께 공격자의 IP에 해당하는 iph_sourceip.s_addr에 rand() 함수로 무작위 값을 설정하고 있습니다. 이렇게 되면, 서버는 SYN 패킷을 받은 후 SYN-ACK를 "무작위 IP"를 대상으로 전송하게 되고, 클라이언트로부터 전송되기를 기대하는 ACK를 기약 없이 기다리면서 SYN_RECV 상태의 소켓이 늘어나게 됩니다. 당연히, 서비스 장애로 이어지겠죠? ^^
윈도우에서는 이런 공격을 예방하기 위해 자체 보안 설정을 가지고 있는데요,
Syn attack protection on Windows Vista, Windows 2008, Windows 7, Windows 2008 R2, Windows 8/8.1, Windows 2012 and Windows 2012 R2
; https://learn.microsoft.com/en-us/archive/blogs/nettracer/syn-attack-protection-on-windows-vista-windows-2008-windows-7-windows-2008-r2-windows-88-1-windows-2012-and-windows-2012-r2
어느 정도의 방어 능력이 있는지는 저 문서만으로는 알 수가 없습니다. 단지, 시스템의 리소스 상황에 맞게 SYN attack에 대한 방어 태세로 돌입하고 그것은
ETL trace로만 알 수 있다고 합니다.
(2024-10-25 추가) 3-way handshake 단계에서 어떻게 listen과 accept가 이뤄지는지 아래의 다이어그램이 잘 보여주고 있습니다.
[출처:
https://eunomia.dev/en/tutorials/13-tcpconnlat/#tcp-connection-principle]
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]