[TCP] 체크섬 오프로드 및 하프오픈 공격 대응 방법

 

1. TCP 체크섬 오프로드 기능

- 체크섬 계산의 기본 수행 위치

TCP 체크섬 계산은 보통 운영체제의 소켓 레벨에서 이루어진다. 하지만 최근 통신 성능 향상을 위해 체크섬 연산을 이더넷 NIC(Network Interface Card)에서 처리하는 경우가 많아지고 있다.

 

- 체크섬 오프로트듸 장점

NIC에서 체크섬을 계산하면 시스템의 통신 처리 성능이 향상된다.

일반 패킷	약 5% 성능 향상
점보 패킷	약 15% 성능 향상

 

- 체크섬 오프로드와 패킷 캡처

 패킷 캡처 도구(예: Wireshark)에서 TCP Bad Checksum 오류가 나타나는 경우, 실제 통신 에러일 수도 있지만 대부분은 NIC에서 잘못된 체크섬 연산 때문에 발생한다.

 

- 체크섬 오프로드 비활성화 방법

NIC에서 체크섬 오프로드 기능을 비활성화하면 이러한 오류를 방지할 수 있다.

• Windows 설정 경로:
  NIC 설정 > 속성 > 구성 > 고급 > Offload TCP/IP Checksum에서 해당 기능 조정 가능.

- 운영 환경에서의 권장 사항

• 분석 및 개발 목적(패킷 캡처 등)으로는 기능을 비활성화할 수 있다.
• 하지만 운영 중인 시스템에서는 통신 성능 향상을 위해 기능 활성화를 권장한다.

 

2. TCP 체크섬 에러 증상

- 증상 발생 사례

 고객 사이트에서 발생하는 커넥션 타임아웃 또는 TCP 재전송 이슈를 분석하기 위해 패킷 캡처 툴을 활용한다.
이 과정에서 'TCP Checksum Error'라는 메시지가 표시될 경우, 초보 분석가는 이를 주요 원인으로 오인하기 쉽다.

 

- TCP 체크섬 에러의 실제 원인

TCP는 신뢰성 있는 프로토콜이다. 만약 체크섬 오류가 있는 세그먼트가 수신되면 해당 세그먼트는 폐기되고 재전송 요청이 이루어진다. 따라서, 실제 에러인지 분석기가 잘못 표시한 것인지 확인이 필요하다.

진짜 에러	재전송 요청 발생 및 응답(ACK) 없음.
오탐	분석기 오류 또는 NIC 오프로드 연산 문제.

 

- 오탐으 주요 원인

패킷 분석기 문제	트레이스 파일을 변환하는 과정에서 체크섬 필드 값이 잘못 수정되는 경우.
NIC 오프로드 연산 문제	NIC의 잘못된 체크섬 계산으로 인해 분석기에 오류로 표시되는 경우.

 

- 정상 여부 확인 방법

TCP 체크섬 에러로 표시된 프레임 이후의 데이터 흐름을 확인한다.

• 순서 번호(Sequence Number)와 확인 응답 번호(Acknowledgement Number)가 일치하면 이는 분석기의 실수로 간주된다.
• 반대로, 세그먼트 폐기 및 재전송이 발생한다면 이는 실제 에러일 가능성이 높다.

 

3. TCP SYN 플러딩 또는 TCP 하프오픈 공격

- TCP SYN 플러딩 공격의 개요

TCP SYN 플러딩은 서비스 거부(DoS) 공격의 대표적인 유형으로, TCP 프로토콜의 3-way handshake 동작 방식을 악용한 공격이다.

• TCP는 세션 연결을 위해 클라이언트와 서버 간 3-way handshake 과정을 거친다.
  1. 클라이언트가 서버로 SYN 패킷 전송.
  2. 서버가 SYN-ACK 패킷으로 응답.
  3. 클라이언트가 ACK 패킷으로 연결 완료.
• 공격자는 이 과정을 악용해 SYN 패킷만 보내고 ACK를 보내지 않음으로써 서버를 과부하 상태로 만든다.

 

- TCP 하프오픈 상태와 서버의 백로그 큐

• 서버는 클라이언트의 SYN 패킷에 응답한 뒤 하프오픈(Half-Open) 상태로 대기한다.
• 이 상태는 약 75초 동안 지속되며, ACK 패킷이 오지 않으면 연결 요청이 초기화된다.
• 초기화 전까지 하프오픈 상태 정보는 서버의 백로그 큐(Backlog Queue)에 저장된다.

 

- 공격자의 의도와 방법

공격자는 서버의 백로그 큐를 고의적으로 가득 채워 정상적인 요청이 처리되지 못하게 한다.

• 대량의 SYN 패킷만 전송해 큐를 점유.
• 서버의 자원을 고갈시켜 정상적인 서비스 제공을 방해.
• IP 스푸핑(IP Spoofing)을 함께 사용해 출발지 IP를 위조하는 경우가 많다.

- 하프오픈 공격 탐지 방법

공격 여부는 netstat 명령을 통해 확인할 수 있다.

• 정상적인 통신에서는 Received-SYN 상태가 순간적으로만 나타난다.
• 공격 시에는 SYN-RECV 상태가 대량으로 확인된다.

netstat -an | grep SYN-RECV

 

4. 해결 방법

(1) 서버 측면의 TCP 하프오픈 공격 대비

- 서버 백로그 큐 늘리기

 하프오픈 공격을 방어하는 가장 간단한 방법 중 하나는 서버의 백로그 큐(Backlog Queue) 크기를 늘리는 것이다. 백로그 큐는 서버가 연결 요청을 기다리는 버퍼로, 이 값을 충분히 늘려주면 공격이 발생하더라도 일정 부분 지연시킬 수 있다. 그러나 이 방법은 완전한 방어가 아닌 지연 효과만을 제공한다.

• 서버의 RAM 용량에 따라 적절한 크기로 설정한다. 예를 들어, RAM이 128MB일 경우 128KB, 그 이상일 경우 1024KB로 설정할 수 있다.
• 이 방법은 과거 마이크로소프트 윈도우 서버에서도 사용되었으나, 현대적인 방어 방식으로는 충분하지 않다고 볼 수 있다.

• 백로그 큐 값의 확인

[root@jjang/root] # sysctl - a | grep syn-backlog net.ipv4.tcp_max_syn_backlog = 128

• 백로그 큐 값의 설정

[root@jjang/root] # sysctl -w net.ipv4.tcp_max_syn_backlog = 1024 or [root@jjang/root] # echo 1024 > /proc/sys/net/ipv4/.tcp_max_syn_backlog

 

- Syncookies 기능 활성화

 Syncookies 기능은 TCP 3-way 핸드셰이킹에서 세션이 성공적으로 설정되지 않으면 세션을 종료하는 방식으로, 하프오픈 공격을 확실하게 차단할 수 있는 방법이다. Syncookies는 TCP 헤더의 일부를 추출하여 암호화하고, 이를 통해 올바른 핸드셰이킹이 이루어지지 않으면 세션을 종료시킨다.

• 이 기능은 커널에서 CONFIG_SYN_COOKIES 옵션이 Y로 설정되어야 활성화된다.

• Syncookies 값 확인

[root@jjang/root] # sysctl - a | grep syncookie net.ipv4.tcp_syncookies = 0

• Syncookies 값 설정

[root@jjang/root] # sysctl -w net.ipv4.tcp_syncookies = 0

이 외에도 여러 시스템의 네트워크 파라미터 값을 최적화하는 방법이 있지만, 서버에 종속적인 내용이므로 생략한다.

 

- 기타 네트워크 파라미터 최적화

하프오픈 공격을 방어하기 위해 여러 시스템의 네트워크 파라미터를 최적화할 수 있다. 그러나 이는 서버 환경에 달라지므로, 각 서버 환경에 맞는 최적화를 적용하는 것이 중요하다.

 

(2) 네트워크 측면의 TCP 하프오픈 공격 대비

- TCP 가로채기(TCP Intercpt)

 하프오픈 공격은 공격자가 TCP 세션을 연결하려는 목적이 아니라, 세션 연결 과정에서 서버의 백로그 큐를 초과하여 서비스 거부(DoS) 상태를 유발하는 공격이다. 이 공격을 방지하려면 네트워크 장비에서 중간자 역할을 하여, 서버와 클라이언트 간의 세션을 확인하는 방법이 필요하다.

 

 Cisco의 TCP 가로채기(intercept) 기능은 이를 해결하기 위한 기술이다. 이 방식은 네트워크 장비가 클라이언트로부터 받은 SYN 패킷에 대해 직접 응답하고, 클라이언트와 3-way handshake를 맺은 후, 그 연결만 서버로 전달하는 방식입니다. 이를 통해 서버가 하프오픈 상태에 빠지는 것을 방지할 수 있다.

• 작동 방식
  • 네트워크 장비가 클라이언트로부터의 SYN 세그먼트를 가로채고, 서버와 3-way handshake를 완료한 뒤, 클라이언트와 서버 간의 세션을 정상적으로 연결합니다.
  • 주의점: 중간에서 SYN-ACK 응답을 보낼 때 윈도우 크기를 0으로 설정하여, 서버와의 연결이 확인되면 클라이언트와 서버 간에 정상적인 연결이 이루어지도록 합니다.

• Cisco 장비에서의 TCP 인터셉트 설정

router(config) # ip address-list extended TCP_Intercept router(config-ext-nac1) # permit tcp any host 10.10.20.2 eq www router(config-ext-nac1) # end router(config) # ip tcp intercept list TCP_Intercept router(config) # ip tcp intercept connection-timeout 30(기본 값으로 생략 가능)

 

※ 주의 사항: 대량의 트래픽을 처리하는 상황에서는 네트워크 장비의 CPU와 메모리 부하가 증가할 수 있으므로 적절한 설정과 모니터링이 필요하다.

 

- 지연 연결(Delayed Binding)

 지연 연결은 TCP 인터셉트와 유사하지만, L7 스위치 및 일부 L4 스위치에서 기본적으로 제공되는 기능이다. 이 기능은 클라이언트와 서버 간의 TCP 세션 형성을 잠시 보류하고, 클라이언트의 요청을 기반으로 세션을 확인한 후 서버와의 연결을 확립하는 방식이다. 이를 통해 하프오픈 공격을 방지할 수 있다.

• 작동 방식
  • L7 스위치는 클라이언트와 서버 간의 TCP 세션 형성을 보류한 뒤, 클라이언트의 요청 정보를 분석하여 적절한 서버로 세션을 연결한다.
  • 이 방식은 트래픽을 중간에서 제어하고, 불필요한 세션을 차단하여 서버가 하프오픈 상태에 빠지지 않도록 한다.

 

• 라드웨어 알테온 L4 스위치에서의 지연 연결 설정

# 일반적 설정 # /cfg/slb/virt <virtual server number> / service <service type? / dbind # 캐시 리다이렉트를 위한 설정 # /cfg/slb/filt <filter number> /adv/layer7/urlp ena # SYN attack 차단 임계치 변경 # /cfg/slb/adv/synatk

 

- IP 스푸핑 대역의 ACL 필터링

 하프오픈 공격에서 사용되는 IP 주소는 종종 비활성화된 시스템이나 내부 네트워크의 IP 대역을 사용한다. 공격자는 SYN 패킷을 보낸 후 서버로부터 SYN-ACK 패킷을 받지만, 해당 IP 주소는 실제로 존재하지 않거나 비활성 상태일 수 있다. 이를 통해 서버는 하프오픈 상태의 세션을 유지하게 된다.

• 대응 방법
  • ACL 필터링을 사용하여 비활성화된 IP 대역이나 내부 네트워크에서 유입되는 비정상적인 패킷을 차단한다.
  • 이를 통해 공격자는 비활성 IP 대역을 사용하여 공격 효과를 극대화할 수 없게 된다.

• ACL 설정 예
  • 내부 네트워크 대역, 로컬 호스트 대역(127.0.0.0/8), RFC 1918의 사설 대역, 멀티캐스트 예약 대역 등에서 유입되는 패킷을 차단한다.
  • 최신 Bogon List를 참고하여 보안 설정을 강화하는 것이 좋다.

# ACL 설정 예 access-list 101 deny ip 192.168.0.0 0.0.255.255 any access-list 101 deny ip 127.0.0.0 0.0.0.255 any

 

이 방식은 IP 스푸핑 공격을 차단하고, 서버가 하프오픈 상태에서 벗어나도록 도와줍니다.