tcp 연결 상태 확인을 하기 위해서, 프로그래밍을 하고 있는 중입니다.

* DoS, DDoS에 대해 오래전(6~7년전?) 잠시 고민해 본적이 있어서.... 가물가물합니다만, 오랜 기억을 더듬어 써보겠습니다.

DDoS 공격 유형중 하나인 SYN flooding도 마찬가지로, DDoS에 대한 탐지와 차단은 별개로 나누어 시작하시는게 좋습니다.
탐지하는 방법론도 다양하며, 차단(실제는 완화가 적절)하는 방법론도 다양합니다.

몇 가지만 조언을 드리자면,

0) SYN FLOOD는 서버가 보내는 SYN_ACK(클라이언트로부터 받은 SYN패킷에 대한 응답) 패킷으로 측정하게 됩니다.
SYN Flood공격의 시나리오를 잠시 보면,
(1) 공격자는 세션을 성립하기 위해 SYN을 보내고,
(2) 서버는 SYN_ACK를 공격자에게 응답으로 보낸다. 그리고,.. 세션(연결)을 위한 자료구조 만들고(자원사용하고) 타이머 돌리고, 등등, 서버는 이후 공격자로부터 ACK 패킷이 오기를 대기한다.
(3) 그런데, 공격자는 해당 세션에 대해 ACK를 보내지 않는다.
(4) 서버는 타임아웃이 오기까지 (2)에서 만든 자료구조를 유지한다.
위 (1)에서 (3)까지가 짧은 시간내에 n번 반복되면, 서버는 여전히 n개의 (4)로 유지되고, 결국, 서버의 자원은 고갈되고 결국 서버는 서비스 불능 상태로 빠지게 되는 것이 SYN Flood이지요.

TCP연결 상태를 모른다고 하셨는데, SYN Flood 탐지시에는 서버에서 클라이언트로 가는, 즉, 서버가 보내는 SYN_ACK(클라이언트로부터 받은 SYN패킷에 대한 응답) 패킷을 기준으로 측정하게 됩니다.

또 하나는 공격자인지? 정당한 사용자인지? 알 수 없다는 것입니다. 그래서, 판단 방법이 필요한데, 다양한 방법들이 있습니다. 패킷, 소스, 목적지, 플로우, 도메인, 국가, 통계, 시각화 분석등 다양한 방법론이 있습니다. 하여간...

1) 링크드리스트: 패킷 수준을 다루는 저수준 네트워크 프로그램에서는 링크드리스트는 너무 느려서, 시뮬레이션/프로토타입/테스트등 외에는 가급적 사용하지 않는 자료구조입니다.

고성능 lookup구조가 필요한데요, 다양한 자료구조가 있고, bloom filter도 그 중 하나로 볼 수 있습니다. 또는, tcam등 하드웨어 기반을 사용하기도 합니다. 멀티기가급 이상의 네트워크에서는 하드웨어의 도움 없이 대용량 패킷을 다루기가 어렵습니다.
그래도, 최대한 소프트웨어만으로 하신다면, 위의 bloom filter또는 hash라던지를 구현(또는, 오픈소스를) 사용하던가, 이미 내장된 라이브러리들을 사용하는 방법도 있겠습니다.
man tfind, man hsearch 참조
물론, 성능/기능 테스트가 필요하겠습니다.
아울러 메모리 한계에 대한 고찰이 필요하겠습니다.

2) libpcap
이는 원본 패킷을 복사받는데 사용되는 것입니다. 복사할때 원본 패킷 및 트래픽 속도 등에는 전혀 영향을 주지 않지요.
그래서, 이는 주로 네트워크에 영향(느려짐, 끊김 등)을 주지 않아야 하는 범주에서, 패시브(패킷 수준, 트래픽등) 모니터링 영역에서 널리 사용되고 있습니다.
네트워크 영향없이 패킷을 복사받기 위해 네트워크 라인에 탭(tap) 장비를 두어 트래픽 사본을 받도록 하고, 이를 분석장비의 NIC가 받게끔 하는 구조로 보통 합니다.
소규모 네트워크인 경우 스위치등에 있는 미러 포트를 이용(관리자 세팅)해서 하기도 하고, 별로 안좋은 방법으로 arp spoofing으로 패킷을 리다이렉트하고, libpcap으로 패킷을 잡기도 합니다.
libpcap은 잘 만들어진 라이브러리 이기는 하지만, 단지, 멀티기가(트래픽 유통이 많은 경우)인 경우 패킷의 캡쳐율이 100%가 되지 않을 수 있으므로
이에 대한 고려가 필요합니다.(100% 잡으려고 노력하는 것도 이 분야에서는 기술의 하나입니다.) NIC(Network Interface Card) 드라이버, 시스템 BUS 스피드도 고려대상이 됩니다.

'실제 패킷'을 보고 싶다고 하셨는데, 일단, libpcap이 주는 패킷은 복사본이지만 실제 패킷과 동일합니다.
단지, 특정 패킷을 프로그래머가 제어(판단)하기 전까지 네트워크로 흘러가지 못하게 하고 싶다면- 소위 인라인 모드(inline)라고 합니다 -,
커널 내부 tcpip스택 코드(skb를 다루는)를 직접 다루거나, netfilter 프레임워크를 사용하는 방법으로 libipq를 이용한 방법(사용자수준프로그래밍),netfilter 커널모듈 작성하는 법등이 있겠습니다.
아주 중요한 주의사항으로, 인라인 모드인 경우 코드를 매우 잘~ 작성하지 않으면, 트래픽이 느려지거나, 또는, 잘 안 흐르겠지요?!! ^^

libpcap수준(사용자영역프로그래밍) 에서 하는 방법은 8~9년 전에 sourceforge.net에 잠시 등장했다가 사라진(저는 실제 해보지 않았지만 아이디얼하게는 될 듯) 랜카드 2장을 꽂고, 한 랜카드에서 패킷을 읽고, 판단해서 정당하다고 판단하면 다음 랜카드로 송신하게 하는 방법입니다. libpcap에도 패킷을 송신하는 함수가 있지요?! 송신의 또 다른 방법으로는 libnet을 사용하는 것도 있습니다.
그외 NPU(Network Process Unit)이나, FPGA등에서 제공하는 프레임워크/방법을 사용할 수 있겠네요. 이 방법은 고성능이 나오지만, 비용이 제법 든다는 단점이 있습니다. 아울러 특정 플랫폼에 종속되게 되는 단점을 가지지요.

3) DoS인지 탐지하는 방법의 어려움
어떤 트래픽 플로우가 도스(DoS, 악성)인지 여부를 판단하는 것은 아주 어렵습니다. 특정 트래픽 플로우가 악성이라고 100% 확신하기 어렵다는 얘기입니다.
무죄 추정이랄까? 악의가 아니라, 선의로 거대한/대량의 연결 시도가 발생할 수도 있다는 사실을 항상 생각해야 합니다.
또는, 소수의 악의와 다수의 선의, 반대의 경우 등도 고려해야 합니다.
결국, 100% 확신을 가지고 판단할 수 없는 상황으로 귀착되는데요.
구현 알고리즘/방법론에 따라 다르겠지만, 최대한의 확률적 데이터/수치와, 이러한 데이터/수치 발생시, 이에 대해 미리 세워둔 대응 정책등을 고려하여, 오탐을 각오하고, 판단하는 식의 결론을 내리게 됩니다.

DDoS의 경우는 그 판단이 더욱 어렵습니다. 어떤 상황이 DDoS라고 정확히만 판단하여 알 수 있다면, 차단은 어떤 방식으로든 풀 수 있는 문제가 됩니다.

4) DDoS 차단/완화 방법
만약에, 회사업무의 중요한 통신트래픽인데, 빈번하게 연결시도를 하는 응용이 있다면 자칫 도스로 오해받을 수도 있습니다.
이러한 경우, 선량한 트래픽 플로우가 자칫 잘못 차단되어 업무/비용등에 커다란 손실을 끼칠 수 있습니다.

그래서, 실제 제품들은 섣불리 차단하는 방법을 사용하지 않을 것 입니다.
특정 도메인 차단, 특정국가 차단 , 특정 IP대역 차단, 특정 도메인 이외 전부차단 등을 하기 위해서는, 책임있는 결정권자의 개입이 요구될 것입니다..
이러한 경우 라우터 등에서 매뉴얼(자동화가 아닌 수작업)로 차단할 수 있을 것 입니다. 어렴풋하지만, 공격 봇넷 코드가 희생서버를 Name으로 하지 않고 IP로 되어 있어서, 서버의 IP대역을 바꿔서 대응했다는 얘기가 있기도 합니다.

저는 차단 보다는 완화시키는 방법을 선호할 것이라고 (개인적으로) 생각합니다. 트래픽을 분석하여 조건 발생시 해당 트래픽이 XXX 면에서 좀.. 과~하니, 완화시키자 라는 얘기지요.
완화시키는 것은 QoS를 사용하는 방식이 있을 수 있습니다. 트래픽의 QoS를 결정하는 파라메터로 위 탐지 방법이 사용 되겠지요.
특정 도메인 트래픽 QoS낮추기, 특정국가 트래픽 QoS낮추기 , 특정 IP대역 QoS낮추기, 특정 도메인외 전부QoS낮추기 또는 적절한 짬뽕?

5) 탐지 + 차단
- 탐지만을 구현하기도 합니다. 차단은 방화벽, 라우터와 연계하는 방법(하이브리드방식)을 사용하기도 합니다.
- 탐지+차단(완화)을 일체형으로 구현하기도 합니다.
- 차단(완화)하는 장비만을 구현하기도 합니다. 또는, 라우터, QoS장비를 사용하여 하기도 합니다.

* 아~ 로긴하니 CAPTCHA를 물어 보지 않아 좋네요^^