Re: Mimicking TCP connection

Hello Shai,

Maybe I did not explain it clearly...

1....

>2. Seems like the "solution" is to use a different IP address. But this 
>requires messing with the arp, which will require more time.

You will not have to do much.... just when you capture an ARP packet which 
asks for the MAC of IP you use in your program, reply with an ARP reply 
packet to the source MAC and IP of the packet you just captured. using 
libnet it is very easy.... you could actually do it in a seperate thread in 
which you only capture arp requests for your IP address....you start this 
thread at the beginning of your program and forget about it..... When you 
send the TCP packets, send it via LIBNET_RAW mode in order to save the 
headache of ARPing. The kernel will do it for you.

you could use a code similar to the below in your ARP reply thread:


       arp_hdr = (struct libnet_arp_hdr*)(pkt + LIBNET_ETH_H);

        if( ntohs(arp_hdr->ar_op) != ARPOP_REQUEST )
        {
            //printf("\nNot ARP-Req pkt");
            continue;
        }

       /*I made up this ARP header for IP ARPs
       struct arp_ip_hdr
       {
            u_char eth_addr_send[ETHER_ADDR_LEN];
            u_char ip_addr_send[4];
            u_char eth_addr_req[ETHER_ADDR_LEN];
            u_char ip_addr_req[4];
       };*/

        arp_info_ip = (struct arp_ip_hdr*)((u_char*)arp_hdr + LIBNET_ARP_H);


        //get IP addr of sender
        ip_addr_sender = (struct in_addr*)(arp_info_ip->ip_addr_send);

        //get IP requested
        ip_addr_requested = (struct in_addr*)(arp_info_ip->ip_addr_req);

        tag_arp = libnet_build_arp(ARPHRD_ETHER,
                                   ETHERTYPE_IP,
                                   ETHER_ADDR_LEN,
                                   4,
                                   ARPOP_REPLY,
                                   eth_addr_dev,
                                   (u_char*)ip_addr_requested,
                                   arp_info_ip->eth_addr_send,
                                   (u_char*)ip_addr_sender,
                                   NULL,
                                   0,
                                   l_handle,
                                   tag_arp);
        if( -1 == tag_arp )
        {
            fprintf(stderr,"\nError in libnet_build_arp(): %s", 
libnet_geterror(l_handle));
            return (void*)-1;
        }

        tag_eth = libnet_build_ethernet(arp_info_ip->eth_addr_send,
                                        eth_addr_dev,
                                        ETHERTYPE_ARP,
                                        NULL,
                                        0,
                                        l_handle,
                                        tag_eth);
        if( -1 == tag_eth )
        {
            fprintf(stderr,"\nError in libnet_build_ethernet(): %s", 
libnet_geterror(l_handle));
            return (void*)-1;
        }

        if( (count = libnet_write(l_handle)) == -1)
        {
            fprintf(stderr, "\nError in libnet_write: %s", 
libnet_geterror(l_handle));
            return (void*)-1;
        }
////////////////////////////////////////////////////
>3. I will try the iptables filter to drop outgoing packets that the kernel 
>produces. I wonder however, why an iptables filter will filter those 
>packets and not the packet I generate with libnet.
>
I am not so familiar with ip tables, but what I know is that you rather let 
the ip filter drop the incoming packets to prevent that hey reach the 
kernel... and thus prevent any response from it.

e.g: you send a TCP packet with source port 12345.. then define a rule which 
stops incoming packets with the dest. port 12345.. you will capture it with 
libpcap but it will not reach the kernel. (i did not try this but this is 
what i was told...)

P.S.. you could check the libpcap mailing list archieves or post your 
question there.. they will reply.

Regards,
Mustaffa

>From: Shai Rubin <[email protected]>
>To: Mustafa Abu Sedera <[email protected]>
>CC: [email protected]
>Subject: Re: Mimicking TCP connection
>Date: Sat, 07 Aug 2004 06:29:33 -0500
>
>All,
>Thank you for the replies. I will try them and let you know.
>Just few comments:
>
>1. Using a socket to open the connection. I tried that before. It does not 
>really solve the problem because after the handshake the kernel continues 
>to send  responses (acks) when a packet arrive. This interfere with my 
>"real" TCP connection.
>
>
>Thanks again,
>
>Shai
>
>
>Mustafa Abu Sedera wrote:
>>Hello there,
>>I had the same problem. I asked in the libpcap mailing list and got te 
>>following suggestions...
>>
>>1- use iptables rules to set up rules which prevent the packets -which you 
>>send the syns for-  from getting to the kernel
>>
>>2- send the packests from the interface using a different source ip than 
>>that of the interface but on the same network (use an unused ip on your 
>>lan). then sniff in promiscous mode, set up a libpcap filter to only 
>>capture packets destined to this new source ip you used and wait for the 
>>replies. like this you would have like 2 ips for the same interface...one 
>>for the kernel, which is the real ip of the interface, and the other, the  
>>"virtual" one is for your own usage without the kernel interfering.
>>
>>I hope you understood what I mean..
>>please ask me if you didn't.
>>regards,
>>Mustaffa Abu Sedira
>>
>>
>>>From: Shai Rubin <[email protected]>
>>>To: [email protected]
>>>Subject: Mimicking TCP connection
>>>Date: 6 Aug 2004 11:36:16 -0000
>>>
>>>
>>>
>>>Hi there,
>>>
>>>I try to use libpcap and libnet to write a program that will mimic a TCP 
>>>connection. In other words, my program performs TCP-handshake with a 
>>>remote machine, sends out some data, analyzes the data it receives from 
>>>the remote machine, and ends the TCP connection (i.e., FIN sequence).
>>>
>>>While I can capture and send packets, it seems that the Linux kernel 
>>>interfere with my program. For example, in the TCP-handshake procedure, 
>>>this is what happens:
>>>1.    I send a syn
>>>2.    I get back a synack.
>>>3.    I send the next ack, but the kernel sends out a reset (RST) packet 
>>>too (which ruin my handshake).
>>>
>>>
>>>It seems to me that the kernel “does not know” about the connection I’m 
>>>trying to establish. This seems logical to me because I never use the 
>>>“legal” interface (e.g., TCP-sockets) to establish this connection.
>>>
>>>How can I prevent the kernel from interfering with my program?
>>>
>>>Thanks,
>>>
>>>Shai Rubin
>>
>>
>>_________________________________________________________________
>>Protect your PC - get McAfee.com VirusScan Online 
>>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>>

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail