2008-09-21 3 views
15

좋아,이 상황은 다소 드문 일이지만, 원시 소켓 (Linux의 C 언어)을 사용하여 TCP 연결 (3 방향 핸드 셰이크)을 설정해야합니다. 즉 IP 헤더와 TCP 헤더를 직접 만드십시오. 나는 서버를 작성하고있다 (그래서 나는 들어오는 SYN 패킷에 먼저 응답해야한다). 그리고 어떤 이유로 든 나는 그것을 올바르게 얻지 못한다. 예, SOCK_STREAM이이 문제를 처리 할 것이라는 것을 알고 있습니다.하지만 그 이유에 대해서는 제가 선택할 수있는 옵션이 아닙니다.SOCK_RAW 소켓을 사용하는 TCP 핸드 셰이크

원시 소켓을 사용하여 온라인에서 찾은 튜토리얼은 모두 SYN 플로터를 작성하는 방법을 설명하지만 실제로는 TCP 연결을 설정하는 것보다 다소 쉽습니다. 원본을 기반으로 응답을 작성할 필요가 없으므로 패킷. SYN flooder 예제가 작동하고있어 원본 소켓에서 들어오는 SYN 패킷을 읽을 수는 있지만 여전히 클라이언트로부터 들어오는 SYN에 유효한 SYN/ACK 응답을 생성하는 데 문제가 있습니다.

누구나 SYN flooder를 만드는 것을 넘어서는 원시 소켓 사용에 관한 좋은 지침서를 알고 있습니까? 아니면 누군가 SOCK_RAW가 아닌 SOCK_STREAM을 사용하여 이렇게 할 수있는 코드를 가지고 있습니까? 나는 매우 감사하게 될 것입니다.


MarkR 절대적 권리 - 문제는 포트가 닫혀 생각 때문에 커널 초기 패킷에 응답하여 리셋 패킷을 전송된다는 것이다. 커널이 응답에 나를 때리고 연결이 끊어집니다. 나는 이미 연결을 모니터하기 위해 tcpdump를 사용하고 있었다. 나는 더주의 깊어 야했고 두 가지 응답 중 하나가 내 프로그램이 만든 응답뿐만 아니라 모든 것을 망쳐 놨던 리셋이라는 것을 알았다. 도 오!

가장 잘 작동하는 솔루션은 MarkR에서 제안한 iptables 규칙을 사용하여 아웃 바운드 패킷을 차단하는 것입니다. 그러나 제안 된 것처럼 마크 옵션을 사용하는 것보다 쉬운 방법이 있습니다. 난 그냥 리셋 TCP 플래그가 설정되어 있는지 여부와 일치합니다. 정상적인 연결 과정에서 이것이 필요하지는 않을 것입니다. 사용중인 포트에서 모든 아웃 바운드 리셋 패킷을 차단하면 내 응용 프로그램에는 별 문제가되지 않습니다. 이것은 효과적으로 커널의 원치 않는 응답을 차단하지만 내 패킷은 차단하지 않습니다.

iptables -t filter -I OUTPUT -p tcp --sport 9999 --tcp-flags RST RST -j DROP 

답변

1

내가 튜토리얼을 가지고 있지 않지만, 나는 최근에 내가 뭐하고 있었 일부 원시 소켓 프로그램을 디버깅하는 데 좋은 효과를 Wireshark를 사용 : 내 프로그램에서 수신 대기하는 포트가 9999 인 경우 다음의 iptables 규칙은 다음과 같습니다 . 전송하는 패킷을 캡처하는 경우 wireshark는 형식이 잘못되었거나 표시되지 않는 경우 잘 보여줄 것입니다. 이는 일반 연결과 비교할 때도 유용합니다.

2

나는 어떤 자습서도 당신을 도울 수 없다.

그러나 디버깅을 돕기 위해 사용할 수있는 도구에 대한 조언을 드릴 수 있습니다.

먼저 bmdhacks이 제안 했으므로 wireshark (또는 tcpdump -하지만 wireshark는 사용하기가 더 쉽습니다) 사본을 받으십시오. 좋은 악수를 포착하십시오. 이것을 저장하십시오.

실패한 핸드 셰이크 중 하나를 캡처하십시오. Wireshark는 패킷 분석과 오류 검사 기능이 뛰어나므로 직접적인 오류가 있다면 아마 알려줄 것입니다.

다음으로 자신에게 tcpreplay 사본을 가져 오십시오. 여기에는 "tcprewrite"라는 도구도 포함되어야합니다. tcprewrite를 사용하면 이전에 저장 한 캡처 파일을 핸드 셰이크의 각면에 대해 두 개로 나눌 수 있습니다. 그러면 tcpreplay를 사용하여 핸드 쉐이크의 한면을 재생할 수 있으므로 일관된 패킷 세트를 사용할 수 있습니다.

그런 다음 wireshark (다시)를 사용하여 응답을 확인하십시오.

9

사용자 공간에 TCP 스택의 일부를 구현하고 싶습니다 ... 괜찮습니다. 다른 응용 프로그램에서도이를 수행 할 수 있습니다.

커널에서 들어오는 패킷에 대한 응답 (일반적으로 부정적, 도움이되지 않음)이 전송된다는 문제가 하나 있습니다. 이것은 당신이 시작하려는 모든 통신을 망칠 것입니다.

이 문제를 피하는 한 가지 방법은 커널이 자체 IP 스택을 사용하지 않는 IP 주소와 인터페이스를 사용하는 것입니다. 괜찮습니다.하지만 링크 계층 항목 (특히 arp)을 직접 처리해야합니다. IPPROTO_IP, SOCK_RAW보다 낮은 소켓이 필요합니다. 패킷 소켓이 필요합니다 (필자는 생각합니다).

iptables 규칙을 사용하여 커널의 응답을 차단하는 것도 가능할 수 있습니다. 그러나 규칙이 다르게 처리되도록 관리 할 수 ​​없다면 규칙이 자신의 패킷에도 적용될 것으로 의심됩니다 (netfilter 자신의 패킷에 "표시"?)

(7) IP (7) 패킷 맨 페이지

소켓 읽기 (7) 유형에 적용되는 다양한 옵션과 ioctls에 대해 설명

소켓의.

물론 무슨 일이 일어나고 있는지 검사하려면 Wireshark와 같은 도구가 필요합니다. 이를 테스트하려면 여러 대의 컴퓨터가 필요합니다. 필요한 하드웨어의 양을 줄이기 위해 VM웨어 (또는 유사한)를 사용하는 것이 좋습니다.

죄송합니다. 특정 튜토리얼을 추천 할 수 없습니다.

행운을 빈다.

0

netinet/ip.h & netinet/tcp.h에 각각 선언 된 IP 및 TCP 헤더 구조가 있습니다. 이 디렉토리의 다른 헤더에서 추가 매크로 &을 찾아 볼 수 있습니다.

SYN 플래그가 설정된 패킷과 임의의 시퀀스 번호 (x)를 사용하여 패킷을 보냅니다. 다른 쪽에서 SYN + ACK를 받아야합니다. 이 패킷은 다른 측이 다른 시퀀스 번호 (z)뿐만 아니라 수신을 기대하고있는 다음 시퀀스 번호를 나타내는 확인 응답 번호 (y)를 가질 것이다. 연결을 완료하기 위해 시퀀스 번호 x + 1과 확인 번호 z + 1을 가진 ACK 패킷을 되돌려 보냅니다.

또한 적절한 TCP/IP 체크섬을 계산해야합니다. & 보내는 패킷의 나머지 헤더를 기입하십시오. 또한 호스트 & 네트워크 바이트 순서와 같은 것을 잊지 마십시오.

TCP 사용 가능한 여기, RFC 793에 정의되어 http://www.faqs.org/rfcs/rfc793.html

0

당신이 그것을 당신을 위해 TCP 핸드 쉐이크를 처리하는 기존의 소프트웨어를 다운로드하는 것이 더 쉬울 수도 있습니다 뭘 하려는지에 따라.

하나의 오픈 소스 IP 스택은 full tcp/ip 스택을 제공하는 lwIP (http://savannah.nongnu.org/projects/lwip/)입니다. SOCK_RAW 또는 pcap을 사용하여 사용자 모드에서 실행되도록하는 것이 가능합니다.

0

원시 소켓을 사용하는 경우 다른 소스 mac 주소를 사용하여 실제 주소로 보내면 Linux는 응답 패킷을 무시하고 처음을 보내지 않습니다.

+0

4 세의 질문이지만 귀하의 제안이 매우 흥미롭게 보입니다. 그래서 나는 당신에게 명확한 설명을하기로했습니다. 질문 : 잘못된 장치의 MAC 주소로 특정 컴퓨터에 응답 패킷을 라우팅하는 동안 라우터에 문제가 있습니까? 요즘 방화벽이나 바이러스 백신으로 패킷을 걸러 낼 수 있습니까? –

+0

스푸핑 된 MAC은 포트 보안을 위해 구성된 경우 스위치로 필터링 될 수 있습니다. MAC 계층에는 ACL이있을 수 있지만 일반적으로 MAC을 스푸핑하는 것을 막을 수있는 방법은 없습니다. 네트워크 카드가이 스푸핑 된 맥에 대한 대답을 수락 할 수 있도록하기 만하면됩니다 (맥을 수락 된 패킷 테이블에 추가하거나 promisc 모드로 넣음). 권한이없는 경우이 작업을 수행하는 것은 좋지 않은 생각입니다. – eckes

관련 문제