Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

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는 다음의 과정으로 진행이 됩니다.

tcp_connect_1.jpg

보는 바와 같이, 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로만 알 수 있다고 합니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 11/2/2022]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  5  6  7  8  9  10  11  12  [13]  14  15  ...
NoWriterDateCnt.TitleFile(s)
13262정성태2/15/20234295디버깅 기술: 191. dnSpy를 이용한 (소스 코드가 없는) 닷넷 응용 프로그램 디버깅 방법 [1]
13261정성태2/15/20233504Windows: 224. Visual Studio - 영문 폰트가 Fullwidth Latin Character로 바뀌는 문제
13260정성태2/14/20233375오류 유형: 847. ilasm.exe 컴파일 오류 - error : syntax error at token '-' in ... -inf
13259정성태2/14/20233486.NET Framework: 2095. C# - .NET5부터 도입된 CollectionsMarshal
13258정성태2/13/20233365오류 유형: 846. .NET Framework 4.8 Developer Pack 설치 실패 - 0x81f40001
13257정성태2/13/20233472.NET Framework: 2094. C# - Job에 Process 포함하는 방법 [1]파일 다운로드1
13256정성태2/10/20234294개발 환경 구성: 665. WSL 2의 네트워크 통신 방법 - 두 번째 이야기
13255정성태2/10/20233637오류 유형: 845. gihub - windows2022 이미지에서 .NET Framework 4.5.2 미만의 프로젝트에 대한 빌드 오류
13254정성태2/10/20233515Windows: 223. (WMI 쿼리를 위한) PowerShell 문자열 escape 처리
13253정성태2/9/20234158Windows: 222. C# - 다른 윈도우 프로그램이 실행되었음을 인식하는 방법파일 다운로드1
13252정성태2/9/20233156오류 유형: 844. ssh로 명령어 수행 시 멈춤 현상
13251정성태2/8/20233592스크립트: 44. 파이썬의 3가지 스레드 ID
13250정성태2/8/20235410오류 유형: 843. System.InvalidOperationException - Unable to configure HTTPS endpoint
13249정성태2/7/20234070오류 유형: 842. 리눅스 - You must wait longer to change your password
13248정성태2/7/20233390오류 유형: 841. 리눅스 - [사용자 계정] is not in the sudoers file. This incident will be reported.
13247정성태2/7/20234241VS.NET IDE: 180. Visual Studio - 닷넷 소스 코드 디버깅 중 "Decompile source code"가 동작하는 않는 문제
13246정성태2/6/20233368개발 환경 구성: 664. Hyper-V에 설치한 리눅스 VM의 VHD 크기 늘리는 방법 - 두 번째 이야기
13245정성태2/6/20233834.NET Framework: 2093. C# - PEM 파일을 이용한 RSA 개인키/공개키 설정 방법파일 다운로드1
13244정성태2/5/20233321VS.NET IDE: 179. Visual Studio - External Tools에 Shell 내장 명령어 등록
13243정성태2/5/20234109디버깅 기술: 190. windbg - Win32 API 호출 시점에 BP 거는 방법 [1]
13242정성태2/4/20233525디버깅 기술: 189. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.UnauthorizedAccessException
13241정성태2/3/20233164디버깅 기술: 188. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.IO.FileNotFoundException
13240정성태2/1/20233304디버깅 기술: 187. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.Web.HttpException
13239정성태2/1/20232956디버깅 기술: 186. C# - CacheDependency의 숨겨진 예외 - System.Web.HttpException
13238정성태1/31/20234773.NET Framework: 2092. IIS 웹 사이트를 TLS 1.2 또는 TLS 1.3 프로토콜로만 운영하는 방법
13237정성태1/30/20234409.NET Framework: 2091. C# - 웹 사이트가 어떤 버전의 TLS/SSL을 지원하는지 확인하는 방법
1  2  3  4  5  6  7  8  9  10  11  12  [13]  14  15  ...